linux-kernel - Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101102142226.GB10780@kroah.com>
Date:	Tue, 2 Nov 2010 07:22:26 -0700
From:	Greg KH <greg@...ah.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Naveen Kumar G <naveen.gaddipati@...ricsson.com>,
	linux-kernel@...r.kernel.org, STEricsson_nomadik_linux@...t.st.com
Subject: Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

On Tue, Nov 02, 2010 at 02:06:11PM +0000, Alan Cox wrote:
> On Tue, 2 Nov 2010 07:03:37 -0700
> Greg KH <greg@...ah.com> wrote:
> 
> > On Tue, Nov 02, 2010 at 05:38:45PM +0530, Naveen Kumar G wrote:
> > > --- /dev/null
> > > +++ b/drivers/staging/ste_rmi4/TODO
> > > @@ -0,0 +1,7 @@
> > > +TODO
> > > +----
> > > +
> > > +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> > > +Merge any device support needed from this driver into it
> > > +Delete this driver
> > 
> > Huh?
> > 
> > Why not just add this driver to the kernel tree instead?  When the
> > "promised" driver then eventually shows up (who is promising it?) then
> > delete the thing.
> 
> I've suggested that in the past.

Then we should do that.

> > But until then, why is this needed to go into the staging tree?  Is
> > there any other main reason it should be here and not in the "real" part
> > of the kernel?
> 
> It's a driver nobody wants to commit to keeping around when there is
> eventually a general purpose driver. In other words things like module
> names will change.

module names change is not a big deal, right?

So, this driver should go into the proper subsystem then, and not
staging.  Staging is for code that is either working on getting merged
to the main kernel, or it is on the way out.  Not to just sit there and
wait for some other thing to happen (well, for the most part, there are
some exceptions of course...)

thanks,

greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/