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 986B62BEFFB; Fri, 31 Oct 2025 15:20:27 +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=1761924030; cv=none; b=eWvEBfYoofgZYGGNvXRoATYIRW25fSwPcbDNByHzyfPUadCk56dguPOzT7QeGUN5pI3ifB6hI2IR7XKD2bAJ76vI8s/QoJFJpJ8cejGgp6HqWUbP1wwKly05czU8zU3r54WechXzFo/UxXjt33gr0vqZZ8mnhCYYrXTo5Oiiy0Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761924030; c=relaxed/simple; bh=y3b+wUCsWckPBCTPgAZadRRNBEdlpxrfsSHKNnGesNY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IIaBcq2DZFuFNWCJ69Rp0+KvIfpGueRbZrey+b0r4YUEldPX23/cFLYyPXuR7y7OVFEDeUfC36Mk+wy6edhs8knsppObLPKWJzX7olzwvTmKIcm7U2PRpgMev9arNBx8aTv5dw3R4a0H4WpDPy2dAuPOut7Zp8NffcGGgLtXzO8= 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=ZXX1Bma9; 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="ZXX1Bma9" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 36A3FC0E957; Fri, 31 Oct 2025 15:20:05 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 9CDE360710; Fri, 31 Oct 2025 15:20:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 067DE11818041; Fri, 31 Oct 2025 16:20:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1761924023; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=goHQM/1NASiwEpJFuU+gt1w80LtYcWXr5Gc0K9tmMcc=; b=ZXX1Bma9X3KMNXlEJ6m3KmzgeWaoHvqKZUDGbtyXcyczSWNcqa1WxZl7PaaP3QnmzL9gq4 h0YuPlq7t/ag22Qc0RV6DUkEOizZ8aU4YvVAi5tQ0oCrNCN9uTlgnrGvmTf6uzjWAFrc/P iOZon5nGEinDurKqvP8UIygDFPUWAiUqm59zHUbmHyOs3e60XOGs63ifmZhf114mLUKRqK bIKj+JoZJxnMO/w5PK2AbEIM7ADXeVegLKetdhc6qx0E6UYxyvcnSln30z+BZXKje9+TfM AmSNEEcgTn5HJwFcJWmSNYyzhr1jXdHX0RhRB0lSnwspgtNFDoD+bFqnfo/hgQ== Date: Fri, 31 Oct 2025 16:20:04 +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: <20251031162004.180d5e3f@bootlin.com> In-Reply-To: <20251030141448.GA3853761-robh@kernel.org> References: <20251015071420.1173068-1-herve.codina@bootlin.com> <20251015071420.1173068-6-herve.codina@bootlin.com> <20251030141448.GA3853761-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 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(). - 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é