linux/drivers/net/wireless, branch v3.8.7

rt2x00: rt2x00pci_regbusy_read() - only print register access failure once

2013-04-12T16:52:13Z

commit 83589b30f1e1dc9898986293c9336b8ce1705dec upstream. BugLink: http://bugs.launchpad.net/bugs/1128840 It appears that when this register read fails it never recovers, so I think there is no need to repeat the same error message ad infinitum. Signed-off-by: Tim Gardner Cc: Ivo van Doorn Cc: Gertjan van Wingerde Cc: Helmut Schaa Cc: "John W. Linville" Cc: linux-wireless@vger.kernel.org Cc: users@rt2x00.serialmonkey.com Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mwifiex: complete last internal scan

2013-04-12T16:52:12Z

commit 21de979ecfc7b7f9442f8aea9a54b3ab670d0151 upstream. We are waiting on first scan command of internal scan request before association, so we should complete on last internal scan command response. Tested-by: Daniel Drake Tested-by: Marco Cesarano Signed-off-by: Bing Zhao Signed-off-by: Amitkumar Karwar Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mwifiex: limit channel number not to overflow memory

2013-04-12T16:52:07Z

commit 901ceba4e81e9dd6b4a3c4c37ee22000a6c5c65f upstream. Limit the channel number in scan request, or the driver scan config structure memory will be overflowed. Signed-off-by: Stone Piao Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: don't send HCMD in restart flow

2013-04-05T16:26:15Z

commit 2d5d50ee596361566f7f84300117cba7d7672bc5 upstream. There is a race between the restart flow and the workers. The workers are cancelled after the fw is already killed and might send HCMD when there is fw to handle them. Simply check that there is a fw to which the HCMD can be sent before actually sending it. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Lingzhu Xiang Reviewed-by: CAI Qian Signed-off-by: Greg Kroah-Hartman

mwifiex: cancel cmd timer and free curr_cmd in shutdown process

2013-04-05T16:25:50Z

commit 084c7189acb3f969c855536166042e27f5dd703f upstream. curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Tested-by: Marco Cesarano Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mwifiex: skip pending commands after function shutdown

2013-04-05T16:25:50Z

commit a3e240cacc93a06bff3313e28938e980d01a2160 upstream. During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is sent to firmware. Firmware expcets only FUNC_INIT once WLAN function is shut down. Any command pending in the command queue should be ignored and freed. Tested-by: Daniel Drake Tested-by: Marco Cesarano Signed-off-by: Bing Zhao Signed-off-by: Amitkumar Karwar Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mwifiex: fix race when queuing commands

2013-04-05T16:25:50Z

commit 00d7ea11ff0783e24fe70778f3141270b561aaa1 upstream. Running the following script repeatedly on XO-4 with SD8787 produces command timeout and system lockup. insmod mwifiex_sdio.ko sleep 1 ifconfig eth0 up iwlist eth0 scan & sleep 0.5 rmmod mwifiex_sdio mwifiex_send_cmd_async() is called for sync as well as async commands. (mwifiex_send_cmd_sync() internally calls it for sync command.) "adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async() routine for both types of commands. But it is used only for sync commands in mwifiex_wait_queue_complete(). This could lead to a race when two threads try to queue a sync command with another sync/async command simultaneously. Get rid of global variable and pass command node as a parameter to mwifiex_wait_queue_complete() to fix the problem. Reported-by: Daniel Drake Tested-by: Daniel Drake Tested-by: Marco Cesarano Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

b43: N-PHY: use more bits for offset in RSSI calibration

2013-04-05T16:25:48Z

commit 2e1253d640eb7f8707d2591c93097c1e9f9c71d5 upstream. When calculating "offset" for final RSSI calibration we're using numbers bigger than s8 can hold. We have for example: offset[j] = 232 - poll_results[j]; formula. If poll_results[j] is small enough (it usually is) we treat number's bit as a sign bit. For example 232 - 1 becomes: 0xE8 - 0x1 = 0xE7, which is not 231 but -25. This code was introduced in e0c9a0219a8f542e3946fe972a68aacf8c3f906c and caused stability regression on some cards, for ex. BCM4322. Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville

b43: A fix for DMA transmission sequence errors

2013-04-05T16:25:48Z

commit b251412db99ccd4495ce372fec7daee27bf06923 upstream. Intermittently, b43 will report "Out of order TX status report on DMA ring". When this happens, the driver must be reset before communication can resume. The cause of the problem is believed to be an error in the closed-source firmware; however, all versions of the firmware are affected. This change uses the observation that the expected status is always 2 less than the observed value, and supplies a fake status report to skip one header/data pair. Not all devices suffer from this problem, but it can occur several times per second under heavy load. As each occurence kills the unmodified driver, this patch makes if possible for the affected devices to function. The patch logs only the first instance of the reset operation to prevent spamming the logs. Tested-by: Chris Vine Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

b43: N-PHY: increase initial value of "mind" in RSSI calibration

2013-04-05T16:25:48Z

commit e67dd874e60529dbd2e8232babb1e23479ba2ffa upstream. We're using "mind" variable to find the VCM that got the best polling results. For each VCM we calculte "currd" which is compared to the "mind". For PHY rev3+ "currd" gets values around 14k-40k. Looking for a value smaller than 40 makes no sense, so increase the initial value. This fixes a regression introduced in 3.4 by commit: e0c9a0219a8f542e3946fe972a68aacf8c3f906c (my BCM4322 performance dropped from 18,4Mb/s to 9,26Mb/s) Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman