| 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: <20250911121103.40ccb112@bootlin.com>
Date: Thu, 11 Sep 2025 12:11:03 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Ayush Singh
<ayush@...gleboard.org>, Luca Ceresoli <luca.ceresoli@...tlin.com>,
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
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'.
--- 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 ?
Best regards,
Hervé
Powered by blists - more mailing lists