From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7946234E763 for ; Wed, 12 Nov 2025 19:29:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762975764; cv=none; b=e3XRdSqbr/TorSlOwQYo/NV0t4Ar+9ningLmcYnwzU6d3syZ5CKyusnTIc5LOeCYDEoRTYHtK9Eg6VUZytrZVZlBQuIO7argsRaVzfmBcme7jWZsFJwg2VbauwZCZHJRuJNUSv8bgzW5kjxftFjLPtv9g7mIF/1QRnTXoOqzZtg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762975764; c=relaxed/simple; bh=cBs5VsCM5bkQCwAVcWEWV1HKeCFrZdeAh6gx6vjF0Ps=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ru6qZc81xyYbl7+8QU94jnbivuxnuUGkQsf7ZIItin/YziWaA+5eTkNtBtMF/iSbVyVIs21NrPB+iGRHiFdvM6nSo4SwKSfZV9aeozCszmKbBHDqq8lyGQvPcr7Gy1LOQmwmjp3SzHklBTd6Iv6cmIJ13OIHAA7GLvOUj5WdNIk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=szv3xAGH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="szv3xAGH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38A8AC2BCB5 for ; Wed, 12 Nov 2025 19:29:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762975764; bh=cBs5VsCM5bkQCwAVcWEWV1HKeCFrZdeAh6gx6vjF0Ps=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=szv3xAGH5agPEKMl9f7UkYYhRkgqB9AKS9v5496ledDdhmin+wBReWGI/iRlnpyNh HbYV6ylofcN/goxA5r50ITFCx+VPTD/XMpI2F+HTqWiVmXb4Ba/WsGQCub3AicyInu Ow8oG5q2NYNmka0aHseXh9DODZAbXJhxzKQn2f73gxSmsRUPvvLd8anRteQ9sj444E /Mlx1OFvwWRhC3fmxGHHwnyMo6Hor+kqovSGQ/g/qG38H4WqSasIzCVRFPRQ6h+h2M RQDZlilfFhJd8BVjaxhYZ0q9NyXQ9nvv3D3ovq7RmI7DOt7/d/Xw+wRa1dkg9PJaol ZbIunWXzgsM/A== Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-640a503fbe8so21403a12.1 for ; Wed, 12 Nov 2025 11:29:24 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVSmbTBcXmNtVpjBrglBAZlVPe2Tybny1PIbAxFq59zuncHMqXHtELAzKQqcQMFjtYstes12HDyMTKA@vger.kernel.org X-Gm-Message-State: AOJu0YyCMV+d57hZPbo49KDnFsOgMIRVrpQJSgzc2geFE2ght/HfJT2q W7/17uWkhBvt6uZtRgvH7mgWF+Cr8jmO8UJ7q1S6p097OeP8T2zHpx+IhEh17jrBPTh0SU6rD4j mFbhuINVDtuHZrHWRaPitDql/xMo9FA== X-Google-Smtp-Source: AGHT+IHHsq6g1iGPfNpj/BGp5eL9w+14A+MEbPOCADp6BJOBMQBWxT0j5cv1w9FevsaSK63J53W6goPTLfg5SnHB+/k= X-Received: by 2002:a05:6402:34ce:b0:63b:ef0e:dfa7 with SMTP id 4fb4d7f45d1cf-6431a4bfc9cmr3902960a12.6.1762975760981; Wed, 12 Nov 2025 11:29:20 -0800 (PST) Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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> In-Reply-To: <20251112142632.GA1610836-robh@kernel.org> From: Rob Herring Date: Wed, 12 Nov 2025 13:29:09 -0600 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bnvVqS34104BGAfHcYDtcOO0joqpBN-zpybKauFgaXAFRsInCQMBTqH6M4 Message-ID: Subject: Re: [PATCH v4 05/29] dt-bindings: bus: Add simple-platform-bus To: Herve Codina 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 12, 2025 at 8:26=E2=80=AFAM 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 spec= ific > > > > driver to perform operations at bus level. > > > > > > > > Similar to simple-bus, a Simple Platform Bus allows to automaticall= y > > > > instantiate devices connected to this bus. > > > > > > > > Those devices are instantiated only by the Simple Platform Bus prob= e > > > > function itself. > > > > > > Don't let Greg see this... :) > > > > > > I can't say I'm a fan either. "Platform bus" is a kernel thing, and t= he > > > distinction here between the 2 compatibles is certainly a kernel thin= g. > > > > > > 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 hav= ing > > > a specific compatible and having its own driver. So if someone has > > > 'compatible =3D "vendor,not-so-simple-bus", "simple-bus"', when and i= f > > > they add a driver for "vendor,not-so-simple-bus", then they have to a= dd > > > 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 makin= g > > > linux handle 2 (or more) drivers matching a node and picking the driv= er > > > 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 focu= s > > 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