linux-kernel - Re: [PATCH] hwmon: (ads1015) Add devicetree documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2011 13:20:25 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Dirk Eibach <eibach@...ys.de>, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, rdunlap@...otime.net,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [PATCH] hwmon: (ads1015) Add devicetree documentation

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@...ys.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/