[PATCH v2 0/7] spi: multi CS cleanup and controller CS limit removal

Jonas Gorski posted 7 patches 2 weeks, 2 days ago
drivers/spi/spi-cadence-quadspi.c |  2 +-
drivers/spi/spi.c                 | 75 +++++++++++++------------------
include/linux/spi/spi.h           | 16 ++++---
3 files changed, 42 insertions(+), 51 deletions(-)
[PATCH v2 0/7] spi: multi CS cleanup and controller CS limit removal
Posted by Jonas Gorski 2 weeks, 2 days ago
This series aims at cleaning up the current multi CS parts and removing
the CS limit per controller that was introduced with the multi CS
support.

To do this, store the assigned chip selects per device in
spi_device::num_chipselects, which allows us to use that instead of
SPI_CS_CNT_MAX for most loops, as well as remove the check for
SPI_INVALID_CS for any chip select.

This should hopefully make it obvious that SPI_CS_CNT_MAX only limits
accesses to arrays indexed by the number of chip selects of a device,
not the controller, and we can remove the check for
spi_controller::num_chipselects being less than SPI_CS_CNT_MAX in device
registration (which was the wrong place to do that anyway).

After having done that, we can reduce SPI_CS_CNT_MAX again to 4 without
breaking devices on higher CS lines.

Finally, rename SPI_CS_CNT_MAX to SPI_DEVICE_CNT_MAX to make it more
clear that this limit only applies to devices, not controllers.

There are still more issues left, but these can be addressed in future
submissions:

* The code allows multi-cs devices for any controller, as long as the
  device does not set parallel-memories.
* No current spi controller driver handles logical chip selects other
  than the first one, and always use it, regardless what cs_index_mask
  says.
* While most spi controllers should be able to handle devices that have
  multiple cs that just get enabled selectively, but not at the same
  time, there is no way to tell that to the core (ties into the above).
* There is no parallel memories/multi cs flag for devices, so any
  implementing driver needs to check the device tree node, making it
  impossible to register these kind of devices via platform code.

Changes v1 -> v2:

* rebased onto current spi/for-next
* kept the initialization of spi_device::chip_select[] to SPI_INVALID_CS
* reworded the reduce patch to not be a revert anymore

Jonas Gorski (7):
  spi: fix return code when spi device has too many chipselects
  spi: keep track of number of chipselects in spi_device
  spi: move unused device CS initialization to __spi_add_device()
  spi: drop check for validity of device chip selects
  spi: don't check spi_controller::num_chipselect when parsing a dt
    device
  spi: reduce device chip select limit again
  spi: rename SPI_CS_CNT_MAX => SPI_DEVICE_CS_CNT_MAX

 drivers/spi/spi-cadence-quadspi.c |  2 +-
 drivers/spi/spi.c                 | 75 +++++++++++++------------------
 include/linux/spi/spi.h           | 16 ++++---
 3 files changed, 42 insertions(+), 51 deletions(-)


base-commit: 34c2202f5ca2325511a0e0b8802492eec17a2c76
-- 
2.43.0
Re: [PATCH v2 0/7] spi: multi CS cleanup and controller CS limit removal
Posted by Mark Brown 1 week, 2 days ago
On Mon, 15 Sep 2025 20:37:18 +0200, Jonas Gorski wrote:
> This series aims at cleaning up the current multi CS parts and removing
> the CS limit per controller that was introduced with the multi CS
> support.
> 
> To do this, store the assigned chip selects per device in
> spi_device::num_chipselects, which allows us to use that instead of
> SPI_CS_CNT_MAX for most loops, as well as remove the check for
> SPI_INVALID_CS for any chip select.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/7] spi: fix return code when spi device has too many chipselects
      commit: 188f63235bcdd207646773a8739387d85347ed76
[2/7] spi: keep track of number of chipselects in spi_device
      commit: 099f942182e3695554cba44e4bafb08a4111b50f
[3/7] spi: move unused device CS initialization to __spi_add_device()
      commit: 1c923f624439b26b6740cdd2a9f7a12b1968f3f3
[4/7] spi: drop check for validity of device chip selects
      commit: f3982daccf42cefcd80218c76a6b5dd134fe97e3
[5/7] spi: don't check spi_controller::num_chipselect when parsing a dt device
      commit: 83c522fb642384aef43697aa5c7686363e9e92dd
[6/7] spi: reduce device chip select limit again
      commit: 08fda410bae41cc8dde9697f9104da525be53153
[7/7] spi: rename SPI_CS_CNT_MAX => SPI_DEVICE_CS_CNT_MAX
      commit: e336ab509b43ea601801dfa05b4270023c3ed007

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark