Hi Jonathan, > -----Original Message----- > From: Jonathan Cameron <jic23@xxxxxxxxxx> > Sent: Sunday, June 27, 2021 6:32 PM > To: linux-iio@xxxxxxxxxxxxxxx; Rob Herring <robh+dt@xxxxxxxxxx>; > devicetree@xxxxxxxxxxxxxxx > Cc: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>; Lars-Peter > Clausen <lars@xxxxxxxxxx>; Ricardo Ribalda <ribalda@xxxxxxxxxx>; > Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>; Gwenhael > Goavec-Merou <gwenhael.goavec-merou@xxxxxxxxxxxxxx>; Michael > Welling <mwelling@xxxxxxxx> > Subject: [PATCH 00/15] dt-bindings: iio: dac: Add most missing binding > documents. > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > 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@xxxxxxxxxx>
