Re: [PATCH v2 5/6] dt-bindings: iio: adc: adi,ad7380: add spi-buses property

[David Lechner <dlechner@baylibre.com>]

On 12/4/25 8:28 AM, Rob Herring wrote:
> On Wed, Nov 19, 2025 at 08:45:42AM -0600, David Lechner wrote:
>> On 11/19/25 7:18 AM, Rob Herring wrote:
>>> On Tue, Nov 18, 2025 at 11:46 AM David Lechner <dlechner@baylibre.com> wrote:
>>>>
>>>> On 11/18/25 9:59 AM, Rob Herring wrote:
>>>>> On Fri, Nov 07, 2025 at 02:52:51PM -0600, David Lechner wrote:
>>>>>> Add spi-buses property to describe how many SDO lines are wired up on
>>>>>> the ADC. These chips are simultaneous sampling ADCs and have one SDO
>>>>>> line per channel, either 2 or 4 total depending on the part number.
>>>>>>
>>>>>> Signed-off-by: David Lechner <dlechner@baylibre.com>
>>>>>> ---
>>>>>>  .../devicetree/bindings/iio/adc/adi,ad7380.yaml    | 22 ++++++++++++++++++++++
>>>>>>  1 file changed, 22 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
>>>>>> index b91bfb16ed6bc6c605880f81050250d1ed9c307a..9ef46cdb047d45d088e0fbc345f58c5b09083385 100644
>>>>>> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
>>>>>> @@ -62,6 +62,10 @@ properties:
>>>>>>    spi-cpol: true
>>>>>>    spi-cpha: true
>>>>>>
>>>>>> +  spi-data-buses:
>>>>>> +    minItems: 1
>>>>>> +    maxItems: 4
>>>>>> +
>>>>>
>>>>> As the property is not required, what's the default?
>>>>
>>>> spi-perepheral-props.yaml defines:
>>>>
>>>>         default: [0]
>>>>
>>>> Do I need to repeat that here?
>>>
>>> No. So that means you only use one channel and the others are not connected?
>>
>> Correct.
>>
>>>
>>>>
>>>>>
>>>>>>    vcc-supply:
>>>>>>      description: A 3V to 3.6V supply that powers the chip.
>>>>>>
>>>>>> @@ -245,6 +249,22 @@ allOf:
>>>>>>        patternProperties:
>>>>>>          "^channel@[0-3]$": false
>>>>>>
>>>>>> +  # 2-channel chip can only have up to 2 buses
>>>>>> +  - if:
>>>>>> +      properties:
>>>>>> +        compatible:
>>>>>> +          enum:
>>>>>> +            - adi,ad7380
>>>>>> +            - adi,ad7381
>>>>>> +            - adi,ad7386
>>>>>> +            - adi,ad7387
>>>>>> +            - adi,ad7388
>>>>>> +            - adi,ad7389
>>>>>> +    then:
>>>>>> +      properties:
>>>>>> +        spi-data-buses:
>>>>>> +          maxItems: 2
>>>>>> +
>>>>>>  examples:
>>>>>>    - |
>>>>>>      #include <dt-bindings/interrupt-controller/irq.h>
>>>>>> @@ -260,6 +280,7 @@ examples:
>>>>>>              spi-cpol;
>>>>>>              spi-cpha;
>>>>>>              spi-max-frequency = <80000000>;
>>>>>> +            spi-data-buses = <0>, <1>;
>>>>>>
>>>>>>              interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
>>>>>>              interrupt-parent = <&gpio0>;
>>>>>> @@ -284,6 +305,7 @@ examples:
>>>>>>              spi-cpol;
>>>>>>              spi-cpha;
>>>>>>              spi-max-frequency = <80000000>;
>>>>>> +            spi-data-buses = <0>, <1>, <2>, <3>;
>>>>>
>>>>> An example that doesn't look like a 1 to 1 mapping would be better.
>>>>> Otherwise, it still looks to me like you could just define the bus
>>>>> width.
>>>>
>>>> I'm not sure we could do that on this chip since it doesn't have
>>>> the possibility of more than one line per channel.
>>>
>>> That's a property of the SPI controller though, right?
>>>
>>> If the above controller had 4 lines per channel/serializer, then you could have:
>>>
>>> spi-data-buses = <0>, <4>, <8>, <12>;
>>
>> Ah, I get what you mean now. The intention here though was that the
>> index numbers correspond to the data lane (channel/serializer), not
>> to individual lines. So the example you gave would mean that the chip
>> has at least 13 data lanes (rather than what I think your intention was
>> of saying it has at least 16 data wires). I did it that way because all
>> of the hardware I looked at didn't allow assigning arbitrary data lines
>> to arbitrary lanes/channels so it keeps things simpler and easier to match
>> to the actual hardware docs.
> 
> But what happens if there is such h/w? Better to design things for 
> something we can visualize and not have to revisit this. Of course there 
> will be things we don't anticipate. (Who thought we'd have parallel 
> SPI...)
> 
> I suppose if that's rare enough we can just have another property to map 
> pins to channels.
> 
> Rob

I haven't seen any hardware that can handle arbitrary wiring like this
and most hardware designs tend to wire things up in a logical order
so I'm inclined to go with the "adding a controller-specific property
for this later if we find we really need it" approach.

(BTW I sent a v3 on Monday when you have a chance to take a look)