Documentation/spi/multiple-data-lanes.rst | 30 ++++++ drivers/spi/spi-axi-spi-engine.c | 106 +++++++++++++++++----- drivers/spi/spi.c | 97 +++++++++++++++++--- include/linux/spi/spi.h | 12 +++ 4 files changed, 206 insertions(+), 39 deletions(-)
This series introduces two SPI subsystem features: per-transfer chipselect masks and multi-CS device support. Together they address the multi-device setup described in [1] and the limitation noted in [2], where no SPI controller completely handles logical chip selects beyond the first one. The first part of the set addresses multi-CS support. Some SPI controllers can assert multiple chip selects simultaneously, but the existing code hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), preventing this from working. The second part addresses dynamic lane selection for STRIPE mode. In SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always active. Some peripherals need to select a different subset of rx/tx lanes per transfer. New fields are added to the spi_transfer struct to allow drivers to specify which lanes to use for each transfer. The documentation is also updated to describe this new behavior. [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ Jonathan Santos (6): spi: support simultaneous assertion of multiple CS spi: add per-transfer CS mask spi: spi-engine-ex: Add support for multi-CS devices spi: Documentation: multiple-data-lanes: describe rx and tx lane mask spi: add rx and tx lane mask to spi_transfer struct spi: axi-spi-engine: add support for dynamic multi-lane selection Documentation/spi/multiple-data-lanes.rst | 30 ++++++ drivers/spi/spi-axi-spi-engine.c | 106 +++++++++++++++++----- drivers/spi/spi.c | 97 +++++++++++++++++--- include/linux/spi/spi.h | 12 +++ 4 files changed, 206 insertions(+), 39 deletions(-) base-commit: 093239070573637ad2b4cb56abc9c4c7ee109294 -- 2.34.1
On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote: > This series introduces two SPI subsystem features: per-transfer chipselect > masks and multi-CS device support. Together they address the multi-device > setup described in [1] and the limitation noted in [2], where no SPI > controller completely handles logical chip selects beyond the first one. > > The first part of the set addresses multi-CS support. Some SPI controllers > can assert multiple chip selects simultaneously, but the existing code > hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), > preventing this from working. > > The second part addresses dynamic lane selection for STRIPE mode. In > SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always > active. Some peripherals need to select a different subset of rx/tx lanes > per transfer. New fields are added to the spi_transfer struct to allow > drivers to specify which lanes to use for each transfer. The documentation > is also updated to describe this new behavior. > > [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t > [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ > > Jonathan Santos (6): > spi: support simultaneous assertion of multiple CS > spi: add per-transfer CS mask > spi: spi-engine-ex: Add support for multi-CS devices > spi: Documentation: multiple-data-lanes: describe rx and tx lane mask > spi: add rx and tx lane mask to spi_transfer struct > spi: axi-spi-engine: add support for dynamic multi-lane selection It would be nice to include an actual user for this in the series. - Nuno Sá > > Documentation/spi/multiple-data-lanes.rst | 30 ++++++ > drivers/spi/spi-axi-spi-engine.c | 106 +++++++++++++++++----- > drivers/spi/spi.c | 97 +++++++++++++++++--- > include/linux/spi/spi.h | 12 +++ > 4 files changed, 206 insertions(+), 39 deletions(-) > > > base-commit: 093239070573637ad2b4cb56abc9c4c7ee109294 > -- > 2.34.1 >
On 7/14/26 5:29 AM, Nuno Sá wrote:
> On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote:
>> This series introduces two SPI subsystem features: per-transfer chipselect
>> masks and multi-CS device support. Together they address the multi-device
>> setup described in [1] and the limitation noted in [2], where no SPI
>> controller completely handles logical chip selects beyond the first one.
>>
>> The first part of the set addresses multi-CS support. Some SPI controllers
>> can assert multiple chip selects simultaneously, but the existing code
>> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(),
>> preventing this from working.
>>
>> The second part addresses dynamic lane selection for STRIPE mode. In
>> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always
>> active. Some peripherals need to select a different subset of rx/tx lanes
>> per transfer. New fields are added to the spi_transfer struct to allow
>> drivers to specify which lanes to use for each transfer. The documentation
>> is also updated to describe this new behavior.
>>
>> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t
>> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/
>>
>> Jonathan Santos (6):
>> spi: support simultaneous assertion of multiple CS
>> spi: add per-transfer CS mask
>> spi: spi-engine-ex: Add support for multi-CS devices
>> spi: Documentation: multiple-data-lanes: describe rx and tx lane mask
>> spi: add rx and tx lane mask to spi_transfer struct
>> spi: axi-spi-engine: add support for dynamic multi-lane selection
>
> It would be nice to include an actual user for this in the series.
Agree.
For context, here is the scenario from [1] (with arrow directions fixed):
+---------------+
| ADC 0 |
| |
| SYNC_IN|<--+---------------------------+
| DRDY0|---|------------------------+ |
| | | | | +------------+
| SCLK0|<--|------+ | | | HOST |
| SDI0|<--|------|--+ | | | |
| CS0|<--|------|--|-----------+ | +---|ADC_SYNC |
| DOUT0|---|------|--|--------+ | | | |
| | | | | | | | | |
+---------------+ | +--|--------|--|--|------|SCLK |
| | +--------|--|--|------|MOSI |
+---------------+ | | | | | | | |
| ADC 1 | | | | | | | | |
| | | | | | | +----->|DRDY0 |
| SYNC_IN|<--+ | | | +---------|CS0 |
| DRDY1|---|------|--|----+ +----------->|MISO0 |
| | | | | | | |
| SCLK1|<--|------+ | | | |
| SDI1|<--|------|--+ +--------------->|DRDY1 |
| CS1|<--|------|--|---------------------|CS1 |
| DOUT1|---|------|--|-------------------->|MISO1 |
| | | | | | |
+---------------+ | | | | . |
| | | | . |
... | | | | . |
| | | | |
+---------------+ | | | +------->|DRDYN |
| ADC N | | | | | +------|CSN |
| | | | | | | +--->|MISON |
| SYNC_IN|<--+ | | | | | | |
| DRDYN|----------|--|------------+ | | +------------+
| | | | | |
| SCLKN|<---------+ | | |
| SDIN|<------------+ | |
| CSN|<---------------------------+ |
| DOUTN|------------------------------+
| |
+---------------+
And the proposed DT from the discussion in [1].
spi {
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "adi,adaq7768-1";
reg = <0>, <1>, <2>, <3>;
spi-rx-bus-width = <1>, <1>, <1>, <1>;
/* other properties */
};
};
As a refresher, the idea is that this is considered to be one big ADC
with more channels (for simultaneous sampling) even though it is
physically multiple chips.
Currently, this series is treating CS selection and mutli-lane SPI line
selection as completely independent. However, clearly certain spi-rx-bus
lines are tightly coupled with certain CS lines.
To reflect that (and easier to use in peripheral drivers), I think we
could bake this correlation into the SPI core code.
So struct spi_device.rx_lane_map would become a 2-D array where the
first index is the logical CS (following the pattern of .chip_select)
and the second index is the existing one for the data lane.
The trivial implementation would be to assume that reg and spi-rx-bus-width
have the same length and there is just a 1-to-1 correspondence (first data
lane is associated with first CS, and so on).
And we could add a new DT property for more complex mappings (multiple
data lanes per CS or wires not connected in logical order). We probably
don't need to do that right now though if there are no expected users
at the moment.
Then we would only need to add the CS selection to struct spi_transfer
and the controller driver would just use the map to pick the correct
data lanes based on other parameters as it does now. (So no need to
add .rx_lane_mask to struct spi_transfer.)
This way, the ADC (SPI peripheral driver) can set 1 CS in order to
configure individual chips and then set all CS to read sample data.
And all of the data lane selection is all handled transparently between
the core SPI code and the SPI controller driver.
(And obviously everything above applies to tx too, I just wrote rx
everywhere to keep it shorter.)
>
> - Nuno Sá
>
>>
>> Documentation/spi/multiple-data-lanes.rst | 30 ++++++
>> drivers/spi/spi-axi-spi-engine.c | 106 +++++++++++++++++-----
>> drivers/spi/spi.c | 97 +++++++++++++++++---
>> include/linux/spi/spi.h | 12 +++
>> 4 files changed, 206 insertions(+), 39 deletions(-)
>>
>>
>> base-commit: 093239070573637ad2b4cb56abc9c4c7ee109294
>> --
>> 2.34.1
>>
On 07/14, David Lechner wrote:
> On 7/14/26 5:29 AM, Nuno Sá wrote:
> > On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote:
> >> This series introduces two SPI subsystem features: per-transfer chipselect
> >> masks and multi-CS device support. Together they address the multi-device
> >> setup described in [1] and the limitation noted in [2], where no SPI
> >> controller completely handles logical chip selects beyond the first one.
> >>
> >> The first part of the set addresses multi-CS support. Some SPI controllers
> >> can assert multiple chip selects simultaneously, but the existing code
> >> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(),
> >> preventing this from working.
> >>
> >> The second part addresses dynamic lane selection for STRIPE mode. In
> >> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always
> >> active. Some peripherals need to select a different subset of rx/tx lanes
> >> per transfer. New fields are added to the spi_transfer struct to allow
> >> drivers to specify which lanes to use for each transfer. The documentation
> >> is also updated to describe this new behavior.
> >>
> >> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t
> >> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/
> >>
> >> Jonathan Santos (6):
> >> spi: support simultaneous assertion of multiple CS
> >> spi: add per-transfer CS mask
> >> spi: spi-engine-ex: Add support for multi-CS devices
> >> spi: Documentation: multiple-data-lanes: describe rx and tx lane mask
> >> spi: add rx and tx lane mask to spi_transfer struct
> >> spi: axi-spi-engine: add support for dynamic multi-lane selection
Hi david,
Thanks for the suggestions!
> >
> > It would be nice to include an actual user for this in the series.
>
> Agree.
>
> For context, here is the scenario from [1] (with arrow directions fixed):
>
> +---------------+
> | ADC 0 |
> | |
> | SYNC_IN|<--+---------------------------+
> | DRDY0|---|------------------------+ |
> | | | | | +------------+
> | SCLK0|<--|------+ | | | HOST |
> | SDI0|<--|------|--+ | | | |
> | CS0|<--|------|--|-----------+ | +---|ADC_SYNC |
> | DOUT0|---|------|--|--------+ | | | |
> | | | | | | | | | |
> +---------------+ | +--|--------|--|--|------|SCLK |
> | | +--------|--|--|------|MOSI |
> +---------------+ | | | | | | | |
> | ADC 1 | | | | | | | | |
> | | | | | | | +----->|DRDY0 |
> | SYNC_IN|<--+ | | | +---------|CS0 |
> | DRDY1|---|------|--|----+ +----------->|MISO0 |
> | | | | | | | |
> | SCLK1|<--|------+ | | | |
> | SDI1|<--|------|--+ +--------------->|DRDY1 |
> | CS1|<--|------|--|---------------------|CS1 |
> | DOUT1|---|------|--|-------------------->|MISO1 |
> | | | | | | |
> +---------------+ | | | | . |
> | | | | . |
> ... | | | | . |
> | | | | |
> +---------------+ | | | +------->|DRDYN |
> | ADC N | | | | | +------|CSN |
> | | | | | | | +--->|MISON |
> | SYNC_IN|<--+ | | | | | | |
> | DRDYN|----------|--|------------+ | | +------------+
> | | | | | |
> | SCLKN|<---------+ | | |
> | SDIN|<------------+ | |
> | CSN|<---------------------------+ |
> | DOUTN|------------------------------+
> | |
> +---------------+
>
>
> And the proposed DT from the discussion in [1].
>
> spi {
> #address-cells = <1>;
> #size-cells = <0>;
>
> adc@0 {
> compatible = "adi,adaq7768-1";
> reg = <0>, <1>, <2>, <3>;
>
> spi-rx-bus-width = <1>, <1>, <1>, <1>;
>
> /* other properties */
> };
> };
>
> As a refresher, the idea is that this is considered to be one big ADC
> with more channels (for simultaneous sampling) even though it is
> physically multiple chips.
>
> Currently, this series is treating CS selection and mutli-lane SPI line
> selection as completely independent. However, clearly certain spi-rx-bus
> lines are tightly coupled with certain CS lines.
>
> To reflect that (and easier to use in peripheral drivers), I think we
> could bake this correlation into the SPI core code.
>
> So struct spi_device.rx_lane_map would become a 2-D array where the
> first index is the logical CS (following the pattern of .chip_select)
> and the second index is the existing one for the data lane.
>
> The trivial implementation would be to assume that reg and spi-rx-bus-width
> have the same length and there is just a 1-to-1 correspondence (first data
> lane is associated with first CS, and so on).
>
I like the idea of binding the CS to rx/tx lanes. I have a concern though: could this 1-1 correspondence break the current implementations where we have multiple data lanes per channel and only one CS? (and in those cases spi-rx-lane-map is ommited, so it is used the default mapping based on the spi-rx-bus-width).
Also, could we extend the ancillary device framework to deal with the multiple data lanes? Maybe it is easier to bind the logical CS with the data lanes in there because there is the assumption of sub-devices with multiple CS (even if we don't use the ancillary device for this case).
> And we could add a new DT property for more complex mappings (multiple
> data lanes per CS or wires not connected in logical order). We probably
> don't need to do that right now though if there are no expected users
> at the moment.
>
> Then we would only need to add the CS selection to struct spi_transfer
> and the controller driver would just use the map to pick the correct
> data lanes based on other parameters as it does now. (So no need to
> add .rx_lane_mask to struct spi_transfer.)
>
Yes, this is less prone to mistakes.
> This way, the ADC (SPI peripheral driver) can set 1 CS in order to
> configure individual chips and then set all CS to read sample data.
> And all of the data lane selection is all handled transparently between
> the core SPI code and the SPI controller driver.
>
Another concern with the CS selection is how to handle this in the
driver using regmap (i will add the driver patches in the next version).
I Created custom regmap write and read handlers and a regmap instace for
each sub-device. Each instace have a context data with the corresponding
CS mask, but it looks overcomplicated. Dealing with this correlation in
the ancillary would be simpler. Don't know if this makes sense.
> (And obviously everything above applies to tx too, I just wrote rx
> everywhere to keep it shorter.)
>
> >
> > - Nuno Sá
> >
> >>
> >> Documentation/spi/multiple-data-lanes.rst | 30 ++++++
> >> drivers/spi/spi-axi-spi-engine.c | 106 +++++++++++++++++-----
> >> drivers/spi/spi.c | 97 +++++++++++++++++---
> >> include/linux/spi/spi.h | 12 +++
> >> 4 files changed, 206 insertions(+), 39 deletions(-)
> >>
> >>
> >> base-commit: 093239070573637ad2b4cb56abc9c4c7ee109294
> >> --
> >> 2.34.1
> >>
On 7/16/26 11:50 AM, Jonathan Santos wrote:
> On 07/14, David Lechner wrote:
>> On 7/14/26 5:29 AM, Nuno Sá wrote:
>>> On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote:
>>>> This series introduces two SPI subsystem features: per-transfer chipselect
>>>> masks and multi-CS device support. Together they address the multi-device
>>>> setup described in [1] and the limitation noted in [2], where no SPI
>>>> controller completely handles logical chip selects beyond the first one.
>>>>
>>>> The first part of the set addresses multi-CS support. Some SPI controllers
>>>> can assert multiple chip selects simultaneously, but the existing code
>>>> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(),
>>>> preventing this from working.
>>>>
>>>> The second part addresses dynamic lane selection for STRIPE mode. In
>>>> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always
>>>> active. Some peripherals need to select a different subset of rx/tx lanes
>>>> per transfer. New fields are added to the spi_transfer struct to allow
>>>> drivers to specify which lanes to use for each transfer. The documentation
>>>> is also updated to describe this new behavior.
>>>>
>>>> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t
>>>> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/
>>>>
>>>> Jonathan Santos (6):
>>>> spi: support simultaneous assertion of multiple CS
>>>> spi: add per-transfer CS mask
>>>> spi: spi-engine-ex: Add support for multi-CS devices
>>>> spi: Documentation: multiple-data-lanes: describe rx and tx lane mask
>>>> spi: add rx and tx lane mask to spi_transfer struct
>>>> spi: axi-spi-engine: add support for dynamic multi-lane selection
>
> Hi david,
> Thanks for the suggestions!
>
>>>
>>> It would be nice to include an actual user for this in the series.
>>
>> Agree.
>>
>> For context, here is the scenario from [1] (with arrow directions fixed):
>>
>> +---------------+
>> | ADC 0 |
>> | |
>> | SYNC_IN|<--+---------------------------+
>> | DRDY0|---|------------------------+ |
>> | | | | | +------------+
>> | SCLK0|<--|------+ | | | HOST |
>> | SDI0|<--|------|--+ | | | |
>> | CS0|<--|------|--|-----------+ | +---|ADC_SYNC |
>> | DOUT0|---|------|--|--------+ | | | |
>> | | | | | | | | | |
>> +---------------+ | +--|--------|--|--|------|SCLK |
>> | | +--------|--|--|------|MOSI |
>> +---------------+ | | | | | | | |
>> | ADC 1 | | | | | | | | |
>> | | | | | | | +----->|DRDY0 |
>> | SYNC_IN|<--+ | | | +---------|CS0 |
>> | DRDY1|---|------|--|----+ +----------->|MISO0 |
>> | | | | | | | |
>> | SCLK1|<--|------+ | | | |
>> | SDI1|<--|------|--+ +--------------->|DRDY1 |
>> | CS1|<--|------|--|---------------------|CS1 |
>> | DOUT1|---|------|--|-------------------->|MISO1 |
>> | | | | | | |
>> +---------------+ | | | | . |
>> | | | | . |
>> ... | | | | . |
>> | | | | |
>> +---------------+ | | | +------->|DRDYN |
>> | ADC N | | | | | +------|CSN |
>> | | | | | | | +--->|MISON |
>> | SYNC_IN|<--+ | | | | | | |
>> | DRDYN|----------|--|------------+ | | +------------+
>> | | | | | |
>> | SCLKN|<---------+ | | |
>> | SDIN|<------------+ | |
>> | CSN|<---------------------------+ |
>> | DOUTN|------------------------------+
>> | |
>> +---------------+
>>
>>
>> And the proposed DT from the discussion in [1].
>>
>> spi {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> adc@0 {
>> compatible = "adi,adaq7768-1";
>> reg = <0>, <1>, <2>, <3>;
>>
>> spi-rx-bus-width = <1>, <1>, <1>, <1>;
>>
>> /* other properties */
>> };
>> };
>>
>> As a refresher, the idea is that this is considered to be one big ADC
>> with more channels (for simultaneous sampling) even though it is
>> physically multiple chips.
>>
>> Currently, this series is treating CS selection and mutli-lane SPI line
>> selection as completely independent. However, clearly certain spi-rx-bus
>> lines are tightly coupled with certain CS lines.
>>
>> To reflect that (and easier to use in peripheral drivers), I think we
>> could bake this correlation into the SPI core code.
>>
>> So struct spi_device.rx_lane_map would become a 2-D array where the
>> first index is the logical CS (following the pattern of .chip_select)
>> and the second index is the existing one for the data lane.
>>
>> The trivial implementation would be to assume that reg and spi-rx-bus-width
>> have the same length and there is just a 1-to-1 correspondence (first data
>> lane is associated with first CS, and so on).
>>
> I like the idea of binding the CS to rx/tx lanes. I have a concern though: could this 1-1 correspondence break the current implementations where we have multiple data lanes per channel and only one CS? (and in those cases spi-rx-lane-map is ommited, so it is used the default mapping based on the spi-rx-bus-width).
I don't think it should break anything. The logic can be something like:
if (spi->num_chipselect <= 1) {
/* Existing behavior */
} else if (spi->num_chipselect == spi->num_rx_lanes) {
/* New 1:1 mapping behavior */
} else {
/* REVISIT: add new firmware mapping description if needed */
return -ENOTSUPP;
}
>
> Also, could we extend the ancillary device framework to deal with the multiple data lanes? Maybe it is easier to bind the logical CS with the data lanes in there because there is the assumption of sub-devices with multiple CS (even if we don't use the ancillary device for this case).
I would not make the change if we are not going to use it (other than
perhaps returning -ENOTSUPP if someone tries to use it).
>
>> And we could add a new DT property for more complex mappings (multiple
>> data lanes per CS or wires not connected in logical order). We probably
>> don't need to do that right now though if there are no expected users
>> at the moment.
>>
>> Then we would only need to add the CS selection to struct spi_transfer
>> and the controller driver would just use the map to pick the correct
>> data lanes based on other parameters as it does now. (So no need to
>> add .rx_lane_mask to struct spi_transfer.)
>>
>
> Yes, this is less prone to mistakes.
>
>> This way, the ADC (SPI peripheral driver) can set 1 CS in order to
>> configure individual chips and then set all CS to read sample data.
>> And all of the data lane selection is all handled transparently between
>> the core SPI code and the SPI controller driver.
>>
>
> Another concern with the CS selection is how to handle this in the
> driver using regmap (i will add the driver patches in the next version).
> I Created custom regmap write and read handlers and a regmap instace for
> each sub-device. Each instace have a context data with the corresponding
> CS mask, but it looks overcomplicated. Dealing with this correlation in
> the ancillary would be simpler. Don't know if this makes sense.
Could we just have 4 regmaps since we would have to do that anyway if
we used ancillary devices.
>
>> (And obviously everything above applies to tx too, I just wrote rx
>> everywhere to keep it shorter.)
>>
>>>
If we did go the ancillary device route though, I suppose we could use
that rather than adding a cs selection to struct spi_transfer. Instead,
we would just add the ancillary devices to struct spi_message (either
allow .spi to take an array and add a new array size field or add a new
ancillary device field). The controller driver would then check this new
field and use the additional CSes and data lanes from the ancillary devices
during any SPI_MULTI_LANE_MODE_STRIPE or SPI_MULTI_LANE_MODE_MIRROR
transfers. This would probably also require a new flag for controllers
to say that they support it. The main SPI device and the ancillaries
could be used individually like a normal SPI device for config using
the default SPI_MULTI_LANE_MODE_SINGLE.
On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote: > This series introduces two SPI subsystem features: per-transfer chipselect > masks and multi-CS device support. Together they address the multi-device > setup described in [1] and the limitation noted in [2], where no SPI > controller completely handles logical chip selects beyond the first one. > > The first part of the set addresses multi-CS support. Some SPI controllers > can assert multiple chip selects simultaneously, but the existing code > hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), > preventing this from working. > > The second part addresses dynamic lane selection for STRIPE mode. In > SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always > active. Some peripherals need to select a different subset of rx/tx lanes > per transfer. New fields are added to the spi_transfer struct to allow > drivers to specify which lanes to use for each transfer. The documentation > is also updated to describe this new behavior. > [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t > [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ Mark usually "merges" a series like this and cover letter goes as merge commit message. With that in mind, can we use Link tags for the above? Like Link: ... [1] Link: ... [2] -- With Best Regards, Andy Shevchenko
On 7/14/26 3:57 AM, Andy Shevchenko wrote: > On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote: >> This series introduces two SPI subsystem features: per-transfer chipselect >> masks and multi-CS device support. Together they address the multi-device >> setup described in [1] and the limitation noted in [2], where no SPI >> controller completely handles logical chip selects beyond the first one. >> >> The first part of the set addresses multi-CS support. Some SPI controllers >> can assert multiple chip selects simultaneously, but the existing code >> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), >> preventing this from working. >> >> The second part addresses dynamic lane selection for STRIPE mode. In >> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always >> active. Some peripherals need to select a different subset of rx/tx lanes >> per transfer. New fields are added to the spi_transfer struct to allow >> drivers to specify which lanes to use for each transfer. The documentation >> is also updated to describe this new behavior. > >> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t >> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ > > Mark usually "merges" a series like this and cover letter goes as merge commit > message. With that in mind, can we use Link tags for the above? Like > > Link: ... [1] > Link: ... [2] > Beware, that would cause b4 to add the links to every patch in the series.
On Tue, Jul 14, 2026 at 09:09:02AM -0500, David Lechner wrote: > On 7/14/26 3:57 AM, Andy Shevchenko wrote: > > On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote: > >> This series introduces two SPI subsystem features: per-transfer chipselect > >> masks and multi-CS device support. Together they address the multi-device > >> setup described in [1] and the limitation noted in [2], where no SPI > >> controller completely handles logical chip selects beyond the first one. > >> > >> The first part of the set addresses multi-CS support. Some SPI controllers > >> can assert multiple chip selects simultaneously, but the existing code > >> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), > >> preventing this from working. > >> > >> The second part addresses dynamic lane selection for STRIPE mode. In > >> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always > >> active. Some peripherals need to select a different subset of rx/tx lanes > >> per transfer. New fields are added to the spi_transfer struct to allow > >> drivers to specify which lanes to use for each transfer. The documentation > >> is also updated to describe this new behavior. > > > >> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t > >> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ > > > > Mark usually "merges" a series like this and cover letter goes as merge commit > > message. With that in mind, can we use Link tags for the above? Like > > > > Link: ... [1] > > Link: ... [2] > Beware, that would cause b4 to add the links to every patch in the series. Even in `b4 shazam` case? I thought it adds only a single Link per patch, and leaves the original Links as is. No? Also this can be done with the blank line before real tags, would it make it behave differently? -- With Best Regards, Andy Shevchenko
On 7/14/26 9:26 AM, Andy Shevchenko wrote: > On Tue, Jul 14, 2026 at 09:09:02AM -0500, David Lechner wrote: >> On 7/14/26 3:57 AM, Andy Shevchenko wrote: >>> On Tue, Jul 14, 2026 at 02:55:31AM -0300, Jonathan Santos wrote: >>>> This series introduces two SPI subsystem features: per-transfer chipselect >>>> masks and multi-CS device support. Together they address the multi-device >>>> setup described in [1] and the limitation noted in [2], where no SPI >>>> controller completely handles logical chip selects beyond the first one. >>>> >>>> The first part of the set addresses multi-CS support. Some SPI controllers >>>> can assert multiple chip selects simultaneously, but the existing code >>>> hardcoded CS index 0 in both spi_set_cs() and of_spi_parse_dt(), >>>> preventing this from working. >>>> >>>> The second part addresses dynamic lane selection for STRIPE mode. In >>>> SPI_MULTI_LANE_MODE_STRIPE, all available lanes are currently always >>>> active. Some peripherals need to select a different subset of rx/tx lanes >>>> per transfer. New fields are added to the spi_transfer struct to allow >>>> drivers to specify which lanes to use for each transfer. The documentation >>>> is also updated to describe this new behavior. >>> >>>> [1]: https://lore.kernel.org/linux-iio/af0EGv172ZMl%2F6N5@JSANTO12-L01.ad.analog.com/T/#t >>>> [2]: https://lore.kernel.org/all/20250915183725.219473-1-jonas.gorski@gmail.com/ >>> >>> Mark usually "merges" a series like this and cover letter goes as merge commit >>> message. With that in mind, can we use Link tags for the above? Like >>> >>> Link: ... [1] >>> Link: ... [2] > >> Beware, that would cause b4 to add the links to every patch in the series. > > Even in `b4 shazam` case? I thought it adds only a single Link per patch, > and leaves the original Links as is. No? Last I checked (which was a while ago), all tags in the cover letter get applied to all patches in the series. > > Also this can be done with the blank line before real tags, would it make > it behave differently? > Don't know.
© 2016 - 2026 Red Hat, Inc.