[PATCH v4 0/9] spi: add multi-CS and multi-chip aggregation support

[Jonathan Santos <Jonathan.Santos@analog.com>]

This series adds support for multi-CS devices and ancillary devices with
lanes, to enable the multi-device setup described in [1], where multiple
AD7768-1 ADCs are wired to the same controller in a synchronized sampling
configuration, 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 spi device name pattern is modified to
include all active CS lines in range format, so multi-CS devices are 
distinguishable in sysfs.

The second part introduces spi_new_ancillary_device_with_lane() and its
devm variant, used here to create subdevices that bind the CS with a 
corresponding rx and tx lane from the parent device. With that we can 
handle each device individually when there are separate data lanes.

The last part uses the above infrastructure in the AD7768-1 driver to
support aggregating multiple chips as a single IIO device. The number of
sub-devices is derived from the number of CS lines. IIO channels are
allocated dynamically, buffered capture is restricted to the full-device
scan mask, and SPI offload mode enables SPI_MULTI_LANE_MODE_STRIPE to
interleave samples from all lanes into the DMA stream.

---
v4 summary:
* Included patch to add new spi-cs-composite property to the bindings,
  to allow multi-CS devices.
* Added new patch restricting CS logical values to a contiguous sequence.
* Device name for multi-CS devices is now formatted as range (the 
  contiguous restriction makes it possible) instead of a list.
* Introduced KUnit tests for SPI core CS management, following the SPI DMA
  pattern.
* Addressed other minor suggestions, see individual patches. Please refer
  to "OBS For V4" section before proceeding.
* Link to v3: https://lore.kernel.org/linux-spi/cover.1786973376.git.Jonathan.Santos@analog.com/T/#t

v3 summary:
* Added new patch to document the properties for multidevice support on 
  ad7768-1 bindings.
* Refactored "spi: introduce SPI ancillary device with lanes" patch
  to reduce duplicated code using helper functions.
* Modified channel mask allocation on ad7768_parse_aaf_gain() to get 
  a static value, Since we assume the family is single channel. Added a 
  comment explaining.
* Addressed other minor suggestions, see individual patches. Please refer
  to "OBS For V3" section before proceeding.
* Link to v2: https://lore.kernel.org/linux-spi/cover.1785725359.git.Jonathan.Santos@analog.com/T/#t

v2 summary:
* Removed the per-transfer CS mask patches, the devices will be 
  individually handled by the ancillary device feature.
* Removed dynamic multilane selection patches. The lane is bound to the 
  CS using the new spi_new_ancillary_device_with_lane() feature.
* Included a use case patch modifying the AD7768-1 driver to support 
  multidevice aggregation.
* Link to v1: https://lore.kernel.org/linux-spi/cover.1783729282.git.Jonathan.Santos@analog.com/T/#t

OBS For V4: An alternative to the 'spi-cs-composite' property would be a
separate composite device holding all CS in its cs_index_mask (as suggested
by David), while the main device and the ancillaries are used for
individual access. That approach was dropped because the composite device
claims chip selects already taken by its siblings (the main device and the
ancillaries), and the CS conflict check only skips the parent device, not
siblings. Relaxing that check is not trivial, so the new property instead
lets the main device act as the composite while the ancillaries handle
individual access.

OBS For V3: The ancillary device approach was chosen over per-transfer CS
masks because it has better integration with regmap. Both approaches
require multiple regmap instances, but the CS mask approach would
additionally require custom read/write functions to route transfers to the
correct CS, while ancillary devices handle this more transparently.

David suggested adding an ancillary device field to spi_message, I guess to
enable dynamic CS-lane selection. For now, using one ancillary device per 
chip for individual access and the main SPI device for simultaneous access
seems to be sufficient. The dynamic approach can be implemented in the future
if needed.

---

[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 (9):
  spi: dt-bindings: Add spi-cs-composite property
  dt-bindings: iio: adc: ad7768-1: Document multidevice support
  spi: support simultaneous assertion of multiple CS
  spi: restrict CS logical values to a contiguous sequence
  spi: expand device name to include enabled CS lines for multi-CS
    devices
  spi: introduce SPI ancillary device with lanes
  spi: add KUnit tests for the multi-CS framework
  spi: spi-engine-ex: Add support for multi-CS devices
  iio: adc: ad7768-1: add support for multiple chip aggregation

 .../bindings/iio/adc/adi,ad7768-1.yaml        |  80 +++-
 .../bindings/spi/spi-peripheral-props.yaml    |   8 +
 drivers/iio/adc/ad7768-1.c                    | 100 ++++-
 drivers/spi/.kunitconfig                      |   1 +
 drivers/spi/Kconfig                           |  11 +
 drivers/spi/Makefile                          |   2 +-
 drivers/spi/internals.h                       |  16 +
 drivers/spi/spi-axi-spi-engine.c              |  21 +-
 drivers/spi/spi.c                             | 172 ++++++--
 drivers/spi/tests/Makefile                    |   3 +-
 drivers/spi/tests/spi-multi-cs-kunit.c        | 374 ++++++++++++++++++
 include/linux/spi/spi.h                       |   8 +
 12 files changed, 751 insertions(+), 45 deletions(-)
 create mode 100644 drivers/spi/tests/spi-multi-cs-kunit.c


base-commit: 43ffda3c7f8456bbe641ae8249a077a361b97880
-- 
2.34.1