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 9EFC034DB63 for ; Wed, 12 Nov 2025 19:29:23 +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=1762975763; cv=none; b=mZMEcTqG1hELWw24hlRYhY304khyJD1ifhLm6mcStp3Zi3NsDoBgqg3Gng8lPuK677pBKvlpTBb6ZipDbqk08g3L9cJpE0vGTDCjAEN3neOksYEVu4Hom1s/HZ4+BbML2Zgs0EMAjhAgw0Qnz2XZb4tZNeJOQZ7kij7hOlnAUfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762975763; c=relaxed/simple; bh=cBs5VsCM5bkQCwAVcWEWV1HKeCFrZdeAh6gx6vjF0Ps=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KHwg2yEqL//3yhZQ++AW0ajJauP/lVGFB8J1ShSY7D9VFoIVU5p/SMfFUr/iUBPBIL3sXMtQ7zJG+9MWn2wJxImeOlbJH9IxMFL21AqWp1gHmxqUhWMQw4uH9GvU/jWwAo/dTm4QYnE2kp3DPnpRX48Tiwttsa/fT3NvDrFQ0cg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K352Iz8A; 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="K352Iz8A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37375C19424 for ; Wed, 12 Nov 2025 19:29:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762975763; bh=cBs5VsCM5bkQCwAVcWEWV1HKeCFrZdeAh6gx6vjF0Ps=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=K352Iz8Ah3njTVW7iehUnnH7mqi0Jd6YwMB4qZkyO+cIO1D7Pz6qNEcuOZXb/AXkw pcmFXpcyZMls1fI59UI/29eJypzLeW20lErann0mpshHzt3ur4vj67oY3kW4uBN2+D wdkZ7dKutDKfxp/0HGFCbyl6exwmzFCVe6M/nkpYSoUlXpG0XiZwVxcppdH7WD6Ni9 z+iTp0EgYBh7btC3FXy9oVN5fPG+ADnQ8+SmKYuB+BPDNb5Nlzg2CF6LxSEFIG7x6r UwVZqF1WwD656gypaRpT/CvjAXPRt6J5giHHLr3kYehrERBJTQ0mYJ1NxiDLglYNmD Y3PHhD2Z86n6w== Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-6431b0a1948so10309a12.3 for ; Wed, 12 Nov 2025 11:29:23 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCU9qQN7EG+oGc5/AjpG7fynNZIsNNKiPb2xUl6o0U56iiuwrpiuGN/LHUAOnHuAU6XDmca6+sIwkpLL@vger.kernel.org X-Gm-Message-State: AOJu0YzjyNe7tQRbbqwBM51uf3e2IwlkFFGOZ+/6be2J6wdyVKZdBc2m x3hOmjJa4kqjIeTe+nILEgYbRO4OrbEPYuUreAqNWV6o01Ie3cCr+OeXI/rVleoJUQy2JFgg5QZ u7liFahaTLgO4P6olwUrVSZS9HIsoJQ== 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: devicetree@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