RFC: kpc2000 driver naming

[Matt Sickler]

>-----Original Message-----
>From: 'gregkh at linuxfoundation.org' <gregkh at linuxfoundation.org>
>On Sun, May 05, 2019 at 10:14:17PM +0000, Matt Sickler wrote:
>> The I2C and SPI drivers don't depend on anything other than the I2C
>> and SPI subsystems.  Actually, they might be depending on the kp2000
>> driver having the PCIe registers mapped into kernel space instead of doing
>> that themselves.
>> I'm not sure if that's the correct thing to do or not, so that might
>> be something to look closely at with all these drivers.
>
>Are all of these drivers needed for this hardware to work?  Should they even
>be separate drivers or should they all be mushed into one?  Can anyone do
>anything useful with just one of them?
>
>> Yes, all 4 drivers are required for proper functioning of the card.
>> SPI is used to reprogram the flash chips that store the FPGA
>> bitstream.  I2C is used for monitoring and programming clock
>> generators.  DMA is required for some parts of other cores.
>
>So should we just merge this into one driver at link time?  That would make
>more sense, right?

Yes.  All the drivers are required for the hardware to work.
In some sense, they "could" be used independently, but most likely only within
Daktronics hardware.  I guess if someone else had an FPGA design that needed a
SPI controller, they could reuse our driver as long as their FPGA implemented
a compatible SPI controller.

One thing I would be concerned with would be future FPGA designs that need to
mix-and-match.
For example (using new names), today we have the P2K card which uses the dak-p2k
main driver, and dak-i2c, dak-spi, and dak-dma "sub-drivers".
Perhaps the next generation hardware would need to use a new dak-p3k main driver
but can reuse the dak-i2c and dak-dma sub-drivers.  And maybe it needs a new
dak-spi-v2 driver (because something in the hardware changed in an incompatible
way).  This is all hypothetical though - it could range from complete driver
reuse to needing all new drivers for everything - we won't know for sure until
the new hardware designs ramp up in the next 6-12 months.

If there's a way to do link-time trickery to get all 4 drivers compiled into
one .ko, I'd be fine with that.  I do think it's a good idea to keep them at
least slightly separated to facilitate that mix-and-match scenario as well as
just ease of maintaining the code.