Re: [PATCH v3 1/6] dt-bindings: iio: adc: ad7768-1: Document multidevice support

On 8/18/26 10:14 AM, Nuno Sá wrote:
> On Tue, Aug 18, 2026 at 10:02:50AM -0500, David Lechner wrote:
>> On 8/17/26 6:32 PM, Jonathan Santos wrote:
>>> 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.
> 
> 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á
> 
>>

Now that I'm reading the later patches again, it is jogging my memory.
I forgot that we want this to operate like a single multi-lane device
when reading data.

So for that part, yes, having spi-rx-bus-width kind of makes sense.

And I'm thinking that we might need a new property to indicate that
this should be treated as a composite device rather than main + 3
auxiliary. I'll reply more about that in a later patch.