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.