On Fri, Dec 18, 2020 at 03:52:04PM +0000, 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 +0000, 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
