[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMknhBHLEjtiQVOVODdvfH=pOP656=1RNb=9-rt37H7iowVDBw@mail.gmail.com>
Date: Wed, 3 Apr 2024 10:14:35 -0500
From: David Lechner <dlechner@...libre.com>
To: "Ceclan, Dumitru" <mitrutzceclan@...il.com>
Cc: dumitru.ceclan@...log.com, Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron <jic23@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: adc: ad7173: add support for ad411x
On Wed, Apr 3, 2024 at 5:08 AM Ceclan, Dumitru <mitrutzceclan@...ilcom> wrote:
>
> On 03/04/2024 10:45, Ceclan, Dumitru wrote:
> > On 01/04/2024 23:22, David Lechner wrote:
> >> On Mon, Apr 1, 2024 at 2:37 PM David Lechner <dlechner@...libre.com> wrote:
> >>>
> >>> On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
> >>> <devnull+dumitru.ceclan.analog.com@...nel.org> wrote:
> >
> > ...
> >
> >>
> >> Also, I just noticed that AD411x have only one AVDD input instead of
> >> AVDD1 and AVDD2. So we need an if statement that says if properties:
> >> compatible: enum: - adi,ad411x, then properties: avdd2-supply: false.
> >
> > Already addressed by this:
> > "
> > # Only ad7172-4, ad7173-8 and ad7175-8 support vref2
> > - if:
> > properties:
> > compatible:
> > not:
> > contains:
> > enum:
> > - adi,ad7172-4
> > - adi,ad7173-8
> > - adi,ad7175-8
> > then:
> > properties:
> > vref2-supply: false
> > patternProperties:
> > "^channel@[0-9a-f]$":
> > properties:
> > adi,reference-select:
> > enum:
> > - vref
> > - refout-avss
> > - avdd
> > "
>
> Mistaken vref2-supply to avdd2-supply.
>
> But still, the presence of avdd2-supply does not influence anything at all.
> Driver does not use it, you cannot select it for channel conversions.
> Would a restriction like this really be required?
It is true that it is not likely to cause any problems we don't fix
this but why would we want the bindings to intentionally be incorrect
when there is an easy fix? Driver implementations should not influence
leaving something out of the bindings [1].
[1]: https://www.kernel.org/doc/html//v5.10/devicetree/bindings/writing-bindings.html#overall-design
Powered by blists - more mailing lists