| Message ID | 20210627163244.1090296-1-jic23@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | dt-bindings: iio: dac: Add most missing binding documents. | expand |
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>
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>
> 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á
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
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