Re: [PATCH 00/15] dt-bindings: iio: dac: Add most missing binding documents.

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 29 Jun 2021 08:28:30 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:

> > From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> > Sent: Monday, June 28, 2021 3:44 PM
> > To: Sa, Nuno <Nuno.Sa@analog.com>
> > Cc: Jonathan Cameron <jic23@kernel.org>; linux-iio@vger.kernel.org;
> > Rob Herring <robh+dt@kernel.org>; devicetree@vger.kernel.org;
> > Lars-Peter Clausen <lars@metafoo.de>; Ricardo Ribalda
> > <ribalda@kernel.org>; Hennerich, Michael
> > <Michael.Hennerich@analog.com>; Gwenhael Goavec-Merou
> > <gwenhael.goavec-merou@trabucayre.com>; Michael Welling
> > <mwelling@ieee.org>
> > Subject: Re: [PATCH 00/15] dt-bindings: iio: dac: Add most missing
> > binding documents.
> > 
> > [External]
> > 
> > On Mon, 28 Jun 2021 07:09:18 +0000
> > "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> >   
> > > Hi Jonathan,
> > >  
> > > > -----Original Message-----
> > > > From: Jonathan Cameron <jic23@kernel.org>
> > > > Sent: Sunday, June 27, 2021 6:32 PM
> > > > To: linux-iio@vger.kernel.org; Rob Herring <robh+dt@kernel.org>;
> > > > devicetree@vger.kernel.org
> > > > Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>; Lars-  
> > Peter  
> > > > Clausen <lars@metafoo.de>; Ricardo Ribalda  
> > <ribalda@kernel.org>;  
> > > > Hennerich, Michael <Michael.Hennerich@analog.com>; Gwenhael
> > > > Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>;  
> > Michael  
> > > > Welling <mwelling@ieee.org>
> > > > Subject: [PATCH 00/15] dt-bindings: iio: dac: Add most missing  
> > binding  
> > > > documents.
> > > >
> > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > >
> > > > We have quite a few drivers in IIO that date back to the days of
> > > > platform
> > > > data.  Many of them either worked out of the box with device tree
> > > > due to the spi core using the spi_device_id to match against
> > > > device tree compatibles, or were updated to use newer interfaces  
> > in  
> > > > the
> > > > intervening years.  As such, they mostly 'work' with device tree but
> > > > can have some slightly odd quirks (particularly around naming of
> > > > supplies).
> > > > As we have no way of knowing what is out in the wild, we need to
> > > > support
> > > > these interesting bits of regulator naming.
> > > >
> > > > I would ultimately like all such bindings to be documented both to
> > > > facilitate
> > > > automated check of device trees and to make things easier for  
> > people  
> > > > trying
> > > > to write device tree files using these devices.
> > > >
> > > > This series fills in the majority of the absent bindings for DACs.
> > > > There are some outstanding
> > > > * max517 - some platform data configuration needs porting over to
> > > > device tree.
> > > > * m62332 - this passes a consumer mapping in as platform data and  
> > will  
> > > > need
> > > >   careful porting over the dt way of doing that.
> > > >
> > > > There is one 'fixlet' in here for the driver to deal with a case were  
> > the  
> > > > code was intended to allow the presence of a regulator to dictate
> > > > whether
> > > > an internal reference was used, but did not use the optional  
> > regulator  
> > > > get.
> > > >
> > > > I've mostly nominated maintainers based on original authorship +
> > > > where
> > > > I was feeling guilty or couldn't find anyone still active I've listed  
> > myself.  
> > > >
> > > > I got bored half way through of producing brief descriptions of
> > > > the devices so stopped doing so. If anyone wants to provide one  
> > for  
> > > > these
> > > > parts I'm happy to add it!
> > > >
> > > > Future series will cover the c. 40 bindings that I've identified as  
> > missing  
> > > > for other types of devices.  I've also kept notes of easy cleanups in
> > > > drivers spotted whilst working these out, so will probably follow up
> > > > with
> > > > those soon as well.
> > > >
> > > > Note I haven't tested all of these so there may well be errors or
> > > > elements
> > > > I've missed.
> > > >  
> > >
> > > LGTM... Just wondering if we could not add the adi,ad5421 directly  
> > into  
> > > the trivial-devices yaml as it looks to be the only one without any odd
> > > regulator name?  
> > 
> > We could, but would probably end up pulling it out again.  As noted in
> > that patch description there is a bunch of stuff the binding doesn't
> > currently
> > support that would make sense to add if anyone actually needs it.  
> 
> Fair enough :)
> 
> - Nuno Sá
> 
Applied all except patch 5 where something odd happened with the test scripts
that needs another look.

Thanks,

Jonathan