Re: [PATCH v2 5/5] iio: adc: ad7768-1: add support for multiple chip aggregation

[Nuno Sá]

On Mon, 03 Aug 2026 00:02:43 -0300, Jonathan Santos <Jonathan.Santos@xxxxxxxxxx> wrote:
> diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c
> index e9060c1bbe6f..0a34d408c188 100644
> --- a/drivers/iio/adc/ad7768-1.c
> +++ b/drivers/iio/adc/ad7768-1.c
> @@ -1694,6 +1706,55 @@ static int ad7768_parse_aaf_gain(struct device *dev, struct ad7768_state *st)
> [ ... skip 25 lines ... ]
> +	indio_dev->channels = channels;
> +
> +	masks = devm_kcalloc(dev, st->chip->num_channels + 1, sizeof(*masks), GFP_KERNEL);
> +	if (!masks)
> +		return -ENOMEM;
> +

You're assuming that num_channels is 1 which it is for all the chips
supported. But semantically I think it is wrong! becasue we pretty much
just want two unsigned longs being the last one the terminator. Hence I think a
plain 2 with a comment would be more correct.

> @@ -1830,6 +1891,15 @@ static int ad7768_probe(struct spi_device *spi)
>  
>  	st->chip = spi_get_device_match_data(spi);
>  	st->spi = spi;
> +	/*
> +	 * This family is composed of 1-lane devices, so we assume that each
> +	 * lane is bound to a different device.
> +	 */
> +	st->num_devices = spi->num_rx_lanes;
> +	if (st->num_devices > AD7768_MAX_AGGR_DEVICES)
> +		return dev_err_probe(&spi->dev, -EINVAL,
> +				     "Too many devices (%u), max %d supported\n",
> +				     st->num_devices, AD7768_MAX_AGGR_DEVICES);

I'm not sure I'm convinced we should tie num_rx_lanes with num_devices.
Maybe it's fine and it's unlikely to change for this driver (same for
the direct mapping between lane id, cs and device number). For example,
the below:


reg = <1>, <2>, <3>, <4>;
spi-rx-bus-width = <1>, <1>, <1>, <1>;
spi-rx-lane-map = <0>, <2>, <1>, <3>;

would be break with the current code If I'm not missing something.
And maybe simply introducing subnodes as:

adc@2 {
	reg = <2>;
	// Or have spi-rx-lane-map directly in here and have the new SPI
	// ANCI API parse the property.
	adi,spi-lane-idx = <1>;
};

would be fairly simple to handle and completely flexible (I think).

Anyways, one thing I'm fairly sure. You need to update the dt-bindings for
this :). For example,

spi-rx-bus-width defauls to [1] which is simply wrong for this setup. We
also need multiple regs and the lane-map.

- Nuno Sá

-- 
Nuno Sá <nuno.sa@xxxxxxxxxx>