linux-kernel - Re: [PATCH] staging:iio:proof of concept in kernel interface.

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: <20111017124807.GD27266@opensource.wolfsonmicro.com>
Date:	Mon, 17 Oct 2011 13:48:07 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Linus Walleij <linus.ml.walleij@...il.com>,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	zdevai@...il.com
Subject: Re: [PATCH] staging:iio:proof of concept in kernel interface.

On Mon, Oct 17, 2011 at 01:31:25PM +0100, Jonathan Cameron wrote:
> On 10/17/11 13:08, Mark Brown wrote:
> > On Mon, Oct 17, 2011 at 12:32:25PM +0100, Jonathan Cameron wrote:

Your mails would be much more legible if you'd leave blank lines between
paragraphs and if you could wrap your mails at less than 80 columns.

> >> (have insist on indexing even with named channels because it is needed as
> >> events codes don't want to carry a string.).

> > This is orthogonal to the request interface, though.

> No it isn't - because it will effect the numbering of the gneral purpose ones.

I don't think the numbers reported in events should be forced to be
directly associated with the numbers (consider the case with mixes of
high sensitivity and low sensitivity inputs for example).

> >> Not hard wired so to my mind these are just general purpose temperature inputs.
> >> Hence naming doesn't make sense (at least not outside of board file or DT).

> > No, they're hard wired - like I say they're wired to a particular place.

> If it isn't physically in the pmic package then it doesn't belong in the driver.

In the case of the die temperature measurement things are obviously
entirely within the PMIC.  In the case of battery temperature monitoring
the actual sensor is outside the device but it's fixed function due to
cross connection with the autonomous control logic for the battery
chargers.

> Note the numbering is still going to be Linux specific just within a given type
> of channel. ADC channels regularly have completely inconsistent (and/or stupid) names
> in device data sheets.

> 0...4
> 1...5
> AUXA....AUXD
> TEMP_EXT1...TEMP_EXT5 (all of which are just normal adc channels that some
> designer decided would be used only for connecting analog temperature sensors.)

None of those look at all unreasonable?

> All of these get mapped to 0...4.  Anything else leads to totally unpredictable
> guessing games when trying to find the channel.

I dunno, things like introducing an offset of 1 into the numbers the
datasheet uses can be pretty painful to work with - it's not obvious
when looking at the code that you've got the number wrong.  With the
PMICs it's been really helpful to do things like map the LDOs and DCDCs
separately even though at the level where you're gluing things together
there's no meaningful difference.

Once we're running it's a different story, it's just when expressing the
wiring to the system that I'm worried.
--
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/