linux-stable.git/drivers/net/wireless, branch v3.4.83

rtlwifi: Fix endian error in extracting packet type

2014-03-11T23:10:10+00:00

commit 0c5d63f0ab6728f05ddefa25aff55e31297f95e6 upstream.

All of the rtlwifi drivers have an error in the routine that tests if
the data is "special". If it is, the subsequant transmission will be
at the lowest rate to enhance reliability. The 16-bit quantity is
big-endian, but was being extracted in native CPU mode. One of the
effects of this bug is to inhibit association under some conditions
as the TX rate is too high.

Based on suggestions by Joe Perches, the entire routine is rewritten.

One of the local headers contained duplicates of some of the ETH_P_XXX
definitions. These are deleted.

Signed-off-by: Larry Finger 
Cc: Mark Cave-Ayland 
Signed-off-by: John W. Linville 
[wujg: Backported to 3.4:
 - adjust context
 - remove rtlpriv->enter_ps = false
 - use schedule_work(&rtlpriv->works.lps_leave_work)]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series

2014-03-11T23:10:10+00:00

commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream.

Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2:
 - Adjust filenames
 - Drop const from struct iwl_cfg]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4:
 - Adjust context
 - Do not drop const from struct iwl_cfg]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: fix calling ieee80211_chswitch_done() with NULL

2014-03-11T23:10:10+00:00

commit 9186a1fd9ed190739423db84bc344d258ef3e3d7 upstream.

If channel switch is pending and we remove interface we can
crash like showed below due to passing NULL vif to mac80211:

BUG: unable to handle kernel paging request at fffffffffffff8cc
IP: [] strnlen+0xd/0x40
Call Trace:
 [] string.isra.3+0x3e/0xd0
 [] vsnprintf+0x219/0x640
 [] vscnprintf+0x11/0x30
 [] vprintk_emit+0x115/0x4f0
 [] printk+0x61/0x63
 [] ieee80211_chswitch_done+0xaf/0xd0 [mac80211]
 [] iwl_chswitch_done+0x34/0x40 [iwldvm]
 [] iwlagn_commit_rxon+0x2a3/0xdc0 [iwldvm]
 [] ? iwlagn_set_rxon_chain+0x180/0x2c0 [iwldvm]
 [] iwl_set_mode+0x36/0x40 [iwldvm]
 [] iwlagn_mac_remove_interface+0x8d/0x1b0 [iwldvm]
 [] ieee80211_do_stop+0x29d/0x7f0 [mac80211]

This is because we nulify ctx->vif in iwlagn_mac_remove_interface()
before calling some other functions that teardown interface. To fix
just check ctx->vif on iwl_chswitch_done(). We should not call
ieee80211_chswitch_done() as channel switch works were already canceled
by mac80211 in ieee80211_do_stop() -> ieee80211_mgd_stop().

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=979581

Reported-by: Lukasz Jagiello 
Signed-off-by: Stanislaw Gruszka 
Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2: adjust context, filename]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4: - adjust context]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth

2014-03-11T23:10:10+00:00

commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream.

The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems, as reported in Redhat BZ 885407.

Fix this by sending the BT_CONFIG command only when the
device has Bluetooth.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2:
 - Adjust filename
 - s/priv->lib/priv->cfg/]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4:
 - s/priv->cfg/priv->shrd->cfg/]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: always copy first 16 bytes of commands

2014-03-11T23:10:10+00:00

commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.

The FH hardware will always write back to the scratch field
in commands, even host commands not just TX commands, which
can overwrite parts of the command. This is problematic if
the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
cause calibration issues.

Address this problem by always putting at least the first
16 bytes into the buffer we also use for the command header
and therefore make the DMA engine write back into this.

For commands that are smaller than 16 bytes also always map
enough memory for the DMA engine to write back to.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop the IWL_HCMD_DFL_DUP handling
 - Fix descriptor addresses and lengths for tracepoint, but otherwise
   leave it unchanged]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4: adjust context]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: handle DMA mapping failures

2014-03-11T23:10:10+00:00

commit 7c34158231b2eda8dcbd297be2bb1559e69cb433 upstream.

The RX replenish code doesn't handle DMA mapping failures,
which will cause issues if there actually is a failure. This
was reported by Shuah Khan who found a DMA mapping framework
warning ("device driver failed to check map error").

Reported-by: Shuah Khan 
Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2:
 - Adjust filename, context, indentation
 - Use bus(trans) instead of trans where necessary
 - Use hw_params(trans).rx_page_order instead of trans_pcie->rx_page_order]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4:
 - Adjust context
 - Use trans instead of bus(trans)
 - Use hw_params(trans).rx_page_order instead of trans_pcie->rx_page_order]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: don't handle masked interrupt

2014-03-11T23:10:09+00:00

commit 25a172655f837bdb032e451f95441bb4acec51bb upstream.

This can lead to a panic if the driver isn't ready to
handle them. Since our interrupt line is shared, we can get
an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks
that even when the interrupt is being freed).

If the op_mode has gone away, we musn't call it. To avoid
this the transport disables the interrupts when the hw is
stopped and the op_mode is leaving.
If there is an event that would cause an interrupt the INTA
register is updated regardless of the enablement of the
interrupts: even if the interrupts are disabled, the INTA
will be changed, but the device won't issue an interrupt.
But the ISR can be called at any time, so we ought ignore
the value in the INTA otherwise we can call the op_mode
after it was freed.

I found this bug when the op_mode_start failed, and called
iwl_trans_stop_hw(trans, true). Then I played with the
RFKILL button, and removed the module.
While removing the module, the IRQ is freed, and the ISR is
called (CONFIG_DEBUG_SHIRQ enabled). Panic.

Signed-off-by: Emmanuel Grumbach 
Reviewed-by: Gregory Greenman 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2:
 - Adjust context
 - Pass bus(trans), not trans, to iwl_{read,write}32()]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4:
 - adjust context
 - Pass trans to iwl_{read,write}32()}]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: protect SRAM debugfs

2014-03-11T23:10:09+00:00

commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream.

If the device is not started, we can't read its
SRAM and attempting to do so will cause issues.
Protect the debugfs read.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[wujg: Backported to 3.4: adjust context]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix flow handler debug code

2014-03-11T23:10:09+00:00

commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream.

iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.

Also, while at it, clean up the arguments to the
function, some code and make it generally safer.

Reported-by: Benjamin Herrenschmidt 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filenames and context]
Signed-off-by: Ben Hutchings 
[wujg: Backported to 3.4: adjust context]
Signed-off-by: Jianguo Wu 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192ce: Fix too long disable of IRQs

2014-03-11T23:09:58+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 
Signed-off-by: Greg Kroah-Hartman