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? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
