Hello,
On 05/12/2020 16:51:36+0100, Greg KH wrote:
To me, the documentation was written, and reviewed, more from the perspective of "why not open code a custom bus instead". So I can see after the fact how that is a bit too much theory and justification and not enough practical application. Before the fact though this was a bold mechanism to propose and it was not clear that everyone was grokking the "why" and the tradeoffs.
Understood, I guess I read this from the "of course you should do this, now how do I use it?" point of view. Which still needs to be addressed I feel.
I also think it was a bit early to identify consistent design patterns across the implementations and codify those. I expect this to evolve convenience macros just like other parts of the driver-core gained over time. Now that it is in though, another pass through the documentation to pull in more examples seems warranted.
A real, working, example would be great to have, so that people can know how to use this. Trying to dig through the sound or IB patches to view how it is being used is not a trivial thing to do, which is why reviewing this took so much work. Having a simple example test module, that creates a number of devices on a bus, ideally tied into the ktest framework, would be great. I'll attach below a .c file that I used for some basic local testing to verify some of this working, but it does not implement a aux bus driver, which needs to be also tested.
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?
We already have a bunch of drivers in tree that have to share a state and register other drivers from other subsystems for the same device. How is the auxiliary bus different?