If only it separated that well. There are numerous bits of iio that need to hack intoTrue.. the code factoring out stuff is supposed to follow once this isNon-staging code cannot depend upon staging code. That is the rule GregKHSo, that's a bit different and not at all obvious from your e-mail - the
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.
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.
sorted.
We do have to be careful about this sort of "this is a little bit of lowYes. But it also helps - there is no user space API here so the only bit
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.
of IIO that needs importing is small, and if the API in kernel changes
nothing userspace will break.
I have no problem with additional abstractions below. What I want to avoid is having
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.
Just to restate this. It doesn't go in drivers/adc. That would cover a tiny corner of the scope
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.
No problem with that. The recent core changes have all been about adding enough
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