Re: [WIP v2] rtlwifi: rtl8192su subdriver

Re: [WIP v2] rtlwifi: rtl8192su subdriver

[Joshua Roys]

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

On 06/30/2012 10:23 AM, Xose Vazquez Perez wrote:
> on Mon, 7 May 2012 Joshua Roys wrote:
>
>> Currently a WIP.
>
>> A few things have changed between this and the previous version.
>> Larry Finger's \
>> patch for handling the race condition with mac80211 and the firmware
>> callback is used \
>> instead (rtlwifi: fix for race condition when firmware is cached), and
>> a new patch \
>  > [...]
>
> hi Joshua,
>
> any news on that ?

Hello,

Currently I'm still searching for the hidden/undocumented registers that 
will allow the rtlwifi driver to drive the *su chips.  (The rtlwifi 
driver uses the softmac infrastructure while the current firmware for 
the *su chips really needs a fullmac driver.)

Josh




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

Re: [WIP v2] rtlwifi: rtl8192su subdriver

[Larry Finger]

On 07/09/2012 07:40 AM, Joshua Roys wrote:
> On 06/30/2012 10:23 AM, Xose Vazquez Perez wrote:
>> on Mon, 7 May 2012 Joshua Roys wrote:
>>
>>> Currently a WIP.
>>
>>> A few things have changed between this and the previous version.
>>> Larry Finger's \
>>> patch for handling the race condition with mac80211 and the firmware
>>> callback is used \
>>> instead (rtlwifi: fix for race condition when firmware is cached), and
>>> a new patch \
>>  > [...]
>>
>> hi Joshua,
>>
>> any news on that ?
>
> Hello,
>
> Currently I'm still searching for the hidden/undocumented registers that will
> allow the rtlwifi driver to drive the *su chips.  (The rtlwifi driver uses the
> softmac infrastructure while the current firmware for the *su chips really needs
> a fullmac driver.)

I don't think I believe the business about a fullmac driver. Driver r8712u, 
which does handle the RTL8191SU, uses its own softmac driver.

Larry

Re: [WIP v2] rtlwifi: rtl8192su subdriver

[Xose Vazquez Perez]

On 07/09/2012 02:40 PM, Joshua Roys wrote:

> Currently I'm still searching for the hidden/undocumented registers that will
 > allow the rtlwifi driver to drive the *su chips.  (The rtlwifi driver uses the
 > softmac infrastructure while the current firmware for the *su chips really
 > needs a fullmac driver.)

Is there any reason to think a fullmac driver is better than a softmac for this chip ?

Re: [WIP v2] rtlwifi: rtl8192su subdriver

[Joshua Roys]

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

On 07/13/2012 05:16 PM, Xose Vazquez Perez wrote:
> On 07/09/2012 02:40 PM, Joshua Roys wrote:
>
>> Currently I'm still searching for the hidden/undocumented registers
>> that will
>  > allow the rtlwifi driver to drive the *su chips.  (The rtlwifi driver
> uses the
>  > softmac infrastructure while the current firmware for the *su chips
> really
>  > needs a fullmac driver.)
>
> Is there any reason to think a fullmac driver is better than a softmac
> for this chip ?

The firmware provides a very similar set of services as called by 
drivers/net/wireless/rndis_wlan.c (albeit through a different calling 
interface).  This would offload some processing to the device and 
potentially allow the host to sleep more.  The big reason not to is that 
we have rtlwifi/softmac already...

Josh




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

[WIP] rtlwifi: rtl8192su subdriver

[Joshua Roys]

Hello all,

I would like to submit the work I have done so far on a native mac80211 
driver for the RTL8192SU family of chips (91SU/88SU also).  It builds 
off of the rtlwifi driver, especially the rtl8192se subdriver, as well 
as the r8712u and the deleted rtl8192su staging drivers.

The first few patches are enhancements or bug fixes to the rtlwifi core 
which I would like to get pulled upstream after review.  The second to 
last patch is an ugly hack to allow subdrivers to register new/different 
features with mac80211 (hardware scanning, for instance).  And the last 
patch adds the work done so far on rtl8192su.

As of now, the rtl8192su subdriver can initialize the hardware, load the 
firmware, setup bulk communication, and configure the RF/BB/PHY.  There 
are a handful of FIXMEs scattered around the code, and many of the new 
FW commands still need to be implemented.  The site survey FW command 
works quite well and returns available BSSIDs in the area.  However, the 
firmware currently eats beacons and returns the scan results in a struct 
that will require some work to feed into mac80211.

(I'm too tired to setup git-send-email tonight, so please pardon the 
following manually sent patches which are not inlined.)

Joshua Roys

[WIP v2] rtlwifi: rtl8192su subdriver

[Joshua Roys]

Hello,

A few things have changed between this and the previous version.  Larry Finger's patch for handling the race condition with mac80211 and the firmware callback is used instead (rtlwifi: fix for race condition when firmware is cached), and a new patch for disabling the LEDs in the usb core is added (mirroring rtl_pci_stop).  All patches were rebased on wireless-testing from the 3rd.  The subdriver handles shutdown much better, although there is still room for improvement.  Some differences from rtl8192se were eliminated, although all PHY/BB/RF reg commands are still commented out.  When any of those regs were accessed directly, the device would die.  When accessed through the IOCMD regs, the firmware on the device would seem to disable automatic control of some important functions causing a large drop in receive sensitivity and general performance.
I discovered the RXFILTERMAP registers were set by the firmware after download causing the firmware to handle many management frames; allowing everything but beacons through still does not allow an association/authentication against a WPA2-PSK AP to succeed.  The AP sees a probe request and sends a probe response, but the driver never sees the response.  There are firmware commands available for offloading the joining of a BSS and the authentication bits which are likely the easiest solution.  Also needing fixing are a few WARNs, for example if you happen to unload the module during a scan.  Finally, the site survey results are now properly handed off to cfg80211.

Thanks,

Josh