tree dd58d22c939bea9d8c94b36e14b2eddf074cb1ca
parent 878702702dbbd933a5da601c75b8e58eadeec311
parent e336ab509b43ea601801dfa05b4270023c3ed007
author Mark Brown <broonie@kernel.org> 1758616150 +0200
committer Mark Brown <broonie@kernel.org> 1758616150 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjSWlcTHGJyb29uaWVA
 a2VybmVsLm9yZwAKCRAk1otyXVSH0MzRB/9FjbR1MqN2cyy5/kypRvw28SUBEtov
 S5SqGBAqWDkiTB05L4nZPLpgdql1KUdKlL7i5Yv2zilG67BXcxjOg+5bVfc6Jt4/
 WsghqvBetIJOl9jqgonHV1pseUC1FUpU0iEG/f79krJZyigihw9ROKsq/6ylzwHb
 W2O1d25rkX4PbWOIqrfAZQreP63jXlRhrOuEJLcAMftAHWLazjXPEM7WU46dEKMH
 44868DvPILKdjwmHHogUihs3eQdhYJ7PfJqvEkHlVKgGpmRa65uNLNOqV5n+oZHg
 tGQu7d04Wn9vu8IW8JV/mRbQ2/sL1XmI9mFyNi9kqCz+VlPgkZYJUg0v
 =yIUB
 -----END PGP SIGNATURE-----

spi: multi CS cleanup and controller CS limit

Merge series from Jonas Gorski <jonas.gorski@gmail.com>:

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.