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]

Date:	Wed, 11 Apr 2012 12:19:04 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>, 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 12:13 PM, Alan Cox wrote:
>>>> 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.
> At the IIO layer, but an ADC layer itself needs very very little indeed.
>
> You've got
> 	allocate
> 	deallocate
> 	read_samples (block/nonblock)
> 	setup
> 	->samples() callback

To add a few more things that are common (there are others).

Read scale, read offset.
Hardware event interrupts,
Triggering control.
Filtering control.

Some adcs may only need what you specify, others need a whole lot more.
You might term these setup I suppose, but the consumer of the data often
needs to know about them.
>
> and devices are either polled, IRQ driven or DMA.
>
> Now setup is a lot of different things but those can be abstracted and
> added as needed (and much probably taken from the IIO bits).
>
> A pure ADC abstraction ought to be a very very thin layer of code.
Except that you then end up with simple_adc abstraction and a whole host 
of more
complex abstractions on top.
>
>> 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.
> I don't see the two conflicting. At one level we have a need for a simple
> abstraction for low level ADC access within devices (akin to gpio). At the
> level above we have a need for a consistent, sensible interface to
> userspace with a stable API.
We have that simple abstraction.  Dumb polled or irq driven adc stuff 
can be done cleanly
in minimal code.
What I disagree on is that the bit you have grouped into setup is 
actually separate.  That
needs to be abstracted as well.  Consumers might not care that the gain 
just doubled
because someone else requested it, but I suspect many of them will.
>
> Your simple IIO examples would just use the ADC abstraction, your complex
> IIO examples would use the ADC abstraction *and* layer it with IIO level
> code that is mixing it with all the other needed work.
I suspect you'll end up adding more and more to your adc abstraction 
till you actually
end up with most of IIO.  That's effectively what we did...   It's big 
because there are
actually not that many 'simple' adc's out there.

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