linux-kernel - Re: [PATCH v3 01/10] dt-bindings: iio: adc: Add AD4170

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: <20250531165030.17916667@jic23-huawei>
Date: Sat, 31 May 2025 16:50:30 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-kernel@...r.kernel.org, lars@...afoo.de,
 Michael.Hennerich@...log.com, dlechner@...libre.com, nuno.sa@...log.com,
 andy@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 linus.walleij@...aro.org, brgl@...ev.pl
Subject: Re: [PATCH v3 01/10] dt-bindings: iio: adc: Add AD4170

On Mon, 26 May 2025 18:59:48 -0300
Marcelo Schmitt <marcelo.schmitt1@...il.com> wrote:

> Hi Jonathan,
> 
> I'm still working on the changes suggested for this set.
> Just to mention, I've updated the dt-binding to declare only channel nodes under
> the ADC node.
> 
> ... 
> > > +      adi,sensor-type:
> > > +        description: |
> > > +          Type of sensor connected to the device. Depending on the sensor type
> > > +          (weigh scale, RTD, or thermocouple) the values of sensor-node
> > > +          properties have slightly different constraints. This property
> > > +          specifies which particular external sensor is connected to the ADC so
> > > +          the sensor-node properties can be properly parsed and verified. The
> > > +          possible sensor types are:
> > > +          0: weigh scale;
> > > +          1: RTD;
> > > +          2: thermocouple.
> > > +        $ref: /schemas/types.yaml#/definitions/uint8  
> > 
> > I think this should be an enum of strings.  That will give us a clean
> > way to extend it for other sensor types in future.  
> Ack
> 
> ...
> > > +
> > > +  interrupts:
> > > +    maxItems: 1  
> > 
> > What if they are both wired?  At that point shouldn't software
> > make up it's mind which to use?  
> 
> Not sure I understand the concern here. Is 'interrupt-names' property expected
> to precede 'interrupts' in dt-doc? For AD4170 and similar parts, the data
> ready signal (/RDY) is by default provided on the SDO line after the completion
> of a conversion. Alternatively, it can be provided on the DIG_AUX1 pin in
> which case the chip disables the RDY function on SDO. So, there can only be one
> data ready interrupt enabled at a time. Guess I'll add some description to make
> clear only one interrupt can be enabled.

DT is describing the wiring, not what should be enabled by the driver.

There is no need for it to restrict to 1 interrupt if someone has wired them
both that I can think of.  In that circumstance the driver gets to decide
between the mess of shared SDO / dataready handling vs a nice
separate signal on dig_aux1

If both are wired to the host on appropriate pins, up to the driver to
decide what it wants.  A driver may also only supports the
dig_aux1 combination or only the sdo combination and so just fail to load
if it isn't happy with the one the DT author thought mattered.
Providing both if that is what is wired, gives the flexibility to find
the right one. 

> 
> > > +
> > > +  interrupt-names:
> > > +    description:
> > > +      Specify which pin should be configured as Data Ready interrupt.
> > > +    enum:
> > > +      - sdo
> > > +      - dig_aux1
> > > +    default: sdo
> > > +  
> 
> Thanks,
> Marcelo
>