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: >> On Tue, 4 Mar 2025 10:00:36 -0400 Jason Gunthorpe wrote: >> > I never agreed to that formulation. I suggested that perhaps runtime >> > configurations where netdev is the only driver using the HW could be >> > disabled (ie a netdev exclusion, not a rdma inclusion). >> >> 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. It's not always simple to find clear cut though. Like for example devlink and representors code related to eswitch orchestration. The benefit would be that lots of core-related non-netdev patch-trafic would go directly, which would ease the netdev maintainership burden and would make things more flexible. This per-driver-serialization for patchset processing bottleneck would become much more bareable.
