netdev - Re: [PATCH v5 0/8] Introduce fwctl subystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dc72c6fe-4998-4dba-9442-73ded86470f5@kernel.org>
Date: Thu, 13 Mar 2025 13:30:52 +0100
From: David Ahern <dsahern@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jiri Pirko <jiri@...nulli.us>, Jason Gunthorpe <jgg@...dia.com>,
 Jakub Kicinski <kuba@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>,
 Aron Silverton <aron.silverton@...cle.com>,
 Dan Williams <dan.j.williams@...el.com>,
 Daniel Vetter <daniel.vetter@...ll.ch>, Dave Jiang <dave.jiang@...el.com>,
 Christoph Hellwig <hch@...radead.org>, Itay Avraham <itayavr@...dia.com>,
 Jiri Pirko <jiri@...dia.com>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, Leonid Bloch <lbloch@...dia.com>,
 linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org,
 netdev@...r.kernel.org, Saeed Mahameed <saeedm@...dia.com>,
 "Nelson, Shannon" <shannon.nelson@....com>,
 "Sinyuk, Konstantin" <konstantin.sinyuk@...el.com>
Subject: Re: [PATCH v5 0/8] Introduce fwctl subystem

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@...dia.com 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?