[<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
 
