netdev - Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl

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: <20250212132229.GG17863@unreal>
Date: Wed, 12 Feb 2025 15:22:29 +0200
From: Leon Romanovsky <leon@...nel.org>
To: "Nelson, Shannon" <shannon.nelson@....com>
Cc: Jakub Kicinski <kuba@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
	Saeed Mahameed <saeedm@...dia.com>,
	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>, David Ahern <dsahern@...nel.org>,
	Andy Gospodarek <gospo@...adcom.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,
	Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl_bnxt

On Tue, Feb 11, 2025 at 10:36:37AM -0800, Nelson, Shannon wrote:
> On 2/10/2025 11:55 PM, Leon Romanovsky wrote:
> > 
> > On Mon, Feb 10, 2025 at 05:04:23PM -0800, Jakub Kicinski wrote:
> > > On Fri, 7 Feb 2025 21:16:47 -0400 Jason Gunthorpe wrote:
> > > > On Fri, Feb 07, 2025 at 01:51:11PM -0800, Jakub Kicinski wrote:
> > > > 
> > > > > But if you agree the netdev doesn't need it seems like a fairly
> > > > > straightforward way to unblock your progress.
> > > > 
> > > > I'm trying to understand what you are suggesting here.
> > > > 
> > > > We have many scenarios where mlx5_core spawns all kinds of different
> > > > devices, including recovery cases where there is no networking at all
> > > > and only fwctl. So we can't just discard the aux dev or mlx5_core
> > > > triggered setup without breaking scenarios.
> > > > 
> > > > However, you seem to be suggesting that netdev-only configurations (ie
> > > > netdev loaded but no rdma loaded) should disable fwctl. Is that the
> > > > case? All else would remain the same. It is very ugly but I could see
> > > > a technical path to do it, and would consider it if that brings peace.
> > > 
> > > Yes, when RDMA driver is not loaded there should be no access to fwctl.
> > 
> > There are users mentioned in cover letter, which need FWCTL without RDMA.
> > https://lore.kernel.org/all/0-v4-0cf4ec3b8143+4995-fwctl_jgg@nvidia.com/
> > 
> > I want to suggest something different. What about to move all XXX_core
> > logic (mlx5_core, bnxt_core, e.t.c.) from netdev to some other dedicated
> > place?
> > 
> > There is no technical need to have PCI/FW logic inside networking stack.
> > 
> > Thanks
> 
> Our pds_core device fits this description as well: it is not an ethernet PCI
> device, but helps manage the FW/HW for Eth and other things that are
> separate PCI functions.  We ended up in the netdev arena because we first
> went in as a support for vDPA VFs.
> 
> Should these 'core' devices live in linux-pci land?  Is it possible that
> some 'core' things might be platform devices rather than PCI?

IMHO, linux-pci was right place before FWCTL and auxbus arrived, but now
these core drivers can be placed in drivers/fwctl instead. It will be natural
place for them as they will be located near the UAPI which provides an access
to them.

All other components will be auxbus devices in their respective
subsystems (eth, RDMA ...).

Thanks

> 
> sln
> 
>