Message-ID: <CAL_JsqJ89EcUvQnS0xYXOrw6wJ30TT5oFA85eCqHYdu43056cw@mail.gmail.com>
Date: Wed, 12 Nov 2025 13:29:09 -0600
From: Rob Herring <robh@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>, Shawn Guo <shawnguo@...nel.org>, 
	Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>, 
	Fabio Estevam <festevam@...il.com>, Michael Turquette <mturquette@...libre.com>, 
	Stephen Boyd <sboyd@...nel.org>, Andi Shyti <andi.shyti@...nel.org>, 
	Wolfram Sang <wsa+renesas@...g-engineering.com>, Peter Rosin <peda@...ntia.se>, 
	Arnd Bergmann <arnd@...db.de>, Saravana Kannan <saravanak@...gle.com>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Charles Keepax <ckeepax@...nsource.cirrus.com>, 
	Richard Fitzgerald <rf@...nsource.cirrus.com>, David Rhodes <david.rhodes@...rus.com>, 
	Linus Walleij <linus.walleij@...aro.org>, Ulf Hansson <ulf.hansson@...aro.org>, 
	Mark Brown <broonie@...nel.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Daniel Scally <djrscally@...il.com>, Heikki Krogerus <heikki.krogerus@...ux.intel.com>, 
	Sakari Ailus <sakari.ailus@...ux.intel.com>, Len Brown <lenb@...nel.org>, 
	Davidlohr Bueso <dave@...olabs.net>, Jonathan Cameron <jonathan.cameron@...wei.com>, 
	Dave Jiang <dave.jiang@...el.com>, Alison Schofield <alison.schofield@...el.com>, 
	Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, 
	Dan Williams <dan.j.williams@...el.com>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Wolfram Sang <wsa@...nel.org>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
	linux-clk@...r.kernel.org, linux-i2c@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-sound@...r.kernel.org, 
	patches@...nsource.cirrus.com, linux-gpio@...r.kernel.org, 
	linux-pm@...r.kernel.org, linux-spi@...r.kernel.org, 
	linux-acpi@...r.kernel.org, linux-cxl@...r.kernel.org, 
	Allan Nielsen <allan.nielsen@...rochip.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>, 
	Steen Hegelund <steen.hegelund@...rochip.com>, Luca Ceresoli <luca.ceresoli@...tlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 05/29] dt-bindings: bus: Add simple-platform-bus

On Wed, Nov 12, 2025 at 8:26 AM Rob Herring <robh@...nel.org> 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@...nel.org> 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

Powered by blists - more mailing lists