--- On Thu, 8/26/10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
If there are "zillions" that suggests the HW
engineers have version/naming issues just like
certain software engineers. Only goes to show
how close Verilog and VHDL are to software! :)
My suggestion was to use the name provided/used
by the hardware engineers. (E.g. whatever the
Verilog or VHDL equivalent of a module name is.)
So -- NO RENAME -- except for the driver.
If I understand you correctly, those engineers
are not reusing a named module; they are at best
just copying/pasting some Verilog/VHDL and adding
ASIC/SoC/.../FPGA-specific hacks. (Which calls into
question just how much assurance there can be that
one driver will work reliably for all instances...
Someone should have a few words with those hardware
engineers about module naming and consistency, so
software doesn't need to work around such issues.
Such problems have been solved for decades, and
there's no reason to create confusion higher up
the system stack. (or force workarounds.)
Note that such names are already used in Linux
with IP blocks from AMBA; Designware blocks, as
I noted, aren't dissimilar (dw_foo.c in at least
a few cases).
That's a much better name. I'ts got technical
content, even! (vs "simple" being "marketing",
including easy confusion with other entities).
All I'll say is that it might
be *too* generic a name. I know I can come up
with current examples of GPIO done via MMIO
(tables) that this driver won't fit at all.
That can probably be worked around via docs and
conventions.
There'd need to be good docs on what this
gpio-mmio-table interface expects. Some of that
belongs in Kconfig, not much; mostly I'd think
it belongs in driver header comments, but also
some in the patch comment itself. I hear you
strongly implying that there's no generic hardware
doc to reference. (As theree would be if this
block came from the AMBA or DesignWare families.)
--
