Fwd: Re: Anybody working on rtl8712?

[Larry Finger]

On 06/21/2014 12:52 PM, Christian Lamparter wrote:
> On Saturday, June 21, 2014 06:45:07 PM Kristina Martšenko wrote:
>> On 20/06/14 23:52, Christian Lamparter wrote:
>>> On Friday, June 20, 2014 09:19:07 PM Xose Vazquez Perez wrote:
>>>> Kristina wrote:
>>>>
>>>>> I'm helping Greg do a bit of cleanup in the staging tree. I noticed that
>>>>> nobody seems to have worked towards moving rtl8712 out of staging in
>>>>> over a year. Are there any plans to clean it up and move it out soon?
>>>>> Because otherwise we're going to have to delete the driver, as we don't
>>>>> want staging to become a permanent place for unfinished code.
>>>> Christian Lamparter <chunkeey at googlemail.com> is working on a new driver
>>>> based on mac80211: https://github.com/chunkeey/rtl8192su
>>
>> Thanks for pointing that out and forwarding the email to Christian.
>>
>>> rtl8192su development is chugging along. It just doesn't take place on
>>> driverdev list. The driver reached "feature parity" with rtl8192cu for
>>> some time ago.
>>
>> Great, thanks for letting me know. If you plan to keep working on it, do
>> you think it would be a good idea to add yourself and a link to your
>> github to the staging driver's TODO file? That way people who find it
>> and want to work on it can join your effort, instead of starting their own.
>
> Actually, this is already happening. I get mails about rtl8192su. So,
> people who are interested are definitely following the development.
> However the hurdles for rtl8192su driver are quite high
> (3.15+ kernel [1]). This is due to the driver being based on rtlwifi
> framework (the devices shares a lot of common code with the
> rtl8192SE - the pcie version). The development takes place on
> top of wireless-testing.git, so it can be merged with the rest of
> the drivers.
>
> (If someone is interested in the details: how a wireless drivers are
> mainlined. There's a nifty process plan right here: [0] - check it out!).
>
> (NB: my stance on the TODO: Leave it the way it is. After all, you want
> those free checkpatch.pl and smatch/sparse fixes, right?)
>>> But as with rtl8192cu, I would recommend adding just a friendly "printk".
>>
>> I'm not sure what printk you're referring to.
> I think there's a reason why the development takes so long
> (The RTL8192S* chips have been around since 2008, 2009)
> and why we all have better things to do and write harsh
> responses. As far as I can tell, It would be great if Realtek
> could have a few dedicated devs, which take care of integrating
> their own linux drivers into /drivers/net/wireless instead of
> dumping it into /driver/staging.
>
> This might sounds like hobbyists wifi-devs are a bunch of *****.
> However, other (wifi-)vendor (e.g.: Intel, Qualcom, TI, Broadcom
> and Marvell) have been participating for some time now. And
> their end-users are very happy as a result of this. Now, if only
> Realtek would join the party; that would be "awesome".

OK, a little clarification seems to be necessary. First of all, I have no 
official connection with Realtek. I do not get paid, and I do not have any sort 
of NDA with them. In fact, I would refuse to sign one. What I know about the 
internals of their chips is derived from reading code that they publish.

At one point, I needed a Linux driver for a D-Link DWA-130. I took the Realtek 
driver, fixed the problems when running it on 64-bit hardware and on big-endian 
machines, and submitted it to staging as r8712u. Shortly thereafter, the PCI 
group at Realsil (the Chinese affiliate of Realtek) asked me if I would help 
them get their mac80211 drivers into the kernel. That group has been quite 
active in adapting their coding styles and practices to what is required for Linux.

The USB programming group is in Taiwan, and they are much less interested in 
getting their drivers into Linux. Unlike the PCIe group, I don't even get 
hardware from them. They did write rtl8192cu, but have not done much with it 
since. The drivers for newer chips can be built for FreeBSD, Windows, or Linux. 
In several cases, I have not even had the hardware, which makes it impossible to 
do much in the way of improvement other than stripping out the foreign code. Jes 
Sorensen of RedHat has taken on the maintenance of the RTL8723AU driver as he 
has that hardware. He is actively reworking it with tens of patches per week, 
but he has not yet tackled the conversion to mac80211. It should have much in 
common with the RTL8723AE, but it will still be a big job.

The PCI group recently sent me new code for all the PCI devices, and I am 
working at getting it merged into the wireless-testing tree. Once that is done, 
I plan to entice them to take over the maintainers role for those drivers.

What to do about the USB drivers is still an open question.

Larry