linux-kernel - Re: [PATCH v4 2/9] spi: dt-bindings: add spi-{tx,rx}-lane-map properties

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aV-jQImroXxFqj3Z@debian-BULLSEYE-live-builder-AMD64>
Date: Thu, 8 Jan 2026 09:29:52 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	Michael Hennerich <michael.hennerich@...log.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Andy Shevchenko <andy@...nel.org>,
	Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH v4 2/9] spi: dt-bindings: add spi-{tx,rx}-lane-map
 properties

On 12/19, David Lechner wrote:
> Add spi-tx-lane-map and spi-rx-lane-map properties to the SPI peripheral
> device tree binding. These properties allow specifying the mapping of
> peripheral data lanes to controller data lanes. This is needed e.g. when
> some lanes are skipped on the controller side so that the controller
> can correctly route data to/from the peripheral.
> 
> Signed-off-by: David Lechner <dlechner@...libre.com>
> ---
> 
> v4 changes:
> - This replaces the data-lanes property from the previous revision. Now
>   there are separate properties for tx and rx lane maps. And instead of
>   being the primary property for determining the number of lanes, this
>   is only needed in special cases where the mapping is non-trivial.
> ---
>  .../devicetree/bindings/spi/spi-peripheral-props.yaml      | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> index 59ddead7da14..2f278f145f78 100644
> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> @@ -75,6 +75,13 @@ properties:
>        enum: [0, 1, 2, 4, 8]
>      default: [1]
>  
> +  spi-rx-lane-map:
> +    description: Mapping of peripheral RX lanes to controller RX lanes.
> +      Each index in the array represents a peripheral RX lane, and the value
> +      at that index represents the corresponding controller RX lane.
These are peripheral props so I guess RX is from peripheral perspective.
In that case, those would be routed to controller TX lanes, no?
Could maybe use MISO/MOSI or COPI/CIPO (Controller Out Peripheral In)
nomenclature but that might become too verboragic.

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    default: [0, 1, 2, 3, 4, 5, 6, 7]
> +
>    spi-rx-delay-us:
>      description:
>        Delay, in microseconds, after a read transfer.
> @@ -99,6 +106,13 @@ properties:
>        enum: [0, 1, 2, 4, 8]
>      default: [1]
>  
> +  spi-tx-lane-map:
> +    description: Mapping of peripheral TX lanes to controller TX lanes.
> +      Each index in the array represents a peripheral TX lane, and the value
> +      at that index represents the corresponding controller TX lane.
Similar thoughts about the tx side.