public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: edwin_rong <edwin_rong@realsil.com.cn>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor
Date: Wed, 16 May 2012 13:19:57 +0300	[thread overview]
Message-ID: <20120516101957.GJ16999@mwanda> (raw)
In-Reply-To: <4FB36E89.80404@realsil.com.cn>

On Wed, May 16, 2012 at 05:08:25PM +0800, edwin_rong wrote:
> On 05/16/2012 03:20 PM, Dan Carpenter wrote:
> > When is the new driver going to be released?  How can we tell if
> > it's better than the cleaned up staging driver without seeing it?
> >
> > regards,
> > dan carpenter
> Hi Dan carpenter,
> 
> > When is the new driver going to be released?
> 
> I'm afraid it will take a long time before we release it to kernel. You
> know that Realtek now has several series of card reader on the market, and
> we have to integrated these ICs into the new driver, and make sure it
> works well, in addition, now we're working on another new card reader IC.
> Once everything is done, the driver will be released.
> 
> >  How can we tell if it's better than the cleaned up staging driver without seeing it?
> Yes, quite right. Seeing is believing.
> 

This seems like we're going down the broadcom model where we have
the b34_legacy, b43, brcm drivers.  We've got three drivers for
broadcom cards and there is some overlap on which hardware they
support.  The first two were developed by the community and the brcm
driver was developed by Broadcom and it's the only one they support.
It was a frustrating experience.  We came very close to dropping the
brcm drivers.

The thing about the brcm drivers was that the Broadcom devs did all
their development in the open.  We knew they had worked hard and
were responsive to bug reports and code criticism.

The kernel history is full of people working hard for years on code
and then having it rejected and not merged.  When it comes to
drivers we often think we'll write a new driver and drop the old one
but it doesn't always happen.  We still have OSS sound drivers from
90s.

It's best to put up a git tree with the new driver as soon as
possible.  I would try get stuff merged into the kernel as soon as
possible.

regards,
dan carpenter


  reply	other threads:[~2012-05-16 10:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15  2:36 [PATCH] staging: update TODO files for rts5139 & rts_pstor edwin_rong
2012-05-15 15:39 ` Greg KH
2012-05-16  2:16   ` edwin_rong
2012-05-16  7:20     ` Dan Carpenter
2012-05-16  9:08       ` edwin_rong
2012-05-16 10:19         ` Dan Carpenter [this message]
2012-05-16 20:22           ` Greg KH

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=20120516101957.GJ16999@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=devel@linuxdriverproject.org \
    --cc=edwin_rong@realsil.com.cn \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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