Message-ID: <20120410175846.GQ7499@opensource.wolfsonmicro.com>
Date:	Tue, 10 Apr 2012 18:58:47 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

On Tue, Apr 10, 2012 at 05:56:32PM +0100, Alan Cox wrote:
> > > We can't go around blocking entire platforms because of the IIO blob. I
> > > raised this point with the whole previous *generation* of Intel SoC
> > > devices about IIO and nothing has been done about it.

> > Including by Intel, of course.

> Given the responses I got to moving it out of staging were of the "not
> yet" and "no" variety it hardly got a request to be worked upon.

The "not yet" bit of it certainly seems like something that could be
worked on, presumably "not yet" included a "we need to do X first"
element.

> > That's not where the rest of the embedded community has been coming from
> > on this stuff and from a deployment point of view staging isn't really
> > that big a blocker to users

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

> > Frankly at this point I don't understand why we can't just lift IIO out
> > of staging as-is, perhaps with the userspace ABI nobbled or moved into
> > debugfs for the time being if that's still a concern.  Alternatively
> > there is the option of you proposing some other generic framework.

> I've been saying this for over a year. It's still a huge blob of code

I've CCed in Greg and Jonathan here - guys, what is happening with
getting IIO out of staging?  It's been there since 2009 and from an
outside point of view it's really difficult to see progress here, the
time taken to merge the subsystem seems really long.

To me it really feels like the subsystem is pretty mature at this point
and that if anything staging is blocking things rather than helping
them, the subsystem feels like it's getting normal development rather
than work to integrate it into the rest of the kernel and being in
staging is discouraging users who don't absolutely need to use it.

For example, when we get extcon (or whatever it ends up being called)
merged we'll either have to start writing a raft of auxadc specific
drivers for it or we'll have to come up with *some* kind of subsystem to
use to abstract out the standard DC measurement pattern.

If the code was moved out of staging today what would go wrong?

> that isn't needed for pure low level stuff, but that's fixable and
> something which can eventually be worked upon.

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.

> You are trying to make the tail wag the dog. Staging is basically out of

You keep saying "you" here.  To repeat once more, this is pretty much
what the general embedded community has been pushing towards, this is
not particularly my personal opinion.

> kernel. The x86 stuff is *in kernel*, this driver is the basis of
> cleaning it up. We can sort out making it talk to IIO later. Right now
> all you are doing is blocking a pile of much needed code cleanups, and
> without them you *won't* have an API for the gpadc on Intel, it'll be
> hardcoded in each driver still. That will mean you have *zero* change of
> getting IIO support at all.

Like I said above you'd not posted the patches which factor the code out
of the existing users, if that's what you're trying to do that's a bit
different to what your patch looked like.

> Whether gpadc then adopts an IIO interface is a question to ask later,
> after (if) IIO is ever merged. If the platform ever starts using gpadc
> for non internal hardware stuff then I'm pretty sure it'll end up adopting
> whatever generic GPADC layer eventually emerges simply because we'll want
> to share drivers.

Again, this is the sort of thing that SoC vendors routinely say but
don't end up doing quite so routinely as one would hope.  This is
understandable as this sort of thing is more of a problem for people
working in off-SoC devices and system integration than the SoC vendors
themselves.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists