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

> * Event passing to consumers else where in the kernel. Right now an
> input driver can readings from a sensor, but there is no way of
> requesting threshold interrupts.

> * Interaction between consumer drivers (e.g. hwmon or input) where some
> are requesting data by polling when they want it and others want a

These sound like something that can be added incrementally?

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

> Churn in interfaces is probably about it.  Maybe a good use of any time

I guess the big question is then if we can live with that.

> would be for people to take their non IIO drivers that they think might
> fit (or data sheets!) and see whether there are things that they would
> like to be different.

In tree there's a few auxadc and comparator drivers in drivers/mfd, plus
things like arch/arm/plat-samsung/adc.c in the arch direcories.  These
are all broadly similar to the at91 code that's been sent to IIO
already.  There's also the code Alan posted at the top of this thread.