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.