From: Dan Williams <dcbw@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: Ivo Van Doorn <ivdoorn@gmail.com>,
rt2400-devel@lists.sourceforge.net,
linux-wireless@vger.kernel.org
Subject: Re: rtl2860 driver in mainline?
Date: Tue, 28 Oct 2008 10:59:57 -0400 [thread overview]
Message-ID: <1225205997.2387.12.camel@localhost.localdomain> (raw)
In-Reply-To: <20081028061023.GA6568@kroah.com>
On Mon, 2008-10-27 at 23:10 -0700, Greg KH wrote:
> On Tue, Oct 28, 2008 at 06:48:31AM +0100, Ivo Van Doorn wrote:
> > Hi,
> >
> > > So, on my quest to suck up every out-of-tree driver and get it into the
> > > main kernel tree (drivers/staging/ to start with), I've been pointed at
> > > the rtl2860 driver.
> >
> > in that case make sure you include rt2870 on your list as well then. ;)
>
> Do you have a pointer to it?
>
> > > Does anyone know of a "cleaned up" version of this driver that is
> > > newer/better than the one on ralink's web site? I found the
> > > 2008_0918_RT2860_Linux_STA_v1.8.0.0.tar.bz2 version there, and will
> > > start with that if no one else has yet.
> >
> > rt2800pci/rt2800usb development is in progress in the rt2x00.git
> > experimental branch:
> > http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=shortlog;h=experimental
> >
> > The current status is that rt2800usb has working RX with some warnings
> > regarding the
> > RX signal, and a non functional TX. rt2800pci isn't complete yet.
> >
> > So far progress has been very slow because of lack of time, so any help with the
> > development of the drivers is welcome.
>
> Is this a port of the tarball driver to the in-kernel wireless stack, or
> starting over from scratch?
>
> As it's not really working, do you mind if I just dump the tarball
> driver into the staging tree for users to use now (hint, they already
> are, the distros are shipping that driver as a kernel module package),
> and then when this "real" driver is up and working properly, we can drop
> the staging version?
Seriously, how does including this help _anybody_ beyond today? The
vendor driver is not going to get upstream, and shipping it in staging
suggests that people help fix the vendor driver there, not work on the
driver that will actually go upstream.
staging drivers are supposed to eventually go "mainstream" if somebody
fixes them up, right? So how does cramming in a driver that will go
nowhere help anyone in the medium or long term? Should we have shipped
madwifi with the open HAL in staging while ath5k was getting brought up
to speed? Would that have taken effort away from ath5k?
I highly respect the work that you're doing with staging, but just
because the driver is out of tree doesn't mean that it'll ever go
mainline, and that including some drivers will just sap effort from
where it's needed. Cleaning up crappy vendor driver code is _not_ where
the effort is needed. We have a higher standard of quality.
Dan
next prev parent reply other threads:[~2008-10-28 15:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 0:49 rtl2860 driver in mainline? Greg KH
2008-10-28 5:48 ` Ivo Van Doorn
2008-10-28 6:10 ` Greg KH
2008-10-28 6:23 ` Ivo Van Doorn
2008-10-28 14:59 ` Dan Williams [this message]
2008-10-28 17:24 ` Luis R. Rodriguez
2008-10-28 7:03 ` Thorsten Leemhuis
2008-10-28 7:48 ` Luis Correia
2008-10-28 8:01 ` Luis R. Rodriguez
2008-10-28 8:06 ` Thorsten Leemhuis
2008-10-28 17:10 ` Greg KH
2008-10-28 7:56 ` Johannes Berg
2008-10-28 8:02 ` Luis R. Rodriguez
2008-10-28 8:06 ` Luis Correia
2008-10-28 17:09 ` Greg KH
2008-10-28 8:12 ` Johannes Berg
2008-10-28 8:17 ` Luis R. Rodriguez
2008-10-28 8:19 ` Johannes Berg
2008-10-28 17:08 ` Greg KH
2008-10-28 18:35 ` Johannes Berg
2008-10-28 22:45 ` Greg KH
2008-10-29 10:13 ` Dan Williams
2008-10-29 16:30 ` Greg KH
2008-10-30 4:02 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1225205997.2387.12.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=greg@kroah.com \
--cc=ivdoorn@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=rt2400-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).