| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250912114039.30e8422f@booty>
Date: Fri, 12 Sep 2025 11:40:39 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Herve Codina <herve.codina@...tlin.com>
Cc: David Gibson <david@...son.dropbear.id.au>, Geert Uytterhoeven
<geert@...ux-m68k.org>, Ayush Singh <ayush@...gleboard.org>, Krzysztof
Kozlowski <krzk@...nel.org>, devicetree@...r.kernel.org, Rob Herring
<robh@...nel.org>, Jason Kridner <jkridner@...il.com>, Krzysztof Kozlowski
<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
devicetree-compiler@...r.kernel.org, linux-kernel@...r.kernel.org, Thomas
Petazzoni <thomas.petazzoni@...tlin.com>, Andrew Davis <afd@...com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
at ELCE
Hello,
On Thu, 11 Sep 2025 12:11:03 +0200
Herve Codina <herve.codina@...tlin.com> wrote:
> Hi David, Geert,
>
> On Wed, 10 Sep 2025 14:36:46 +1000
> David Gibson <david@...son.dropbear.id.au> wrote:
>
> ...
> > >
> > > A PMOD Type 2A (expanded SPI) connector provides SPI and 4 GPIOS.
> > > A PMOD Type 6A (expanded I2C) connector provides I2C and 4 GPIOS.
> > > Hence a plug-in board that needs SPI, I2C, and a few GPIOs, would need
> > > to plug into two PMOD connectors.
> > >
> > > Or:
> > > A PMOD Type 1A (expanded GPIO) connector provides 8 GPIOS.
> > > Hence a non-multiplexed dual 7-segment LED display plug-in board needs
> > > 14 or 16 GPIOS, and thus would plug into two PMOD connectors.
> > >
> > > To plug into two connectors, a mapping needs to provided between two
> > > connectors on base and add-on board.
> > >
>
> Base on this, let me draft some ideas to have some basis to move forward.
>
> Suppose:
> - A base board with:
> 2x PMOD Type 2A (SPI + 4 GPIOS)
> 1x PMOD Type 6A (I2C + 4 GPIOS)
> 3x PMOD Type 1A ( 8 GPIOS)
>
> - An addon board which needs:
> - 1x PMOD type 2A
> - 2x PMOD type 1A
>
> Hardware connection:
> base board addon board
> PMOD 2A #0 +------+ PMOD 2A
> PMOD 2A #1
> PMOD 6A
> PMOD 1A #0
> PMOD 1A #1 +------+ PMOD 1A I
> PMOD 1A #2 +------+ PMOD 1A II
>
> The base board 'PMOD 1A #0' is not connected to the addon board.
> The addon board uses the base board PMOD 1A #1 and #2.
>
>
> The base board DT:
> pmods {
> compatible = "pmods";
>
> pmod_2a_0: pmod-2a-0 {
> compatible = "pmod-2a"
>
> /* Describe 4 gpios connected to this connector */
> gpio-map = < 0 &gpio 10>,
> ...
> < 3 &gpio 43>;
>
> /* Describe the bus connected to this connector */
> spi_bus_2a_0: spi-bus {
> compatible = "spi-bus-extension";
> spi-parent = <&spi2>;
> };
>
> /* Export symbols related to this connector */
> export-symbols {
> pmod-2a = <&pmod_2a_0>;
> spi = <&spi_bus_2a_0>;
> ...
> };
> };
>
> pmod_2a_1: pmod-2a-1 {
> compatible = "pmod-2a"
>
> /* Describe 4 gpios connected to this connector */
> gpio-map = ...
>
> /* Describe the bus connected to this connector */
> spi_bus_2a_1: spi-bus { ... };
>
> /* Export symbols related to this connector */
> export-symbols {
> pmod_2a = <&pmod_2a_1>;
> spi = <&spi_bus_2a_1>;
> ...
> };
> };
>
> pmod_6a: pmod-6a {
> compatible = "pmod-6a";
> ...
> export-symbols {
> pmod_6a = <&pmod_6a>;
> ...
> };
> };
>
> pmod_1a_0: pmod-1a-0 {
> compatible = "pmod-1a"
>
> /* Describe 8 gpios connected to this connector */
> gpio-map = < 0 &gpio 16>,
> ...
> < 7 &gpio 33>;
>
> export-symbols {
> pmod_1a = <&pmod_1a_0>;
> gpio0_muxed_as_gpio = <&pin_mux_xxxx>;
> gpio1_muxed_as_gpio = <&pin_mux_yyyy>;
> gpio2_muxed_as_gpio = <&pin_mux_zzzz>;
> };
> };
>
> pmod_1a_1: pmod-1a-1 {
> compatible = "pmod-1a"
>
> /* Describe 8 gpios connected to this connector */
> ...
>
> export-symbols {
> pmod_1a = <&pmod_1a_1>;
> };
> };
>
> pmod_1a_2: pmod-1a-2 {
> compatible = "pmod-1a"
>
> /* Describe 8 gpios connected to this connector */
> ...
>
> export-symbols {
> pmod_1a = <&pmod_1a_2>;
> };
> };
> };
>
>
> -- Question 1: How to describe resources needed by the addon
>
> On the addon side, we need to tell that we need 1 PMOD 2A and 2
> PMODs 1A (named i and ii).
>
> Proposal supposing that this description will be applied at
> base board pmods node (the one grouping pmod connectors):
>
> \{ or ??? corresponding to the entry point of the addon
> import-symbols {
> pmod_2a = "pmod_2a";
> pmod_1a_i = "pmod_1a";
> pmod_1a_ii = "pmod_1a";
> };
>
> &pmod_2a {
> spi-bus {
> regulator@0 {
> compatible "gpio-regulator";
> pinctrl-0 = <&pmod_1a_i.gpio2_muxed_as_gpio>;
> enable-gpios = <&pmod_1a_i 2>; /* Use GPIO #2 available on PMOD 1A I */
> };
>
> ...
> };
> };
>
> Import-symbols asked for symbols with local name and type (compatible string ?).
> for instance 'pmod_1a_i = "pmod_2a";' means:
> Hey I refernce localy 'pmod_1a_i' but I don't define it and so 'pmod_1a_i' should
> be remapped to a symbol, probably a node of my expected type "pmod_2a".
>
> Also, we can node the syntax:
> &pmod_1a_i.gpio2_muxed_as_gpio
>
> meaning I use the symbols gpio2_muxed_as_gpio provided by pmod_1a_i (namespace).
> In other word, to have the addon DT successfully applied,
> the node remapped to 'pmod_1a_i' has to export the symbol 'gpio2_muxed_as_gpio'.
Thanks for taking time to prepare a complete example. I think this
example is very effective as it exposes perhaps all the features we are
discussing.
I consider it pseudocode, i.e. the syntax may not be OK, but that's not
too relevant at this point of the discussion. But as far as I can say
it has the right information at the right place, and IMO that's what we
need to iron out in the first place.
> --- Question 2: how to perform the mapping between pmods available on the
> base board and pmods needed by the addon board.
>
> The addon board describes what it is expected:
> import-symbols {
> pmod_2a = "pmod_2a";
> pmod_1a_i = "pmod_1a";
> pmod_1a_ii = "pmod_1a";
> };
>
> Based on compatible string:
> pmod_2a expected by the addon can be remapped to the node
> pmod-2a-0 or pmod-2a-1 described in the base board.
>
> pmod_1a_i and pmod_1a_ii expected by the addon can be remapped
> to pmod-1a-0, pmod-1a-1, pmod-1a-2.
>
> We need some more information to set correct mapping
> pmod_2a <---> pmod-2a-0
> pmod_1a_i <---> pmod-1a-1
> pmod_1a_ii <---> pmod-1a-2
>
> Can we imagine that this mapping is set by the compatible "pmods"
> driver base on some specific external information.
> - Read info from addon to have some more hardware connection
> details (not sure it is relavant with PMODs connector)
>
> - Expect this information from user-space ?
>
> - Any other ideas ?
I'd say the only possible answer to question 2 is "this is specific to
each connector type and thus to each connector driver".
As you just described in [0], some connector types have model discovery
capabilities so the driver can do on its own. In principle this might
apply to addons using multiple connectors.
However for PMODs AFAIK there is no discovery at all, so the driver must
be instructed by the user.
[0] https://lore.kernel.org/all/20250911122333.2e25e208@bootlin.com/
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists