linux-kernel - Re: [PATCH] staging: update TODO files for rts5139 & rts

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] [day] [month] [year] [list]

Message-ID: <20120516202230.GA20954@kroah.com>
Date:	Wed, 16 May 2012 13:22:30 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	edwin_rong <edwin_rong@...lsil.com.cn>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

On Wed, May 16, 2012 at 01:19:57PM +0300, Dan Carpenter wrote:
> 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.

I agree, you need to post code, even if it's not quite working, or
finished, as soon as possible.  Don't expect to wait until you are all
finished, and drop a whole new driver subsystem on us and think that it
will be instantly accepted.  It takes review time, and when you are
creating a whole new way to handle this hardware, it will take a few
tries to get it all correct.

So please, post code now, if possible.  But in the mean time, users will
continue to use this staging driver, as that is all that they have, so I
will not reject patches fixing and cleaning it up, as we really have no
way of knowing if anything else will ever end up in the kernel tree,
right?

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/