On Fri, Dec 18, 2020 at 1:17 PM Alexandre Belloni alexandre.belloni@bootlin.com wrote:
On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote:
On Fri, Dec 18, 2020 at 08:32:11PM +0000, 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.