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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251031162004.180d5e3f@bootlin.com>
Date: Fri, 31 Oct 2025 16:20:04 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Rob Herring <robh@...nel.org>
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

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().
 - In simple-bus probe(), check the device we probe against the
   'no_instantiate_children' list
      - If it matches, do not instantiate chidren
      - If it doesn't match instantiate children

Is that correct?

Best regards,
Hervé