Re: [PATCH RESEND] x86, intel_mid: ADC management

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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