RFC: kpc2000 driver naming

'gregkh@linuxfoundation.org' gregkh at linuxfoundation.org
Mon May 6 15:16:25 UTC 2019

On Mon, May 06, 2019 at 02:38:16PM +0000, Matt Sickler wrote:
> >-----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.

Ok, keeping them separate is fine, just wanted to make sure, thanks,

greg k-h

More information about the devel mailing list