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 11:24:11 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	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

> > Non-staging code cannot depend upon staging code. That is the rule GregKH
> > laid down. The Intel drivers involved are established non staging drivers
> > and the gpadc layer is basically cleaning up the fact they all do this
> > themselves in private right now without any central co-ordination or
> > abstraction.
> 
> So, that's a bit different and not at all obvious from your e-mail - the
> diffstat shows only the code you're adding, not the code you've factored
> out of the existing mainline drivers.  The diffstat you posted was:
> 
> | arch/x86/include/asm/intel_mid_gpadc.h   |   13 +
> | arch/x86/platform/mrst/Makefile          |    1
> | arch/x86/platform/mrst/intel_mid_gpadc.c |  645 ++++++++++++++++++++++++++++++
> | arch/x86/platform/mrst/mrst.c            |    6
> | 4 files changed, 665 insertions(+), 0 deletions(-)
> 
> which is a pure addition of code and I'm not seeing anything in the
> changelog about this either.

True.. the code factoring out stuff is supposed to follow once this is
sorted.

> We do have to be careful about this sort of "this is a little bit of low
> level code" thing - it (along with "our hardware is unique") comes up
> rather a lot and it's often missing a good chunk of the picture.

Yes. But it also helps - there is no user space API here so the only bit
of IIO that needs importing is small, and if the API in kernel changes
nothing userspace will break.

I don't btw think that layer should depend upon IIO though - IIO should
depend upon that layer. There's no need to drag all the rest of IIO in
for this, just as it can depend upon the gpio layer etc.

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.

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.

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