When to submit into drivers/staging

[johannes.thumshirn@men.de (Johannes Thumshirn)]

On Mon, Feb 10, 2014 at 09:45:20AM +0100, Bj?rn Mork wrote:
> Johannes Thumshirn <johannes.thumshirn@men.de> writes:
>
> > Hi,
> >
> > I have a question regarding driver submission into mainline. I'm not exactly
> > sure if my driver is ready to be submittet into normal drivers or if it would be
> > better to submit it to staging first.
>
> New drivers do not normally go through staging.  If your driver is
> mostly following the kernel coding standards and using appropriate
> kernel interfaces, then, in my opinion, there is no reason to submit it
> to staging first.  I'd submit as a normal driver first, and then only
> consider staging if the initial feedback indicates that major changes
> are necessary before the driver is ready for mainline.
>
> My impression is that staging is primarily for code which was written
> without Linux mainline in mind.
>
> > Is there any recomendation when to submit to drivers/staging instead of drivers?
> > I've searched the archives but haven't found an answer to it. If you can instead
> > just point me to a document I'm fine.
>
> I believe Documentation/development-process/2.Process gives the best
> description of what staging is for:
>
> <quote>
> 2.4.1: STAGING TREES
>
> The kernel source tree contains the drivers/staging/ directory, where
> many sub-directories for drivers or filesystems that are on their way to
> being added to the kernel tree live.  They remain in drivers/staging while
> they still need more work; once complete, they can be moved into the
> kernel proper.  This is a way to keep track of drivers that aren't
> up to Linux kernel coding or quality standards, but people may want to use
> them and track development.
>
> Greg Kroah-Hartman currently maintains the staging tree.  Drivers that
> still need work are sent to him, with each driver having its own
> subdirectory in drivers/staging/.  Along with the driver source files, a
> TODO file should be present in the directory as well.  The TODO file lists
> the pending work that the driver needs for acceptance into the kernel
> proper, as well as a list of people that should be Cc'd for any patches to
> the driver.  Current rules require that drivers contributed to staging
> must, at a minimum, compile properly.
>
> Staging can be a relatively easy way to get new drivers into the mainline
> where, with luck, they will come to the attention of other developers and
> improve quickly.  Entry into staging is not the end of the story, though;
> code in staging which is not seeing regular progress will eventually be
> removed.  Distributors also tend to be relatively reluctant to enable
> staging drivers.  So staging is, at best, a stop on the way toward becoming
> a proper mainline driver.
> </quote>
>
> > The driver(s) in question is a bus driver for multi function FPGAs made by my
> > company and one first iio/adc driver using this bus. It was sucessfully tested
> > on x86 but is known to crash on powerpc because of my parser code (which will of
> > cause be fixed when submitting, even into staging).
>
> If it is a new class of driver then I guess that means that you will
> define some new APIs. Which is all the more reason to get it directly
> into mainline.  You cannot extend or define any kernel interfaces from
> staging.
>
>
> Bj?rn

Thanks for the answer Bj?rn. I wrote the driver to be submittable into mainline
and defined a new API, so I'll send directly to lkml when it has a good stable
point (hopefully the next 1-2 Weeks).

Thanks
	Johannes