On 05/16/2012 04:02 PM, Oleksij Rempel wrote:
Am 16.05.2012 04:16, schrieb edwin_rong:
On 05/15/2012 11:39 PM, Greg KH wrote:
On Tue, May 15, 2012 at 10:36:32AM +0800, edwin_rong@xxxxxxxxxxxxxx wrote:
From: edwin_rong<edwin_rong@xxxxxxxxxxxxxx>
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
Hi Edwin, Wwang,
please understand, people do not trust realtek. Most drivers we got, are
not finished and not ready to go to the kernel. Most problematic are
Wifi dirivers, till now cardreader drivers too.
There is no documentations. Drivers haw lots of dead code with not
enough comments. If you stop to work on this, we will need to finish and
support then.
On other hand i happy to see that realtek wish to collaborate. And it is
not easy to get a good reputation. So i do not wont to interrupt you to
make a good job.
If you wont get the trust back, you will need to start work in the open
way. Like it doing Intel, Atheros and other comp work on this, we will need to finish and
support then.
On other hand i happy to see that realtek wish to collaborate. And it is
not easy to get a good reputation. So i do not wont to interrupt you to
make a good job.
If you wont get the trust back, you will need to start work in the open
way. Like it doing Intel, Atheros and other companies.
Create a git repository and let people use your code, test it and write
patches. Or at least see, that the work is in progress.
anies.
Create a git repository and let pe work on this, we will need to finish and
support then.
On other hand i happy to see that realtek wish to collaborate. And it is
not easy to get a good reputation. So i do not wont to interrupt you to
make a good job.
If you wont get the trust back, you will need to start work in the open
way. Like it doing Intel, Atheros and other companies.
Create a git repository and let people use your code, test it and write
patches. Or at least see, that the work is in progress.
ople use your code, test it and write
patches. Or at least see, that the work is in progress.
Hi Oleksij,
We'll try our best and thanks for your suggestions.
BRs
Edwin
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
