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 │
└─────────────────┘ └─────────────────┘ └───────────────────┘
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?
