[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251030141448.GA3853761-robh@kernel.org>
Date: Thu, 30 Oct 2025 09:14:48 -0500
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, 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.
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.
If we have to do something in the DT, then I think I prefer a property
to control the behavior. That way we have the option to ignore it.
Rob
Powered by blists - more mailing lists