linux-kernel - Re: [PATCH v2 2/8] dt-bindings: iio: dac: maxim,ds4424: add maxim,rfs-ohms property

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] [day] [month] [year] [list]

Message-ID: <20260128090118.5c1d7906@erd003.prtnl>
Date: Wed, 28 Jan 2026 09:01:18 +0100
From: David Jander <david@...tonic.nl>
To: Conor Dooley <conor@...nel.org>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Jonathan Cameron
 <jic23@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 kernel@...gutronix.de, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org, Andy Shevchenko
 <andy@...nel.org>, David Lechner <dlechner@...libre.com>, Nuno
 Sá <nuno.sa@...log.com>
Subject: Re: [PATCH v2 2/8] dt-bindings: iio: dac: maxim,ds4424: add
 maxim,rfs-ohms property

On Tue, 27 Jan 2026 19:55:26 +0000
Conor Dooley <conor@...nel.org> wrote:

> On Tue, Jan 27, 2026 at 07:49:20PM +0000, Conor Dooley wrote:
> > On Tue, Jan 27, 2026 at 07:09:33AM +0100, Oleksij Rempel wrote:  
> > > The Maxim DS4422/DS4424 and DS4402/DS4404 current DACs determine their
> > > full-scale output current via external resistors (Rfs) connected to the
> > > FSx pins. Without knowing these values, the full-scale range of the
> > > hardware is undefined.
> > > 
> > > Add the 'maxim,rfs-ohms' property to describe these physical components.
> > > This property is required to provide a complete description of the
> > > hardware configuration.
> > > 
> > > Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> > > ---
> > > changes v2:
> > > - make maxim,rfs-ohms a required property as the hardware range is undefined
> > >   without external resistors.
> > > - add allOf constraints to enforce 2 vs 4 items in maxim,rfs-ohms based on
> > >   compatible string.
> > > - drop explicit $ref for maxim,rfs-ohms to fix dt_binding_check warning.
> > > - update example in binding to include the new required property.
> > > ---
> > >  .../bindings/iio/dac/maxim,ds4424.yaml        | 36 +++++++++++++++++++
> > >  1 file changed, 36 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
> > > index efe63e6cb55d..400afd8771aa 100644
> > > --- a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
> > > +++ b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
> > > @@ -27,9 +27,44 @@ properties:
> > >  
> > >    vcc-supply: true
> > >  
> > > +  maxim,rfs-ohms:
> > > +    description: |
> > > +      Array of resistance values in Ohms for the external Rfs resistors
> > > +      connected to the FS pins.
> > > +      - For DS44x2 (2 channels): 2 values required.
> > > +      - For DS44x4 (4 channels): 4 values required.
> > > +      Typical values range from 40000 (40 kOhm) to 160000 (160 kOhm).  
> > 
> > Add here
> > maxItems: 4
> > minItems: 2
> > 
> > Are 40kOhm and 160kOhm actual max/min values, or just a suggested range?  
> 
> Datasheet for the ds4424 seems to imply they're actual max/min values:
> "Input resistors (RFS) must be between the speciifed values to ensure the
> device meets its accuracy and linearity specifications."
> In that case, consider also adding something like:
>     items:
>       maximum: 40000
>       minimum: 160000
> 
> Although, that would complain about the 5100 Ohms you're using. How come
> the example lies outside of the "typical" range?

Sorry to chime in here out of nowhere with this, but 2 things:
1. Rfs for DS4402/4 has a different "typical" range than DS4424 (different
Vref and different output current range).
2. "Typical" or "recommended" ranges should not translate to a hard limit in
the driver. IMHO, no max or min value should be enforced here.

> > > +
> > >  required:
> > >    - compatible
> > >    - reg
> > > +  - maxim,rfs-ohms
> > > +
> > > +allOf:
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - maxim,ds4402
> > > +              - maxim,ds4422
> > > +    then:
> > > +      properties:
> > > +        maxim,rfs-ohms:  
> >   
> > > +          minItems: 2  
> > 
> > Remove this...
> >   
> > > +          maxItems: 2
> > > +  - if:
> > > +      properties:
> > > +        compatible:
> > > +          contains:
> > > +            enum:
> > > +              - maxim,ds4404
> > > +              - maxim,ds4424
> > > +    then:
> > > +      properties:
> > > +        maxim,rfs-ohms:
> > > +          minItems: 4  
> > 
> >   
> > > +          maxItems: 4  
> > 
> > ...and this. The outer-most constraints should be in the definition and
> > the if/else bit just adjusts whichever bounds it needs to.
> > 
> > Cheers,
> > Conor.
> > 
> > pw-bot: changes-requested
> >   
> > >  
> > >  additionalProperties: false
> > >  
> > > @@ -43,6 +78,7 @@ examples:
> > >              compatible = "maxim,ds4424";
> > >              reg = <0x10>; /* When A0, A1 pins are ground */
> > >              vcc-supply = <&vcc_3v3>;
> > > +            maxim,rfs-ohms = <5100>, <5100>, <5100>, <5100>;
> > >          };
> > >      };
> > >  ...
> > > -- 
> > > 2.47.3
> > >   
> 
> 



-- 
David Jander