Re: [PATCH v4 1/9] spi: dt-bindings: change spi-{rx,tx}-bus-width to arrays

From: Rob Herring (Arm)

Date: Tue Jan 06 2026 - 11:36:14 EST



On Fri, 19 Dec 2025 15:32:09 -0600, David Lechner wrote:
> Change spi-rx-bus-width and spi-tx-bus-width properties from single
> uint32 values to arrays of uint32 values. This allows describing SPI
> peripherals connected to controllers that have multiple data lanes for
> receiving or transmitting two or more words in parallel.
>
> Each index in the array corresponds to a physical data lane (one or more
> wires depending on the bus width). Additional mapping properties will be
> needed in cases where a lane on the controller or peripheral is skipped.
>
> Bindings that make use of this property are updated in the same commit
> to avoid validation errors.
>
> The adi,ad4030 binding can now better describe the chips multi-lane
> capabilities, so that binding is refined and gets a new example.
>
> Converting from single uint32 to array of uint32 does not break .dts/
> .dtb files since there is no difference between specifying a single
> uint32 value and an array with a single uint32 value in devicetree.
>
> Signed-off-by: David Lechner <dlechner@xxxxxxxxxxxx>
> ---
>
> v4 changes:
> - New patch to replace data-lanes property patch.
>
> In v3, Rob suggested possibly splitting the spi-controller.yaml file
> to have a way to make most SPI controllers have maxItems: 1 for these
> properties. I would like to avoid that because it doesn't seem scalable,
> e.g. if we need another similar split in the future, the number of
> combinations would grow exponentially (factorially?). I have an idea to
> instead do this using $dynamicAnchor and $dynamicRef, but dt-schema
> doesn't currently support that. So I propose we do the best we can for
> now with the current dt-schema and make further improvements later.
>
> Also, in v3, I suggested that we could have leading 0s in the arrays
> to indicate unused lanes. But after further consideration, I think it's
> better to have separate lane-mapping properties for that purpose. It
> will be easier to explain and parse and be a bit more flexible that way.
> ---
> .../bindings/display/panel/sitronix,st7789v.yaml | 5 +--
> .../devicetree/bindings/iio/adc/adi,ad4030.yaml | 42 +++++++++++++++++++++-
> .../devicetree/bindings/iio/adc/adi,ad4695.yaml | 5 +--
> .../bindings/spi/allwinner,sun4i-a10-spi.yaml | 6 ++--
> .../bindings/spi/allwinner,sun6i-a31-spi.yaml | 6 ++--
> .../bindings/spi/nvidia,tegra210-quad.yaml | 6 ++--
> .../bindings/spi/spi-peripheral-props.yaml | 26 ++++++++++----
> 7 files changed, 79 insertions(+), 17 deletions(-)
>

You'll need to add spi/andestech,ae350-spi.yaml which is only in Mark's
tree, but otherwise:

Reviewed-by: Rob Herring (Arm) <robh@xxxxxxxxxx>