The consensus for the auxiliary_device model was hard to reach, and the
agreement was to align on a minimal model. If you disagree with the
directions, you will have to convince Nvidia/Mellanox and Intel networking
folks who contributed the solution to do something different.
The purpose of the aux devices was primarily to bind a *software*
interface between two parts of the kernel.
The auxiliary bus documentation states clearly that we wanted to
partition the functionality of a specific hardware into separate parts
that are not exposed through ACPI/DT.
See excerpts from
https://www.kernel.org/doc/html/latest/driver-api/auxiliary_bus.html
"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)" <- that's us.
This is the case for our audio controller, which exposes 4 SoundWire
links. Since the links can be individually power-managed, creating 4
subdevices below the PCI parent is a natural design.
"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:" <- that's also us
Péter Ujfalusi is working on this part to split the DSP capabilities and
let different 'clients' control them. That's a different case where we
partition 'firmware' capabilities, not hardware as in the case of SoundWire.
If there is a strong defined HW boundary and no software interface
then the mfd subsytem may be a better choice.
That objection has been made before, there were lengthy threads on this
between GregKH, Mark Brown and others. Clearly if we go back to this
kind of debates I will respectfully stick to platform devices until
maintainers agree.
This is beyond my area of expertise, outside of my control, and I've
spent enough time trying to move away from platform devices - we've been
at it for 2 years.
The auxiliary bus as suggested in this patch works fine. We don't have
any needs that are not handled by the auxiliary bus code as of today,
and we are not planning any future extensions.
For a software layer I expect to see some 'handle' and then a set of
APIs to work within that. It is OK if that 'handle' refers to some HW
resources that the API needs to work, the purpose of this is to
control HW after all.
You might help Vinod by explaining what the SW API is here.
There is no suggested change in API, what we use today for the platform
devices is exactly the same as what we need for auxiliary bus devices.
We are not creating something new for SoundWire, just substituting one
type of devices for another.
