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: <54781c0c-a1e7-4e97-acf1-1fc5a2ee548c@amd.com>
Date: Thu, 13 Mar 2025 12:59:16 -0700
From: "Nelson, Shannon" <shannon.nelson@....com>
To: Leon Romanovsky <leon@...nel.org>, David Ahern <dsahern@...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>,
 "Sinyuk, Konstantin" <konstantin.sinyuk@...el.com>
Subject: Re: [PATCH v5 0/8] Introduce fwctl subystem

On 3/13/2025 5:48 AM, Leon Romanovsky wrote:
> On Thu, Mar 13, 2025 at 01:30:52PM +0100, David Ahern wrote:


>> 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.

Between the two of these I prefer drivers/core - I don't want to see 
this tied to aux for the same reasons we don't want it tied to pci or net.

sln