Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Tue, Jan 05, 2021 at 10:36:27AM -0400, Jason Gunthorpe wrote: > On Tue, Jan 05, 2021 at 01:42:56PM +, Mark Brown wrote: > > You're missing the point there. I2C is enumerated by firmware in > > exactly the same way as the platform bus is, it's not discoverable from > > the hardware (and similarly for a bunch of other buses). If we were to > No, I understand how I2C works and I think it is fine as is because > the enumeration outcome is all standard. You always end up with a > stable I2C device address (the name) and you always end up with the > I2C programming API. So it doesn't matter how I2C gets enumerated, it > is always an I2C device. I don't follow this logic at all, sorry - whatever the platonic ideal of what a platform device actually turns out to be when we get down to using the hardware it's the same hardware which we interact with in the same way no matter how we figured out that it was present. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Tue, Jan 05, 2021 at 01:42:56PM +, Mark Brown wrote: > On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote: > > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote: > > > > Like I keep saying the same thing applies to all non-enumerable buses - > > > exactly the same considerations exist for all the other buses like I2C > > > (including the ACPI naming issue you mention below), and for that matter > > > with enumerable buses which can have firmware info. > > > And most busses do already have their own bus type. ACPI, I2C, PCI, > > etc. It is just a few that have been squished into platform, notably > > OF. > > You're missing the point there. I2C is enumerated by firmware in > exactly the same way as the platform bus is, it's not discoverable from > the hardware (and similarly for a bunch of other buses). If we were to > say that we need separate device types for platform devices enumerated > using firmware then by analogy we should do the same for devices on > these other buses that happen to be enumerated by firmware. No, I understand how I2C works and I think it is fine as is because the enumeration outcome is all standard. You always end up with a stable I2C device address (the name) and you always end up with the I2C programming API. So it doesn't matter how I2C gets enumerated, it is always an I2C device. PCI does this too, pci_device gets crossed over to the DT data, but it is still a pci_device. I see a big difference between attaching FW data to an existing subsystem's HW centric bus (and possibly guiding enumeration of a HW bus from FW data) and directly creating struct devices based on FW data unconnected to any existing subsystem. The latter case is where the enumerating FW should stay on its own bus_type because there is no standardized subsystem bus providing an API or naming rules, so the FW type should provide those rules instead. > > With an actual bus specific virtual function: > > > return dev->bus->gpio_count(dev); > > That won't work, you might have a mix of enumeration types for a given > bus type in a single system so you'd need to do this per device. I'm being very general here, probably what we want is a little more formal 'fw_type' concept, so a device is on a bus and also has a FW attachment which can provide this other data. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > Like I keep saying the same thing applies to all non-enumerable buses -
> > exactly the same considerations exist for all the other buses like I2C
> > (including the ACPI naming issue you mention below), and for that matter
> > with enumerable buses which can have firmware info.
> And most busses do already have their own bus type. ACPI, I2C, PCI,
> etc. It is just a few that have been squished into platform, notably
> OF.
You're missing the point there. I2C is enumerated by firmware in
exactly the same way as the platform bus is, it's not discoverable from
the hardware (and similarly for a bunch of other buses). If we were to
say that we need separate device types for platform devices enumerated
using firmware then by analogy we should do the same for devices on
these other buses that happen to be enumerated by firmware.
I'm not convinced this is actually the design that's being pushed by
Greg here, to the extent anything is being actively pushed.
> But now it begs the question, why not push harder to make 'struct
> device' the generic universal access point and add some resource_get()
> API along these lines so even a platform_device * isn't needed?
We still need a struct device of some kind so the discussions about
exactly which bus type one is supposed to use in which circumstances
remain given that you're not supposed to have raw struct devices.
> Then the path seems much clearer, add a multi-bus-type device_driver
> that has a probe(struct device *) and uses the 'universal api_get()'
> style interface to find the generic 'resources'.
That's exactly how things like mixed I2C/SPI devices work at present,
given that they can usually use regmap to hide register I/O.
> int gpiod_count(struct device *dev, const char *con_id)
> {
> int count = -ENOENT;
> if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> count = of_gpio_get_count(dev, con_id);
> else if (IS_ENABLED(CONFIG_ACPI) && dev && ACPI_HANDLE(dev))
> count = acpi_gpio_count(dev, con_id);
>
> if (count < 0)
> count = platform_gpio_count(dev, con_id);
> With an actual bus specific virtual function:
> return dev->bus->gpio_count(dev);
That won't work, you might have a mix of enumeration types for a given
bus type in a single system so you'd need to do this per device. It's
also not clear to me that it is useful to spread things out like this,
it makes it more hassle to add new APIs since you have to change core
code.
signature.asc
Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 04, 2021 at 07:12:47PM -0800, Dan Williams wrote: > I get that, but I'm fearing a gigantic bus_ops structure that has > narrow helpers like ->gpio_count() that mean nothing to the many other > clients of the bus. Maybe I'm overestimating the pressure there will > be to widen the ops structure at the bus level. If we want a 'universal device' then that stuff must live someplace.. Open coding the dispatch as is today is also not the end of the world, just seeing that is just usually a sign something is not ideal with the object model. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 4, 2021 at 5:53 PM Jason Gunthorpe wrote: > > On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote: > > On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote: > > > > > > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote: > > > > > > > > > > > Regardless of the shortcut to make everything a struct > > > > > platform_device, I think it was a mistake to put OF devices on > > > > > platform_bus. Those should have remained on some of_bus even if they > > > > > > > > Like I keep saying the same thing applies to all non-enumerable buses - > > > > exactly the same considerations exist for all the other buses like I2C > > > > (including the ACPI naming issue you mention below), and for that matter > > > > with enumerable buses which can have firmware info. > > > > > > And most busses do already have their own bus type. ACPI, I2C, PCI, > > > etc. It is just a few that have been squished into platform, notably > > > OF. > > > > > > > I'll note that ACPI is an outlier that places devices on 2 buses, > > where new acpi_driver instances are discouraged [1] in favor of > > platform_drivers. ACPI scan handlers are awkwardly integrated into the > > Linux device model. > > > > So while I agree with sentiment that an "ACPI bus" should > > theoretically stand on its own there is legacy to unwind. > > > > I only bring that up to keep the focus on how to organize drivers > > going forward, because trying to map some of these arguments backwards > > runs into difficulties. > > > > [1]: > > http://lore.kernel.org/r/cajz5v0j_rek3agddw7flvmw_7kneccg2u_hukgjzqelcy8s...@mail.gmail.com > > Well, this is the exact kind of thing I think we are talking about > here.. > > > > It should be split up based on the unique naming scheme and any bus > > > specific API elements - like raw access to ACPI or OF data or what > > > have you for other FW bus types. > > > > I agree that the pendulum may have swung too far towards "reuse > > existing bus_type", and auxiliary-bus unwinds some of that, but does > > the bus_type really want to be an indirection for driver apis outside > > of bus-specific operations? > > If the bus is the "enumeration entity" and we define that things like > name, resources, gpio's, regulators, etc are a generic part of what is > enumerated, then it makes sense that the bus would have methods > to handle those things too. > > In other words, the only way to learn what GPIO 'resource' is to ask > the enumeration mechnism that is providing the bus. If the enumeration > and bus are 1:1 then you can use a function pointer on the bus type > instead of open coding a dispatch based on an indirect indication. > I get that, but I'm fearing a gigantic bus_ops structure that has narrow helpers like ->gpio_count() that mean nothing to the many other clients of the bus. Maybe I'm overestimating the pressure there will be to widen the ops structure at the bus level.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote: > On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote: > > > > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote: > > > > > > > > Regardless of the shortcut to make everything a struct > > > > platform_device, I think it was a mistake to put OF devices on > > > > platform_bus. Those should have remained on some of_bus even if they > > > > > > Like I keep saying the same thing applies to all non-enumerable buses - > > > exactly the same considerations exist for all the other buses like I2C > > > (including the ACPI naming issue you mention below), and for that matter > > > with enumerable buses which can have firmware info. > > > > And most busses do already have their own bus type. ACPI, I2C, PCI, > > etc. It is just a few that have been squished into platform, notably > > OF. > > > > I'll note that ACPI is an outlier that places devices on 2 buses, > where new acpi_driver instances are discouraged [1] in favor of > platform_drivers. ACPI scan handlers are awkwardly integrated into the > Linux device model. > > So while I agree with sentiment that an "ACPI bus" should > theoretically stand on its own there is legacy to unwind. > > I only bring that up to keep the focus on how to organize drivers > going forward, because trying to map some of these arguments backwards > runs into difficulties. > > [1]: > http://lore.kernel.org/r/cajz5v0j_rek3agddw7flvmw_7kneccg2u_hukgjzqelcy8s...@mail.gmail.com Well, this is the exact kind of thing I think we are talking about here.. > > It should be split up based on the unique naming scheme and any bus > > specific API elements - like raw access to ACPI or OF data or what > > have you for other FW bus types. > > I agree that the pendulum may have swung too far towards "reuse > existing bus_type", and auxiliary-bus unwinds some of that, but does > the bus_type really want to be an indirection for driver apis outside > of bus-specific operations? If the bus is the "enumeration entity" and we define that things like name, resources, gpio's, regulators, etc are a generic part of what is enumerated, then it makes sense that the bus would have methods to handle those things too. In other words, the only way to learn what GPIO 'resource' is to ask the enumeration mechnism that is providing the bus. If the enumeration and bus are 1:1 then you can use a function pointer on the bus type instead of open coding a dispatch based on an indirect indication. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
>
> On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
>
>
> > > Regardless of the shortcut to make everything a struct
> > > platform_device, I think it was a mistake to put OF devices on
> > > platform_bus. Those should have remained on some of_bus even if they
> >
> > Like I keep saying the same thing applies to all non-enumerable buses -
> > exactly the same considerations exist for all the other buses like I2C
> > (including the ACPI naming issue you mention below), and for that matter
> > with enumerable buses which can have firmware info.
>
> And most busses do already have their own bus type. ACPI, I2C, PCI,
> etc. It is just a few that have been squished into platform, notably
> OF.
>
I'll note that ACPI is an outlier that places devices on 2 buses,
where new acpi_driver instances are discouraged [1] in favor of
platform_drivers. ACPI scan handlers are awkwardly integrated into the
Linux device model.
So while I agree with sentiment that an "ACPI bus" should
theoretically stand on its own there is legacy to unwind.
I only bring that up to keep the focus on how to organize drivers
going forward, because trying to map some of these arguments backwards
runs into difficulties.
[1]:
http://lore.kernel.org/r/cajz5v0j_rek3agddw7flvmw_7kneccg2u_hukgjzqelcy8s...@mail.gmail.com
> > > are represented by struct platform_device and fiddling in the core
> > > done to make that work OK.
> >
> > What exactly is the fiddling in the core here, I'm a bit unclear?
>
> I'm not sure, but I bet there is a small fall out to making bus_type
> not 1:1 with the struct device type.. Would have to attempt it to see
>
> > > This feels like a good conference topic someday..
> >
> > We should have this discussion *before* we get too far along with trying
> > to implement things, we should at least have some idea where we want to
> > head there.
>
> Well, auxillary bus is clearly following the original bus model
> intention with a dedicated bus type with a controlled naming
> scheme. The debate here seems to be "what about platform bus" and
> "what to do with mfd"?
>
> > Those APIs all take a struct device for lookup so it's the same call for
> > looking things up regardless of the bus the device is on or what
> > firmware the system is using - where there are firmware specific lookup
> > functions they're generally historical and shouldn't be used for new
> > code. It's generally something in the form
> >
> > api_type *api_get(struct device *dev, const char *name);
>
> Well, that is a nice improvement since a few years back when I last
> worked on this stuff.
>
> But now it begs the question, why not push harder to make 'struct
> device' the generic universal access point and add some resource_get()
> API along these lines so even a platform_device * isn't needed?
>
> Then the path seems much clearer, add a multi-bus-type device_driver
> that has a probe(struct device *) and uses the 'universal api_get()'
> style interface to find the generic 'resources'.
>
> The actual bus types and bus structs can then be split properly
> without the boilerplate that caused them all to be merged to platform,
> even PCI could be substantially merged like this.
>
> Bonus points to replace the open coded method disptach:
>
> int gpiod_count(struct device *dev, const char *con_id)
> {
> int count = -ENOENT;
>
> if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> count = of_gpio_get_count(dev, con_id);
> else if (IS_ENABLED(CONFIG_ACPI) && dev && ACPI_HANDLE(dev))
> count = acpi_gpio_count(dev, con_id);
>
> if (count < 0)
> count = platform_gpio_count(dev, con_id);
>
> With an actual bus specific virtual function:
>
> return dev->bus->gpio_count(dev);
>
> > ...and then do the same thing for every other bus with firmware
> > bindings. If it's about the firmware interfaces it really isn't a
> > platform bus specific thing. It's not clear to me if that's what it is
> > though or if this is just some tangent.
>
> It should be split up based on the unique naming scheme and any bus
> specific API elements - like raw access to ACPI or OF data or what
> have you for other FW bus types.
I agree that the pendulum may have swung too far towards "reuse
existing bus_type", and auxiliary-bus unwinds some of that, but does
the bus_type really want to be an indirection for driver apis outside
of bus-specific operations?
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > Regardless of the shortcut to make everything a struct
> > platform_device, I think it was a mistake to put OF devices on
> > platform_bus. Those should have remained on some of_bus even if they
>
> Like I keep saying the same thing applies to all non-enumerable buses -
> exactly the same considerations exist for all the other buses like I2C
> (including the ACPI naming issue you mention below), and for that matter
> with enumerable buses which can have firmware info.
And most busses do already have their own bus type. ACPI, I2C, PCI,
etc. It is just a few that have been squished into platform, notably
OF.
> > are represented by struct platform_device and fiddling in the core
> > done to make that work OK.
>
> What exactly is the fiddling in the core here, I'm a bit unclear?
I'm not sure, but I bet there is a small fall out to making bus_type
not 1:1 with the struct device type.. Would have to attempt it to see
> > This feels like a good conference topic someday..
>
> We should have this discussion *before* we get too far along with trying
> to implement things, we should at least have some idea where we want to
> head there.
Well, auxillary bus is clearly following the original bus model
intention with a dedicated bus type with a controlled naming
scheme. The debate here seems to be "what about platform bus" and
"what to do with mfd"?
> Those APIs all take a struct device for lookup so it's the same call for
> looking things up regardless of the bus the device is on or what
> firmware the system is using - where there are firmware specific lookup
> functions they're generally historical and shouldn't be used for new
> code. It's generally something in the form
>
> api_type *api_get(struct device *dev, const char *name);
Well, that is a nice improvement since a few years back when I last
worked on this stuff.
But now it begs the question, why not push harder to make 'struct
device' the generic universal access point and add some resource_get()
API along these lines so even a platform_device * isn't needed?
Then the path seems much clearer, add a multi-bus-type device_driver
that has a probe(struct device *) and uses the 'universal api_get()'
style interface to find the generic 'resources'.
The actual bus types and bus structs can then be split properly
without the boilerplate that caused them all to be merged to platform,
even PCI could be substantially merged like this.
Bonus points to replace the open coded method disptach:
int gpiod_count(struct device *dev, const char *con_id)
{
int count = -ENOENT;
if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
count = of_gpio_get_count(dev, con_id);
else if (IS_ENABLED(CONFIG_ACPI) && dev && ACPI_HANDLE(dev))
count = acpi_gpio_count(dev, con_id);
if (count < 0)
count = platform_gpio_count(dev, con_id);
With an actual bus specific virtual function:
return dev->bus->gpio_count(dev);
> ...and then do the same thing for every other bus with firmware
> bindings. If it's about the firmware interfaces it really isn't a
> platform bus specific thing. It's not clear to me if that's what it is
> though or if this is just some tangent.
It should be split up based on the unique naming scheme and any bus
specific API elements - like raw access to ACPI or OF data or what
have you for other FW bus types.
Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Jan 04, 2021 at 02:08:31PM -0400, Jason Gunthorpe wrote: > On Mon, Dec 21, 2020 at 06:51:40PM +, Mark Brown wrote: > > BTW I did have a bit of a scan through some of the ACPI devices and > > for a good proportion of them it seems fairly clear that they are > > not platform devices at all - they were mostly interacting with ACPI > > firmware functionality rather than hardware, something you can't > > really do with FDT at all. > Right, that is kind of the point. We also have cases where ACPI > devices are just an ioresource list and don't have any special > ACPIness. IIRC DT has a similar issue where there are DT drivers that > just don't work without the OF stuff. Why are they platform drivers? There *might* be some very legacy ones for actual OF systems but that's not really at all a thing for FDT which is essentially all DT usage at this point - to the extent that things won't work it's due to the non-enumarability of the hardware so it's just a question of where the data comes from rather than one of communicating with a firmware (and for more generic things like GPIOs exactly where the data comes from ends up abstracted away from the driver anyway which is all some devices need). The idiom with DT is more that it's just a different way of filling out the data you'd get from a board file, it's not a runtime thing like ACPI. > We fake this idea out by being able to convert platform to DT and OF, > but if platform is to be the universal device then why do we have PCI > device and not a 'platform to pci' operator instead? None of this is > consistent. If it were more common for there to be IPs that appear as both PCI and platform devices (Intel do it a bit but otherwise it's quite rare) I'd guess we would actually have helpers for that translation. > Regardless of the shortcut to make everything a struct > platform_device, I think it was a mistake to put OF devices on > platform_bus. Those should have remained on some of_bus even if they Like I keep saying the same thing applies to all non-enumerable buses - exactly the same considerations exist for all the other buses like I2C (including the ACPI naming issue you mention below), and for that matter with enumerable buses which can have firmware info. > are represented by struct platform_device and fiddling in the core > done to make that work OK. What exactly is the fiddling in the core here, I'm a bit unclear? > I agree with this, IMHO there is no really cohesive explanation for > when to create a bus vs use the "universal bus" (platform) that can > also explain the things platform is already doing. > This feels like a good conference topic someday.. We should have this discussion *before* we get too far along with trying to implement things, we should at least have some idea where we want to head there. > > Personally I'm even struggling to identify a practical problem that > > we're trying to solve here. Like Alexandre says what would an > > mfd_driver actually buy us? > Well, there is the minor issue of name collision eg > /sys/bus/XX/devices/* must list all devices in the system with no > collisions. > The owner of the bus is supposed to define the stable naming scheme > and all the devices are supposed to follow it. platform doesn't have > this: > $ ls /sys/bus/platform/devices/ > ACPI000C:00 dell-smbios.0 'Fixed MDIO bus.0' INT33A1:00 > microcode PNP0C04:00 PNP0C0B:03 PNP0C14:00 > alarmtimer.0.auto dell-smbios.1 GHES.0 intel_rapl_msr.0 > MSFT0101:00 PNP0C0B:00 PNP0C0B:04 PNP0C14:01 > coretemp.0efi-framebuffer.0 GHES.1 iTCO_wdt > pcspkrPNP0C0B:01 PNP0C0C:00 reg-dummy > dcdbaseisa.0 INT0800:00 kgdboc > PNP0103:00PNP0C0B:02 PNP0C0E:00 serial8250 > Why are ACPI names in here? It looks like "because platform drivers > were used to bind to ACPI devices" I think we decided that the ACPI namespace was sufficiently divergent from our general conventions that we could just safely use the string, ICBW though. > > I have some bad news for you about the hardware description problem > > space. Among other things we have a bunch of platform devices that > > don't have any resources exposed through the resource API but are still > > things like chips on a board, doing some combination of exposing > > resources for other devices (eg, a fixed voltage regulator) and > > consuming things like clocks or GPIOs that don't appear in the resource > > API. > So in these cases how do I use the generic platform bus API to find > the GPIOs, regulators, and so on to connect with? > If drivers take a platform device and immediately covert it to an OF > object and use OF APIs to find those connections then it really > *never* was a platform device in the first place and coding an OF > driver as platform is an abuse. Those APIs all take a struct device for lookup so it's the
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Mon, Dec 21, 2020 at 06:51:40PM +, Mark Brown wrote: > > with some kind of inheritance scheme where platform device remained as > > only instantiated directly in board files, while drivers could bind to > > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication & > > boilerplate. > > Like I said in my previous message that is essentially what we have now. > It's not worded in quite that way but it's how all the non-enumerable > buses work. I think it is about half way there. We jammed everything into platform device and platform bus and then had a few api aspects to tell if which of the subtypes it might be. That functions sort of like an object model with inheritance, but a single type and 'is it a XXX' queries is not quite the same thing. > BTW I did have a bit of a scan through some of the ACPI devices and > for a good proportion of them it seems fairly clear that they are > not platform devices at all - they were mostly interacting with ACPI > firmware functionality rather than hardware, something you can't > really do with FDT at all. Right, that is kind of the point. We also have cases where ACPI devices are just an ioresource list and don't have any special ACPIness. IIRC DT has a similar issue where there are DT drivers that just don't work without the OF stuff. Why are they platform drivers? IMHO the point of the bus type is to tell the driver what API set you have. If you have a of_device then you have an OF node and can do all the of operations. Same for PCI/ACPI/etc. We fake this idea out by being able to convert platform to DT and OF, but if platform is to be the universal device then why do we have PCI device and not a 'platform to pci' operator instead? None of this is consistent. Regardless of the shortcut to make everything a struct platform_device, I think it was a mistake to put OF devices on platform_bus. Those should have remained on some of_bus even if they are represented by struct platform_device and fiddling in the core done to make that work OK. It is much easier to identify what a bus_type is (the unique collection of APIs) and thus when to create those. If the bus_type should contain struct platform_device or a unqiue struct then becomes a different question. Yes that is very hacky, but it feels less hacky than the platform bus/device is everything and can be used everwhere idea. > > The only problem with mfd as far as SOF is concerned was Greg was not > > happy when he saw PCI stuff in the MFD subsystem. > > This is a huge part of the problem here - there's no clearly articulated > logic, it's all coming back to these sorts of opinion statements about > specific cases which aren't really something you can base anything > on. I agree with this, IMHO there is no really cohesive explanation for when to create a bus vs use the "universal bus" (platform) that can also explain the things platform is already doing. This feels like a good conference topic someday.. > Personally I'm even struggling to identify a practical problem that > we're trying to solve here. Like Alexandre says what would an > mfd_driver actually buy us? Well, there is the minor issue of name collision eg /sys/bus/XX/devices/* must list all devices in the system with no collisions. The owner of the bus is supposed to define the stable naming scheme and all the devices are supposed to follow it. platform doesn't have this: $ ls /sys/bus/platform/devices/ ACPI000C:00 dell-smbios.0 'Fixed MDIO bus.0' INT33A1:00 microcode PNP0C04:00 PNP0C0B:03 PNP0C14:00 alarmtimer.0.auto dell-smbios.1 GHES.0 intel_rapl_msr.0 MSFT0101:00 PNP0C0B:00 PNP0C0B:04 PNP0C14:01 coretemp.0 efi-framebuffer.0 GHES.1 iTCO_wdt pcspkrPNP0C0B:01 PNP0C0C:00 reg-dummy dcdbas eisa.0 INT0800:00 kgdboc PNP0103:00PNP0C0B:02 PNP0C0E:00 serial8250 Why are ACPI names in here? It looks like "because platform drivers were used to bind to ACPI devices" eg INT33A1 is pmc_core_driver so the device was moved from acpi_bus to platform_bus? How does that make sense?? Why is pmc_core_driver a platform device instead of ACPI? Because some platforms don't have ACPI and the board file properly creates a platform device in C code. > I have some bad news for you about the hardware description problem > space. Among other things we have a bunch of platform devices that > don't have any resources exposed through the resource API but are still > things like chips on a board, doing some combination of exposing > resources for other devices (eg, a fixed voltage regulator) and > consuming things like clocks or GPIOs that don't appear in the resource > API. So in these cases how do I use the generic platform bus API to find the GPIOs, regulators, and so on to connect with? If drivers take a platform device and immediately covert it to an OF object and use OF APIs
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 04:58:56PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote: > > > Historically people did try to create custom bus types, as I have > > pointed out before there was then pushback that these were duplicating > > the platform bus so everything uses platform bus. > Yes, I vaugely remember.. > I don't know what to say, it seems Greg doesn't share this view of > platform devices as a universal device. He did at the time, he seems to have changed his mind at some point for unclear reasons > Reading between the lines, I suppose things would have been happier > with some kind of inheritance scheme where platform device remained as > only instantiated directly in board files, while drivers could bind to > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication & > boilerplate. Like I said in my previous message that is essentially what we have now. It's not worded in quite that way but it's how all the non-enumerable buses work. BTW I did have a bit of a scan through some of the ACPI devices and for a good proportion of them it seems fairly clear that they are not platform devices at all - they were mostly interacting with ACPI firmware functionality rather than hardware, something you can't really do with FDT at all. > > I can't tell the difference between what it's doing and what SOF is > > doing, the code I've seen is just looking at the system it's running > > on and registering a fixed set of client devices. It looks slightly > > different because it's registering a device at a time with some wrapper > > functions involved but that's what the code actually does. > SOF's aux bus usage in general seems weird to me, but if you think > it fits the mfd scheme of primarily describing HW to partition vs > describing a SW API then maybe it should use mfd. > The only problem with mfd as far as SOF is concerned was Greg was not > happy when he saw PCI stuff in the MFD subsystem. This is a huge part of the problem here - there's no clearly articulated logic, it's all coming back to these sorts of opinion statements about specific cases which aren't really something you can base anything on. Personally I'm even struggling to identify a practical problem that we're trying to solve here. Like Alexandre says what would an mfd_driver actually buy us? > MFD still doesn't fit what mlx5 and others in the netdev area are > trying to do. Though it could have been soe-horned it would have been > really weird to create a platform device with an empty HW resource > list. At a certain point the bus type has to mean *something*! I have some bad news for you about the hardware description problem space. Among other things we have a bunch of platform devices that don't have any resources exposed through the resource API but are still things like chips on a board, doing some combination of exposing resources for other devices (eg, a fixed voltage regulator) and consuming things like clocks or GPIOs that don't appear in the resource API. We *could* make a new bus type and move all these things over to that but it is not clear what the upside of doing that would be, especially given the amount of upheval it would generate and the classification issues that will inevitably result. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On 18/12/2020 19:36:08-0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote: > > > But then again, what about non-enumerable devices on the PCI device? I > > feel this would exactly fit MFD. This is a collection of IPs that exist > > as standalone but in this case are grouped in a single device. > > So, if mfd had a mfd_device and a mfd bus_type then drivers would need > to have both a mfd_driver and a platform_driver to bind. Look at > something like drivers/char/tpm/tpm_tis.c to see how a multi-probe > driver is structured > > See Mark's remarks about the old of_platform_device, to explain why we > don't have a 'dt_device' today > So, what would that mfd_driver have that the platform_driver doesn't already provide? > > Note that I then have another issue because the kernel doesn't support > > irq controllers on PCI and this is exactly what my SoC has. But for now, > > I can just duplicate the irqchip driver in the MFD driver. > > I think Thomas fixed that recently on x86 at least.. > > Having to put dummy irq chip drivers in MFD anything sounds scary :| > This isn't a dummy driver it is a real irqchip, what issue is there to register an irqchip from MFD ? > > Let me point to drivers/net/ethernet/cadence/macb_pci.c which is a > > fairly recent example. It does exactly that and I'm not sure you could > > do it otherwise while still not having to duplicate most of macb_probe. > > Creating a platform_device to avoid restructuring the driver's probe > and device logic to be generic is a *really* horrible reason to use a > platform device. > Definitively but it made it in and seemed reasonable at the time it seems. I stumbled upon that a while ago because I wanted to remove platform_data support from the macb driver and this is the last user. I never got the time to tackle that. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote: > But then again, what about non-enumerable devices on the PCI device? I > feel this would exactly fit MFD. This is a collection of IPs that exist > as standalone but in this case are grouped in a single device. So, if mfd had a mfd_device and a mfd bus_type then drivers would need to have both a mfd_driver and a platform_driver to bind. Look at something like drivers/char/tpm/tpm_tis.c to see how a multi-probe driver is structured See Mark's remarks about the old of_platform_device, to explain why we don't have a 'dt_device' today > Note that I then have another issue because the kernel doesn't support > irq controllers on PCI and this is exactly what my SoC has. But for now, > I can just duplicate the irqchip driver in the MFD driver. I think Thomas fixed that recently on x86 at least.. Having to put dummy irq chip drivers in MFD anything sounds scary :| > Let me point to drivers/net/ethernet/cadence/macb_pci.c which is a > fairly recent example. It does exactly that and I'm not sure you could > do it otherwise while still not having to duplicate most of macb_probe. Creating a platform_device to avoid restructuring the driver's probe and device logic to be generic is a *really* horrible reason to use a platform device. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 1:17 PM Alexandre Belloni wrote: > > On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote: > > On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote: > > > > > > So, I strongly suspect, MFD should create mfd devices on a MFD bus > > > > type. > > > > > > Historically people did try to create custom bus types, as I have > > > pointed out before there was then pushback that these were duplicating > > > the platform bus so everything uses platform bus. > > > > Yes, I vaugely remember.. > > > > I don't know what to say, it seems Greg doesn't share this view of > > platform devices as a universal device. > > > > Reading between the lines, I suppose things would have been happier > > with some kind of inheritance scheme where platform device remained as > > only instantiated directly in board files, while drivers could bind to > > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication & > > boilerplate. > > > > And maybe that is exactly what we have today with platform devices, > > though the name is now unfortunate. > > > > > I can't tell the difference between what it's doing and what SOF is > > > doing, the code I've seen is just looking at the system it's running > > > on and registering a fixed set of client devices. It looks slightly > > > different because it's registering a device at a time with some wrapper > > > functions involved but that's what the code actually does. > > > > SOF's aux bus usage in general seems weird to me, but if you think > > it fits the mfd scheme of primarily describing HW to partition vs > > describing a SW API then maybe it should use mfd. > > > > The only problem with mfd as far as SOF is concerned was Greg was not > > happy when he saw PCI stuff in the MFD subsystem. > > > > But then again, what about non-enumerable devices on the PCI device? I > feel this would exactly fit MFD. This is a collection of IPs that exist > as standalone but in this case are grouped in a single device. > > Note that I then have another issue because the kernel doesn't support > irq controllers on PCI and this is exactly what my SoC has. But for now, > I can just duplicate the irqchip driver in the MFD driver. > > > This whole thing started when Intel first proposed to directly create > > platform_device's in their ethernet driver and Greg had a quite strong > > NAK to that. > > Let me point to drivers/net/ethernet/cadence/macb_pci.c which is a > fairly recent example. It does exactly that and I'm not sure you could > do it otherwise while still not having to duplicate most of macb_probe. > This still feels an orthogonal example to the problem auxiliary-bus is solving. If a platform-device and a pci-device surface an IP with a shared programming model that's an argument for a shared library, like libata to house the commonality. In contrast auxiliary-bus is a software model for software-defined sub-functionality to be wrapped in a driver model. It assumes a parent-device / parent-driver hierarchy that platform-bus and pci-bus do not imply.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote: > > > > So, I strongly suspect, MFD should create mfd devices on a MFD bus > > > type. > > > > Historically people did try to create custom bus types, as I have > > pointed out before there was then pushback that these were duplicating > > the platform bus so everything uses platform bus. > > Yes, I vaugely remember.. > > I don't know what to say, it seems Greg doesn't share this view of > platform devices as a universal device. > > Reading between the lines, I suppose things would have been happier > with some kind of inheritance scheme where platform device remained as > only instantiated directly in board files, while drivers could bind to > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication & > boilerplate. > > And maybe that is exactly what we have today with platform devices, > though the name is now unfortunate. > > > I can't tell the difference between what it's doing and what SOF is > > doing, the code I've seen is just looking at the system it's running > > on and registering a fixed set of client devices. It looks slightly > > different because it's registering a device at a time with some wrapper > > functions involved but that's what the code actually does. > > SOF's aux bus usage in general seems weird to me, but if you think > it fits the mfd scheme of primarily describing HW to partition vs > describing a SW API then maybe it should use mfd. > > The only problem with mfd as far as SOF is concerned was Greg was not > happy when he saw PCI stuff in the MFD subsystem. > But then again, what about non-enumerable devices on the PCI device? I feel this would exactly fit MFD. This is a collection of IPs that exist as standalone but in this case are grouped in a single device. Note that I then have another issue because the kernel doesn't support irq controllers on PCI and this is exactly what my SoC has. But for now, I can just duplicate the irqchip driver in the MFD driver. > This whole thing started when Intel first proposed to directly create > platform_device's in their ethernet driver and Greg had a quite strong > NAK to that. Let me point to drivers/net/ethernet/cadence/macb_pci.c which is a fairly recent example. It does exactly that and I'm not sure you could do it otherwise while still not having to duplicate most of macb_probe. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote: > > So, I strongly suspect, MFD should create mfd devices on a MFD bus > > type. > > Historically people did try to create custom bus types, as I have > pointed out before there was then pushback that these were duplicating > the platform bus so everything uses platform bus. Yes, I vaugely remember.. I don't know what to say, it seems Greg doesn't share this view of platform devices as a universal device. Reading between the lines, I suppose things would have been happier with some kind of inheritance scheme where platform device remained as only instantiated directly in board files, while drivers could bind to OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication & boilerplate. And maybe that is exactly what we have today with platform devices, though the name is now unfortunate. > I can't tell the difference between what it's doing and what SOF is > doing, the code I've seen is just looking at the system it's running > on and registering a fixed set of client devices. It looks slightly > different because it's registering a device at a time with some wrapper > functions involved but that's what the code actually does. SOF's aux bus usage in general seems weird to me, but if you think it fits the mfd scheme of primarily describing HW to partition vs describing a SW API then maybe it should use mfd. The only problem with mfd as far as SOF is concerned was Greg was not happy when he saw PCI stuff in the MFD subsystem. This whole thing started when Intel first proposed to directly create platform_device's in their ethernet driver and Greg had a quite strong NAK to that. MFD still doesn't fit what mlx5 and others in the netdev area are trying to do. Though it could have been soe-horned it would have been really weird to create a platform device with an empty HW resource list. At a certain point the bus type has to mean *something*! Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 02:41:50PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote: > > If it's not supposed to use platform devices so I'm assuming that the > > intention is that it should use aux devices, otherwise presumably it'd > > be making some new clone of the platform bus but I've not seen anyone > > suggesting this. > I wouldn't assume that, I certainly don't want to see all the HW > related items in platform_device cloned roughly into aux device. > I've understood the bus type should be basically related to the thing > that is creating the device. In a clean view platform code creates > platform devices. DT should create DT devices, ACPI creates ACPI > devices, PNP does pnp devices, etc Ah, so we *used* to do that and in fact at least acpi_device still exists but it was realized that this was causing a lot of effort with boilerplate - like Lee said board files, ACPI and DT are all just enumeration methods which have zero effect on the underlying hardware so you end up having duplication on both the bus and driver side. Since this applies to all non-enumerable buses this process gets repeated for all of them, we wouldn't just have an of_device we'd have of_i2c_device, of_spi_device, of_1wire_device and so on or have to jump through hoops to map things into the actual bus type. See eca3930163ba8884060ce9d9 (of: Merge of_platform_bus_type with platform_bus_type) for part of this getting unwound. Fundamentally this is conflating physical bus type and enumeration method, for enumerable buses they are of course the same (mostly) but for non-enumerable buses not so much. > So, I strongly suspect, MFD should create mfd devices on a MFD bus > type. Historically people did try to create custom bus types, as I have pointed out before there was then pushback that these were duplicating the platform bus so everything uses platform bus. > Alexandre's point is completely valid, and I think is the main > challenge here, somehow avoiding duplication. > If we were to look at it with some OOP viewpoint I'd say the generic > HW resource related parts should be some shared superclass between > 'struct device' and 'struct platform/pnp/pci/acpi/mfd/etc_device'. Right, duplication is the big issue with separate firmware based bus types particularly as we consider all non-enumerable buses. I think what you're looking for here is multiple inheritance, that's potentially interesting but it's pretty much what we have already TBH. We have the physical bus type as a primary type for devices but we also can enquire if they also have the properties of a DT or ACPI object and then use those APIs on them. Consider also FPGAs which can have the same problem Alexandre raised, there's the parent device for the FPGA and then we can instantiate bitstreams within that which may expose standard IPs which can also appear directly within a SoC. > > > The places I see aux device being used are a terrible fit for the cell > > > idea. If there are MFD drivers that are awkardly crammed into that > > > cell description then maybe they should be aux devices? > > When you say the MFD cell model it's not clear what you mean - I *think* > > you're referring to the idea of the subdevices getting all the > I mean using static "struct mfd_cell" arrays to describe things. OK, but then SOF has been actively pushed into using auxiliary devices since there is a desire to avoid using mfd_cells on PCI devices rather than the fact that it wasn't able to use a static array, and of course you might have devices with a mix of static and dynamic functions, or functions that can be both static and dynamic. > > Look at something like wm8994 for example - the subdevices just know > > which addresses in the device I2C/SPI regmap to work with but some of > > them have interrupts passed through to them (and could potentially also > > have separate subdevices for clocks and pinctrl). These subdevices are > > not memory mapped, not enumerated by firmware and the hardware has > > indistinct separation of functions in the register map compared to how > > Linux models the chips. > wm8994 seems to fit in the mfd_cell static arrays pretty well.. I can't tell the difference between what it's doing and what SOF is doing, the code I've seen is just looking at the system it's running on and registering a fixed set of client devices. It looks slightly different because it's registering a device at a time with some wrapper functions involved but that's what the code actually does. Clearly there's something other than just the registration method going on here. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 07:09:11PM +, Lee Jones wrote: > ACPI, DT and MFD are not busses. And yet ACPI and PNP have a bus: extern struct bus_type acpi_bus_type; extern struct bus_type pnp_bus_type; Why? Because in the driver core if you subclass struct device and want to bind drivers, as both PNP and ACPI do, you must place those devices on a bus with a bus_type matching the device type. Thus subclassing the device means subclassing the bus as well. The purpose of the bus_type is to match drivers to devices and provide methods to the driver core. The bus_type also defines the unique name space of the device names. It is confusing because the word bus immediately makes people think of physical objects like I2C, PCI, etc, but that is not what bus_type does in the object model of the driver core, IMHO. So, if you subclass struct device for MFD's usage, then you must also create a bus_type to handle driver binding. The MFD bus_type. Just like auxillary does. Making a mfd subclass is the logical thing for a subsystem to do, co-opting another subsystem's bus_type is just really weird/abusive. auxillary bus shows how all these parts work, and it is simple enough to see the pieces clearly. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 18 Dec 2020, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote: > > > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote: > > > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > > > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > > > for gluing to subsystems together using a driver specific software API > > > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > > > regions of HW. > > > > > > This conflicts with the statements from Greg about not using the > > > > platform bus for things that aren't memory mapped or "direct firmware", > > > > a large proportion of MFD subfunctions are neither at least in so far as > > > > I can understand what direct firmware means. > > > > > I assume MFD will keep existing and it will somehow stop using > > > platform device for the children it builds. > > > > If it's not supposed to use platform devices so I'm assuming that the > > intention is that it should use aux devices, otherwise presumably it'd > > be making some new clone of the platform bus but I've not seen anyone > > suggesting this. > > I wouldn't assume that, I certainly don't want to see all the HW > related items in platform_device cloned roughly into aux device. > > I've understood the bus type should be basically related to the thing > that is creating the device. In a clean view platform code creates > platform devices. DT should create DT devices, ACPI creates ACPI > devices, PNP does pnp devices, etc > > So, I strongly suspect, MFD should create mfd devices on a MFD bus > type. > > Alexandre's point is completely valid, and I think is the main > challenge here, somehow avoiding duplication. > > If we were to look at it with some OOP viewpoint I'd say the generic > HW resource related parts should be some shared superclass between > 'struct device' and 'struct platform/pnp/pci/acpi/mfd/etc_device'. You're confusing things here. ACPI, DT and MFD are not busses. They are just methods to describe/register devices which will operate on buses. Busses include things like; I2C, SPI, PCI, USB and Platform (MMIO). -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote: > On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote: > > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote: > > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > > for gluing to subsystems together using a driver specific software API > > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > > regions of HW. > > > > This conflicts with the statements from Greg about not using the > > > platform bus for things that aren't memory mapped or "direct firmware", > > > a large proportion of MFD subfunctions are neither at least in so far as > > > I can understand what direct firmware means. > > > I assume MFD will keep existing and it will somehow stop using > > platform device for the children it builds. > > If it's not supposed to use platform devices so I'm assuming that the > intention is that it should use aux devices, otherwise presumably it'd > be making some new clone of the platform bus but I've not seen anyone > suggesting this. I wouldn't assume that, I certainly don't want to see all the HW related items in platform_device cloned roughly into aux device. I've understood the bus type should be basically related to the thing that is creating the device. In a clean view platform code creates platform devices. DT should create DT devices, ACPI creates ACPI devices, PNP does pnp devices, etc So, I strongly suspect, MFD should create mfd devices on a MFD bus type. Alexandre's point is completely valid, and I think is the main challenge here, somehow avoiding duplication. If we were to look at it with some OOP viewpoint I'd say the generic HW resource related parts should be some shared superclass between 'struct device' and 'struct platform/pnp/pci/acpi/mfd/etc_device'. > > > To be honest I don't find the LWN article clarifies things particularly > > > here, the rationale appears to involve some misconceptions about what > > > MFDs look like. It looks like it assumes that MFD functions have > > > physically separate register sets for example which is not a reliable > > > feature of MFDs, nor is the assumption that there's no shared > > > functionality which appears to be there. It also appears to assume that > > > I think the MFD cell model is probably the deciding feature. If that > > cell description scheme suites the device, and it is very HW focused, > > then MFD is probably the answer. > > > The places I see aux device being used are a terrible fit for the cell > > idea. If there are MFD drivers that are awkardly crammed into that > > cell description then maybe they should be aux devices? > > When you say the MFD cell model it's not clear what you mean - I *think* > you're referring to the idea of the subdevices getting all the I mean using static "struct mfd_cell" arrays to describe things. > Look at something like wm8994 for example - the subdevices just know > which addresses in the device I2C/SPI regmap to work with but some of > them have interrupts passed through to them (and could potentially also > have separate subdevices for clocks and pinctrl). These subdevices are > not memory mapped, not enumerated by firmware and the hardware has > indistinct separation of functions in the register map compared to how > Linux models the chips. wm8994 seems to fit in the mfd_cell static arrays pretty well.. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > for gluing to subsystems together using a driver specific software API > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > regions of HW. > > This conflicts with the statements from Greg about not using the > > platform bus for things that aren't memory mapped or "direct firmware", > > a large proportion of MFD subfunctions are neither at least in so far as > > I can understand what direct firmware means. > I assume MFD will keep existing and it will somehow stop using > platform device for the children it builds. If it's not supposed to use platform devices so I'm assuming that the intention is that it should use aux devices, otherwise presumably it'd be making some new clone of the platform bus but I've not seen anyone suggesting this. > That doesn't mean MFD must use aux device, so I don't see what you > mean by conflicts? I was excluding the possibility that we have to make a third bus which clones platform bus which nobody has been visibly suggesting. > If someone has a PCI device and they want to split it up, they should > choose between aux device and MFD (assuming MFD gets fixed, as Greg > has basically blanket NAK'd adding more of them to MFD as is) It is unclear to me how one is intended to choose between these approaches, especially for systems that have a range of subdevices with a range of characteristics. > > To be honest I don't find the LWN article clarifies things particularly > > here, the rationale appears to involve some misconceptions about what > > MFDs look like. It looks like it assumes that MFD functions have > > physically separate register sets for example which is not a reliable > > feature of MFDs, nor is the assumption that there's no shared > > functionality which appears to be there. It also appears to assume that > I think the MFD cell model is probably the deciding feature. If that > cell description scheme suites the device, and it is very HW focused, > then MFD is probably the answer. > The places I see aux device being used are a terrible fit for the cell > idea. If there are MFD drivers that are awkardly crammed into that > cell description then maybe they should be aux devices? When you say the MFD cell model it's not clear what you mean - I *think* you're referring to the idea of the subdevices getting all the information they need to talk to the hardware from the device resources. That's actually relatively uncommon with I2C/SPI MFDs, usually there's at least some element of just knowing what's going on and the mfd_cells are to some extent just a list of things to register rather than a model of anything. Look at something like wm8994 for example - the subdevices just know which addresses in the device I2C/SPI regmap to work with but some of them have interrupts passed through to them (and could potentially also have separate subdevices for clocks and pinctrl). These subdevices are not memory mapped, not enumerated by firmware and the hardware has indistinct separation of functions in the register map compared to how Linux models the chips. > > > Maybe there is some overlap, but if you want to add HW representations > > > to the general auxillary device then I think you are using it for the > > > wrong thing. > > Even for the narrowest use case for auxiliary devices that I can think > > of I think the assumption that nobody will ever design something which > > can wire an interrupt intended to be serviced by a subfunction is a bit > > optimistic. > mlx5, for example, uses interrupts but an aux device is not assigned > an exclusive MSI interrupt list. > These devices have a very dynamic interrupt scheme, pre-partitioning > the MSI vector table is completely the wrong API. I'm not saying dynamic interrupt schemes or event queues from firmware can't exist, I'm saying not all interrupt schemes are dynamic. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote: > > > > > > As previously discussed this will need the auxilliary bus extending to > > > > support at least interrupts and possibly also general resources. > > > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > for gluing to subsystems together using a driver specific software API > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > regions of HW. > > > > This conflicts with the statements from Greg about not using the > > platform bus for things that aren't memory mapped or "direct firmware", > > a large proportion of MFD subfunctions are neither at least in so far as > > I can understand what direct firmware means. > > I assume MFD will keep existing and it will somehow stop using > platform device for the children it builds. > > That doesn't mean MFD must use aux device, so I don't see what you > mean by conflicts? > > If someone has a PCI device and they want to split it up, they should > choose between aux device and MFD (assuming MFD gets fixed, as Greg > has basically blanket NAK'd adding more of them to MFD as is) > I have an SoC with for example, a designware SPI controller (handled by drivers/spi/spi-dw-mmio.c), a designware I2C controller (handled by drivers/i2c/busses/i2c-designware-platdrv.c). So, those are MMIO and described using device tree. On this particular SoC, I can disable the CPU and connect it to another SoC using PCIe. In that case it will expose one BAR, with all the HW IPs. The question here is why would I use something different from platform devices to register the SPI and I2C controllers? It seems that by using auxiliary devices, I would have to reinvent parsing device property and children/clients description. This isn't great from a code reuse perspective. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote: > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote: > > > > As previously discussed this will need the auxilliary bus extending to > > > support at least interrupts and possibly also general resources. > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > for gluing to subsystems together using a driver specific software API > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > regions of HW. > > This conflicts with the statements from Greg about not using the > platform bus for things that aren't memory mapped or "direct firmware", > a large proportion of MFD subfunctions are neither at least in so far as > I can understand what direct firmware means. I assume MFD will keep existing and it will somehow stop using platform device for the children it builds. That doesn't mean MFD must use aux device, so I don't see what you mean by conflicts? If someone has a PCI device and they want to split it up, they should choose between aux device and MFD (assuming MFD gets fixed, as Greg has basically blanket NAK'd adding more of them to MFD as is) > To be honest I don't find the LWN article clarifies things particularly > here, the rationale appears to involve some misconceptions about what > MFDs look like. It looks like it assumes that MFD functions have > physically separate register sets for example which is not a reliable > feature of MFDs, nor is the assumption that there's no shared > functionality which appears to be there. It also appears to assume that > MFD subfunctions can clearly be described by ACPI (where it would be > unidiomatic, we just don't see this happening for the MFDs that appear > on ACPI systems and I'm not sure bindings exist within ACPI) or DT > (where even where subfunctions are individually described it's rarely > doing more than enumerating that things exist). I think the MFD cell model is probably the deciding feature. If that cell description scheme suites the device, and it is very HW focused, then MFD is probably the answer. The places I see aux device being used are a terrible fit for the cell idea. If there are MFD drivers that are awkardly crammed into that cell description then maybe they should be aux devices? > > Maybe there is some overlap, but if you want to add HW representations > > to the general auxillary device then I think you are using it for the > > wrong thing. > > Even for the narrowest use case for auxiliary devices that I can think > of I think the assumption that nobody will ever design something which > can wire an interrupt intended to be serviced by a subfunction is a bit > optimistic. mlx5, for example, uses interrupts but an aux device is not assigned an exclusive MSI interrupt list. These devices have a very dynamic interrupt scheme, pre-partitioning the MSI vector table is completely the wrong API. The "interrupt" API is more like: mlx5_register_event_handler(hw_object, my_function); Which would call my_function from some MSI interrupt vector when hw_object has an event to report. There might be 1000's of dynamic hw_objects in the system any moment. As I said, I see aux device as being something that exposes a driver specifc SW API, not a list of generic HW resources. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote: > > As previously discussed this will need the auxilliary bus extending to > > support at least interrupts and possibly also general resources. > I thought the recent LWN article summed it up nicely, auxillary bus is > for gluing to subsystems together using a driver specific software API > to connect to the HW, MFD is for splitting a physical HW into disjoint > regions of HW. This conflicts with the statements from Greg about not using the platform bus for things that aren't memory mapped or "direct firmware", a large proportion of MFD subfunctions are neither at least in so far as I can understand what direct firmware means. To be honest I don't find the LWN article clarifies things particularly here, the rationale appears to involve some misconceptions about what MFDs look like. It looks like it assumes that MFD functions have physically separate register sets for example which is not a reliable feature of MFDs, nor is the assumption that there's no shared functionality which appears to be there. It also appears to assume that MFD subfunctions can clearly be described by ACPI (where it would be unidiomatic, we just don't see this happening for the MFDs that appear on ACPI systems and I'm not sure bindings exist within ACPI) or DT (where even where subfunctions are individually described it's rarely doing more than enumerating that things exist). > Maybe there is some overlap, but if you want to add HW representations > to the general auxillary device then I think you are using it for the > wrong thing. Even for the narrowest use case for auxiliary devices that I can think of I think the assumption that nobody will ever design something which can wire an interrupt intended to be serviced by a subfunction is a bit optimistic. If Greg's statements about not using platform buses for MMIO or direct firmware devices are accurate then those cases already exist, if nothing else a common subfunction for MFDs is an interrupt controller. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote: > There is room for documentation improvement here. I realize reading it > back now that much of the justification for "why not platform bus?" > happened on the list, but only a small mention made it into the It wasn't clear from the list discussions either TBH, or at least the bits I happened to see (I did miss several versions of this). > document. It turns out that platform-bus has some special integrations > and hacks with platform-firmware implementations. For example, the > ACPI companion magic Could you be more specific about the problems that these cause for users of the bus? > and specific platform firmware integrations in > platform_match(). It's also an awkward bus name to use because these Going through a bunch of possible firmware interfaces is standard for buses that can't be enumerated, SPI has almost exactly the same code for example. Again, I'm not clear what problem this causes? > devices do not belong to the platform. The platform bus is for devices > that do not have an enumeration mechanism besides board files or > firmware descriptions. This is the one thing I was getting from what I did see, it was an abstraction thing. I'm still unclear what the abstraction is supposed to be - I had thought that it was supposed to be purely for MMIO devices but in a parallel reply Greg is suggesting that it applies to at least "firmware direct" devices which I guess is things enumerated by board files or firmware but that makes things even less clear for me as it's kind of random if people try to describe the internals of devices in DT or not, and ACPI goes the other way and doesn't really describe some things that physically exist. > > We already have a bunch of drivers in tree that have to share a state > > and register other drivers from other subsystems for the same device. > > How is the auxiliary bus different? > > There's also custom subsystem buses that do this. Why not other > alternatives? They didn't capture the simultaneous mindshare of RDMA, > SOF, and NETDEV developers. Personally my plans for using At least in the case of SOF they were getting active pushback from somewhere telling them not to use MFD. > auxiliary-bus do not map cleanly to anything else in the tree. I want > to use it for attaching an NPEM driver (Native PCIE Enclosure > Management) to any PCI device driver that opts-in, but it would be > overkill to go create an "npem" bus for this. This is why everyone is using platform devices here - people were making custom buses but people (including Greg!) pointed out that these were just carbon copies of the platform bus. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote: > As previously discussed this will need the auxilliary bus extending to > support at least interrupts and possibly also general resources. I thought the recent LWN article summed it up nicely, auxillary bus is for gluing to subsystems together using a driver specific software API to connect to the HW, MFD is for splitting a physical HW into disjoint regions of HW. Maybe there is some overlap, but if you want to add HW representations to the general auxillary device then I think you are using it for the wrong thing. Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 18 Dec 2020, Mark Brown wrote: > On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote: > > On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote: > > > > There is something I don't get from the documentation and it is what is > > > this introducing that couldn't already be done using platform drivers > > > and platform devices? > > > Because platform drivers and devices should ONLY be for actual platform > > devices. Do NOT use that interface to fake up a non-platform device > > (i.e. something that is NOT connected to a cpu through a memory-mapped > > or direct-firmware interface). > > > Do not abuse the platform code anymore than it currently is, it's bad > > enough what has been done to it over time, let's not make it any worse. > > I am not clear on why you're giving direct-firmware devices (which I > assume means things like ARM SCMI where we're talking directly to some > firmware?) a pass here but not for example a GPIO controlled devices. > If this is mainly about improving abstractions it seems like the > boundary here isn't great. Or perhaps I'm just missing what > direct-firmware is supposed to mean? > > In any case, to be clear part of what you're saying here is that all > I2C and SPI MFDs should be rewritten to use this new bus - I've just > copied Lee in again since he keeps getting missed from these threads. > As previously discussed this will need the auxilliary bus extending to > support at least interrupts and possibly also general resources. Thanks Mark. Not entirely sure why this needed an entirely new subsystem to handle non-MMIO Multi-Functional Devices (MFD). Or why I was not approached by any of the developers during the process. Having 2 entirely separate subsystems where MFDs can now be registered sounds confusing and convoluted at best. Why not simply extend actual MFD to be capable of registering non-pure platform devices via other means? By doing so you keep things bound to a central location resulting in less chance of misuse. I turn away MFD implementation abuses all the time. Seeing as the 2 subsystems are totally disjoint, this just unwittingly opened up another back-channel opportunity for those abuses to make it into the mainline kernel. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote: > On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote: > > There is something I don't get from the documentation and it is what is > > this introducing that couldn't already be done using platform drivers > > and platform devices? > Because platform drivers and devices should ONLY be for actual platform > devices. Do NOT use that interface to fake up a non-platform device > (i.e. something that is NOT connected to a cpu through a memory-mapped > or direct-firmware interface). > Do not abuse the platform code anymore than it currently is, it's bad > enough what has been done to it over time, let's not make it any worse. I am not clear on why you're giving direct-firmware devices (which I assume means things like ARM SCMI where we're talking directly to some firmware?) a pass here but not for example a GPIO controlled devices. If this is mainly about improving abstractions it seems like the boundary here isn't great. Or perhaps I'm just missing what direct-firmware is supposed to mean? In any case, to be clear part of what you're saying here is that all I2C and SPI MFDs should be rewritten to use this new bus - I've just copied Lee in again since he keeps getting missed from these threads. As previously discussed this will need the auxilliary bus extending to support at least interrupts and possibly also general resources. signature.asc Description: PGP signature
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote: > Hello, > > On 05/12/2020 16:51:36+0100, Greg KH wrote: > > > To me, the documentation was written, and reviewed, more from the > > > perspective of "why not open code a custom bus instead". So I can see > > > after the fact how that is a bit too much theory and justification and > > > not enough practical application. Before the fact though this was a > > > bold mechanism to propose and it was not clear that everyone was > > > grokking the "why" and the tradeoffs. > > > > Understood, I guess I read this from the "of course you should do this, > > now how do I use it?" point of view. Which still needs to be addressed > > I feel. > > > > > I also think it was a bit early to identify consistent design patterns > > > across the implementations and codify those. I expect this to evolve > > > convenience macros just like other parts of the driver-core gained > > > over time. Now that it is in though, another pass through the > > > documentation to pull in more examples seems warranted. > > > > A real, working, example would be great to have, so that people can know > > how to use this. Trying to dig through the sound or IB patches to view > > how it is being used is not a trivial thing to do, which is why > > reviewing this took so much work. Having a simple example test module, > > that creates a number of devices on a bus, ideally tied into the ktest > > framework, would be great. I'll attach below a .c file that I used for > > some basic local testing to verify some of this working, but it does not > > implement a aux bus driver, which needs to be also tested. > > > > There is something I don't get from the documentation and it is what is > this introducing that couldn't already be done using platform drivers > and platform devices? Because platform drivers and devices should ONLY be for actual platform devices. Do NOT use that interface to fake up a non-platform device (i.e. something that is NOT connected to a cpu through a memory-mapped or direct-firmware interface). Do not abuse the platform code anymore than it currently is, it's bad enough what has been done to it over time, let's not make it any worse. thanks, greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 17, 2020 at 1:20 PM Alexandre Belloni wrote: > > Hello, > > On 05/12/2020 16:51:36+0100, Greg KH wrote: > > > To me, the documentation was written, and reviewed, more from the > > > perspective of "why not open code a custom bus instead". So I can see > > > after the fact how that is a bit too much theory and justification and > > > not enough practical application. Before the fact though this was a > > > bold mechanism to propose and it was not clear that everyone was > > > grokking the "why" and the tradeoffs. > > > > Understood, I guess I read this from the "of course you should do this, > > now how do I use it?" point of view. Which still needs to be addressed > > I feel. > > > > > I also think it was a bit early to identify consistent design patterns > > > across the implementations and codify those. I expect this to evolve > > > convenience macros just like other parts of the driver-core gained > > > over time. Now that it is in though, another pass through the > > > documentation to pull in more examples seems warranted. > > > > A real, working, example would be great to have, so that people can know > > how to use this. Trying to dig through the sound or IB patches to view > > how it is being used is not a trivial thing to do, which is why > > reviewing this took so much work. Having a simple example test module, > > that creates a number of devices on a bus, ideally tied into the ktest > > framework, would be great. I'll attach below a .c file that I used for > > some basic local testing to verify some of this working, but it does not > > implement a aux bus driver, which needs to be also tested. > > > > There is something I don't get from the documentation and it is what is > this introducing that couldn't already be done using platform drivers > and platform devices? There is room for documentation improvement here. I realize reading it back now that much of the justification for "why not platform bus?" happened on the list, but only a small mention made it into the document. It turns out that platform-bus has some special integrations and hacks with platform-firmware implementations. For example, the ACPI companion magic and specific platform firmware integrations in platform_match(). It's also an awkward bus name to use because these devices do not belong to the platform. The platform bus is for devices that do not have an enumeration mechanism besides board files or firmware descriptions. So while many of the auxiliary device use cases might be able to be squeezed into a platform-bus scheme it further overloads what is already a wide responsibility. In comparison, the auxiliary-bus is tailored to the "sub-function of a parent device/driver" use case. It lets the host driver be the root of a namespace of sub-functionality in a standard template way. > We already have a bunch of drivers in tree that have to share a state > and register other drivers from other subsystems for the same device. > How is the auxiliary bus different? There's also custom subsystem buses that do this. Why not other alternatives? They didn't capture the simultaneous mindshare of RDMA, SOF, and NETDEV developers. Personally my plans for using auxiliary-bus do not map cleanly to anything else in the tree. I want to use it for attaching an NPEM driver (Native PCIE Enclosure Management) to any PCI device driver that opts-in, but it would be overkill to go create an "npem" bus for this.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
Hello, On 05/12/2020 16:51:36+0100, Greg KH wrote: > > To me, the documentation was written, and reviewed, more from the > > perspective of "why not open code a custom bus instead". So I can see > > after the fact how that is a bit too much theory and justification and > > not enough practical application. Before the fact though this was a > > bold mechanism to propose and it was not clear that everyone was > > grokking the "why" and the tradeoffs. > > Understood, I guess I read this from the "of course you should do this, > now how do I use it?" point of view. Which still needs to be addressed > I feel. > > > I also think it was a bit early to identify consistent design patterns > > across the implementations and codify those. I expect this to evolve > > convenience macros just like other parts of the driver-core gained > > over time. Now that it is in though, another pass through the > > documentation to pull in more examples seems warranted. > > A real, working, example would be great to have, so that people can know > how to use this. Trying to dig through the sound or IB patches to view > how it is being used is not a trivial thing to do, which is why > reviewing this took so much work. Having a simple example test module, > that creates a number of devices on a bus, ideally tied into the ktest > framework, would be great. I'll attach below a .c file that I used for > some basic local testing to verify some of this working, but it does not > implement a aux bus driver, which needs to be also tested. > There is something I don't get from the documentation and it is what is this introducing that couldn't already be done using platform drivers and platform devices? We already have a bunch of drivers in tree that have to share a state and register other drivers from other subsystems for the same device. How is the auxiliary bus different? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Sat, Dec 5, 2020 at 4:24 PM David Ahern wrote: > > On 12/2/20 5:54 PM, Dan Williams wrote: > > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > > index 8d7001712062..040be48ce046 100644 > > --- a/drivers/base/Kconfig > > +++ b/drivers/base/Kconfig > > @@ -1,6 +1,9 @@ > > # SPDX-License-Identifier: GPL-2.0 > > menu "Generic Driver Options" > > > > +config AUXILIARY_BUS > > + bool > > + > > config UEVENT_HELPER > > bool "Support for uevent helper" > > help > > Missing a description and without it does not appear in menuconfig or in > the config file. > > Could use a blurb in the help as well. It doesn't have a description or help because it is a select-only symbol, but a comment to that effect and a pointer to the documentation would help.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On 12/2/20 5:54 PM, Dan Williams wrote: > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index 8d7001712062..040be48ce046 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -1,6 +1,9 @@ > # SPDX-License-Identifier: GPL-2.0 > menu "Generic Driver Options" > > +config AUXILIARY_BUS > + bool > + > config UEVENT_HELPER > bool "Support for uevent helper" > help Missing a description and without it does not appear in menuconfig or in the config file. Could use a blurb in the help as well.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 08:41:09AM -0800, Dan Williams wrote: > On Fri, Dec 4, 2020 at 3:41 AM Greg KH wrote: > > > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > From: Dave Ertman > > > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > > It enables drivers to create an auxiliary_device and bind an > > > auxiliary_driver to it. > > > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > > Each auxiliary_device has a unique string based id; driver binds to > > > an auxiliary_device based on this id through the bus. > > > > > > Co-developed-by: Kiran Patil > > > Co-developed-by: Ranjani Sridharan > > > Co-developed-by: Fred Oh > > > Co-developed-by: Leon Romanovsky > > > Signed-off-by: Kiran Patil > > > Signed-off-by: Ranjani Sridharan > > > Signed-off-by: Fred Oh > > > Signed-off-by: Leon Romanovsky > > > Signed-off-by: Dave Ertman > > > Reviewed-by: Pierre-Louis Bossart > > > Reviewed-by: Shiraz Saleem > > > Reviewed-by: Parav Pandit > > > Reviewed-by: Dan Williams > > > Reviewed-by: Martin Habets > > > Link: > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > Signed-off-by: Dan Williams > > > --- > > > This patch is "To:" the maintainers that have a pending backlog of > > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > > understand you have asked for more time to fully review this and apply > > > it to driver-core.git, likely for v5.12, but please consider Acking it > > > for v5.11 instead. It looks good to me and several other stakeholders. > > > Namely, stakeholders that have pressure building up behind this facility > > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > > > Compute Express Link. > > > > > > I will take the blame for the 2 months of silence that made this awkward > > > to take through driver-core.git, but at the same time I do not want to > > > see that communication mistake inconvenience other parties that > > > reasonably thought this was shaping up to land in v5.11. > > > > > > I am willing to host this version at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > tags/auxiliary-bus-for-5.11 > > > > > > ...for all the independent drivers to have a common commit baseline. It > > > is not there yet pending Greg's Ack. > > > > > > For example implementations incorporating this patch, see Dave Ertman's > > > SOF series: > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > > ...and Leon's mlx5 series: > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > PS: Greg I know I promised some review on newcomer patches to help with > > > your queue, unfortunately Intel-internal review is keeping my plate > > > full. Again, I do not want other stakeholder to be waiting on me to > > > resolve that backlog. > > > > Ok, I spent some hours today playing around with this. I wrote up a > > small test-patch for this (how did anyone test this thing???) and while > > it feels awkward in places, and it feels like there is still way too > > much "boilerplate" code that a user has to write and manage, I don't > > have the time myself to fix it up right now. > > > > So I'll go apply this to my tree, and provide a tag for everyone else to > > be able to pull from for their different development trees so they can > > work on. > > > > I do have 3 follow-on patches that I will send to the list in response > > to this message that I will be applying on top of this patch. They do > > some minor code formatting changes, as well as change the return type of > > the remove function to make it more future-proof. That last change will > > require users of this code to change their implementations, but it will > > be obvious what to do as you will get a build warning. > > > > Note, I'm still not comfortable with a few things here. The > > documentation feels odd, and didn't really help me out in writing any > > test code, which doesn't seem right. Also the use of strings and '.' as > > part of the api feels awkward, and messy, and of course, totally > > undocumented. > > > > But, as the use of '.' is undocumented, that means we can change it in > > the future! Because no driver or device name should ever be a user api > > reliant thing, if we come up with a better way to do all of this in the > > future, that shouldn't be a problem to change existing users over to > > this. So this is a warning to everyone, you CAN NOT depend on the sysfs > > name of a device or bus name for any tool. If so, your userspace tool > > is broken. > > > > Thanks for everyone in sticking with this, I know it's been a long slog, > > hopefully this will help some driver authors move forward with their > > crazy complex devices :) > > To me, the documentation was written, and reviewed, more from the > perspective of "why not open code a custom bus
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 09:10:34AM -0800, Ranjani Sridharan wrote: > On Fri, 2020-12-04 at 13:59 +0100, Greg KH wrote: > > On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote: > > > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > > > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > > > From: Dave Ertman > > > > > > > > > > Add support for the Auxiliary Bus, auxiliary_device and > > > > > auxiliary_driver. > > > > > It enables drivers to create an auxiliary_device and bind an > > > > > auxiliary_driver to it. > > > > > > > > > > The bus supports probe/remove shutdown and suspend/resume > > > > > callbacks. > > > > > Each auxiliary_device has a unique string based id; driver > > > > > binds to > > > > > an auxiliary_device based on this id through the bus. > > > > > > > > > > Co-developed-by: Kiran Patil > > > > > Co-developed-by: Ranjani Sridharan < > > > > > ranjani.sridha...@linux.intel.com> > > > > > Co-developed-by: Fred Oh > > > > > Co-developed-by: Leon Romanovsky > > > > > Signed-off-by: Kiran Patil > > > > > Signed-off-by: Ranjani Sridharan < > > > > > ranjani.sridha...@linux.intel.com> > > > > > Signed-off-by: Fred Oh > > > > > Signed-off-by: Leon Romanovsky > > > > > Signed-off-by: Dave Ertman > > > > > Reviewed-by: Pierre-Louis Bossart < > > > > > pierre-louis.boss...@linux.intel.com> > > > > > Reviewed-by: Shiraz Saleem > > > > > Reviewed-by: Parav Pandit > > > > > Reviewed-by: Dan Williams > > > > > Reviewed-by: Martin Habets > > > > > Link: > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > Signed-off-by: Dan Williams > > > > > --- > > > > > This patch is "To:" the maintainers that have a pending backlog > > > > > of > > > > > driver updates dependent on this facility, and "Cc:" Greg. > > > > > Greg, I > > > > > understand you have asked for more time to fully review this > > > > > and apply > > > > > it to driver-core.git, likely for v5.12, but please consider > > > > > Acking it > > > > > for v5.11 instead. It looks good to me and several other > > > > > stakeholders. > > > > > Namely, stakeholders that have pressure building up behind this > > > > > facility > > > > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and > > > > > later on > > > > > Compute Express Link. > > > > > > > > > > I will take the blame for the 2 months of silence that made > > > > > this awkward > > > > > to take through driver-core.git, but at the same time I do not > > > > > want to > > > > > see that communication mistake inconvenience other parties that > > > > > reasonably thought this was shaping up to land in v5.11. > > > > > > > > > > I am willing to host this version at: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > > > tags/auxiliary-bus-for-5.11 > > > > > > > > > > ...for all the independent drivers to have a common commit > > > > > baseline. It > > > > > is not there yet pending Greg's Ack. > > > > > > > > > > For example implementations incorporating this patch, see Dave > > > > > Ertman's > > > > > SOF series: > > > > > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > > > > > > ...and Leon's mlx5 series: > > > > > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > > > > > PS: Greg I know I promised some review on newcomer patches to > > > > > help with > > > > > your queue, unfortunately Intel-internal review is keeping my > > > > > plate > > > > > full. Again, I do not want other stakeholder to be waiting on > > > > > me to > > > > > resolve that backlog. > > > > > > > > Ok, I spent some hours today playing around with this. I wrote > > > > up a > > > > small test-patch for this (how did anyone test this thing???). > > > > > > We are running all verifications tests that we have over our > > > mlx5 driver. It includes devices reloads, power failures, FW > > > reconfiguration to emulate different devices with and without error > > > injections and many more. Up till now, no new bugs that are not > > > known > > > to us were found. > > > > Yes, sorry, I was implying that the authors here had to create _some_ > > code to test this with, it would have been nice to include that as > > well > > here. We are collecting more and more in-kernel tests, having one > > for > > this code would be nice to also have so we make sure not to break any > > functionality in the future. > > Hi Greg, > > Thanks for your patience with this series. The v4 version submitted by > Dave included the SOF usage code to demonstrate the usage. We have run > all tests for device registration, module reload, PM etc and have not > observed any regressions in the SOF audio driver. Yes, that works great if you have that specific hardware to test with. If you don't, then it's kind of impossible to test this code :( thanks, greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 2020-12-04 at 13:35 +0100, Greg KH wrote: > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > From: Dave Ertman > > > > Add support for the Auxiliary Bus, auxiliary_device and > > auxiliary_driver. > > It enables drivers to create an auxiliary_device and bind an > > auxiliary_driver to it. > > > > The bus supports probe/remove shutdown and suspend/resume > > callbacks. > > Each auxiliary_device has a unique string based id; driver binds to > > an auxiliary_device based on this id through the bus. > > > > Co-developed-by: Kiran Patil > > Co-developed-by: Ranjani Sridharan < > > ranjani.sridha...@linux.intel.com> > > Co-developed-by: Fred Oh > > Co-developed-by: Leon Romanovsky > > Signed-off-by: Kiran Patil > > Signed-off-by: Ranjani Sridharan > > > > Signed-off-by: Fred Oh > > Signed-off-by: Leon Romanovsky > > Signed-off-by: Dave Ertman > > Reviewed-by: Pierre-Louis Bossart < > > pierre-louis.boss...@linux.intel.com> > > Reviewed-by: Shiraz Saleem > > Reviewed-by: Parav Pandit > > Reviewed-by: Dan Williams > > Reviewed-by: Martin Habets > > Link: > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > Signed-off-by: Dan Williams > > --- > > This patch is "To:" the maintainers that have a pending backlog of > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > understand you have asked for more time to fully review this and > > apply > > it to driver-core.git, likely for v5.12, but please consider Acking > > it > > for v5.11 instead. It looks good to me and several other > > stakeholders. > > Namely, stakeholders that have pressure building up behind this > > facility > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and > > later on > > Compute Express Link. > > > > I will take the blame for the 2 months of silence that made this > > awkward > > to take through driver-core.git, but at the same time I do not want > > to > > see that communication mistake inconvenience other parties that > > reasonably thought this was shaping up to land in v5.11. > > > > I am willing to host this version at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > tags/auxiliary-bus-for-5.11 > > > > ...for all the independent drivers to have a common commit > > baseline. It > > is not there yet pending Greg's Ack. > > Here is now a signed tag for everyone else to pull from and build on > top > of, for 5.11-rc1, that includes this patch, and the 3 others I sent > in > this series. > > Please let me know if anyone has any problems with this tag. I'll > keep > it around until 5.11-rc1 is released, after which it doesn't make any > sense to be there. > thanks, > > greg k-h Hi Mark, Could I request you to please pull from this tag and will we re-submit the SOF changes soon after. Thanks, Ranjani
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 2020-12-04 at 08:25 -0800, Jakub Kicinski wrote: > On Fri, 4 Dec 2020 14:54:55 +0200 Leon Romanovsky wrote: > > Thanks, pulled to mlx5-next > > > > Jason, Jakob, > > > > Can you please pull that mlx5-next branch to your trees? > > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git > > Could you post a PR with a proper description and so on? > > Thanks! I will do that. Thanks!
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 2020-12-04 at 13:59 +0100, Greg KH wrote: > On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote: > > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > > From: Dave Ertman > > > > > > > > Add support for the Auxiliary Bus, auxiliary_device and > > > > auxiliary_driver. > > > > It enables drivers to create an auxiliary_device and bind an > > > > auxiliary_driver to it. > > > > > > > > The bus supports probe/remove shutdown and suspend/resume > > > > callbacks. > > > > Each auxiliary_device has a unique string based id; driver > > > > binds to > > > > an auxiliary_device based on this id through the bus. > > > > > > > > Co-developed-by: Kiran Patil > > > > Co-developed-by: Ranjani Sridharan < > > > > ranjani.sridha...@linux.intel.com> > > > > Co-developed-by: Fred Oh > > > > Co-developed-by: Leon Romanovsky > > > > Signed-off-by: Kiran Patil > > > > Signed-off-by: Ranjani Sridharan < > > > > ranjani.sridha...@linux.intel.com> > > > > Signed-off-by: Fred Oh > > > > Signed-off-by: Leon Romanovsky > > > > Signed-off-by: Dave Ertman > > > > Reviewed-by: Pierre-Louis Bossart < > > > > pierre-louis.boss...@linux.intel.com> > > > > Reviewed-by: Shiraz Saleem > > > > Reviewed-by: Parav Pandit > > > > Reviewed-by: Dan Williams > > > > Reviewed-by: Martin Habets > > > > Link: > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > Signed-off-by: Dan Williams > > > > --- > > > > This patch is "To:" the maintainers that have a pending backlog > > > > of > > > > driver updates dependent on this facility, and "Cc:" Greg. > > > > Greg, I > > > > understand you have asked for more time to fully review this > > > > and apply > > > > it to driver-core.git, likely for v5.12, but please consider > > > > Acking it > > > > for v5.11 instead. It looks good to me and several other > > > > stakeholders. > > > > Namely, stakeholders that have pressure building up behind this > > > > facility > > > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and > > > > later on > > > > Compute Express Link. > > > > > > > > I will take the blame for the 2 months of silence that made > > > > this awkward > > > > to take through driver-core.git, but at the same time I do not > > > > want to > > > > see that communication mistake inconvenience other parties that > > > > reasonably thought this was shaping up to land in v5.11. > > > > > > > > I am willing to host this version at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > > tags/auxiliary-bus-for-5.11 > > > > > > > > ...for all the independent drivers to have a common commit > > > > baseline. It > > > > is not there yet pending Greg's Ack. > > > > > > > > For example implementations incorporating this patch, see Dave > > > > Ertman's > > > > SOF series: > > > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > > > > ...and Leon's mlx5 series: > > > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > > > PS: Greg I know I promised some review on newcomer patches to > > > > help with > > > > your queue, unfortunately Intel-internal review is keeping my > > > > plate > > > > full. Again, I do not want other stakeholder to be waiting on > > > > me to > > > > resolve that backlog. > > > > > > Ok, I spent some hours today playing around with this. I wrote > > > up a > > > small test-patch for this (how did anyone test this thing???). > > > > We are running all verifications tests that we have over our > > mlx5 driver. It includes devices reloads, power failures, FW > > reconfiguration to emulate different devices with and without error > > injections and many more. Up till now, no new bugs that are not > > known > > to us were found. > > Yes, sorry, I was implying that the authors here had to create _some_ > code to test this with, it would have been nice to include that as > well > here. We are collecting more and more in-kernel tests, having one > for > this code would be nice to also have so we make sure not to break any > functionality in the future. Hi Greg, Thanks for your patience with this series. The v4 version submitted by Dave included the SOF usage code to demonstrate the usage. We have run all tests for device registration, module reload, PM etc and have not observed any regressions in the SOF audio driver. Thanks, Ranjani
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 4, 2020 at 3:41 AM Greg KH wrote: > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > From: Dave Ertman > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > It enables drivers to create an auxiliary_device and bind an > > auxiliary_driver to it. > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > Each auxiliary_device has a unique string based id; driver binds to > > an auxiliary_device based on this id through the bus. > > > > Co-developed-by: Kiran Patil > > Co-developed-by: Ranjani Sridharan > > Co-developed-by: Fred Oh > > Co-developed-by: Leon Romanovsky > > Signed-off-by: Kiran Patil > > Signed-off-by: Ranjani Sridharan > > Signed-off-by: Fred Oh > > Signed-off-by: Leon Romanovsky > > Signed-off-by: Dave Ertman > > Reviewed-by: Pierre-Louis Bossart > > Reviewed-by: Shiraz Saleem > > Reviewed-by: Parav Pandit > > Reviewed-by: Dan Williams > > Reviewed-by: Martin Habets > > Link: > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > Signed-off-by: Dan Williams > > --- > > This patch is "To:" the maintainers that have a pending backlog of > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > understand you have asked for more time to fully review this and apply > > it to driver-core.git, likely for v5.12, but please consider Acking it > > for v5.11 instead. It looks good to me and several other stakeholders. > > Namely, stakeholders that have pressure building up behind this facility > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > > Compute Express Link. > > > > I will take the blame for the 2 months of silence that made this awkward > > to take through driver-core.git, but at the same time I do not want to > > see that communication mistake inconvenience other parties that > > reasonably thought this was shaping up to land in v5.11. > > > > I am willing to host this version at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > tags/auxiliary-bus-for-5.11 > > > > ...for all the independent drivers to have a common commit baseline. It > > is not there yet pending Greg's Ack. > > > > For example implementations incorporating this patch, see Dave Ertman's > > SOF series: > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > ...and Leon's mlx5 series: > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > PS: Greg I know I promised some review on newcomer patches to help with > > your queue, unfortunately Intel-internal review is keeping my plate > > full. Again, I do not want other stakeholder to be waiting on me to > > resolve that backlog. > > Ok, I spent some hours today playing around with this. I wrote up a > small test-patch for this (how did anyone test this thing???) and while > it feels awkward in places, and it feels like there is still way too > much "boilerplate" code that a user has to write and manage, I don't > have the time myself to fix it up right now. > > So I'll go apply this to my tree, and provide a tag for everyone else to > be able to pull from for their different development trees so they can > work on. > > I do have 3 follow-on patches that I will send to the list in response > to this message that I will be applying on top of this patch. They do > some minor code formatting changes, as well as change the return type of > the remove function to make it more future-proof. That last change will > require users of this code to change their implementations, but it will > be obvious what to do as you will get a build warning. > > Note, I'm still not comfortable with a few things here. The > documentation feels odd, and didn't really help me out in writing any > test code, which doesn't seem right. Also the use of strings and '.' as > part of the api feels awkward, and messy, and of course, totally > undocumented. > > But, as the use of '.' is undocumented, that means we can change it in > the future! Because no driver or device name should ever be a user api > reliant thing, if we come up with a better way to do all of this in the > future, that shouldn't be a problem to change existing users over to > this. So this is a warning to everyone, you CAN NOT depend on the sysfs > name of a device or bus name for any tool. If so, your userspace tool > is broken. > > Thanks for everyone in sticking with this, I know it's been a long slog, > hopefully this will help some driver authors move forward with their > crazy complex devices :) To me, the documentation was written, and reviewed, more from the perspective of "why not open code a custom bus instead". So I can see after the fact how that is a bit too much theory and justification and not enough practical application. Before the fact though this was a bold mechanism to propose and it was not clear that everyone was grokking the "why" and the tradeoffs. I
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, 4 Dec 2020 14:54:55 +0200 Leon Romanovsky wrote: > Thanks, pulled to mlx5-next > > Jason, Jakob, > > Can you please pull that mlx5-next branch to your trees? > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git Could you post a PR with a proper description and so on? Thanks!
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote: > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > From: Dave Ertman > > > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > > It enables drivers to create an auxiliary_device and bind an > > > auxiliary_driver to it. > > > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > > Each auxiliary_device has a unique string based id; driver binds to > > > an auxiliary_device based on this id through the bus. > > > > > > Co-developed-by: Kiran Patil > > > Co-developed-by: Ranjani Sridharan > > > Co-developed-by: Fred Oh > > > Co-developed-by: Leon Romanovsky > > > Signed-off-by: Kiran Patil > > > Signed-off-by: Ranjani Sridharan > > > Signed-off-by: Fred Oh > > > Signed-off-by: Leon Romanovsky > > > Signed-off-by: Dave Ertman > > > Reviewed-by: Pierre-Louis Bossart > > > Reviewed-by: Shiraz Saleem > > > Reviewed-by: Parav Pandit > > > Reviewed-by: Dan Williams > > > Reviewed-by: Martin Habets > > > Link: > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > Signed-off-by: Dan Williams > > > --- > > > This patch is "To:" the maintainers that have a pending backlog of > > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > > understand you have asked for more time to fully review this and apply > > > it to driver-core.git, likely for v5.12, but please consider Acking it > > > for v5.11 instead. It looks good to me and several other stakeholders. > > > Namely, stakeholders that have pressure building up behind this facility > > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > > > Compute Express Link. > > > > > > I will take the blame for the 2 months of silence that made this awkward > > > to take through driver-core.git, but at the same time I do not want to > > > see that communication mistake inconvenience other parties that > > > reasonably thought this was shaping up to land in v5.11. > > > > > > I am willing to host this version at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > tags/auxiliary-bus-for-5.11 > > > > > > ...for all the independent drivers to have a common commit baseline. It > > > is not there yet pending Greg's Ack. > > > > > > For example implementations incorporating this patch, see Dave Ertman's > > > SOF series: > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > > ...and Leon's mlx5 series: > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > PS: Greg I know I promised some review on newcomer patches to help with > > > your queue, unfortunately Intel-internal review is keeping my plate > > > full. Again, I do not want other stakeholder to be waiting on me to > > > resolve that backlog. > > > > Ok, I spent some hours today playing around with this. I wrote up a > > small test-patch for this (how did anyone test this thing???). > > We are running all verifications tests that we have over our > mlx5 driver. It includes devices reloads, power failures, FW > reconfiguration to emulate different devices with and without error > injections and many more. Up till now, no new bugs that are not known > to us were found. Yes, sorry, I was implying that the authors here had to create _some_ code to test this with, it would have been nice to include that as well here. We are collecting more and more in-kernel tests, having one for this code would be nice to also have so we make sure not to break any functionality in the future. thanks, greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 01:35:05PM +0100, Greg KH wrote: > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > From: Dave Ertman > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > It enables drivers to create an auxiliary_device and bind an > > auxiliary_driver to it. > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > Each auxiliary_device has a unique string based id; driver binds to > > an auxiliary_device based on this id through the bus. > > > > Co-developed-by: Kiran Patil > > Co-developed-by: Ranjani Sridharan > > Co-developed-by: Fred Oh > > Co-developed-by: Leon Romanovsky > > Signed-off-by: Kiran Patil > > Signed-off-by: Ranjani Sridharan > > Signed-off-by: Fred Oh > > Signed-off-by: Leon Romanovsky > > Signed-off-by: Dave Ertman > > Reviewed-by: Pierre-Louis Bossart > > Reviewed-by: Shiraz Saleem > > Reviewed-by: Parav Pandit > > Reviewed-by: Dan Williams > > Reviewed-by: Martin Habets > > Link: > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > Signed-off-by: Dan Williams > > --- > > This patch is "To:" the maintainers that have a pending backlog of > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > understand you have asked for more time to fully review this and apply > > it to driver-core.git, likely for v5.12, but please consider Acking it > > for v5.11 instead. It looks good to me and several other stakeholders. > > Namely, stakeholders that have pressure building up behind this facility > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > > Compute Express Link. > > > > I will take the blame for the 2 months of silence that made this awkward > > to take through driver-core.git, but at the same time I do not want to > > see that communication mistake inconvenience other parties that > > reasonably thought this was shaping up to land in v5.11. > > > > I am willing to host this version at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > tags/auxiliary-bus-for-5.11 > > > > ...for all the independent drivers to have a common commit baseline. It > > is not there yet pending Greg's Ack. > > Here is now a signed tag for everyone else to pull from and build on top > of, for 5.11-rc1, that includes this patch, and the 3 others I sent in > this series. > > Please let me know if anyone has any problems with this tag. I'll keep > it around until 5.11-rc1 is released, after which it doesn't make any > sense to be there. Thanks, pulled to mlx5-next Jason, Jakob, Can you please pull that mlx5-next branch to your trees? git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git Thanks
RE: [resend/standalone PATCH v4] Add auxiliary bus support
> From: Leon Romanovsky > Sent: Friday, December 4, 2020 6:02 PM > > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > From: Dave Ertman > > > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > > It enables drivers to create an auxiliary_device and bind an > > > auxiliary_driver to it. > > > > > > The bus supports probe/remove shutdown and suspend/resume > callbacks. > > > Each auxiliary_device has a unique string based id; driver binds to > > > an auxiliary_device based on this id through the bus. > > > > > > Co-developed-by: Kiran Patil > > > Co-developed-by: Ranjani Sridharan > > > > > > Co-developed-by: Fred Oh > > > Co-developed-by: Leon Romanovsky > > > Signed-off-by: Kiran Patil > > > Signed-off-by: Ranjani Sridharan > > > Signed-off-by: Fred Oh > > > Signed-off-by: Leon Romanovsky > > > Signed-off-by: Dave Ertman > > > Reviewed-by: Pierre-Louis Bossart > > > > > > Reviewed-by: Shiraz Saleem > > > Reviewed-by: Parav Pandit > > > Reviewed-by: Dan Williams > > > Reviewed-by: Martin Habets > > > Link: > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ertman@in > > > tel.com > > > Signed-off-by: Dan Williams > > > --- > > > This patch is "To:" the maintainers that have a pending backlog of > > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > > understand you have asked for more time to fully review this and > > > apply it to driver-core.git, likely for v5.12, but please consider > > > Acking it for v5.11 instead. It looks good to me and several other > stakeholders. > > > Namely, stakeholders that have pressure building up behind this > > > facility in particular Mellanox RDMA, but also SOF, Intel Ethernet, > > > and later on Compute Express Link. > > > > > > I will take the blame for the 2 months of silence that made this > > > awkward to take through driver-core.git, but at the same time I do > > > not want to see that communication mistake inconvenience other > > > parties that reasonably thought this was shaping up to land in v5.11. > > > > > > I am willing to host this version at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > tags/auxiliary-bus-for-5.11 > > > > > > ...for all the independent drivers to have a common commit baseline. > > > It is not there yet pending Greg's Ack. > > > > > > For example implementations incorporating this patch, see Dave > > > Ertman's SOF series: > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ertman@in > > > tel.com > > > > > > ...and Leon's mlx5 series: > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > PS: Greg I know I promised some review on newcomer patches to help > > > with your queue, unfortunately Intel-internal review is keeping my > > > plate full. Again, I do not want other stakeholder to be waiting on > > > me to resolve that backlog. > > > > Ok, I spent some hours today playing around with this. I wrote up a > > small test-patch for this (how did anyone test this thing???). > > We are running all verifications tests that we have over our > mlx5 driver. It includes devices reloads, power failures, FW reconfiguration > to > emulate different devices with and without error injections and many more. > Up till now, no new bugs that are not known to us were found. > Subfunction patchset [1] that is using auxiliary bus in mlx5 driver is also been used by verification and performance tests. [1] https://lore.kernel.org/linux-rdma/20201112192424.2742-1-pa...@nvidia.com/
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > From: Dave Ertman > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > It enables drivers to create an auxiliary_device and bind an > auxiliary_driver to it. > > The bus supports probe/remove shutdown and suspend/resume callbacks. > Each auxiliary_device has a unique string based id; driver binds to > an auxiliary_device based on this id through the bus. > > Co-developed-by: Kiran Patil > Co-developed-by: Ranjani Sridharan > Co-developed-by: Fred Oh > Co-developed-by: Leon Romanovsky > Signed-off-by: Kiran Patil > Signed-off-by: Ranjani Sridharan > Signed-off-by: Fred Oh > Signed-off-by: Leon Romanovsky > Signed-off-by: Dave Ertman > Reviewed-by: Pierre-Louis Bossart > Reviewed-by: Shiraz Saleem > Reviewed-by: Parav Pandit > Reviewed-by: Dan Williams > Reviewed-by: Martin Habets > Link: > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > Signed-off-by: Dan Williams > --- > This patch is "To:" the maintainers that have a pending backlog of > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > understand you have asked for more time to fully review this and apply > it to driver-core.git, likely for v5.12, but please consider Acking it > for v5.11 instead. It looks good to me and several other stakeholders. > Namely, stakeholders that have pressure building up behind this facility > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > Compute Express Link. > > I will take the blame for the 2 months of silence that made this awkward > to take through driver-core.git, but at the same time I do not want to > see that communication mistake inconvenience other parties that > reasonably thought this was shaping up to land in v5.11. > > I am willing to host this version at: > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > tags/auxiliary-bus-for-5.11 > > ...for all the independent drivers to have a common commit baseline. It > is not there yet pending Greg's Ack. Here is now a signed tag for everyone else to pull from and build on top of, for 5.11-rc1, that includes this patch, and the 3 others I sent in this series. Please let me know if anyone has any problems with this tag. I'll keep it around until 5.11-rc1 is released, after which it doesn't make any sense to be there. thanks, greg k-h --- The following changes since commit f8394f232b1eab649ce2df5c5f15b0e528c92091: Linux 5.10-rc3 (2020-11-08 16:10:16 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/auxbus-5.11-rc1 for you to fetch changes up to 0d2bf11a6b3e275a526b8d42d8d4a3a6067cf953: driver core: auxiliary bus: minor coding style tweaks (2020-12-04 13:30:59 +0100) Auxiliary Bus support tag for 5.11-rc1 This is a signed tag for other subsystems to be able to pull in the auxiliary bus support into their trees for the 5.11-rc1 merge. Signed-off-by: Greg Kroah-Hartman Dave Ertman (1): Add auxiliary bus support Greg Kroah-Hartman (3): driver core: auxiliary bus: move slab.h from include file driver core: auxiliary bus: make remove function return void driver core: auxiliary bus: minor coding style tweaks Documentation/driver-api/auxiliary_bus.rst | 234 Documentation/driver-api/index.rst | 1 + drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/auxiliary.c | 274 + include/linux/auxiliary_bus.h | 77 include/linux/mod_devicetable.h| 8 + scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 8 + 9 files changed, 609 insertions(+) create mode 100644 Documentation/driver-api/auxiliary_bus.rst create mode 100644 drivers/base/auxiliary.c create mode 100644 include/linux/auxiliary_bus.h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > From: Dave Ertman > > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > > It enables drivers to create an auxiliary_device and bind an > > auxiliary_driver to it. > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > Each auxiliary_device has a unique string based id; driver binds to > > an auxiliary_device based on this id through the bus. > > > > Co-developed-by: Kiran Patil > > Co-developed-by: Ranjani Sridharan > > Co-developed-by: Fred Oh > > Co-developed-by: Leon Romanovsky > > Signed-off-by: Kiran Patil > > Signed-off-by: Ranjani Sridharan > > Signed-off-by: Fred Oh > > Signed-off-by: Leon Romanovsky > > Signed-off-by: Dave Ertman > > Reviewed-by: Pierre-Louis Bossart > > Reviewed-by: Shiraz Saleem > > Reviewed-by: Parav Pandit > > Reviewed-by: Dan Williams > > Reviewed-by: Martin Habets > > Link: > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > Signed-off-by: Dan Williams > > --- > > This patch is "To:" the maintainers that have a pending backlog of > > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > > understand you have asked for more time to fully review this and apply > > it to driver-core.git, likely for v5.12, but please consider Acking it > > for v5.11 instead. It looks good to me and several other stakeholders. > > Namely, stakeholders that have pressure building up behind this facility > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > > Compute Express Link. > > > > I will take the blame for the 2 months of silence that made this awkward > > to take through driver-core.git, but at the same time I do not want to > > see that communication mistake inconvenience other parties that > > reasonably thought this was shaping up to land in v5.11. > > > > I am willing to host this version at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > tags/auxiliary-bus-for-5.11 > > > > ...for all the independent drivers to have a common commit baseline. It > > is not there yet pending Greg's Ack. > > > > For example implementations incorporating this patch, see Dave Ertman's > > SOF series: > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > ...and Leon's mlx5 series: > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > PS: Greg I know I promised some review on newcomer patches to help with > > your queue, unfortunately Intel-internal review is keeping my plate > > full. Again, I do not want other stakeholder to be waiting on me to > > resolve that backlog. > > Ok, I spent some hours today playing around with this. I wrote up a > small test-patch for this (how did anyone test this thing???). We are running all verifications tests that we have over our mlx5 driver. It includes devices reloads, power failures, FW reconfiguration to emulate different devices with and without error injections and many more. Up till now, no new bugs that are not known to us were found. <...> > Note, I'm still not comfortable with a few things here. The > documentation feels odd, and didn't really help me out in writing any > test code, which doesn't seem right. Also the use of strings and '.' as > part of the api feels awkward, and messy, and of course, totally > undocumented. Agree, I didn't look on the documentation at all when implemented mlx5. But from driver perspective the usage is quite straightforward. <...> > Thanks for everyone in sticking with this, I know it's been a long slog, > hopefully this will help some driver authors move forward with their > crazy complex devices :) Thanks a lot. > > thanks, > > greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > From: Dave Ertman > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > It enables drivers to create an auxiliary_device and bind an > auxiliary_driver to it. > > The bus supports probe/remove shutdown and suspend/resume callbacks. > Each auxiliary_device has a unique string based id; driver binds to > an auxiliary_device based on this id through the bus. > > Co-developed-by: Kiran Patil > Co-developed-by: Ranjani Sridharan > Co-developed-by: Fred Oh > Co-developed-by: Leon Romanovsky > Signed-off-by: Kiran Patil > Signed-off-by: Ranjani Sridharan > Signed-off-by: Fred Oh > Signed-off-by: Leon Romanovsky > Signed-off-by: Dave Ertman > Reviewed-by: Pierre-Louis Bossart > Reviewed-by: Shiraz Saleem > Reviewed-by: Parav Pandit > Reviewed-by: Dan Williams > Reviewed-by: Martin Habets > Link: > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > Signed-off-by: Dan Williams > --- > This patch is "To:" the maintainers that have a pending backlog of > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > understand you have asked for more time to fully review this and apply > it to driver-core.git, likely for v5.12, but please consider Acking it > for v5.11 instead. It looks good to me and several other stakeholders. > Namely, stakeholders that have pressure building up behind this facility > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > Compute Express Link. > > I will take the blame for the 2 months of silence that made this awkward > to take through driver-core.git, but at the same time I do not want to > see that communication mistake inconvenience other parties that > reasonably thought this was shaping up to land in v5.11. > > I am willing to host this version at: > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > tags/auxiliary-bus-for-5.11 > > ...for all the independent drivers to have a common commit baseline. It > is not there yet pending Greg's Ack. > > For example implementations incorporating this patch, see Dave Ertman's > SOF series: > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > ...and Leon's mlx5 series: > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > PS: Greg I know I promised some review on newcomer patches to help with > your queue, unfortunately Intel-internal review is keeping my plate > full. Again, I do not want other stakeholder to be waiting on me to > resolve that backlog. Ok, I spent some hours today playing around with this. I wrote up a small test-patch for this (how did anyone test this thing???) and while it feels awkward in places, and it feels like there is still way too much "boilerplate" code that a user has to write and manage, I don't have the time myself to fix it up right now. So I'll go apply this to my tree, and provide a tag for everyone else to be able to pull from for their different development trees so they can work on. I do have 3 follow-on patches that I will send to the list in response to this message that I will be applying on top of this patch. They do some minor code formatting changes, as well as change the return type of the remove function to make it more future-proof. That last change will require users of this code to change their implementations, but it will be obvious what to do as you will get a build warning. Note, I'm still not comfortable with a few things here. The documentation feels odd, and didn't really help me out in writing any test code, which doesn't seem right. Also the use of strings and '.' as part of the api feels awkward, and messy, and of course, totally undocumented. But, as the use of '.' is undocumented, that means we can change it in the future! Because no driver or device name should ever be a user api reliant thing, if we come up with a better way to do all of this in the future, that shouldn't be a problem to change existing users over to this. So this is a warning to everyone, you CAN NOT depend on the sysfs name of a device or bus name for any tool. If so, your userspace tool is broken. Thanks for everyone in sticking with this, I know it's been a long slog, hopefully this will help some driver authors move forward with their crazy complex devices :) thanks, greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 3, 2020 at 6:34 PM Jason Gunthorpe wrote: > > On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote: > > > > ...for all the independent drivers to have a common commit baseline. It > > > is not there yet pending Greg's Ack. > > > > I have been trying to carve out some time to review this. At my initial > > glance, I still have objections, so please, give me a few more days to > > get this done... > > There are still several more days till the merge window, but I am > going to ask Leon to get the mlx5 series, and this version of the > auxbus patch it depends on, into linux-next with the intention to > forward it to Linus if there are no substantive comments. > > Regardless of fault or reason this whole 1.5 year odyssey seems to have > brought misery to everyone involved and it really is time to move on. > > Leon and his team did a good deed 6 weeks ago to quickly turn around > and build another user example. For their efforts they have been > rewarded with major merge conflicts and alot of delayed work due to > the invasive nature of the mlx5 changes. To continue to push this out > is disrespectful to him and his team's efforts. > > A major part of my time as RDMA maintainer has been to bring things > away from vendor trees and into a common opensource community. Intel > shipping a large out of tree RDMA driver and abandoning their intree > driver is really harmful. This auxbus is a substantial blocker to them > normalizing their operations, thus I view it as important to > resolve. Even after this it is going to take a long time and alot of > effort to review their new RDMA driver. When you have 3 independent driver teams (mlx5, i40e, sof) across 2 companies (NVIDIA and Intel), and multiple subsystem maintainers with a positive track record of upstream engagement all agreeing on a piece of infrastructure, I struggle to imagine a stronger case for merging. I did get word of a fixup needed in the shutdown code, I'll get that folded. Then, barring a concrete objection, I'll look to publish a commit that others can pull in to start building soak time in -next this time tomorrow.
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote: > > ...for all the independent drivers to have a common commit baseline. It > > is not there yet pending Greg's Ack. > > I have been trying to carve out some time to review this. At my initial > glance, I still have objections, so please, give me a few more days to > get this done... There are still several more days till the merge window, but I am going to ask Leon to get the mlx5 series, and this version of the auxbus patch it depends on, into linux-next with the intention to forward it to Linus if there are no substantive comments. Regardless of fault or reason this whole 1.5 year odyssey seems to have brought misery to everyone involved and it really is time to move on. Leon and his team did a good deed 6 weeks ago to quickly turn around and build another user example. For their efforts they have been rewarded with major merge conflicts and alot of delayed work due to the invasive nature of the mlx5 changes. To continue to push this out is disrespectful to him and his team's efforts. A major part of my time as RDMA maintainer has been to bring things away from vendor trees and into a common opensource community. Intel shipping a large out of tree RDMA driver and abandoning their intree driver is really harmful. This auxbus is a substantial blocker to them normalizing their operations, thus I view it as important to resolve. Even after this it is going to take a long time and alot of effort to review their new RDMA driver. Regards, Jason
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 03, 2020 at 04:07:42PM +0100, Greg KH wrote: > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > PS: Greg I know I promised some review on newcomer patches to help with > > your queue, unfortunately Intel-internal review is keeping my plate > > full. Again, I do not want other stakeholder to be waiting on me to > > resolve that backlog. > > Ah, but it's not only you that should be helping out here. Why isn't > anyone else who is wanting this patch merged willing to also help out > with patch review and bug fixes that have higher priority than adding > new features like this one? > > It's not your fault by any means, but the lack of anyone else willing to > do this is quite sad :( First step to get help is to ask for the help. From whom did you ask? And where did you ask? I never heard any request to help with newcomer patches, nor direct, nor in korg-users/newbies MLs. Thanks > > greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > PS: Greg I know I promised some review on newcomer patches to help with > your queue, unfortunately Intel-internal review is keeping my plate > full. Again, I do not want other stakeholder to be waiting on me to > resolve that backlog. Ah, but it's not only you that should be helping out here. Why isn't anyone else who is wanting this patch merged willing to also help out with patch review and bug fixes that have higher priority than adding new features like this one? It's not your fault by any means, but the lack of anyone else willing to do this is quite sad :( greg k-h
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > From: Dave Ertman > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. > It enables drivers to create an auxiliary_device and bind an > auxiliary_driver to it. > > The bus supports probe/remove shutdown and suspend/resume callbacks. > Each auxiliary_device has a unique string based id; driver binds to > an auxiliary_device based on this id through the bus. > > Co-developed-by: Kiran Patil > Co-developed-by: Ranjani Sridharan > Co-developed-by: Fred Oh > Co-developed-by: Leon Romanovsky > Signed-off-by: Kiran Patil > Signed-off-by: Ranjani Sridharan > Signed-off-by: Fred Oh > Signed-off-by: Leon Romanovsky > Signed-off-by: Dave Ertman > Reviewed-by: Pierre-Louis Bossart > Reviewed-by: Shiraz Saleem > Reviewed-by: Parav Pandit > Reviewed-by: Dan Williams > Reviewed-by: Martin Habets > Link: > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > Signed-off-by: Dan Williams > --- > This patch is "To:" the maintainers that have a pending backlog of > driver updates dependent on this facility, and "Cc:" Greg. Greg, I > understand you have asked for more time to fully review this and apply > it to driver-core.git, likely for v5.12, but please consider Acking it > for v5.11 instead. It looks good to me and several other stakeholders. > Namely, stakeholders that have pressure building up behind this facility > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on > Compute Express Link. > > I will take the blame for the 2 months of silence that made this awkward > to take through driver-core.git, but at the same time I do not want to > see that communication mistake inconvenience other parties that > reasonably thought this was shaping up to land in v5.11. > > I am willing to host this version at: > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > tags/auxiliary-bus-for-5.11 > > ...for all the independent drivers to have a common commit baseline. It > is not there yet pending Greg's Ack. I have been trying to carve out some time to review this. At my initial glance, I still have objections, so please, give me a few more days to get this done... thanks, greg k-h
[resend/standalone PATCH v4] Add auxiliary bus support
From: Dave Ertman Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver. It enables drivers to create an auxiliary_device and bind an auxiliary_driver to it. The bus supports probe/remove shutdown and suspend/resume callbacks. Each auxiliary_device has a unique string based id; driver binds to an auxiliary_device based on this id through the bus. Co-developed-by: Kiran Patil Co-developed-by: Ranjani Sridharan Co-developed-by: Fred Oh Co-developed-by: Leon Romanovsky Signed-off-by: Kiran Patil Signed-off-by: Ranjani Sridharan Signed-off-by: Fred Oh Signed-off-by: Leon Romanovsky Signed-off-by: Dave Ertman Reviewed-by: Pierre-Louis Bossart Reviewed-by: Shiraz Saleem Reviewed-by: Parav Pandit Reviewed-by: Dan Williams Reviewed-by: Martin Habets Link: https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com Signed-off-by: Dan Williams --- This patch is "To:" the maintainers that have a pending backlog of driver updates dependent on this facility, and "Cc:" Greg. Greg, I understand you have asked for more time to fully review this and apply it to driver-core.git, likely for v5.12, but please consider Acking it for v5.11 instead. It looks good to me and several other stakeholders. Namely, stakeholders that have pressure building up behind this facility in particular Mellanox RDMA, but also SOF, Intel Ethernet, and later on Compute Express Link. I will take the blame for the 2 months of silence that made this awkward to take through driver-core.git, but at the same time I do not want to see that communication mistake inconvenience other parties that reasonably thought this was shaping up to land in v5.11. I am willing to host this version at: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux tags/auxiliary-bus-for-5.11 ...for all the independent drivers to have a common commit baseline. It is not there yet pending Greg's Ack. For example implementations incorporating this patch, see Dave Ertman's SOF series: https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com ...and Leon's mlx5 series: http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org PS: Greg I know I promised some review on newcomer patches to help with your queue, unfortunately Intel-internal review is keeping my plate full. Again, I do not want other stakeholder to be waiting on me to resolve that backlog. Documentation/driver-api/auxiliary_bus.rst | 234 Documentation/driver-api/index.rst |1 drivers/base/Kconfig |3 drivers/base/Makefile |1 drivers/base/auxiliary.c | 268 include/linux/auxiliary_bus.h | 78 include/linux/mod_devicetable.h|8 + scripts/mod/devicetable-offsets.c |3 scripts/mod/file2alias.c |8 + 9 files changed, 604 insertions(+) create mode 100644 Documentation/driver-api/auxiliary_bus.rst create mode 100644 drivers/base/auxiliary.c create mode 100644 include/linux/auxiliary_bus.h diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst new file mode 100644 index ..5dd7804631ef --- /dev/null +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -0,0 +1,234 @@ +.. SPDX-License-Identifier: GPL-2.0-only + += +Auxiliary Bus += + +In some subsystems, the functionality of the core device (PCI/ACPI/other) is +too complex for a single device to be managed by a monolithic driver +(e.g. Sound Open Firmware), multiple devices might implement a common +intersection of functionality (e.g. NICs + RDMA), or a driver may want to +export an interface for another subsystem to drive (e.g. SIOV Physical Function +export Virtual Function management). A split of the functinoality into child- +devices representing sub-domains of functionality makes it possible to +compartmentalize, layer, and distribute domain-specific concerns via a Linux +device-driver model. + +An example for this kind of requirement is the audio subsystem where a single +IP is handling multiple entities such as HDMI, Soundwire, local devices such as +mics/speakers etc. The split for the core's functionality can be arbitrary or +be defined by the DSP firmware topology and include hooks for test/debug. This +allows for the audio core device to be minimal and focused on hardware-specific +control and communication. + +Each auxiliary_device represents a part of its parent functionality. The +generic behavior can be extended and specialized as needed by encapsulating an +auxiliary_device within other domain-specific structures and the use of .ops +callbacks. Devices on the auxiliary bus do not share any structures and the use +of a communication channel with the parent is domain-specific. + +Note that ops are intended as a way to augment instance behavior within a class +of auxiliary
