linux-kernel - Re: [PATCH RESEND] x86, intel

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: <4F856173.8000901@cam.ac.uk>
Date:	Wed, 11 Apr 2012 11:48:19 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management

On 4/11/2012 11:38 AM, Mark Brown wrote:
> On Wed, Apr 11, 2012 at 11:24:11AM +0100, Alan Cox wrote:
>
>> If that code gets pulled out of IIO dumped into drivers/adc and has a bit
>> of a different API to the gpadc code then no problem, gpadc can follow it
>> happily enough. IIO can use it from staging and IIO can migrate whenever.
IIO is about a heck of a lot other than ADCs.  Keep that in mind. They 
are a substantial
corner but we handle a lot of output devices and other input devices 
(though these
might be adc's inside, that's not what your average users think of them as).
We 'have' to ensure anything we do works for the other device types as well.
>> It does make sense to think hard about userspace APIs for IIO but for
>> kernel APIs its really being too conservative - we break kernel APIs
>> every release. They are not set into stone.
> The way I keep thinking about this (which I'm sure I've suggested
> before) is that we should be refactoring IIO such that the userspace ABI
> is just another in-kernel consumer of the device driver bit of IIO and
> that driver bit should be small enough to just use.  I think that winds
> up being roughly equivalent to your suggestion but means that there's
> just one place to put the drivers which seems like a win.
The intent is there, but there are an awful lot of corner cases that 
need working out.
Mostly these don't relate to simple adc usage. Just take a look at those 
elements
of the drivers that don't pass through the read_raw and write_raw callbacks.

It might be possible to make the userspace interfaces optional without 
too much pain.

I  know it's not ideal, but at the end of the day IIO had a rather 
different target when
we wrote it from SoC ADCs. That target of consistent userspace 
interfaces and
brute force data capture still has to be met without introducing major 
regressions.



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