linux-kernel - Re: [PATCH v4 2/2] iio: mcp4531: Driver for Microchip digital potentiometers

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]

Message-ID: <5602574B.5020205@lysator.liu.se>
Date:	Wed, 23 Sep 2015 09:39:55 +0200
From:	Peter Rosin <peda@...ator.liu.se>
To:	Jonathan Cameron <jic23@...23.retrosnub.co.uk>,
	linux-iio@...r.kernel.org
Cc:	Peter Rosin <peda@...ntia.se>, Crt Mori <cmo@...exis.com>,
	Daniel Baluta <daniel.baluta@...il.com>,
	Andreas Dannenberg <dannenberg@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jonathan Cameron <jic23@...nel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] iio: mcp4531: Driver for Microchip digital
 potentiometers

On 2015-09-22 20:22, Jonathan Cameron wrote:
> On 22 September 2015 16:36:49 BST, Peter Rosin <peda@...ator.liu.se> wrote:

*snip* lots of cosmetics that I'll fix in the next spin...

>> +
>> +static int mcp4531_read_raw(struct iio_dev *indio_dev,
>> +			    struct iio_chan_spec const *chan,
>> +			    int *val, int *val2, long mask)
>> +{
>> +	int err;
>> +
>> +	switch (mask) {
>> +	case IIO_CHAN_INFO_RAW:
>> +		err = mcp4531_get_value(indio_dev, chan->address, val);
>> +		if (err < 0)
>> +			return err;
>> +		return IIO_VAL_INT;
>> +	}
> No scale known? Be nice to relate to real world values.  I gather this may need
>  platform data of some type (can't open data sheet on phone for some reason)

...but I need more input on this.

Yes, it would be nice and yes it requires platform data, as there is
no way to retrieve if the driver is dealing with a 5, 10, 50 or 100 kOhms
pot/rheostat. You would also have to expose both the resistance between
A to W and between W to B, as you have no way to know how it's been
connected (or you'd need more platform data). Ok, for rheostats you
know how it's connected, since A isn't available, but for pots there
are two resistance values controlled with a single value X i.e.
X*scale/max and (max-X)*scale/max (ignoring the 75 Ohm wiper resistance).

But, I'd rather not go there, as I don't need any of it. Is it Ok to not
provide scaling?

Cheers,
Peter

--
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/