Re: [PATCH v4 05/29] dt-bindings: bus: Add simple-platform-bus

[Rob Herring]

On Wed, Nov 12, 2025 at 8:26 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Fri, Oct 31, 2025 at 04:20:04PM +0100, Herve Codina wrote:
> > Hi Rob,
> >
> > On Thu, 30 Oct 2025 09:14:48 -0500
> > Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > > On Wed, Oct 15, 2025 at 09:13:52AM +0200, Herve Codina wrote:
> > > > A Simple Platform Bus is a transparent bus that doesn't need a specific
> > > > driver to perform operations at bus level.
> > > >
> > > > Similar to simple-bus, a Simple Platform Bus allows to automatically
> > > > instantiate devices connected to this bus.
> > > >
> > > > Those devices are instantiated only by the Simple Platform Bus probe
> > > > function itself.
> > >
> > > Don't let Greg see this... :)
> > >
> > > I can't say I'm a fan either. "Platform bus" is a kernel thing, and the
> > > distinction here between the 2 compatibles is certainly a kernel thing.
> > >
> > > I think this needs to be solved within the kernel.
> >
> > I fully agree with that.
> >
> > >
> > > What I previously said is define a list of compatibles to not
> > > instantiate the child devices. This would essentially be any case having
> > > a specific compatible and having its own driver. So if someone has
> > > 'compatible = "vendor,not-so-simple-bus", "simple-bus"', when and if
> > > they add a driver for "vendor,not-so-simple-bus", then they have to add
> > > the compatible to the list in the simple-pm-bus driver. I wouldn't
> > > expect this to be a large list. There's only a handful of cases where
> > > "simple-bus" has a more specific compatible. And only a few of those
> > > have a driver. A more general and complicated solution would be making
> > > linux handle 2 (or more) drivers matching a node and picking the driver
> > > with most specific match. That gets complicated with built-in vs.
> > > modules. I'm not sure we really need to solve that problem.
> >
> > Right. Let discard the "more general and complicated solution" and focus
> > on the list of compatible to avoid child devices instantiation.
> >
> > Do you mean that, for "simple-bus" compatible we should:
> >  - Remove the recursive device instantiation from of_platform_populate().
>
> That may be a problem I hadn't considered. While we've solved most probe
> ordering issues, I think some may remain. Even when of_platform_populate()
> is called affects this. For example, I tried removing various arm32
> of_platform_.*populate() calls which run earlier than the default call,
> but that broke some platforms. (Looking at the list of remaining ones, I
> fixed the at91 pinctrl/gpio drivers, but never tried to remove the
> calls again.)
>
> Maybe this can be restricted to cases which are not recursively created
> from the root node. Not sure how we detect that. Perhaps no OF_POPULATED
> flag on the parent node? Or we could just enable this for OF_DYNAMIC
> nodes? That should be sufficient for your usecase.

Thinking a bit more about this, I think you don't have to do anything.
If child nodes already got populated, calling of_platform_populate() a
second time is essentially a nop. And for cases you care about, that
wouldn't have happened. Of course, I'd still rather there only be 1
path that devices could have been instantiated.

Rob