Messages in this thread | | | Date | Mon, 29 Apr 2024 19:36:41 -0600 | Subject | Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver | From | David Ahern <> |
| |
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
| |