r92su: status and will it be merged anytime soon?

r92su: status and will it be merged anytime soon?

[Alexandre Demers]

Good afternoon,

I was playing in r8712u because I wanted to send a patch to 
conditionally silence a flooding netdev_info(). But then I found out on 
http://wireless.kernel.org/en/users/Drivers/rtl819x that r8712u was to 
be replaced by r92su.

 From its git tree, it seems no commit were added since 4 months ago. 
Could someone tell me in what shape is this new driver? Is there any 
plan to merge it (under staging I suppose) soon?

Thank you,

-- 
Alexandre Demers

Re: r92su: status and will it be merged anytime soon?

[Christian Lamparter]

Hello,

On Saturday 02 November 2013 16:19:16 Alexandre Demers wrote:
> I was playing in r8712u because I wanted to send a patch to 
> conditionally silence a flooding netdev_info(). But then I found out on 
> http://wireless.kernel.org/en/users/Drivers/rtl819x that r8712u was to 
> be replaced by r92su.
> 
>  From its git tree, it seems no commit were added since 4 months ago. 
> Could someone tell me in what shape is this new driver? Is there any 
> plan to merge it (under staging I suppose) soon?

That's the story:

"Yes, r8712u has been in staging for a long time; however, it is not a
matter of improving it. For a new wireless driver to be included in the
main wireless directories, it must use mac80211."

<http://www.spinics.net/lists/linux-wireless/msg105633.html>

r92su is "just a nice" rewrite of r8712u with a cfg80211 interface.
However, this is due to the firmware interface shortcomings. For 
instance the r8712u firmware won't allow a driver initialize the PHY.
It's true that there's a command to set the phy to a specified 
channel, however it's not possible to define the channel mode.
(whenever it is supposed to be legacy, HT20, HT40+ or HT40-.)

The issue with r92su is: The driver is ready, but it's fundamentally
incompatible with the rtlwifi framework and mac80211.

...

However, 

José Vázquez discovered that Realtek has produced two linux drivers
for these devices. The other driver (and more importantly: the firmware)
can be the base for a rtl8192su+rtlwifi driver 
(which could even support a proper AP mode!)

If you want to take a look:
<http://www.edimax.com/images/Image/OpenSourceCode/Wireless/Router/AR-7284WnA/AR-7284WnA&B_SDK_6222.tar.zip>

The driver is located in:
  Edimax/src/kernel/linux-2.6.18.8/drivers/usb/net/8192su

The firmware + phy values:
  Edimax/src/kernel/linux-2.6.18.8/usr/ramfs/usr/rtl8192su

So, it's back to the drawing board.

...

I hope this answers your question, if not... let me know ;).

Regards

Christian

Re: r92su: status and will it be merged anytime soon?

[Larry Finger]

On 11/02/2013 03:19 PM, Alexandre Demers wrote:
> Good afternoon,
>
> I was playing in r8712u because I wanted to send a patch to conditionally
> silence a flooding netdev_info(). But then I found out on
> http://wireless.kernel.org/en/users/Drivers/rtl819x that r8712u was to be
> replaced by r92su.
>
>  From its git tree, it seems no commit were added since 4 months ago. Could
> someone tell me in what shape is this new driver? Is there any plan to merge it
> (under staging I suppose) soon?

As nothing has happened with that GitHub account for several months, my guess is 
that it will not be merged any time soon.

It would make little sense to replace one staging driver (r8712u) with a 
different one. The only thing that makes sense is for it to use mac80211 and be 
merged in the regular drivers/net/wireless/rtlwifi tree.

Larry

Re: r92su: status and will it be merged anytime soon?

[Alexandre Demers]

Ok, so if I was to work on one of the drivers, I should continue with 
the one under staging, isn't it? Because, let's say I would have some 
spare time to invest somewhere, I could port the driver to use mac80211, 
maybe with some support. I'd prefer to do it only once... on the good 
driver.

Alexandre Demers

On 11/02/2013 05:53 PM, Larry Finger wrote:
> On 11/02/2013 03:19 PM, Alexandre Demers wrote:
>> Good afternoon,
>>
>> I was playing in r8712u because I wanted to send a patch to 
>> conditionally
>> silence a flooding netdev_info(). But then I found out on
>> http://wireless.kernel.org/en/users/Drivers/rtl819x that r8712u was 
>> to be
>> replaced by r92su.
>>
>>  From its git tree, it seems no commit were added since 4 months ago. 
>> Could
>> someone tell me in what shape is this new driver? Is there any plan 
>> to merge it
>> (under staging I suppose) soon?
>
> As nothing has happened with that GitHub account for several months, 
> my guess is that it will not be merged any time soon.
>
> It would make little sense to replace one staging driver (r8712u) with 
> a different one. The only thing that makes sense is for it to use 
> mac80211 and be merged in the regular drivers/net/wireless/rtlwifi tree.
>
> Larry
>
>

Re: r92su: status and will it be merged anytime soon?

[Alexandre Demers]

As I understand it, there is a will to replace r8712u with r92su. I
was thinking about it this weekend and if it is saner and nearer to
where the community wants to bring the driver, why not go with it?
Could we think about merging it in the staging drivers for kernel 3.13
and tag r8712u as deprecated? One could always build it or try r92su
instead, which would give a better overlook about its shape and
performance, don't you think?

Alexandre

On Mon, Nov 4, 2013 at 1:32 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2013-11-04 at 17:19 +0100, Christian Lamparter wrote:
>
>> Yes, there is even more duplicated code if you factor in the (de-)fragmentation
>> and deaggregation code from mac80211. Furthermore r92su could be sharing a bit
>> of infrastructure with rtlwifi.
>
> Yeah, that some of that seems to be duplicated in mwifiex too. I think
> there'd be some benefit in trying to share more. Maybe moving some to
> cfg80211? Or some new module?
>
>> I didn't include lib80211 since it reports mic failures via WEXT:
>> wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *)&ev);
>> (And I don't think this can be changed easily without touching ipw2200
>> and hostap-driver).
>
> Yeah that'd be tricky, though I guess you could pass a wdev pointer and
> allow it to be NULL or so.
>
> johannes
>

Re: r92su: status and will it be merged anytime soon?

[Johannes Berg]

On Mon, 2013-11-04 at 17:19 +0100, Christian Lamparter wrote:

> Yes, there is even more duplicated code if you factor in the (de-)fragmentation
> and deaggregation code from mac80211. Furthermore r92su could be sharing a bit 
> of infrastructure with rtlwifi.

Yeah, that some of that seems to be duplicated in mwifiex too. I think
there'd be some benefit in trying to share more. Maybe moving some to
cfg80211? Or some new module?

> I didn't include lib80211 since it reports mic failures via WEXT: 
> wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *)&ev);
> (And I don't think this can be changed easily without touching ipw2200
> and hostap-driver).

Yeah that'd be tricky, though I guess you could pass a wdev pointer and
allow it to be NULL or so.

johannes

Re: r92su: status and will it be merged anytime soon?

[Larry Finger]

On 11/04/2013 10:06 AM, Xose Vazquez Perez wrote:
> On 11/04/2013 04:34 PM, Larry Finger wrote:
>
>>> _anything_ is better than a staging driver.
>>>
>>> There are distributions that don't build staging drivers.
>>
>> As a result, they force their users to build out-of-tree drivers!
>
> reformulating: As a result, they force their users to _have a stable kernel_

Not all staging drivers are unstable, just as not all regular drivers are stable.

> Staging is only a working area. And the rtl8712-TODO is unreal:
> - merge Realtek's bugfixes and new features into the driver
> - switch to use LIB80211
> - switch to use MAC80211
> - checkpatch.pl fixes - only a few remain
>
>>> So, please, replace and delete staging/rtl8712 with r92su.
>>
>> You seem not to understand. Any new wireless driver that does not
>> use mac80211 *must* go into staging. AFAIK, that rule is absolute,
>                                                ^^^^^^^^^^^^^^^^^^^^^
>> and r92su cannot go into the regular wireless tree.
>
> Who said that ? Then replace staging/rtl8712 with staging/r92su
>
> Anyway, r92su is a _linux_ driver with a cfg80211 interface.
> staging/rtl8712 is crap?
>
> 1152k    drivers/staging/rtl8712/
> 340k     r92su/
>
>> If you do not like having drivers for RTL8192SU in staging, then
>> write one that uses mac80211. You have access to as much information
>> about the chips as anyone outside Realtek. They have no interest
>> in doing the mac80211 version, and I have many other tasks with
>> higher priority.
>
> Nobody said that you have to write a rtl8712-mac80211.
> But right now there is a better alternative, and it should be used.

Go ahead and submit it and remove r8712u. I would be more than happy to be able 
to just bitch about bugs the way other people do! :)

Larry

Re: r92su: status and will it be merged anytime soon?

[Christian Lamparter]

On Monday, November 04, 2013 05:04:20 PM you wrote:
> On Mon, 2013-11-04 at 16:47 +0100, Christian Lamparter wrote:
> 
> > Be careful ;-). mac80211 is great for softmac/umac/halfmac/semimac devices.
> > However the rtl8712 firmware interface is fullmac-like, so it needs cfg80211.
> > ... and r92su uses cfg80211 exclusively. There's no more WEXT or realtek ioctl
> > legacy API support.
> 
> still seems there's duplicate stuff in there like the michael MIC, at
> least lib80211 has that?
Yes, there is even more duplicated code if you factor in the (de-)fragmentation
and deaggregation code from mac80211. Furthermore r92su could be sharing a bit 
of infrastructure with rtlwifi.

I didn't include lib80211 since it reports mic failures via WEXT: 
wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *)&ev);
(And I don't think this can be changed easily without touching ipw2200
and hostap-driver).

Regards,

Christian

Re: r92su: status and will it be merged anytime soon?

[Joshua Roys]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On 11/04/2013 11:04 AM, Johannes Berg wrote:
> On Mon, 2013-11-04 at 16:47 +0100, Christian Lamparter wrote:
>
>> Be careful ;-). mac80211 is great for softmac/umac/halfmac/semimac devices.
>> However the rtl8712 firmware interface is fullmac-like, so it needs cfg80211.
>> ... and r92su uses cfg80211 exclusively. There's no more WEXT or realtek ioctl
>> legacy API support.
>
> still seems there's duplicate stuff in there like the michael MIC, at
> least lib80211 has that? OTOH, that's not all that much code.
>
> johannes
>

FWIW I separately wrote a "rtlfmac" cfg80211 driver that, after all was 
said and done, looked a lot like a barebones r92su.  I have been using 
my driver for a few weeks now and it looks like multiple people have 
reported success using r92su.  I believe a fullmac/cfg80211 approach is 
completely sufficient and far superior to the mess that is rtl8712.  I 
would be in favor of r92su replacing staging/rtl8712/.

Josh



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5059 bytes --]

Re: r92su: status and will it be merged anytime soon?

[Xose Vazquez Perez]

On 11/04/2013 04:34 PM, Larry Finger wrote:

>> _anything_ is better than a staging driver.
>>
>> There are distributions that don't build staging drivers.
> 
> As a result, they force their users to build out-of-tree drivers!

reformulating: As a result, they force their users to _have a stable kernel_

Staging is only a working area. And the rtl8712-TODO is unreal:
- merge Realtek's bugfixes and new features into the driver
- switch to use LIB80211
- switch to use MAC80211
- checkpatch.pl fixes - only a few remain

>> So, please, replace and delete staging/rtl8712 with r92su.
> 
> You seem not to understand. Any new wireless driver that does not
> use mac80211 *must* go into staging. AFAIK, that rule is absolute,
                                              ^^^^^^^^^^^^^^^^^^^^^
> and r92su cannot go into the regular wireless tree.

Who said that ? Then replace staging/rtl8712 with staging/r92su

Anyway, r92su is a _linux_ driver with a cfg80211 interface.
staging/rtl8712 is crap?

1152k    drivers/staging/rtl8712/
340k     r92su/

> If you do not like having drivers for RTL8192SU in staging, then
> write one that uses mac80211. You have access to as much information
> about the chips as anyone outside Realtek. They have no interest
> in doing the mac80211 version, and I have many other tasks with
> higher priority.

Nobody said that you have to write a rtl8712-mac80211.
But right now there is a better alternative, and it should be used.

Re: r92su: status and will it be merged anytime soon?

[Johannes Berg]

On Mon, 2013-11-04 at 16:47 +0100, Christian Lamparter wrote:

> Be careful ;-). mac80211 is great for softmac/umac/halfmac/semimac devices.
> However the rtl8712 firmware interface is fullmac-like, so it needs cfg80211.
> ... and r92su uses cfg80211 exclusively. There's no more WEXT or realtek ioctl
> legacy API support.

still seems there's duplicate stuff in there like the michael MIC, at
least lib80211 has that? OTOH, that's not all that much code.

johannes

Re: r92su: status and will it be merged anytime soon?

[Christian Lamparter]

On Monday, November 04, 2013 09:34:28 AM you wrote:
> On 11/04/2013 08:17 AM, Xose Vazquez Perez wrote:
> > Christian Lamparter wrote:
> >
> >> The issue with r92su is: The driver is ready, but it's fundamentally
> >                                        ^^^^^^^^
> >> incompatible with the rtlwifi framework and mac80211.
> >
> > _anything_ is better than a staging driver.
> >
> > There are distributions that don't build staging drivers.
> 
> As a result, they force their users to build out-of-tree drivers!
> 
> > So, please, replace and delete staging/rtl8712 with r92su.
> 
> You seem not to understand. Any new wireless driver that does not use mac80211 
> *must* go into staging. AFAIK, that rule is absolute, and r92su cannot go into 
> the regular wireless tree.

Be careful ;-). mac80211 is great for softmac/umac/halfmac/semimac devices.
However the rtl8712 firmware interface is fullmac-like, so it needs cfg80211.
... and r92su uses cfg80211 exclusively. There's no more WEXT or realtek ioctl
legacy API support.

Regards,

Christian

Re: r92su: status and will it be merged anytime soon?

[Larry Finger]

On 11/04/2013 08:17 AM, Xose Vazquez Perez wrote:
> Christian Lamparter wrote:
>
>> The issue with r92su is: The driver is ready, but it's fundamentally
>                                        ^^^^^^^^
>> incompatible with the rtlwifi framework and mac80211.
>
> _anything_ is better than a staging driver.
>
> There are distributions that don't build staging drivers.

As a result, they force their users to build out-of-tree drivers!

> So, please, replace and delete staging/rtl8712 with r92su.

You seem not to understand. Any new wireless driver that does not use mac80211 
*must* go into staging. AFAIK, that rule is absolute, and r92su cannot go into 
the regular wireless tree.

If you do not like having drivers for RTL8192SU in staging, then write one that 
uses mac80211. You have access to as much information about the chips as anyone 
outside Realtek. They have no interest in doing the mac80211 version, and I have 
many other tasks with higher priority.

Larry

Re: r92su: status and will it be merged anytime soon?

[Johannes Berg]

On Mon, 2013-11-04 at 15:17 +0100, Xose Vazquez Perez wrote:
> Christian Lamparter wrote:
> 
> > The issue with r92su is: The driver is ready, but it's fundamentally
>                                       ^^^^^^^^
> > incompatible with the rtlwifi framework and mac80211.
> 
> _anything_ is better than a staging driver.

That's still only staging quality though.

johannes

Re: r92su: status and will it be merged anytime soon?

[Xose Vazquez Perez]

Christian Lamparter wrote:

> The issue with r92su is: The driver is ready, but it's fundamentally
                                      ^^^^^^^^
> incompatible with the rtlwifi framework and mac80211.

_anything_ is better than a staging driver.

There are distributions that don't build staging drivers.

So, please, replace and delete staging/rtl8712 with r92su.

thank you.