linux-kernel - Re: [PATCH v4 5/9] spi: Documentation: add page on multi-lane support

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_em6a5vxi_AZGg@debian-BULLSEYE-live-builder-AMD64>
Date: Thu, 8 Jan 2026 13:43:07 -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 5/9] spi: Documentation: add page on multi-lane support

On 01/08, David Lechner wrote:
> On 1/8/26 6:44 AM, Marcelo Schmitt wrote:
> > Actually, one more thing ...
> > 
> > On 12/19, David Lechner wrote:
> >> Add a new page to Documentation/spi/ describing how multi-lane SPI
> >> support works. This is uncommon functionality so it deserves its own
> >> documentation page.
> >>
> >> Signed-off-by: David Lechner <dlechner@...libre.com>
> >> ---
> > ...
> >> +- :c:macro:`SPI_MULTI_BUS_MODE_STRIPE`: Send or receive two different data words
> >> +    at the same time, one on each lane. This means that the buffer needs to be
> >> +    sized to hold data for all lanes. Data is interleaved in the buffer, with
> >> +    the first word corresponding to lane 0, the second to lane 1, and so on.
> >> +    Once the last lane is used, the next word in the buffer corresponds to lane
> >> +    0 again. Accordingly, the buffer size must be a multiple of the number of
> >> +    lanes. This mode works for both reads and writes.
> >> +
> >> +    Example::
> >> +
> >> +        struct spi_transfer xfer = {
> >> +            .rx_buf = rx_buf,
> >> +            .len = 2,
> >> +            .multi_lane_mode = SPI_MULTI_BUS_MODE_STRIPE,
> >> +        };
> >> +
> >> +        spi_sync_transfer(spi, &xfer, 1);
> >> +
> >> +    Each tx wire has a different data word sent simultaneously::
> > In this example, the controller is reading data so the rx wires have different
> > data word received?
> 
> Yes, I tried to make that clear below by having a different value
> for each.

Yes, that part is clear. What came a bit odd when reading the doc is that the
first two examples ilustrate the controller writing data to the peripheral and
refer to buffers from controller's perspective ('sent over the tx wire', 
'data is mirrored on each tx wire').
IIUC, in this third example, the controller is reading data so we would describe
it like 'Each rx read has a different data word read simultaneously', no?


> > 
> >> +
> >> +        controller    < data bits <     peripheral
> >> +        ----------   ----------------   ----------
> >> +            SDI 0    0-0-0-1-0-0-0-1    SDO 0
> >> +            SDI 1    1-0-0-0-1-0-0-0    SDO 1
> >> +
> >> +    After the transfer, ``rx_buf[0] == 0x11`` (word from SDO 0) and
> >> +    ``rx_buf[1] == 0x88`` (word from SDO 1).
>