Source code organization

Billie Alsup (balsup) balsup at cisco.com
Mon Oct 17 14:00:40 EDT 2022


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.

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.




More information about the Kernelnewbies mailing list