- 10 May, 2011 2 commits
-
-
Mohammed Shafi Shajakhan authored
during suspend/S3 state drv_flush is called from mac80211 irrespective of interface count. In ath9k we queue a work in ath9k_flush which we expect to be cancelled in the drv_stop call back. during suspend process mac80211 calls drv_stop only when the interface count(local->count) is non-zero. unfortunately when the network manager is enabled, drv_flush is called while drv_stop is not called as local->count reaches '0'. So fix this by simply checking for the device presence in the drv_flush call back in the driver before queueing work or anything else. this patch fixes the following WARNING Call Trace: [<c014c6e2>] warn_slowpath_common+0x72/0xa0 [<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211] [<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211] [<c014c75b>] warn_slowpath_fmt+0x2b/0x30 [<fc133f99>] ieee80211_can_queue_work+0x39/0x50 [mac80211] [<fc134ed1>] ieee80211_queue_delayed_work+0x21/0x50 [mac80211] [<fc1e5b22>] ath_tx_complete_poll_work+0xb2/0x100 [ath9k] [<c016399e>] run_workqueue+0x8e/0x150 [<fc1e5a70>] ? ath_tx_complete_poll_work+0x0/0x100 [ath9k] [<c0163ae4>] worker_thread+0x84/0xe0 [<c0167a60>] ? autoremove_wake_function+0x0/0x50 [<c0163a60>] ? worker_thread+0x0/0xe0 [<c01677d4>] kthread+0x74/0x80 [<c0167760>] ? kthread+0x0/0x80 [<c0104087>] kernel_thread_helper+0x7/0x10 ---[ end trace 2aff81010df9215b ]--- Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luciano Coelho authored
When we are disconnecting, we set PS off, but this happens before we send the deauth/disassoc request. When the deauth/disassoc frames are sent, we trigger the dynamic ps timer, which then times out and turns PS back on. Thus, PS remains on after disconnecting, causing problems when associating again. This can be fixed by preventing the timer to start when we're not associated anymore. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
- 29 Apr, 2011 2 commits
-
-
Stanislaw Gruszka authored
Need to use broadcast sta_id for management frames, otherwise we broke BA session in the firmware and get messages like that: "Received BA when not expected" or (on older kernels): "BA scd_flow 0 does not match txq_id 10" This fix regression introduced in 2.6.35 during station management code rewrite by: commit 2a87c26b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Apr 30 11:30:45 2010 -0700 iwlwifi: use iwl_find_station less Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Stanislaw Gruszka authored
Need to use broadcast sta_id for management frames, otherwise we broke BA session in the firmware and get messages like that: "Received BA when not expected" or (on older kernels): "BA scd_flow 0 does not match txq_id 10" This fix regression introduced in 2.6.35 during station management code rewrite by: commit 2a87c26b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Apr 30 11:30:45 2010 -0700 iwlwifi: use iwl_find_station less Patch partially resolve: https://bugzilla.kernel.org/show_bug.cgi?id=16691 However, there are still 11n performance problems on 4965 and 5xxx devices that need to be investigated. Cc: stable@kernel.org # 2.6.35+ Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
- 28 Apr, 2011 3 commits
-
-
Stanislaw Gruszka authored
Fix the following: WARNING: at drivers/net/wireless/iwlegacy/iwl-4965.c:1128 \ iwl4965_send_tx_power+0x61/0x102 [iwl4965]() Hardware name: [...] TX Power requested while scanning! Pid: 5723, comm: kworker/u:28 Not tainted 2.6.39-0.rc4.4.fc14.x86_64 #1 Call Trace: [<ffffffff8104e27b>] warn_slowpath_common+0x85/0x9d [<ffffffffa02782e0>] ? iwl4965_show_temperature+0x49/0x49 [iwl4965] [<ffffffff8104e336>] warn_slowpath_fmt+0x46/0x48 [<ffffffffa027712f>] iwl4965_send_tx_power+0x61/0x102 [iwl4965] [<ffffffff81477e05>] ? mutex_lock+0x36/0x50 [<ffffffffa0278337>] iwl4965_bg_txpower_work+0x57/0x73 [iwl4965] [<ffffffff810647f3>] process_one_work+0x18d/0x286 [<ffffffff81065a5e>] worker_thread+0xfd/0x181 [<ffffffff81065961>] ? manage_workers.clone.16+0x172/0x172 [<ffffffff81069036>] kthread+0x82/0x8a [<ffffffff81480524>] kernel_thread_helper+0x4/0x10 [<ffffffff81068fb4>] ? kthread_worker_fn+0x14b/0x14b [<ffffffff81480520>] ? gs_change+0x13/0x13 Reported-and-tested-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Wey-Yi Guy authored
commit 5ed540ae change the led behavior for iwlwifi driver; the side effect cause led blink all the time. Modify the led blink table to fix this problem Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
- 20 Apr, 2011 4 commits
-
-
Stanislaw Gruszka authored
Since commit a120e912 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link, making bisection of other problems impossible. Signed-off-by:
-
Stanislaw Gruszka authored
Since commit a120e912 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Cc: stable@kernel.org # 2.6.32+ Signed-off-by:
-
Johannes Berg authored
The locking with SMPS requests means that the debugs file should lock the mgd mutex, not the iflist mutex. Calls to __ieee80211_request_smps() need to hold that mutex, so add an assertion. This has always been wrong, but for some reason never been noticed, probably because the locking error only happens while unassociated. Cc: stable@kernel.org [2.6.34+] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
-
- 19 Apr, 2011 1 commit
-
-
Felix Fietkau authored
The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect a condition where rx DMA was stopped, but the MAC failed to enter the idle state. This condition requires a hardware reset, however the return value of ath_stoprecv was 'true' in that case, which allowed it to skip the reset when issuing a fast channel change. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Paul Stewart <pstew@google.com> Cc: stable@kernel.org Signed-off-by:
-
- 18 Apr, 2011 5 commits
-
-
Ruiyi Zhang authored
When retrasmitting one frame, only SAR bits in control field should be kept. Signed-off-by:
Ruiyi Zhang <Ruiyi.zhang@atheros.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi>
-
Luiz Augusto von Dentz authored
shutdown should wait for SCO link to be properly disconnected before detroying the socket, otherwise an application using the socket may assume link is properly disconnected before it really happens which can be a problem when e.g synchronizing profile switch. Signed-off-by:
Luiz Augusto von Dentz <luiz.dentz-von@nokia.com> Signed-off-by:
-
Vinicius Costa Gomes authored
In the teardown path the reset command is sent to the controller, this event causes the command timer to be reactivated. So the timer is removed in two situations, when the adapter isn't marked as UP and when we know that some command has been sent. Reported-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by:
-
Ville Tervo authored
hci_io_capa_reply_evt() holds reference for hciconnection. It's useless since hci_io_capa_request_evt()/hci_simple_pair_complete_evt() already protects the connection. In addition it leaves connection open after failed SSP pairing. Signed-off-by:
Ville Tervo <ville.tervo@nokia.com> Signed-off-by:
-
Daniel Halperin authored
For some reason, sending QoS configuration causes transmission to stop after a single frame on HT channels when not associated. Removing the extra QoS configuration has no effect on station mode, and fixes injection mode. Signed-off-by:
Daniel Halperin <dhalperi@cs.washington.edu> Signed-off-by:
-
- 13 Apr, 2011 1 commit
-
-
Stanislaw Gruszka authored
priv->tx_power_next is not initialized to max supported power, but instead default value is used, what cause errors like [ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14. [ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22). if maximum tx power read from the eeprom is smaller than default. In consequence card is unable to initialize properly. Fix the problem and cleanup tx power initialization. Reported-and-tested-by:
Robin Dong <hao.bigrat@gmail.com> Signed-off-by:
-
- 12 Apr, 2011 2 commits
-
-
Sujith Manoharan authored
Pass the correct module name and device interface so that ethtool can display the proper values. The firmware version will be fixed later on when the FW can actually report a version. :) Reported-by:
Richard Farina <sidhayn@gmail.com> Signed-off-by:
Sujith Manoharan <Sujith.Manoharan@atheros.com> Tested-by:
-
Felix Fietkau authored
During PHY errors, the MAC can sometimes fail to enter an idle state on older hardware (before AR9380) after an rx stop has been requested. This typically shows up in the kernel log with messages like these: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ------------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]() Call Trace: [<8023f0e8>] dump_stack+0x8/0x34 [<80075050>] warn_slowpath_common+0x78/0xa4 [<80075094>] warn_slowpath_null+0x18/0x24 [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k] [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k] [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k] When this happens, the state that the MAC enters is easy to identify and does not result in bogus DMA traffic, however to ensure a working state after a channel change, the hardware should still be reset. This patch adds detection for this specific MAC state, after which the above warnings completely disappear in my tests. Signed-off-by:
-
- 11 Apr, 2011 1 commit
-
-
John W. Linville authored
Otherwise, IWLWIFI_LEGACY has to be selected independently before the drivers are made available. Reported-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
- 08 Apr, 2011 2 commits
-
-
Jason Conti authored
This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185 Cc: <stable@kernel.org> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Jason Conti <jason.conti@gmail.com> Signed-off-by:
-
Felix Fietkau authored
These missing chip wakeups mainly cause crashes on AR5416 cards in MIPS boards, but have also been reported to cause radio stability issues on AR9285. Signed-off-by:
-
- 07 Apr, 2011 3 commits
-
-
Christian Lamparter authored
Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Cc: <stable@kernel.org> Reported-by:
Joe Culler <joe.culler@gmail.com> Acked-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Brian Cavagnolo authored
When the mwl8k driver attempts and fails to switch from sta to ap firmware (or vice-versa) in the mwl8k_add_interface routine, the mwl8k_stop routine will be called. This routine must not attempt to free the irq if it was not requested. Signed-off-by:
Brian Cavagnolo <brian@cozybit.com> Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
-
Johannes Berg authored
At least EEPROM version 0x11A has the wrong number of chains programmed into it for some reason, so we need to override in the driver. Signed-off-by:
-
- 04 Apr, 2011 13 commits
-
-
John W. Linville authored
A number of these devices have appeared "in the wild", and apparently the Windows driver is perfectly happy to support this EEPROM version. Signed-off-by:
-
Stanislaw Gruszka authored
{rx,tx}done_work's are only initialized for usb devices. Signed-off-by:Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Larry Finger authored
Some compiler/architecture combinations generate some warnings that are not seen on my main system. Two of the "warnings" about unitialized variables are really bugs. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Christian Lamparter authored
Cc: <stable@kernel.org> Reported-by: Mark Davis [via p54/devices wiki] Signed-off-by:
-
Luciano Coelho authored
We were allocating the size of the NVS file struct and not checking whether the length of the buffer passed was correct before copying it into the allocated memory. This is a security hole because buffer overflows can occur if the userspace passes a bigger file than what is expected. With this patch, we check if the size of the data passed from userspace matches the size required. This bug was introduced in 2.6.36. Cc: stable@kernel.org Reported-by:
Ido Yariv <ido@wizery.com> Signed-off-by:
-
Jussi Kivilinna authored
2.6.38 added WARN_ON(in_irq) in del_timer_sync that triggers on zd1211rw when reseting rx idle timer in urb completion handler. Move timer reseting to tasklet. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Jussi Kivilinna authored
Patch removes the bogus flag introduced by upstream commit eefdbec1. Old code had buffer length check that new code tried to handle with URB_SHORT_NOT_OK flag. With USB debugging enabled bogus flag caused usb_submit_urb fail. Remove URB_SHORT_NOT_OK flag and add buffer length check to urb completion handler. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32092Reported-by:
Jonathan Callen <abcd@gentoo.org> Signed-off-by:
-
Helmut Schaa authored
Cleaning the ieee80211_rx_data.flags field here is wrong, instead the flags should be valid accross processing the frame on different interfaces. Fix this by removing the incorrect flags=0 assignment. Introduced in commit 554891e6 (mac80211: move packet flags into packet). Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Johannes Berg authored
The description for buf_size was misleading and just said you couldn't TX larger aggregates, but of course you can't TX aggregates in a way that would exceed the window either, which is possible even if the aggregates are shorter than that. Expand the description, thanks to Emmanuel for explaining this to me. Cc: Emmanuel Grumbach <egrumbach@gmail.com> Signed-off-by:
-
Senthil Balasubramanian authored
The phy information print during driver init time doesn't show the numeric part of the chip name properly for AR9485. This patch addresses this issue by adding the string to the respective array. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Luciano Coelho authored
The MODULE_AUTHOR() macro in the main module (wl12xx) has been updated to reflect one of the author's new email address, but the wl12xx_spi and wl12xx_sdio modules haven't been updated. This patches updates them. Signed-off-by:
-
John W. Linville authored
Otherwise, skb_put inside of dma_rx can fail... https://bugzilla.kernel.org/show_bug.cgi?id=32042Signed-off-by:
-
Mariusz Kozlowski authored
On error path kfree() should get pointer to memory allocated by kmalloc() not the address of variable holding it (which is on stack). Signed-off-by:
Mariusz Kozlowski <mk@lab.zgora.pl> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 02 Apr, 2011 1 commit
-
-
Ilpo Järvinen authored
All callers are prepared for alloc failures anyway, so this error can safely be boomeranged to the callers domain without super bad consequences. ...At worst the connection might go into a state where each RTO tries to (unsuccessfully) re-fragment with such a mis-sized value and eventually dies. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
