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 [off-list ref]; devicetree@vger.kernel.org;
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: 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" [off-list ref] wrote:

quoted

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

quoted

quoted

Clausen [off-list ref]; Ricardo Ribalda

[off-list ref];

quoted

quoted

Hennerich, Michael [off-list ref]; Gwenhael
Goavec-Merou [off-list ref];

Michael

quoted

quoted

Welling [off-list ref]
Subject: [PATCH 00/15] dt-bindings: iio: dac: Add most missing

binding

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

I got bored half way through of producing brief descriptions of
the devices so stopped doing so. If anyone wants to provide one

for

quoted

quoted

these
parts I'm happy to add it!

Future series will cover the c. 40 bindings that I've identified as

missing

quoted

quoted

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

quoted

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á