From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 70B312E41E for ; Thu, 18 Sep 2025 07:53:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758182003; cv=none; b=tUHbdlI8MVUU2Mp5edlNzoH54h4DkqdGxcMt7k1eOoS8Ns8sCBM+OW+NvYzMNtB/Oa4dWMn88LGfp0n+Lm5pc9hESouE/WTrW8Ju1vG4P8OdDS9/nbngGKIGjnuzZj2zmVTvdkhBoSQO3uMfaw7LtmGatsIRbT9i/it+1ftGwDQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758182003; c=relaxed/simple; bh=YBR6J/xTT+tYNygOucvrzlv1Sf553Gi0K8EeE+pFDo4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Jw7Jj/Nzt8f+EdB6RFe2egg2AuBzrxqPwmAFX9PQHM7g2akKpNkNtBz40seF6l51A24QOEI57lEFUsAOGsBtERaEie+Dbm2C7C4hvRZTQJJDimlZBjh69rkaZhIk+ugrWAvLFET/yjv95wzRAmjlsapNX2Ym6aRPRiqEUTddTPg= 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=i7U7V58u; arc=none smtp.client-ip=185.246.85.4 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="i7U7V58u" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 50B544E40CFC; Thu, 18 Sep 2025 07:44:24 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 25BCB60630; Thu, 18 Sep 2025 07:44:24 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 6A98F102F1870; Thu, 18 Sep 2025 09:44:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1758181463; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=MvkDMRbtxk6Ydf/U3xFip5NWPIJs2Mr0IzgXuY8pS/I=; b=i7U7V58u50duMZyYG7RVH6Cpusk/ncywT8GAqowoE0tzvLbjffXsfeGJmxl6ipD+uAzL/X nLI+65+W7Ix6xvSBAbBilnyPGd5FnGVxVJ71sCgos7OUvK1r2nRcv4w6870qb5IeAgQFPB jI1YwuGqpMlUej9rJo10wYviKATweJ+j+tlo/gY7gzuyQq7goOmmL0ZrwXQpGEeiGNecMe nB9EGUrjf1sJnVzRfZTRbWb6roG5vTQ48SMToyQnk72oek8lVzc7qWEFOYZB93B5rbjcc9 b5eqY4wEbZZS0qn61YoTkBIJo/O6gtKWjqH/sbTlLRT0HnYZU3rkFXpqwo5FZQ== Date: Thu, 18 Sep 2025 09:44:09 +0200 From: Herve Codina To: David Gibson , Krzysztof Kozlowski , Rob Herring , Andrew Davis , Wolfram Sang Cc: Ayush Singh , Luca Ceresoli , devicetree@vger.kernel.org, Jason Kridner , Geert Uytterhoeven , Krzysztof Kozlowski , Conor Dooley , devicetree-compiler@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Petazzoni Subject: Re: Device tree representation of (hotplug) connectors: discussion at ELCE Message-ID: <20250918094409.0d5f92ec@bootlin.com> In-Reply-To: References: <337281a8-77f9-4158-beef-ae0eda5000e4@beagleboard.org> <20250908145155.4f130aec@bootlin.com> <20250909114126.219c57b8@bootlin.com> <20250911104828.48ef2c0e@bootlin.com> <20250916084631.77127e29@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: devicetree-compiler@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 David, On Thu, 18 Sep 2025 13:16:32 +1000 David Gibson wrote: ... > > > Thoughts above suggest a different direction, but here's what I was > > > thinking before: > > > > > > base board: > > > > > > connector { > > > /export/ "i2c" &i2c0; > > > }; > > > > > > addon: > > > eeprom@10 { > > > compatible = "foo,eeprom"; > > > bus-reg = <&i2c 0x10>; > > > } > > > > > > Or, if the addon had multiple i2c devices, maybe something like: > > > > > > board-i2c { > > > compatible = "i2c-simple-bridge"; > > > bus-ranges = <&i2c 0 0x3ff>; /* Whole addr space */ > > > eeprom@10 { > > > compatible = "foo,eeprom"; > > > reg = <0x10>; > > > } > > > widget@20 { > > > compatible = "vendor,widget"; > > > reg = <0x20>; > > > } > > > } > > > > > > Writing that, I realise I2C introduces some complications for this. > > > Because it has #size-cells = <0>, ranges doesn't really work (without > > > listing every single address to be translated). Likewise, because we > > > always need the parent bus phandle, we can't use the trick of an empty > > > 'ranges' to mean an identity mapping. > > > > > > We could invent encodings to address those, but given the addon with > > > multiple connectors case provides another incentive for a single > > > connector to allow adding nodes in multiple (but strictly enumerated) > > > places in the base device tree provides a better approach. > > > > and the "place in base device tree" is the goal of the extension bus. > > > > The strict enumeration of nodes enumerated is done by two means: > > - extension busses at connector level > > Those extensions are described as connector sub-nodes. > > The addon DT can only add nodes in those sub-nodes to describe devices > > connected to the relared extension bus. > > - export symbols > > An addon DT can only use symbols exported to reference symbols outside > > the addon DT itself. > > > > Can I assume that bus extensions we proposed (i2c-bus-extension and > > spi-bus-extension) could be a correct solution ? > > Maybe? I prefer the idea of a universal mechanism, not one that's > defined per-bus-type. > > > Also, IIUC the way bus extension operates is a bit different - nodes > would be "physically" added under the bus extension node, but treated > logically as if they go under the main bus. What I'm proposing here > is something at the actualy overlay application layer that allows > nodes to be added to different parts of the base device tree - so you > could add your i2c device under the main i2c bus. I think we should avoid this kind of node dispatching here and there in the base DT. We work on decoupling busses wired to a connector and dispatching nodes looks like this decoupling is ignored. IMHO, keeping devices available on an addon board as nodes under the connector is a real hardware representation. Also, at runtime, once an addon board DT is applied, when you look at your current DT either using /proc/device-tree or some links such as /sys/bus/devices/.../of_node, the connector and extension bus appear and clearly identify devices behind the connector. > > That approach does complicate removal, but its not as bad as overlays > at the moment, because a) it could be limited to adding new nodes, not > modifying existing ones and b) the connector would specify exactly the > places that additions are allowed. > I think bus extensions comply with a) and b). Yes, bus extensions need to be handled per-bus types but they have the advantage of keeping the hardware reality well described and visible at runtime in term of "wiring" topology. Whatever the solution, this will already be handled per-bus types. Only busses that support runtime DT node addition/removal (OF_RECONFIG_* notifications in the kernel implementation) will support adding or removing nodes. Your approach is more complex, dispatch node here and there and actually is also a per-bus types solution. I think, in order to choose between both solutions, the main question is: Do we want to dispatch nodes provided by an addon DT everywhere in the base DT ? IMHO, the answer is no. Rob, others, any opinion ? Best regards, Hervé