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

[David Lechner <dlechner@baylibre.com>]

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.