[PATCH] hwmon: (ads1015) Add devicetree documentation

[Jean Delvare]

Hi Wolfram,

On Thu, 3 Mar 2011 12:51:51 +0100, Wolfram Sang wrote:
> On Thu, Mar 03, 2011 at 10:16:45AM +0100, Dirk Eibach wrote:
> > Signed-off-by: Dirk Eibach <eibach at gdsys.de>
> > ---
> >  Documentation/devicetree/bindings/i2c/ads1015.txt |   15 +++++++++++++++
> >  1 files changed, 15 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/i2c/ads1015.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/i2c/ads1015.txt b/Documentation/devicetree/bindings/i2c/ads1015.txt
> > new file mode 100644
> > index 0000000..3a7d67a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i2c/ads1015.txt
> > @@ -0,0 +1,15 @@
> > +ADS1015 (I2C)
> > +
> > +Optional properties:
> > +
> > + - exported-channels : exported_channels is a bitmask that specifies which
> > +		       inputs should be exported to sysfs.
> 
> Hmm, device tree bindings should be OS-neutral, sysfs is not.

Why do we document this in the Linux kernel tree then?

> Maybe
> "active-channels" would be better; then the OS could decide what to do
> with the active channels. Then again, what is the drawback of exporting
> all channels?

Performance and user-friendliness. libsensors-based applications will
read all available attributes by default, and each reading takes time.
Letting the platform declare how the inputs are used allows for a sane
output for "sensors" and other similar tools out of the box, without
the user having to tinker with ignore statements in configuration files
to discard the nonsensical values.

> Is there another hwmon-driver doing so (couldn't find one)?

If "doing so" means "letting the user define how the ADC inputs are
used", then yes, the pcf8591 driver does something similar, except that
it uses a module parameter for the setting, for historical reasons.
Platform-provided, per-device data is better in my opinion.

-- 
Jean Delvare