From: "Billie Alsup (balsup)" <balsup@cisco.com>
To: "kernelnewbies@kernelnewbies.org" <kernelnewbies@kernelnewbies.org>
Subject: Source code organization
Date: Mon, 17 Oct 2022 18:00:40 +0000 [thread overview]
Message-ID: <BYAPR11MB352706532B2F90F42FDE5BB2D9299@BYAPR11MB3527.namprd11.prod.outlook.com> (raw)
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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next reply other threads:[~2022-10-17 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 18:00 Billie Alsup (balsup) [this message]
2022-10-20 8:01 ` Source code organization Greg KH
2022-10-21 1:51 ` Billie Alsup (balsup)
2022-10-21 4:54 ` Greg KH
2022-10-21 15:45 ` Billie Alsup (balsup)
2024-04-23 4:10 ` auxiliary bus/drivers feature set versus platform/mfd Billie Alsup (balsup)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BYAPR11MB352706532B2F90F42FDE5BB2D9299@BYAPR11MB3527.namprd11.prod.outlook.com \
--to=balsup@cisco.com \
--cc=kernelnewbies@kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).