linux-toradex.git/drivers/net/wireless/rtlwifi, branch v3.2.74

rtlwifi: rtl8192cu: Add new device ID

2015-10-13T02:46:06+00:00

commit 1642d09fb9b128e8e538b2a4179962a34f38dff9 upstream.

The v2 of NetGear WNA1000M uses a different idProduct: USB ID 0846:9043

Signed-off-by: Adrien Schildknecht 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Add new device ID

2015-10-13T02:46:06+00:00

commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream.

Add new ID for ASUS N10 WiFi dongle.

Signed-off-by: Marek Vasut 
Tested-by: Marek Vasut 
Cc: Larry Finger 
Cc: John W. Linville 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Fix kernel deadlock

2015-08-06T23:32:07+00:00

commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.

The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.

This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786.

Reported-by: Bernhard Wiedemann 
Tested-by: Bernhard Wiedemann 
Signed-off-by: Larry Finger 
Cc: Bernhard Wiedemann 
Cc: Takashi Iwai
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Add new USB ID

2015-08-06T23:32:02+00:00

commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.

USB ID 2001:330d is used for a D-Link DWA-131.

Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Add new ID

2014-11-05T20:27:39+00:00

commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream.

The Sitecom WLA-2102 adapter uses this driver.

Reported-by: Nico Baggus 
Signed-off-by: Larry Finger 
Cc: Nico Baggus 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()

2014-06-09T12:29:05+00:00

commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.

Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]

rtlwifi: rtl8192cu: Fix too long disable of IRQs

2014-06-09T12:29:05+00:00

commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
 fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192cu.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

rtl8192ce: Fix null dereference in watchdog

2014-05-18T13:58:09+00:00

Dmitry Semyonov reported that after upgrading from 3.2.54 to
3.2.57 the rtl8192ce driver will crash when its interface is brought
up.  The oops message shows:

[ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 1833.611455] IP: [] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
...
[ 1833.613326] Call Trace:
[ 1833.613346]  [] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
[ 1833.613391]  [] ? process_one_work+0x161/0x269
[ 1833.613425]  [] ? worker_thread+0xc2/0x145
[ 1833.613458]  [] ? manage_workers.isra.25+0x15b/0x15b
[ 1833.613496]  [] ? kthread+0x76/0x7e
[ 1833.613527]  [] ? kernel_thread_helper+0x4/0x10
[ 1833.613563]  [] ? kthread_worker_fn+0x139/0x139
[ 1833.613598]  [] ? gs_change+0x13/0x13

Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
parameter was null.  None of the changes to the rtlwifi family between
3.2.54 and 3.2.57 seem to directly cause this, and reverting commit 
f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
doesn't fix it.

rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
call trace as it was inlined.  That function has been completely
removed upstream which may explain why this crash wasn't seen there.

I'm not sure that it is sensible to completely remove
rtl92c_dm_refresh_rate_adaptive_mask() without making other
compensating changes elsewhere, so try to work around this for 3.2 by
checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
and then skipping the call to rtl92ce_update_hal_rate_tbl().

References: https://bugs.debian.org/745137
References: https://bugs.debian.org/745462
Reported-by: Dmitry Semyonov 
Signed-off-by: Ben Hutchings 
Cc: Larry Finger 
Cc: Chaoming Li

rtlwifi: rtl8192se: Fix too long disable of IRQs

2014-04-30T15:23:21+00:00

commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
 fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192se.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to an error path that we don't have]
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192ce: Fix too long disable of IRQs

2014-04-01T23:58:52+00:00

commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 upstream.

rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans

The observable symptoms in dmesg can be:

- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):

[  250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[  250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[  250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[  250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[  250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[  250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[  250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[  250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[  251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)

The exact code flow that causes that is:

1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3.   rtl_ips_nic_on is called which disable local irqs
4.     rtl92c_phy_set_rf_power_state() is called
5.       rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled

A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().

I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.

Signed-off-by: Olivier Langlois 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings