linux-kernel - Re: [PATCH] iio: add ad5761 DAC driver

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:	Sun, 20 Dec 2015 12:19:06 +0100
From:	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To:	Jonathan Cameron <jic23@...nel.org>
Cc:	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Hartmut Knaack <knaack.h@....de>,
	Peter Meerwald <pmeerw@...erw.net>, linux-iio@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iio: add ad5761 DAC driver

Hello Jonthan

Thanks for your comments, I have fixed all the style problems in v2,
so we can focus in the range parameter.

On Sat, Dec 19, 2015 at 5:31 PM, Jonathan Cameron <jic23@...nel.org> wrote:
> Range isn't actually specified in the ABI docs.
> Documenation\ABI\testing\sysfs-bus-iio*
> The control interface for this is normally scale rather than range
> (we had to pick one of the two and that is the way it fell out)  Usually
> hardware designers care about range, but userspace programs are often
> most directly interested in scale factors that need to be applied.
> (and that was my most rediculously over generalized statement for the day ;)

What about a first version of the driver where the range is set via
pdata and is not userland configurable?
That way the four chips will be supported and we can have more
feedback from other users about the range issue.

>
> I can see this is rather complex here given the random looking collection
> of associated scales and offsets.  You would have to have _available
> attributes to say what offsets are available at a given scale I think.
> Also we'd have to then define a precedence order in the docs for the
> two attributes (worth doing to make it obvious what to do when this
> sort of setup arises).

The problem with that approach is that there will be two operations to
set the range: one  to change the scale, and another for the offset.  The output
voltage will change twice in this process and may have an intermediate value
that can damage a circuit.

I also believe that my approach with a text description is more user friendly
(but problably because I programmed it :P)

In any case, I will implement whatever we agree ;)

Best regards!
--
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/