RE: [PATCH 00/15] dt-bindings: iio: dac: Add most missing binding documents.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux