mbox series

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

Message ID 20210627163244.1090296-1-jic23@kernel.org
Headers show
Series dt-bindings: iio: dac: Add most missing binding documents. | expand

Message

Jonathan Cameron June 27, 2021, 4:32 p.m. UTC
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.

Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Ricardo Ribalda <ribalda@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Cc: Michael Welling <mwelling@ieee.org>

Jonathan Cameron (15):
  dt-bindings: iio: dac: adi,ad5421: Add missing binding document.
  dt-bindings: iio: dac: adi,ad5064: Document bindings for many
    different DACs
  dt-bindings: iio: dac: adi,ad5360: Add missing binding document
  dt-bindings: iio: dac: ad5380: Add missing binding document
  dt-bindings: iio: dac: ad5446: Add missing binding document
  dt-bindings: iio: dac: ad5449: Add missing binding document.
  dt-bindings: iio: dac: ad5504: Add missing binding document
  iio: dac: ad5624r: Fix incorrect handling of an optional regulator.
  dt-bindings: iio: dac: ad5624r: Add missing binding document
  dt-bindings: iio: dac: ad5686 and ad5696: Add missing binding
    document.
  dt-bindings: iio: dac: ad5761: Add missing binding doc.
  dt-bindings: iio: dac: adi,ad5764: Add missing binding document
  dt-bindings: iio: dac: adi,ad5791: Add missing bindings document
  dt-bindings: iio: dac: adi,ad8801: Add missing binding document.
  dt-bindings: iio: dac: microchip,mcp4922: Add missing binding document

 .../bindings/iio/dac/adi,ad5064.yaml          | 268 ++++++++++++++++++
 .../bindings/iio/dac/adi,ad5360.yaml          |  79 ++++++
 .../bindings/iio/dac/adi,ad5380.yaml          |  70 +++++
 .../bindings/iio/dac/adi,ad5421.yaml          |  51 ++++
 .../bindings/iio/dac/adi,ad5446.yaml          | 105 +++++++
 .../bindings/iio/dac/adi,ad5449.yaml          |  97 +++++++
 .../bindings/iio/dac/adi,ad5504.yaml          |  50 ++++
 .../bindings/iio/dac/adi,ad5624r.yaml         |  47 +++
 .../bindings/iio/dac/adi,ad5686.yaml          |  75 +++++
 .../bindings/iio/dac/adi,ad5761.yaml          |  60 ++++
 .../bindings/iio/dac/adi,ad5764.yaml          |  62 ++++
 .../bindings/iio/dac/adi,ad5791.yaml          |  52 ++++
 .../bindings/iio/dac/adi,ad8801.yaml          |  60 ++++
 .../bindings/iio/dac/microchip,mcp4922.yaml   |  46 +++
 drivers/iio/dac/ad5624r_spi.c                 |  18 +-
 15 files changed, 1139 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5446.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml

-- 
2.32.0

Comments

Nuno Sa June 28, 2021, 7:09 a.m. UTC | #1
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?

Anyways, feel free to add:

Acked-by: Nuno Sá <nuno.sa@analog.com>
Jonathan Cameron June 28, 2021, 1:44 p.m. UTC | #2
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.

Hmm. I guess it's a question of whether we think anyone will ever care :)

Jonathan
> 

> Anyways, feel free to add:

> 

> Acked-by: Nuno Sá <nuno.sa@analog.com>
Nuno Sa June 29, 2021, 8:28 a.m. UTC | #3
> 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á
Jonathan Cameron July 17, 2021, 6:11 p.m. UTC | #4
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