On Thu, Mar 13, 2025 at 01:30:52PM +0100, David Ahern wrote: > On 3/5/25 7:28 PM, Leon Romanovsky wrote: > > On Wed, Mar 05, 2025 at 11:17:19AM -0700, David Ahern wrote: > >> On 3/5/25 8:08 AM, Jiri Pirko wrote: > >>> Wed, Mar 05, 2025 at 02:32:54PM +0100, jgg@xxxxxxxxxx wrote: > >>>> On Tue, Mar 04, 2025 at 04:42:03PM -0800, Jakub Kicinski wrote: > >>>>> I thought you were arguing that me opposing the addition was > >>>>> "maintainer overreach". As in me telling other parts of the kernel > >>>>> what is and isn't allowed. Do I not get a say what gets merged under > >>>>> drivers/net/ now? > >>>> > >>>> The PCI core drivers are a shared resource jointly maintained by all > >>>> the subsytems that use them. They are maintained by their respective > >>>> maintainers. Saeed/etc in this case. > >>>> > >>>> It would be inappropriate for your preferences to supersede Saeed's > >>>> when he is a maintainer of the mlx5_core driver and fwctl. Please try > >>>> and get Saeed on board with your plan. > >>>> > >>>> If the placement under drivers/net makes this confusing then we can > >>>> certainly change the directory names. > >>> > >>> According to how mlx5 driver is structured, and the rest of the advanced > >>> drivers in the same area are becoming as well, it would make sense to me > >>> to have mlx5 core in separate core directory, maintained directly by driver > >>> maintainer: > >>> drivers/core/mlx5/ > >>> then each of the protocol auxiliary device lands in appropriate > >>> subsystem directory. > >> > >> +1 > >> > >> This is how I have structured our drivers -- core driver for owning the > >> PCI device and hosting the APIs to communicate with hardware, an aux bus > >> and then smaller subsystem focused drivers for the aux devices that make > >> the device usable from different contexts. > >> > >> I think we are ready to start upstreaming, but I am waiting to see how > >> this falls out - to see if our core driver can land in a non-subsystem > >> specific location (e.g., drivers/core) or if it needs to go with fwctl > >> as a generic location. > > > > Do it right, and push it to drivers/core. I'm aware of at least one > > driver from huge company (not Nvidia) which is in preparation phase > > before upstreaming, and will fit nicely into this model. > > > > They have separated blocks for PCI, eth, RDMA and GPU. > > > > Adding that group here after an offlist discussion with that team. If I > understand correctly, their preferred driver breakout is: > > > ┌───────────────────────────────────────────────────────────┐ > │ Platform Driver │ > │ habanalabs │ > └────────▲───────────────────▲────────────────────▲─────────┘ > │AUX │AUX │AUX > ┌────────┴────────┐ ┌────────┴────────┐ ┌─────────┴─────────┐ > │ Accel Driver │ │ Ethernet Driver │ │ InfiniBand Driver │ > │ habanalabs_accel│ │ habanalabs_en │ │ habanalabs_ib │ > └─────────────────┘ └─────────────────┘ └───────────────────┘ You got it right. > > So that means 3 different vendors and 3 different devices looking for a > similar auxbus based hierarchy with a core driver not buried within one > of the subsystems. > > I guess at this point we just need to move forward with the proposal and > start sending patches. > > Seems like drivers/core is the consensus for the core driver? Yes, anything that is not aux_core is fine by me. drivers/core or drivers/aux. Thanks >
