linux-kernel - Re: [PATCH v11 1/2] dt-bindings: adc: add AD7173

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: <20240117163725.00003981@Huawei.com>
Date: Wed, 17 Jan 2024 16:37:25 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ceclan Dumitru <mitrutzceclan@...il.com>
CC: David Lechner <dlechner@...libre.com>, <linus.walleij@...aro.org>,
	<brgl@...ev.pl>, <andy@...nel.org>, <linux-gpio@...r.kernel.org>, "Lars-Peter
 Clausen" <lars@...afoo.de>, Jonathan Cameron <jic23@...nel.org>, Rob Herring
	<robh+dt@...nel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
	Michael Walle <michael@...le.cc>, Andy Shevchenko
	<andy.shevchenko@...il.com>, Arnd Bergmann <arnd@...db.de>, ChiaEn Wu
	<chiaen_wu@...htek.com>, Niklas Schnelle <schnelle@...ux.ibm.com>, Leonard
 Göhrs <l.goehrs@...gutronix.de>, Mike Looijmans
	<mike.looijmans@...ic.nl>, Haibo Chen <haibo.chen@....com>, Hugo Villeneuve
	<hvilleneuve@...onoff.com>, Ceclan Dumitru <dumitru.ceclan@...log.com>,
	<linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v11 1/2] dt-bindings: adc: add AD7173

On Wed, 17 Jan 2024 14:43:21 +0200
Ceclan Dumitru <mitrutzceclan@...il.com> wrote:

> On 1/16/24 18:30, Jonathan Cameron wrote:
> > On Mon, 15 Jan 2024 15:53:39 -0600
> > David Lechner <dlechner@...libre.com> wrote:
> >   
> >> On Wed, Dec 20, 2023 at 4:48 AM Dumitru Ceclan <mitrutzceclan@...il.com> wrote:  
> 
> ...
> 
> >> Sorry for the late reply as I see this has been applied already but...  
> > We have plenty of time.  Rather than dropping the ad7173 from my tree,
> > I'd prefer to see additional patches on top to tidy up whatever
> > makes sense from David's feedback.
> >   
> Alright then.
> 
> ...
> 
> >>
> >> As discussed in v8 [1] it is not clear what signal this is. Based on
> >> that discussion, I'm assuming the RDY signal, but how would bindings
> >> consumers know that without a description since it is not the only
> >> digital output signal of the chip? And why the ERROR signal was
> >> omitted here was never addressed AFAICT.
> >>
> >> [1]: https://lore.kernel.org/linux-iio/20231217135007.3e5d959a@jic23-huawei/  
> > 
> > I'd forgotten about that.  Adding interrupt-names would be the easiest
> > way to resolve this.
> >   
> 
> I'll add this, but my curiosity for the long run is: How should
> differences between what bindings include and what drivers support
> should be managed and documented?

Drivers almost always support a subset of functionality of the device.
This isn't much different.  The driver 'should' use interrupt-names
but it doesn't need to support all the things that the binding says should
be in there.

Sometimes we document things in a driver, but there isn't any obligation to
do so and those docs are often out of date.

> 
> ...
> 
> >>> +
> >>> +  refin-supply:
> >>> +    description: external reference supply, can be used as reference for conversion.    
> >>
> >> If I'm understanding correctly, this represents both voltage inputs
> >> REF+ and REF-, correct? The datasheet says "Reference Input Negative
> >> Terminal. REF− can span from AVSS to AVDD1 − 1 V". It seems like they
> >> should be separate supplies in case REF- is non-zero. Otherwise, how
> >> can we know what voltage it is? (same comment applies to refin2.)  
> > 
> > Agreed, in this case these are directly used as references (we recently
> > had another driver that could take a wide range of negative and positive
> > inputs but in that case an internal reference was generated that didn't
> > made it not matter exactly what was being supplied.  Not true here though!
> >   
> Wouldn't it be alright to specify that the voltage specified here should
> be the actual difference (REF+)-(REF-)?

How do you establish the offset to apply to single ended channels if you don't
know the value of REF- (relative to local ground)?

So no - as the device supports single ended channels the difference isn't
enough information.  It would probably be fine to do as you say if it
were a device with only differential channels where all that matters is
the scaling.

> 
> ...
> 
> >>> +required:
> >>> +  - compatible
> >>> +  - reg
> >>> +  - interrupts    
> >>
> >> Why are interrupts required? What if the pin is not connected?
> >>  
> > Ah. I clearly failed to review this one closely enough.
> > 
> > Absolutely agree that interrupts should never be required.
> > No need for the driver to work if they aren't, but the binding
> > shouldn't require them!
> > 
> > Jonathan
> >   
> 
> To make sure that I understand, the driver will not probe without
> interrupts, but it is alright to make then optional in the bindings?

Yes - it is fine for a driver to only support a subset of functionality
and fail to probe if that subset isn't what the hardware enables.

> 
> This is in the case that someone will want to use this binding and
> implement reading with polling?

Yes.

J