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

ath9k: Fix kernel panic in AR2427 in AP mode

2012-01-06T22:14:14+00:00

commit b25bfda38236f349cde0d1b28952f4eea2148d3f upstream.

don't do aggregation related stuff for 'AP mode client power save
handling' if aggregation is not enabled in the driver, otherwise it
will lead to panic because those data structures won't be never
intialized in 'ath_tx_node_init' if aggregation is disabled

	EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k]
	EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000
	ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c
	DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
	Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860
	task.ti=f40dc000)
	Stack:
	0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac
	f40e1cb0 f8186741
	f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001
	c0b4ba43 00000000
	0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac
	f2a30000 00010020
	Call Trace:
	[] ath9k_sta_notify+0x41/0x50 [ath9k]
	[] ? ath9k_get_survey+0x110/0x110 [ath9k]
	[] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350
	[mac80211]
	[] ? __module_address+0x95/0xb0
	[] ap_sta_ps_end+0x63/0xa0 [mac80211]
	[] ieee80211_rx_h_sta_process+0x156/0x2b0
	[mac80211]
	[] ieee80211_rx_handlers+0xce/0x510 [mac80211]
	[] ? trace_hardirqs_on+0xb/0x10
	[] ? skb_queue_tail+0x3e/0x50
	[] ieee80211_prepare_and_rx_handle+0x111/0x750
	[mac80211]
	[] ieee80211_rx+0x349/0xb20 [mac80211]
	[] ? ieee80211_rx+0x99/0xb20 [mac80211]
	[] ath_rx_tasklet+0x818/0x1d00 [ath9k]
	[] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
	[] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
	[] ath9k_tasklet+0xf3/0x1c0 [ath9k]
	[] tasklet_action+0xbe/0x180

Cc: Senthil Balasubramanian 
Cc: Rajkumar Manoharan 
Reported-by: Ashwin Mendonca 
Tested-by: Ashwin Mendonca 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: update SCD BC table for all SCD queues

2012-01-06T22:14:10+00:00

commit 96f1f05af76b601ab21a7dc603ae0a1cea4efc3d upstream.

Since we configure all the queues as CHAINABLE, we need to update the
byte count for all the queues, not only the AGGREGATABLE ones.

Not doing so can confuse the SCD and make the fw assert.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville

iwlwifi: allow to switch to HT40 if not associated

2012-01-06T22:13:55+00:00

commit 78feb35b8161acd95c33a703ed6ab6f554d29387 upstream.

My previous patch
34a5b4b6af104cf18eb50748509528b9bdbc4036 iwlwifi: do not re-configure
HT40 after associated

Fix the case of HT40 after association on specified AP, but it break the
association for some APs and cause not able to establish connection.
We need to address HT40 before and after addociation.

Reported-by: Andrej Gelenberg 
Signed-off-by: Wey-Yi Guy 
Tested-by: Andrej Gelenberg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: do not set the sequence control bit is not needed

2012-01-06T22:13:54+00:00

commit 123877b80ed62c3b897c53357b622574c023b642 upstream.

Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to
set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill
make the firmware to increment the sequence number which is incorrect and
cause unknown behavior.

Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix max phy rate at rate control init

2012-01-06T22:13:54+00:00

commit 10636bc2d60942254bda149827b922c41f4cb4af upstream.

The stations always chooses 1Mbps for all trasmitting frames,
whenever the AP is configured to lock the supported rates.
As the max phy rate is always set with the 4th from highest phy rate,
this assumption might be wrong if we have less than that. Fix that.

Cc: Paul Stewart 
Reported-by: Ajay Gummalla 
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: do not re-configure HT40 after associated

2011-12-21T20:57:38+00:00

commit 34a5b4b6af104cf18eb50748509528b9bdbc4036 upstream.

The ht40 setting should not change after association unless channel switch

This fix a problem we are seeing which cause uCode assert because driver
sending invalid information and make uCode confuse

Here is the firmware assert message:
kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
kernel: iwlagn 0000:03:00.0: CSR values:
kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
kernel: iwlagn 0000:03:00.0: FH register values:
kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
kernel: ------------[ cut here ]------------
WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
kernel: Hardware name: 4290W4H
kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
kernel: Call Trace:
kernel:  [] ? warn_slowpath_common+0x73/0x87
kernel:  [] ? ieee80211_reconfig+0x1f1/0x407
kernel:  [] ? ieee80211_recalc_smps_work+0x32/0x32
kernel:  [] ? ieee80211_restart_work+0x7e/0x87
kernel:  [] ? process_one_work+0x1c8/0x2e3
kernel:  [] ? worker_thread+0x17a/0x23a
kernel:  [] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [] ? kthread+0x7a/0x82
kernel:  [] ? kernel_thread_helper+0x4/0x10
kernel:  [] ? kthread_flush_work_fn+0x11/0x11
kernel:  [] ? gs_change+0xb/0xb

Reported-by: Udo Steinberg 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: Fix efuse EEPROM reading on PPC32.

2011-12-09T16:52:30+00:00

commit 68fa64ef606bcee688fce46d07aa68f175070156 upstream.

Fix __le32 to __le16 conversion of the first word of an 8-word block
of EEPROM read via the efuse method.

Reported-and-tested-by: Ingvar Hagelund 
Signed-off-by: Gertjan van Wingerde 
Acked-by: Helmut Schaa 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

p54spi: Fix workqueue deadlock

2011-12-09T16:52:29+00:00

commit 2d1618170eb493d18f66f2ac03775409a6fb97c6 upstream.

priv->work must not be synced while priv->mutex is locked, because
the mutex is taken in the work handler.
Move cancel_work_sync down to after the device shutdown code.
This is safe, because the work handler checks fw_state and bails out
early in case of a race.

Signed-off-by: Michael Buesch 
Acked-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

p54spi: Add missing spin_lock_init

2011-12-09T16:52:28+00:00

commit 32d3a3922d617a5a685a5e2d24b20d0e88f192a9 upstream.

The tx_lock is not initialized properly. Add spin_lock_init().

Signed-off-by: Michael Buesch 
Acked-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: Fix sleep-while-atomic bug in powersaving code.

2011-11-26T17:09:54+00:00

commit ed66ba472a742cd8df37d7072804b2111cdb1014 upstream.

The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.

Fix this by moving the call to rt2x00lib_config to a workqueue call.

This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672

Tested-by: Tomas Trnka 
Signed-off-by: Gertjan van Wingerde 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman