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

p54: clamp properly instead of just truncating

2014-03-31T04:40:30+00:00

commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.

The call to clamp_t() first truncates the variable signed 8 bit and as a
result, the actual clamp is a no-op.

Fixes: 0d78156eef1d ('p54: improve site survey')
Signed-off-by: Dan Carpenter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: Complete backport of "iwlwifi: always copy first 16 bytes of commands"

2014-03-31T04:40:30+00:00

Linux 3.4.83 included an incomplete backport of commit
8a964f44e01ad3bbc208c3e80d931ba91b9ea786 ('iwlwifi: always copy first
16 bytes of commands') which causes a regression for this driver.
This is the missing piece.

Reported-by: Andreas Sturmlechner 
Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Jianguo Wu 
Cc: Andres Bertens 
Tested-by: Andreas Sturmlechner 
Signed-off-by: Ben Hutchings

mwifiex: copy AP's HT capability info correctly

2014-03-24T04:37:04+00:00

commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream.

While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.

This patch fixes an error while copying this field from AP's
beacon.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix ETSI compliance for AR9462 2.0

2014-03-24T04:37:04+00:00

commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream.

The minimum CCA power threshold values have to be adjusted
for existing cards to be in compliance with new regulations.
Newer cards will make use of the values obtained from EEPROM,
support for this was added earlier. To make sure that cards
that are already in use and don't have proper values in EEPROM,
do not violate regulations, use the initvals instead.

Reported-by: Jeang Daniel 
Signed-off-by: Sujith Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

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