[PATCH] staging: update TODO files for rts5139 & rts_pstor

[PATCH] staging: update TODO files for rts5139 & rts_pstor

[edwin_rong]

From: edwin_rong <edwin_rong@realsil.com.cn>

Recently we find that many warm-hearted people are helping improving the
coding style and something else of driver rts5139 & rts_pstor, which will
be replaced with one new refactored uniform Realtek cardreader driver in
the future, update the TODO file to inform people not to do modifications
to both of the drivers any more to avoid wasting their time and energy.

Thanks
Edwin

Signed-off-by: edwin_rong <edwin_rong@realsil.com.cn>
---
 drivers/staging/rts5139/TODO   |    2 ++
 drivers/staging/rts_pstor/TODO |    2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/staging/rts5139/TODO b/drivers/staging/rts5139/TODO
index dd5fabb..df0658e 100644
--- a/drivers/staging/rts5139/TODO
+++ b/drivers/staging/rts5139/TODO
@@ -7,3 +7,5 @@ TODO:
   drivers/mmc instead, as a host driver e.g. drivers/mmc/host/realtek-usb.c;
   see drivers/mmc/host/ushc.c as an example.
 - This driver presents cards as SCSI devices, but they should be MMC devices.
+- Stop updating this driver, one new refactored Realtek cardreader driver will
+  replace this one in the future.
diff --git a/drivers/staging/rts_pstor/TODO b/drivers/staging/rts_pstor/TODO
index becb95e..c2b8720 100644
--- a/drivers/staging/rts_pstor/TODO
+++ b/drivers/staging/rts_pstor/TODO
@@ -7,3 +7,5 @@ TODO:
   drivers/mmc instead, as a host driver e.g. drivers/mmc/host/realtek-pci.c;
   see drivers/mmc/host/via-sdmmc.c as an example.
 - This driver presents cards as SCSI devices, but they should be MMC devices.
+- Stop updating this driver, one new refactored Realtek cardreader driver will
+  replace this one in the future.
-- 
1.7.9.5

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[Greg KH]

On Tue, May 15, 2012 at 10:36:32AM +0800, edwin_rong@realsil.com.cn wrote:
> From: edwin_rong <edwin_rong@realsil.com.cn>
> 
> Recently we find that many warm-hearted people are helping improving the
> coding style and something else of driver rts5139 & rts_pstor, which will
> be replaced with one new refactored uniform Realtek cardreader driver in
> the future, update the TODO file to inform people not to do modifications
> to both of the drivers any more to avoid wasting their time and energy.

Is there anything that you can point people to today for this "new
driver"?  Given that there is no other driver at this point in time, I
don't blame people for fixing up this one to work properly.  So until we
see a new driver, I don't feel comfortable asking people to stop working
here, do you?

thanks,

greg k-h

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[edwin_rong]

On 05/15/2012 11:39 PM, Greg KH wrote:
> On Tue, May 15, 2012 at 10:36:32AM +0800, edwin_rong@realsil.com.cn wrote:
>> From: edwin_rong <edwin_rong@realsil.com.cn>
>>
>> Recently we find that many warm-hearted people are helping improving the
>> coding style and something else of driver rts5139 & rts_pstor, which will
>> be replaced with one new refactored uniform Realtek cardreader driver in
>> the future, update the TODO file to inform people not to do modifications
>> to both of the drivers any more to avoid wasting their time and energy.
> Is there anything that you can point people to today for this "new
> driver"?  Given that there is no other driver at this point in time, I
> don't blame people for fixing up this one to work properly.  So until we
> see a new driver, I don't feel comfortable asking people to stop working
> here, do you?
>
> thanks,
>
> greg k-h
Hi Greg,

No, it's not polite to stop people helping you do some fixing work. I
totally agree your point, but my original purpose is to avoid people
wasting their time and energy :-)

About the "new driver", we make significant modifications and re-design
it with Object-Oriented theory, which is adopted in kernel everywhere.
We divide the driver into several portions: . "card component", which is
used to implement all kinds of card protocols in h/w-independent way;
."card manager component" which manipulate all the cardreader supported
cards; ."card reader component" which is responsible for concrete
operations of IC; ."scsi component", whose work is to accept SCSI
commands from SCSI subsystem and forward them to "card component" for
further process, and ."transport component" which hidden the specfic
physical interface from the compoents mentioned above.

As you have seen that there's 2 drivers "rts5139" and "rts_pstor" under
staging folder in Linux kernel code, the former drives USB-based card
reader, while the later supports PCIe-based card reader and both of them
are driver-based driver, which implement SD/MS/xD card protocol,
respectively, to support these series of cards. In fact, It doesn't need
to do so, since they are standard protocols, if we implement them in a
hardware-independent way, it can be reused, which decreases code redundance.

Also, we have to consider expansion issue of the driver, since our
company will design out new card reader ICs. Actually, the "new driver"
could, to some degree, be treated as an subsystem which supports all
Realtek cardreader ICs.


Thanks & BRs
Edwin

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[Dan Carpenter]

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

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[edwin_rong]

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.


Thanks & BRs
Edwin
 

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[Dan Carpenter]

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

Re: [PATCH] staging: update TODO files for rts5139 & rts_pstor

[Greg KH]

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