spi: add multi-CS and multi-chip aggregation support

The AD7768-1 family supports aggregating up to four devices on a single SPI controller, with each device occupying a dedicated CS line and a single data lane.

Extend the reg property to accept up to 4 entries (one per device).

Add spi-rx-bus-width property to declare the per-device lane count. Since each lane is bound to one CS, the number of entries must match reg. Make it required when reg has more than one entry.

Add an example for a four ADAQ7768-1 aggregation, with shared DRDY and SYNC_IN pin.

Signed-off-by Jonathan Santos <[email protected]>

---
Changes in v3:
* New patch.

Quoted 10 lines · Jonathan Santos

The AD7768-1 family supports aggregating up to four devices on a single SPI controller, with each device occupying a dedicated CS line and a single data lane.

Extend the reg property to accept up to 4 entries (one per device).

Add spi-rx-bus-width property to declare the per-device lane count. Since each lane is bound to one CS, the number of entries must match reg. Make it required when reg has more than one entry.

Quoted 7 lines

Add an example for a four ADAQ7768-1 aggregation, with shared DRDY and SYNC_IN pin.

Signed-off-by Jonathan Santos <[email protected]>

---
Changes in v3:
* New patch.

Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline) or work on fork of kernel (don't, instead use mainline). Just use b4 and everything should be fine, although remember about b4 prep --auto-to-cc if you added new patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be

tested by automated tooling. Performing review on untested code might be a waste of time.

Please kindly resend and include all necessary To/Cc entries.

Best regards,
Krzysztof

The AD7768-1 family supports aggregating up to four devices on a single SPI controller, with each device occupying a dedicated CS line and a single data lane.

Extend the reg property to accept up to 4 entries (one per device).

Add spi-rx-bus-width property to declare the per-device lane count. Since each lane is bound to one CS, the number of entries must match reg. Make it required when reg has more than one entry.

Quoted 10 lines · Jonathan Santos

The AD7768-1 family supports aggregating up to four devices on a single SPI controller, with each device occupying a dedicated CS line and a single data lane.

Extend the reg property to accept up to 4 entries (one per device).

Add spi-rx-bus-width property to declare the per-device lane count. Since each lane is bound to one CS, the number of entries must match reg. Make it required when reg has more than one entry.

I don't see why we should have to require the spi-rx-bus-width property. It seems logical that if it is not present, then we would assume one lane per CS. This is already how bindings work.

For example, adi,ad4080 and ge,achc have multiple CS lines and don't require any bus width properties.

Quoted 11 lines · David Lechner

Quoted 10 lines · Jonathan Santos

The AD7768-1 family supports aggregating up to four devices on a single SPI controller, with each device occupying a dedicated CS line and a single data lane.

Extend the reg property to accept up to 4 entries (one per device).

Add spi-rx-bus-width property to declare the per-device lane count. Since each lane is bound to one CS, the number of entries must match reg. Make it required when reg has more than one entry.

Quoted 6 lines

I don't see why we should have to require the spi-rx-bus-width property. It seems logical that if it is not present, then we would assume one lane per CS. This is already how bindings work.

For example, adi,ad4080 and ge,achc have multiple CS lines and don't require any bus width properties.

Hmm that's my default then! I was the one requesting it. Basically because of:

https://elixir.bootlin.com/linux/v7.2/source/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml#L76

So I thought that $refing spi-peripheral-props.yaml and leaving the default value would make dtbs_check to fail if one used

spi-rx-bus-width = <1>, <1>, <1>, <1>;

in DT.

Won't it fail?

And if we don't give the property I believe we'll have:

https://elixir.bootlin.com/linux/v7.2/source/drivers/spi/spi.c#L2509

And given these series assumption of spi->num_rx_lanes == number of devices (which I don't agree btw), I thought we would need to make spi-rx-bus-width explicit in our bindings! I still think but I might be wrong and I'm by no means an expert on dt bindings schemas work :)

- Nuno Sá

Quoted 1 line

Some SPI controllers allow multiple CS lines to be toggled at the same time. The existing code always used CS index 0 when tracking the last active CS in spi_set_cs(), and unconditionally set cs_index_mask to BIT(0) when parsing DT, both forcing the single CS usage.

Modify spi_set_cs() to iterate last_cs[] using each logical CS index instead of always reading index 0. Modify of_spi_parse_dt() to build cs_index_mask from all parsed CS entries rather than hardcoding BIT(0), so the controller correctly identifies which CS lines belong to a device when asserting them simultaneously.

Board info, ACPI, and ancillary device paths are not updated here. Board info would require an API change to accept an array of CS values and is left for a follow-up when we have a use case for this. Ancillary devices are by design single-CS, so multi-CS is not a current use case for them. ACPI represents the CS as a 64-bit integer with no established convention for encoding multiple CS indices yet, so any extension there would require a separate specification effort.

Some SPI controllers allow multiple CS lines to be toggled at the same time. The existing code always used CS index 0 when tracking the last active CS in spi_set_cs(), and unconditionally set cs_index_mask to BIT(0) when parsing DT, both forcing the single CS usage.

Modify spi_set_cs() to iterate last_cs[] using each logical CS index instead of always reading index 0. Modify of_spi_parse_dt() to build cs_index_mask from all parsed CS entries rather than hardcoding BIT(0), so the controller correctly identifies which CS lines belong to a device when asserting them simultaneously.

Board info, ACPI, and ancillary device paths are not updated here. Board info would require an API change to accept an array of CS values and is left for a follow-up when we have a use case for this. Ancillary devices are by design single-CS, so multi-CS is not a current use case for them. ACPI represents the CS as a 64-bit integer with no established convention for encoding multiple CS indices yet, so any extension there would require a separate specification effort.

Acked-by Nuno Sá <[email protected]>

Signed-off-by Jonathan Santos <[email protected]>

---
Changes in v3:
* None.

Changes in v2:
* Include Summary describind why the other SPI paths were not addressed here.

---
 drivers/spi/spi.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

drivers/spi/spi.c +1 -2

index d9e6b4b87c89..55fb96fea243 100644
@@ -1090,7 +1090,7 @@ static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
 	spi->controller->last_cs_index_mask = spi->cs_index_mask;
 	for (idx = 0; idx < SPI_DEVICE_CS_CNT_MAX; idx++) {
 		if (enable && idx < spi->num_chipselect)
-			spi->controller->last_cs[idx] = spi_get_chipselect(spi, 0);
+			spi->controller->last_cs[idx] = spi_get_chipselect(spi, idx);
 		else
 			spi->controller->last_cs[idx] = SPI_INVALID_CS;
 	}

@@ -2594,10 +2594,11 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
 		spi_set_chipselect(spi, idx, cs[idx]);
 
 	/*
-	 * By default spi->chip_select[0] will hold the physical CS number,

drivers/spi/spi.c +0 -0

index d9e6b4b87c899..55fb96fea2432 100644

drivers/spi/spi.c +0 -0

 	/* Device speed */
 	if (!of_property_read_u32(nc, "spi-max-frequency", &value))

Quoted 50 lines · Jonathan Santos

Some SPI controllers allow multiple CS lines to be toggled at the same time. The existing code always used CS index 0 when tracking the last active CS in spi_set_cs(), and unconditionally set cs_index_mask to BIT(0) when parsing DT, both forcing the single CS usage.

Modify spi_set_cs() to iterate last_cs[] using each logical CS index instead of always reading index 0. Modify of_spi_parse_dt() to build cs_index_mask from all parsed CS entries rather than hardcoding BIT(0), so the controller correctly identifies which CS lines belong to a device when asserting them simultaneously.

Board info, ACPI, and ancillary device paths are not updated here. Board info would require an API change to accept an array of CS values and is left for a follow-up when we have a use case for this. Ancillary devices are by design single-CS, so multi-CS is not a current use case for them. ACPI represents the CS as a 64-bit integer with no established convention for encoding multiple CS indices yet, so any extension there would require a separate specification effort.

Acked-by Nuno Sá <[email protected]>

Signed-off-by Jonathan Santos <[email protected]>

---
Changes in v3:
* None.

Changes in v2:
* Include Summary describind why the other SPI paths were not addressed here.

---
 drivers/spi/spi.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

drivers/spi/spi.c +1 -2

index d9e6b4b87c89..55fb96fea243 100644
@@ -1090,7 +1090,7 @@ static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
 	spi->controller->last_cs_index_mask = spi->cs_index_mask;
 	for (idx = 0; idx < SPI_DEVICE_CS_CNT_MAX; idx++) {
 		if (enable && idx < spi->num_chipselect)
-			spi->controller->last_cs[idx] = spi_get_chipselect(spi, 0);
+			spi->controller->last_cs[idx] = spi_get_chipselect(spi, idx);
 		else
 			spi->controller->last_cs[idx] = SPI_INVALID_CS;
 	}

@@ -2594,10 +2594,11 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
 		spi_set_chipselect(spi, idx, cs[idx]);
 
 	/*
-	 * By default spi->chip_select[0] will hold the physical CS number,

drivers/spi/spi.c static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, · line 2604

Quoted 10 lines

drivers/spi/spi.c +4 -2

-	 * so set bit 0 in spi->cs_index_mask.
+	 * Set cs_index_mask to indicate which logical CS indices are active.
+	 * Each bit corresponds to a logical CS index in the spi->chip_select array.
 	 */
-	spi->cs_index_mask = BIT(0);
+	for (idx = 0; idx < rc; idx++)
+		spi->cs_index_mask |= BIT(idx);
 
 	/* Device speed */
 	if (!of_property_read_u32(nc, "spi-max-frequency", &value))

I have the same concern that sashiko calls out here.

Existing users of multi-cs (not including spi-mem) follow the pattern that a SPI device gets registered with the CS at index 0 and they later create an auxiliary using the additional CS. This would cause the main device to now assert both CS. Not what we want to happen.

If I understood (and remember) the previous explanations of this series correctly, we have a different case for this one.

We want a main device that acts as a single composite device that asserts all 4 CS at the same time. Then we also need 4 auxiliary devices that only assert one CS at a time for configuring the individual chips.

So it seems to me like we need a new DT property or some way to be able to tell the difference to decide whether we just use the first CS here or all of them.

Perhaps another possibility would be to leave this code the way it is and do it this way instead:
- The SPI device passed to the IIO driver is just the first chip (one CS)
- The IIO driver then registers auxiliary drivers for the other 3 chips (also 1 CS each)
- These 4 devices will be used individual to handle configuration.
- The IIO driver registers a separate composite device that has the multiple lanes and and multiple CS. Whether this using the same auxiliary mechanism with additional parameters or something new probably doesn't matter too much.
- In this way of doing things, it would not make sense to have the spi-rx-bus-width property in the devcietree since as far as the devicetree is concerned, these are more-or-less 4 separate devices (from the SPI point of view). Instead, this new composite device registration function would be the one setting the number of lanes based on the number of chip selects.

---
sashiko output for reference:

--- Patch [2]: [PATCH v3 2/6] spi: support simultaneous assertion of multiple CS --- commit 17290644299c39d6ca397b14180cd885c5b04919
Author: Jonathan Santos <[email protected]>
Subject: spi: support simultaneous assertion of multiple CS

This commit modifies spi_set_cs() and of_spi_parse_dt() to allow simultaneous toggling of multiple chip select lines. It builds cs_index_mask from all parsed CS entries instead of hardcoding bit 0.

Quoted 4 lines

drivers/spi/spi.c +0 -0

index d9e6b4b87c899..55fb96fea2432 100644

[ ... ]

drivers/spi/spi.c static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, · line 2601

Quoted 12 lines

drivers/spi/spi.c +4 -3

@@ -2594,10 +2594,11 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
 		spi_set_chipselect(spi, idx, cs[idx]);
 
 	/*
-	 * By default spi->chip_select[0] will hold the physical CS number,
-	 * so set bit 0 in spi->cs_index_mask.
+	 * Set cs_index_mask to indicate which logical CS indices are active.
+	 * Each bit corresponds to a logical CS index in the spi->chip_select array.
 	 */
-	spi->cs_index_mask = BIT(0);
+	for (idx = 0; idx < rc; idx++)
+		spi->cs_index_mask |= BIT(idx);

Will this loop break backward compatibility for devices that use multiple reg entries for independent logical chip selects?

For example, if a device has multiple reg entries and uses spi_new_ancillary_device(), the primary device's cs_index_mask will now have multiple bits set. During a transfer on the primary device, all of these parsed chip selects would be asserted simultaneously.

Could this result in multiple chips driving the shared MISO line at the same time, causing bus contention and data corruption?

Quoted 3 lines

drivers/spi/spi.c +0 -0

 	/* Device speed */
 	if (!of_property_read_u32(nc, "spi-max-frequency", &value))

Quoted 64 lines · David Lechner

Quoted 50 lines · Jonathan Santos

Some SPI controllers allow multiple CS lines to be toggled at the same time. The existing code always used CS index 0 when tracking the last active CS in spi_set_cs(), and unconditionally set cs_index_mask to BIT(0) when parsing DT, both forcing the single CS usage.

Modify spi_set_cs() to iterate last_cs[] using each logical CS index instead of always reading index 0. Modify of_spi_parse_dt() to build cs_index_mask from all parsed CS entries rather than hardcoding BIT(0), so the controller correctly identifies which CS lines belong to a device when asserting them simultaneously.

Board info, ACPI, and ancillary device paths are not updated here. Board info would require an API change to accept an array of CS values and is left for a follow-up when we have a use case for this. Ancillary devices are by design single-CS, so multi-CS is not a current use case for them. ACPI represents the CS as a 64-bit integer with no established convention for encoding multiple CS indices yet, so any extension there would require a separate specification effort.

Acked-by Nuno Sá <[email protected]>

Signed-off-by Jonathan Santos <[email protected]>

---
Changes in v3:
* None.

Changes in v2:
* Include Summary describind why the other SPI paths were not addressed here.

---
 drivers/spi/spi.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

drivers/spi/spi.c +1 -2

index d9e6b4b87c89..55fb96fea243 100644
@@ -1090,7 +1090,7 @@ static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
 	spi->controller->last_cs_index_mask = spi->cs_index_mask;
 	for (idx = 0; idx < SPI_DEVICE_CS_CNT_MAX; idx++) {
 		if (enable && idx < spi->num_chipselect)
-			spi->controller->last_cs[idx] = spi_get_chipselect(spi, 0);
+			spi->controller->last_cs[idx] = spi_get_chipselect(spi, idx);
 		else
 			spi->controller->last_cs[idx] = SPI_INVALID_CS;
 	}

@@ -2594,10 +2594,11 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
 		spi_set_chipselect(spi, idx, cs[idx]);
 
 	/*
-	 * By default spi->chip_select[0] will hold the physical CS number,

drivers/spi/spi.c static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, · line 2604

Quoted 10 lines

drivers/spi/spi.c +4 -2

-	 * so set bit 0 in spi->cs_index_mask.
+	 * Set cs_index_mask to indicate which logical CS indices are active.
+	 * Each bit corresponds to a logical CS index in the spi->chip_select array.
 	 */
-	spi->cs_index_mask = BIT(0);
+	for (idx = 0; idx < rc; idx++)
+		spi->cs_index_mask |= BIT(idx);
 
 	/* Device speed */
 	if (!of_property_read_u32(nc, "spi-max-frequency", &value))

I have the same concern that sashiko calls out here.

Quoted 4 lines

Existing users of multi-cs (not including spi-mem) follow the pattern that a SPI device gets registered with the CS at index 0 and they later create an auxiliary using the additional CS. This would cause the main device to now assert both CS. Not what we want to happen.

Indeed, enalbing all CS for those cases would cause problems (like you describe below). AD4080 would be an example.

The devicetree property seems to be a good ideia to fix this and simpler to execute, but the composite device is interesting.

Quoted 12 lines

If I understood (and remember) the previous explanations of this series correctly, we have a different case for this one.

We want a main device that acts as a single composite device that asserts all 4 CS at the same time. Then we also need 4 auxiliary devices that only assert one CS at a time for configuring the individual chips.

So it seems to me like we need a new DT property or some way to be able to tell the difference to decide whether we just use the first CS here or all of them.

Quoted 17 lines

Perhaps another possibility would be to leave this code the way it is and do it this way instead:
- The SPI device passed to the IIO driver is just the first chip (one CS)
- The IIO driver then registers auxiliary drivers for the other 3 chips (also 1 CS each)
- These 4 devices will be used individual to handle configuration.
- The IIO driver registers a separate composite device that has the multiple lanes and and multiple CS. Whether this using the same auxiliary mechanism with additional parameters or something new probably doesn't matter too much.
- In this way of doing things, it would not make sense to have the spi-rx-bus-width property in the devcietree since as far as the devicetree is concerned, these are more-or-less 4 separate devices (from the SPI point of view). Instead, this new composite device registration function would be the one setting the number of lanes based on the number of chip selects.

My initial idea was to use the main device as the "composite" because it holds the hw description, therefore the multi-lane would be handled by the existing flow (that's why the spi-rx-bus-width property was mandatory). This way each ancillary device would take the lane index from the main device. Using the main + 3 ancillaries for individual access and the new composite for simultaneous is a great alternative, but removing the spi-rx-bus-width kind of excludes the information that we are using multiple lanes for this device. Unless we document that

"number of CS = number of lanes" on multiple-data-lanes.rst, the assumption is:

spi-rx-bus-width = <1>
spi-rx-lane-map = <1>

Also, it would make more sense to take the lane description from the main device described in the DT considering cases like non-default mapping. Or at least take it into consideration.

The device name for SPI devices was formatted as <controller>.<cs0>, always using only the first chip-select index, ignoring the remaining CS lines.

Change the naming format to <controller>.<cs0>+<cs1>+... so that all active chip-selects are reflected in the device name. Single-CS devices are not affected since the loop only appends extra indices when num_chipselect is greater than one.

Quoted 8 lines · Jonathan Santos

The device name for SPI devices was formatted as <controller>.<cs0>, always using only the first chip-select index, ignoring the remaining CS lines.

Change the naming format to <controller>.<cs0>+<cs1>+... so that all active chip-selects are reflected in the device name. Single-CS devices are not affected since the loop only appends extra indices when num_chipselect is greater than one.

...

drivers/spi/spi.c static void spi_dev_set_name(struct spi_device *spi) · line 613

Quoted 6 lines

drivers/spi/spi.c +4 -2

-	dev_set_name(&spi->dev, "%s.%u", dev_name(&spi->controller->dev),
-		     spi_get_chipselect(spi, 0));
+	cs_len = scnprintf(cs_str, sizeof(cs_str), "%u", spi_get_chipselect(spi, 0));
+	for (unsigned int idx = 1; idx < spi->num_chipselect; idx++)
+		cs_len += scnprintf(cs_str + cs_len, sizeof(cs_str) - cs_len,
+				    "+%u", spi_get_chipselect(spi, idx));

So, if this won't support sparse CS list, I would just go with a standard range:

	dev_set_name(&spi->dev, "%s.%u-%u", dev_name(&spi->controller->dev),
		     spi_get_chipselect(spi, 0), spi_get_chipselect(spi, 0) + spi->num_chipselect - 1);

(yes, need a variation for num_chipselect == 1, but I leave the rest for you)

Note, I do not see that we are expecting to see the sparse CS list here. It would make too complex logic to follow. So, range approach is KISS in my opinion.

Quoted 1 line · Andy Shevchenko

On Mon, Aug 17, 2026 at 08:32:57PM -0300, Jonathan Santos wrote:

Quoted 11 lines

drivers/spi/spi.c static void spi_dev_set_name(struct spi_device *spi) · line 613

Quoted 6 lines

drivers/spi/spi.c +4 -2

-	dev_set_name(&spi->dev, "%s.%u", dev_name(&spi->controller->dev),
-		     spi_get_chipselect(spi, 0));
+	cs_len = scnprintf(cs_str, sizeof(cs_str), "%u", spi_get_chipselect(spi, 0));
+	for (unsigned int idx = 1; idx < spi->num_chipselect; idx++)
+		cs_len += scnprintf(cs_str + cs_len, sizeof(cs_str) - cs_len,
+				    "+%u", spi_get_chipselect(spi, idx));

So, if this won't support sparse CS list, I would just go with a standard range:

	dev_set_name(&spi->dev, "%s.%u-%u", dev_name(&spi->controller->dev),
		     spi_get_chipselect(spi, 0), spi_get_chipselect(spi, 0) + spi->num_chipselect - 1);

I don't think there's anything forcing cs to be contiguous. So cs4-0 does not mean we have 0,1,2,3 and 4 which I think the above implies.

Moreover, i also don't think is guaranteed that `spi_get_chipselect(spi,
0) + spi->num_chipselect - 1)` yields a valid cs. IOW, in theory

spi_get_chipselect(spi, spi->num_chipselect - 1) might be different than spi_get_chipselect(spi, 0) + spi->num_chipselect - 1

Quoted 4 lines

(yes, need a variation for num_chipselect == 1, but I leave the rest for you)

Note, I do not see that we are expecting to see the sparse CS list here. It would make too complex logic to follow. So, range approach is KISS in my opinion.

The existing spi_new_ancillary_device() creates an ancillary SPI device but does not consider the parent's lane map. In multi-device setups where each sub-device's chip-select is bound to a dedicated data lane, there is no way to bind an ancillary device to an arbitrary lane index.

Introduce spi_new_ancillary_device_with_lane() and devm_spi_new_ancillary_device_with_lane(), which accept rx_lane_idx and tx_lane_idx parameters to select a specific lane from the parent's rx_lane_map and tx_lane_map respectively. The resulting ancillary device is registered with a single RX and TX lane, keeping it independent from the other sub-devices sharing the same controller.

The SPI Engine controller only handled the first chip select when asserting CS lines and configuring CS polarity inversion, ignoring additional CS indices present in cs_index_mask.

Update spi_engine_gen_cs() to iterate over all set bits in cs_index_mask and toggle each corresponding CS line in the assert mask. Update spi_engine_setup() likewise so that SPI_CS_HIGH polarity is applied to every active CS index rather than only index 0.

Set SPI_CONTROLLER_MULTI_CS in the controller flags to reflect the capability to the SPI core.

The AD7768-1 family is a single-channel ADC, but it is designed to allow connecting multiple devices to the same SPI controller, each on a dedicated CS and data lane, clocked synchronously, and sharing SDO and SCLK. The number of aggregated devices are derived from spi->num_rx_lanes, assuming all parts are single lane.

The DRDY pins are combined to trigger the data interrupt when all devices are ready, and since the synchronization pins are tied, they stay in synchrony.

To reflect the multidevice setup, IIO channels are dynamically set based on the number of devices. Restrict buffered capture to the all-channels scan mask, since all devices sample in lockstep. Register an ancillary SPI device per lane for individual direct reads, and enable SPI_MULTI_LANE_MODE_STRIPE in offload mode to interleave samples from all lanes into the DMA stream.

Since all devices must be in sync, all configurations that affects the sampling rate are unified, so they always have the same sampling frequency.

drivers/iio/adc/ad7768-1.c +8 -0

+	channels = devm_kcalloc(dev, indio_dev->num_channels, sizeof(*channels), GFP_KERNEL);
+	if (!channels)
+		return -ENOMEM;
+
+	for (i = 0; i < st->num_devices; i++) {
+		struct iio_chan_spec *chan = &channels[i];
+
+		*chan = *st->chip->channel_spec;

drivers/iio/adc/ad7768-1.c +19 -0

+	indio_dev->available_scan_masks = masks;
+
+	/* Setup ancillary SPI devices for single device access  */
+	for (i = 0; i < st->num_devices; i++) {
+		cs = spi_get_chipselect(st->spi, i);
+		st->spi_anc[i] = devm_spi_new_ancillary_device_with_lane(st->spi,
+									 cs, i, 0);
+		if (IS_ERR(st->spi_anc[i]))
+			return dev_err_probe(dev, PTR_ERR(st->spi_anc[i]),
+					     "failed to register ancillary device\n");
+
+		st->regmap24_anc[i] = devm_regmap_init_spi(st->spi_anc[i],
+							   &ad7768_regmap24_config);
+		if (IS_ERR(st->regmap24_anc[i]))
+			return PTR_ERR(st->regmap24_anc[i]);
+	}
+
+	return 0;
+}

drivers/iio/adc/ad7768-1.c +5 -0

+					     "Failed to configure multidevice\n");
+	} else {
+		indio_dev->channels = st->chip->channel_spec;
+		indio_dev->num_channels = st->chip->num_channels;
+	}