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 17:30:47 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management



Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:

>On Wed, Apr 11, 2012 at 07:19:01AM +0100, Jonathan Cameron wrote:
>> 
>> 
>> Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:
>> 
>> >On Tue, Apr 10, 2012 at 08:39:40PM +0100, Jonathan Cameron wrote:
>> >
>> >> 1)  Review of code.  This is crucial. If people have a little time
>> >> ripping holes in the core IIO code is what we need.  Arnd did a
>good
>> >job
>> >> of this a while back. Others have done bits of it since.
>> >
>> >> 2) Getting the push code tidied up and pushed out.  I'll post it
>as
>> >an
>> >> updated rfc to linux-iio shortly.  All I had left that definitely
>> >> wanted doing here was cleaning up the example iio to input bridge
>> >> driver.  That can happen later.
>> >
>> >For these two can we refactor in place?  That's pretty much what
>seems
>> >to have been happening anyway...
>> >
>> I guess it comes down to whether Linus will pull.  2 should be there
>> within a week or so anyway depending mostly on analog testing I
>> haven't broken any of their drivers.
>
>Hm, shouldn't I be the one that moves this out of staging?  :)

Sorry. Still in mind set of last try where we a parrallel version planned..

>Anyway, all I care about to get this code out of staging is that you
>feel your userspace api is "sane" and not going to change.  Your
>in-kernel stuff can radically change every kernel release with no
>objection from me at all.
>
>And from what I can tell, your userspace stuff looks pretty stable now,
>right?  So, I don't mind moving this all out of staging for 3.5 as-is.

There are corners of the userspace abi that aren't but they aren't related to the core so we can break the abi docs in two and just move the good stuff... 


>
>If so, I'll be glad to make the change to my repo so it starts to show
>up in linux-next in the "correct" place whenever you want me to.

Will clear current queue under review then that would be great.

Note we will need to leave a lot of drivers in staging for now so move may require a few sed scripts to link up headers etc...  quite a lot of drivers are way off.

Lets start a fresh thread on the move to make sure everyone agrees on what is ready!  

Thanks as ever for all your hard work!

>thanks,
>
>greg k-h

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
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/