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:	Tue, 10 Apr 2012 15:07:50 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management

On Tue, Apr 10, 2012 at 02:42:35PM +0100, Alan Cox wrote:
> > Right, but fundamentally it's just a general purpose ADC which looks
> > just the same as all the other SoC/PMIC ADCs.  Like I say the decision
> > for that hardware was to push it in via IIO. 

> Your decision maybe. And it's one that makes no sense.

> As I said this is a low level interface for driver enabling including

It's not just me, it's where all the ARM SoCs and their PMICs are going.
If you look on the IIO list you'll see patches for at least the AT91 

> early boot time stuff, and its on a platform that's unlikely to want or
> ever use and suck in the big blob of IIO code.

Could you be more specific about what this early boot time stuff is?
Looking at the changelogs in there it all looks like the standard
battery monitoring and power supply stuff that these ADCs get used for -
just based on the changelogs there doesn't appear to be anything
remarkable here.

There's already a standard adaptor to map IIO into at least hwmon, not
sure about the power supply subsystem.  There were also some other
things people were doing in areas like thermal management that were
using this sort of hardware in generic ways.

> If you want an IIO interface to it you can write one, it's just a low
> level resource manager.

We can't just keep on going round adding new custom interfaces every
time someone supports a new SoC - it means we end up having to sit and
write lots of per-device adaptor code to integrate things and it's
hard for us to factor common code out of drivers when we've not got any
kind of framework for them.

If IIO is totally unsuitable then someone needs to make the case for a
new subsystem for this class of hardware and provide that subsystem but
it seems entirely obvious that there is a general class of hardware here
which is widely implemented.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ