Received-SPF: pass (google.com: domain of linux-kernel+bounces-163235-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <2d6b0455-4d82-4bed-93f1-40255641548e@kernel.org>
Date: Mon, 29 Apr 2024 19:36:41 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver
Content-Language: en-US
To: Jason Gunthorpe <jgg@nvidia.com>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@infradead.org>, Saeed Mahameed <saeed@kernel.org>,
 Arnd Bergmann <arnd@arndb.de>, Leon Romanovsky <leonro@nvidia.com>,
 Jiri Pirko <jiri@nvidia.com>, Leonid Bloch <lbloch@nvidia.com>,
 Itay Avraham <itayavr@nvidia.com>, Jakub Kicinski <kuba@kernel.org>,
 Saeed Mahameed <saeedm@nvidia.com>,
 Aron Silverton <aron.silverton@oracle.com>, linux-kernel@vger.kernel.org,
 Andy Gospodarek <andrew.gospodarek@broadcom.com>
References: <20240207072435.14182-1-saeed@kernel.org>
 <Zcx53N8lQjkpEu94@infradead.org>
 <ZczntnbWpxUFLxjp@C02YVCJELVCG.dhcp.broadcom.net>
 <20240214175735.GG1088888@nvidia.com> <20240304160237.GA2909161@nvidia.com>
From: David Ahern <dsahern@kernel.org>
In-Reply-To: <20240304160237.GA2909161@nvidia.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 3/4/24 9:02 AM, Jason Gunthorpe wrote:
> On Wed, Feb 14, 2024 at 01:57:35PM -0400, Jason Gunthorpe wrote:
> 
>> I also like this, I don't want the outcome of this discussion to be
>> that only mlx5ctl gets merged. I want all the HW that has this problem
>> to have support in the mainline kernel.
> 
> To this end here is my proposal to move forward with a new
> mini-subsystem to provide rules for this common approach. Get the
> existing tools out of hacky unstructured direct hardware access via
> /sys/XX and into a formalized lockdown compatible system. I've talked
> to enough people now to think we have a critical mass.
> 
> ===============
> fwctl subsystem
> ===============


The aux bus infrastructure was created specifically for multifunction
devices -- it allows a core PCI device driver with smaller, subsystem
focused drivers for vendor specific implementations of various S/W stack
APIs (IB, netdev, etc). One aspect not addressed in that design is where
to park the various drivers and extensions that are not solely tied to
any one subsystem.

Given, that how about moving the existing auxbus code into a new
directory, drivers/auxbus. From there, create a subdirectory for this
new fwctl subsystem which is most likely to be realized as a new auxbus
device and then subdirectories for vendor specific drivers for the aux
bus device. Then new drivers being developed in this auxbus world can
put the core PCI device handling code under drivers/auxbus/core.

In short:
- drivers/auxbus/auxiliary.c

- drivers/auxbus/core/<vendor>/  - per h/w device driver for managing
the PCI device which is shared across multiple auxbus devices

- drivers/auxbus/fwctl/fwctl.c   - this FW interface

- drivers/auxbus/fwctl/<vendor>/ - vendor specific driver for a fwctl
auxbus device