On Mon, 28 Jun 2021 07:09:18 +0000 "Sa, Nuno" <Nuno.Sa@xxxxxxxxxx> wrote: > 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? 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@xxxxxxxxxx>
