linux-kernel - Re: [PATCH v4 3/9] spi: support controllers with multiple data lanes

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: <2d7b3105-1bb4-40db-9a2b-dfc133b15840@baylibre.com>
Date: Mon, 12 Jan 2026 11:01:09 -0600
From: David Lechner <dlechner@...libre.com>
To: Andy Shevchenko <andriy.shevchenko@...el.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 3/9] spi: support controllers with multiple data lanes

On 12/27/25 9:16 AM, Andy Shevchenko wrote:
> On Fri, Dec 19, 2025 at 03:32:11PM -0600, David Lechner wrote:
>> Add support for SPI controllers with multiple physical SPI data lanes.
>> (A data lane in this context means lines connected to a serializer, so a
>> controller with two data lanes would have two serializers in a single
>> controller).
>>
>> This is common in the type of controller that can be used with parallel
>> flash memories, but can be used for general purpose SPI as well.
>>
>> To indicate support, a controller just needs to set ctlr->num_data_lanes
>> to something greater than 1. Peripherals indicate which lane they are
>> connected to via device tree (ACPI support can be added if needed).
>>
>> The spi-{tx,rx}-bus-width DT properties can now be arrays. The length of
>> the array indicates the number of data lanes, and each element indicates
>> the bus width of that lane. For now, we restrict all lanes to have the
>> same bus width to keep things simple. Support for an optional controller
>> lane mapping property is also implemented.
> 
> ...
> 
>> +#define SPI_DEVICE_DATA_LANE_CNT_MAX 8
> 
>> +	/* Multi-lane SPI controller support. */
>> +	u32			tx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX];
>> +	u32			num_tx_lanes;
>> +	u32			rx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX];
>> +	u32			num_rx_lanes;
> 
> This adds 8*4 + 4 + 8*4 + 4 bytes to the already big enough structure for
> the rather rare use cases. Can we start doing it separately and use just
> a pointer here?
> 

There are rarely more than a few SPI devices, so the tradeoff between
making the code more complex to handle the allocation vs. making the
struct just a bit smaller does not seem worth it to me.