Re: Source code organization

[Greg KH <greg@kroah.com>]

On Mon, Oct 17, 2022 at 06:00:40PM +0000, Billie Alsup (balsup) wrote:
> I have a set of drivers that I would like to upstream.  These are primarily
> MFD style drivers supporting Cisco-8000 FPGAs.  The devices can be
> instantiated through multiple top level drivers, which provide the access
> mechanism for the MFD driver.  For example, an FPGA can be accessed via
> PCI, or via i2c, or via SLPC, or via P2PM (a point-to-point interface).  We
> currently build these drivers out of tree, under a single directory drivers/cisco.
> I note that existing drivers are spread out across the kernel tree, sometimes
> by bus (pci, i2c), sometimes by function (gpio, net/mdio, spi), and sometimes
> under the generic mfd.

Yes, it's not always easy to find the common pattern, but usually it is:
	- is this a bus driver that allows bus access to this hardware
	  (pci, gpio, i2c)?  If so, add to drivers/pci|gpio|i2c
	- is this a userspace-facing driver that implements a user
	  "class" of interactions (input, HID, block, etc.).  If so, add
	  to drivers/input|hid|block
	- is this something else?  Then pick a place and submit a patch
	  and people will tell you if you got it wrong :)

> I would like to start the upstream review process for our drivers, but first want
> to get recommendations on the source code layout.  Is it permissible to keep
> a top level directory such as drivers/cisco to organize our code?  It is not only
> the source code that is affected, but also provides a central place for Kconfig
> entries.  Our FPGAs have multiple logical blocks, each of which is handled by
> a different MFD driver, e.g. i2c controllers, gpio controllers, spi controllers, mdio
> controllers.  There can be multiple instances of each block as well (so multiple
> MFD devices are instantiated for each driver).  And of course, there can be
> multiple FPGAs in a system, each with different combinations of logical blocks.  
> 
> The drivers themselves are pretty specific to our FPGAs, thus it makes sense to
> use Kconfig to select a hardware platform to automatically select the set of MFD
> drivers (and top level bus drivers) that would apply. 
> 
> Would a source layout putting all the code under drivers/cisco be acceptable in
> this case, or do I need to move things around and spread out the Kconfig entries
> across directories? I note that a single drivers/cisco would simplify any related
> modifications to MAINTAINERS as well.

No, we do not have "vendor" directories like this, as that's almost
always not what you want over time anyway.  Just scatter your drivers
around the tree based on the type and the subsystem interactions you
need to have.

But step back, why are you creating MFD devices anyway?  Why not make
"real" devices in your hardware representation as you control the FPGA
and DT definitions, right?  That would make things much easier if you
put the devices on a discoverable bus then the drivers can be autoloaded
as needed by the kernel when they are discovered.

Do that, then you can put your fpga interface in drivers/fpga :)

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies