Re: [PATCH v3 3/7] spi: add multi_lane_mode field to struct spi_transfer

[Andy Shevchenko]

On Mon, Dec 01, 2025 at 08:20:41PM -0600, David Lechner wrote:
> Add a new multi_lane_mode field to struct spi_transfer to allow
> peripherals that support multiple SPI lanes to be used with a single
> SPI controller.
> 
> This requires both the peripheral and the controller to have multiple
> serializers connected to separate data lanes. It could also be used with
> a single controller and multiple peripherals that are functioning as a
> single logical device (similar to parallel memories).
> 
> The possible values for this field have the following semantics:

I believe it's too much for a commit message and will be hidden deeply
for the (potential) user. Can we rather create or update the respective
documentation file?

>   * @rx_nbits: number of bits used for reading. If 0 the default
>   *      (SPI_NBITS_SINGLE) is used.
> + * @multi_lane_mode: How to serialize data on multiple lanes. One of the
> + *      SPI_MULTI_LANE_MODE_* values.
>   * @len: size of rx and tx buffers (in bytes)
>   * @speed_hz: Select a speed other than the device default for this
>   *      transfer. If 0 the default (from @spi_device) is used.
> @@ -1112,6 +1114,10 @@ struct spi_transfer {
>  	unsigned	cs_change:1;
>  	unsigned	tx_nbits:4;
>  	unsigned	rx_nbits:4;
> +	unsigned	multi_lane_mode: 2;
> +#define SPI_MULTI_LANE_MODE_SINGLE	0 /* only use single lane */
> +#define SPI_MULTI_LANE_MODE_STRIPE	1 /* one data word per lane */
> +#define SPI_MULTI_LANE_MODE_MIRROR	2 /* same word sent on all lanes */
>  	unsigned	timestamped:1;
>  	bool		dtr_mode;
>  #define	SPI_NBITS_SINGLE	0x01 /* 1-bit transfer */

Seems to me that this also fell apart, as this define sounds like a part of
*x_bits above and your patch makes it even diverse further. Can we keep grouped
members to be in a group?

-- 
With Best Regards,
Andy Shevchenko