From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D46D2C15AA; Fri, 14 Nov 2025 07:31:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763105480; cv=none; b=f3KyiA1YXz/njNaPtD8G1FqUuu0QfMGFY5cVBrJvkE5HP6ycEDHI7t8mHS3IXBDS5GSQSKYQp/WLzHywN/J7bfOJOfSgDJg7olG0p6bPfoPKRsihfZGBCz9QmZILlkXEHc+dl23XWFkN6CZJAjXPHTVa+COF9hMs6mrGjQms/qM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763105480; c=relaxed/simple; bh=IxF8X1vfgVSVMfT8B2eub1WyPsdDbytWvtHeqhTmLhA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bHcQIEK6/4AM+zIqvhoF1bnKY240npXMQZDDvhWLUTwEi7327xIZL4e09xOsbeVs024VgXKlFQ8CrhjYirP4oaVbGcW2ORim9u7vvYtMyMPTGCXDUSt+IzZhuwuTEWVQPhjKZK2BLzXkzVacnN43/HHMDaFR1NKcRgYg3JKKFgw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Ihh3mPg2; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Ihh3mPg2" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id C03E9C10F5B; Fri, 14 Nov 2025 07:30:54 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 6DB946060E; Fri, 14 Nov 2025 07:31:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 91780102F24BE; Fri, 14 Nov 2025 08:30:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1763105473; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=I/md1yzfYHmg4zf6NhSCwlxOr7WiJ5xSExfYcNRcf0c=; b=Ihh3mPg240Inv5tK6a0y2bc6iUFXi846hUKdidOylUDZuvveWMMENdHQaSkRED6RzFOXBq s3tYQSOkev+hYVQeHR4xdj9gsjCBZE4xoVzfSAK/1g2MipCnnjRB9Bkk5GjuXG3Cx7DOFw kYgFKBggTQm+b9pCxa+CSSQ/ZTWCwURcGhX3PYd9ux7EBGyx/9AHjyRmK+4KGnJIGUEThM qzUZSLvpXFlxbq5qUbppYDVR3bLAksRf/LYtY1SMB9VNJh0223ScvrKjeOG9M97dF0T3LW uvqxAXMSPLBRG2VoFl3r/PtCN/OynUaIXjcWuLff+sSzDc+2UloAc/8A3W9eSw== Date: Fri, 14 Nov 2025 08:30:56 +0100 From: Herve Codina To: Rob Herring Cc: Andrew Lunn , Krzysztof Kozlowski , Conor Dooley , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Michael Turquette , Stephen Boyd , Andi Shyti , Wolfram Sang , Peter Rosin , Arnd Bergmann , Saravana Kannan , Bjorn Helgaas , Charles Keepax , Richard Fitzgerald , David Rhodes , Linus Walleij , Ulf Hansson , Mark Brown , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Geert Uytterhoeven , Wolfram Sang , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-i2c@vger.kernel.org, linux-pci@vger.kernel.org, linux-sound@vger.kernel.org, patches@opensource.cirrus.com, linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, linux-spi@vger.kernel.org, linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org, Allan Nielsen , Horatiu Vultur , Steen Hegelund , Luca Ceresoli , Thomas Petazzoni Subject: Re: [PATCH v4 05/29] dt-bindings: bus: Add simple-platform-bus Message-ID: <20251114083056.31553866@bootlin.com> In-Reply-To: References: <20251015071420.1173068-1-herve.codina@bootlin.com> <20251015071420.1173068-6-herve.codina@bootlin.com> <20251030141448.GA3853761-robh@kernel.org> <20251031162004.180d5e3f@bootlin.com> <20251112142632.GA1610836-robh@kernel.org> Organization: Bootlin X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Hi Rob, On Wed, 12 Nov 2025 13:29:09 -0600 Rob Herring wrote: > On Wed, Nov 12, 2025 at 8:26 AM Rob Herring 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 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. > Hum, if my understanding is correct, this looks like what I did in the v3 iteration [1]. The idea was: 1) Do not change anything in of_platform_.*populate() 2) Update the simple-bus driver to populate children if there is only one compatible string and this string matches the compatible string handled by the driver. We can be more restrictive for 2) and only populate children if the only one compatible string is "simple-bus". This will keep current behavior for "simple-mfd", "isa" and "arm,amba-bus". If you think this could be the right direction, I will bring those modification in the next iteration. Also, do you think we should be more restrictive and populate children in the simple-bus driver only for "simple-bus" compatible? [1] https://lore.kernel.org/lkml/20250613134817.681832-6-herve.codina@bootlin.com/ Best regards, Hervé