On Mon, 28 Jun 2021 07:09:18 +0000
"Sa, Nuno" [off-list ref] wrote:

Hi Jonathan,

quoted

-----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 [off-list ref]; Ricardo Ribalda [off-list ref];
Hennerich, Michael [off-list ref]; Gwenhael
Goavec-Merou [off-list ref]; Michael
Welling [off-list ref]
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>