Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Tue, Mar 15, 2011 at 11:11:00AM +0000, Jonathan Cameron wrote:
> On 03/15/11 09:38, Arnd Bergmann wrote:

[Reflowed Jonathan's text into 80 columns for legibility.]

> > Do you think it would help to split the iio codebase into a smaller part
> > for the relatively clean drivers that can be put into shape for
> > drivers/iio, and the bulk of the code that stays in staging for a bit
> > longer, until it gets converted to the new one in small chunks?

> 1) Spit functionality out in staging. This would give a core set that
> is basically the sysfs only stuff.  To do that we'd have to define a
> struct iio_dev_basic and make it an element of the iio_dev.  Prior to
> that we'd probably need to make pretty much all accesses into iio_dev
> via macros / inline functions which would not be a trivial
> undertaking.

> Then we could switch those drivers doing the minimum to the _basic
> form.  At that point we could perhaps attempt to move a couple of
> drivers and the abi docs out of staging.

> The disadvantages of this that come to mind are: * Makes the path to
> driver addition that I'd prefer trickier.  You write a basic sysfs
> only driver first, then add on stuff like events and buffering as
> separate patches. We could go the other way around like v4l2-subdev
> and have a base structure with the option of pointers to structures
> offering different combinations of features.  * Not many of the
> drivers I'd consider to be ready to go at the moment are actually in
> this _basic class. 

For what it's worth I have a few drivers I'd like to do which fall into
this category.  I've been put off working on them by the fact that I'm
not seeing a route out of staging for the subsystem.

> 2) Basically make a copy.  This would look like the original patch set did when we went

A third option is just to lift everything out of staging roughly as it
is now with anything that definitely needs redoing dropped, addressing
any review comments for mainline but not doing much else, and then
resume working on adding additional stuff.  It sounds like the userspace
interfaces that are there at present are mostly OK and most of the
issues are in-kernel?

You could perhaps have a Kconfig control for disabling any experimental
features in the API if you want to give people hints about areas that
are likely to churn.