lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251204142845.GA1303976-robh@kernel.org>
Date: Thu, 4 Dec 2025 08:28:45 -0600
From: Rob Herring <robh@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	Michael Hennerich <michael.hennerich@...log.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Andy Shevchenko <andy@...nel.org>,
	Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 5/6] dt-bindings: iio: adc: adi,ad7380: add spi-buses
 property

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@...libre.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@...libre.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ