- 22 Dec, 2010 33 commits
-
-
Larry Finger authored
If the radio enable switch is off when the driver is loaded, it is not possible to get radio output until the driver is unloaded and reloaded with the switch on. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Device poller already reads current RSSI, so add support for set_cqm_rssi_config there. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Radio should be off when interface is down. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
rndis_set_default_key did call add_wep_key to set default key on device, even if key is WPA. This caused rndis_wlan not work with wpa_supplicant in nl80211 mode (causing disconnect from AP). Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Sometimes device returns wrong number of items in bssid-list. Appears that some specific beacons trigger this problem and leads to very poor scanning results. Workaround by ignoring num_items received from device and walkthrough full bssid-list buffer. v2: Fix buffer range checks and reading next item length. Old code read behind buffer on last item but didn't use those values as 'count' would also reach zero. Also fix resizing of buffer if device has larger buffer, old code assumed that BSSID-list OID would return same buffer size when it really can return yet another new larger length. Tested-by: Luís Picciochi <Pitxyoki@gmail.com> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
The size of the eeprom data is 1088 bytes for AR9485. But a sanity check is done against 4K which would result in a 'potential read past the end of the buffer' smatch complaint. Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Introduce a helper function to get the EEPROM mode from channel and remove multiple similar switch statements. Also since it's now easy to get the EEPROM mode from the channel, use them inside the functions which need it, instead of passing a redundant ee_mode parameter. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Remove redundant defines. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Add a new variable to keep track of the currently configured tx power. Before max_pwr was re-used for keeping the maximum allowed power as well as the current configuration. Doing a min() on it allows you to lower the txpower, but how would you be able to make it higher again? This patch fixes that by adding a new variable ah_cur_pwr which is used instead of txp_max_pwr to keep the current configuration. txp_max_pwr is used to check if we are within the limits. Another problem fixed by this patch is that it avoids setting a zero txpower when things are initialized first and the current power is not yet set. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
And rename functions which write the powertable to make it clearer. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Let ath5k_hw_txpower() decide if it can re-use the powertable or if it has to be recalculated instead of passing a 'fast' flag from the outside. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
There is a missing unlock when we hit the "No beacon slot available" error condition. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Use function pci_pcie_cap() instead of accessing struct member directly. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Use function pci_is_pcie() instead of accessing struct member directly. CC: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Use function pci_is_pcie() instead of accessing struct member directly. CC: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Use function pci_is_pcie() instead of accessing struct member directly. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Use function pci_is_pcie() instead of accessing struct member directly. CC: Michael Buesch <mb@bu3sch.de> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
No function declared in gpio.h is used here. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
No function declared in gpio.h is used here. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
ath9k supports its own set of virtual wiphys, and it uses the mac80211 idle notifications to know when a device needs to be idle or not. We recently changed ath9k to force idle on driver stop() and on resume but forgot to take into account ath9k's own virtual wiphy idle states. These are used internally by ath9k to check if the device's radio should be powered down on each idle call. Without this change its possible that the device could have been forced off but the virtual wiphy idle was left on. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
The recently added warning message on power change failure is not needed on device removal. ath: Failed to wakeup in 500us ------------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/ath9k/hw.c:1618 ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]() Hardware name: 64756D6 Pid: 540, comm: kworker/u:3 Not tainted 2.6.37-rc6-wl #37 Call Trace: [<ffffffff810501aa>] warn_slowpath_common+0x7a/0xb0 [<ffffffffa056e280>] ? ath9k_iowrite32+0x0/0x90 [ath9k] [<ffffffff810501f5>] warn_slowpath_null+0x15/0x20 [<ffffffffa05226ef>] ath9k_hw_setpower+0x61f/0x630 [ath9k_hw] [<ffffffffa05700e5>] ath9k_ps_wakeup+0x85/0xd0 [ath9k] [<ffffffffa0570685>] ath9k_configure_filter+0x25/0x80 [ath9k] [<ffffffffa04dde43>] ieee80211_configure_filter+0x133/0x190 [mac80211] [<ffffffffa04ee502>] ieee80211_do_stop+0x132/0x540 [mac80211] [<ffffffff813466ff>] ? _raw_spin_unlock_bh+0x1f/0x30 [<ffffffff812b6923>] ? dev_deactivate+0x1c3/0x1e0 [<ffffffffa04ee925>] ieee80211_stop+0x15/0x20 [mac80211] [<ffffffff8129d1b6>] __dev_close+0x56/0x90 Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
The commit "ath9k_hw: warn if we cannot change the power to the chip" introduced a new warning to indicate chip powerup failures, but this is not required for devices that have been removed. Handle USB device removal properly by checking for unplugged status. For PCI devices, this warning will still be seen when the card is pulled out, not sure how to check for card removal. Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
These drivers share one header file, but nothing else. Worse, both drivers use the rtl8225 part with different register settings. The results has been some ugly naming -- let's simplify that. Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
-
- 20 Dec, 2010 7 commits
-
-
John W. Linville authored
create_workqueue is deprecated. The workqueue usage does not seem to demand any special treatment, so do not set any flags either. Signed-off-by: John W. Linville <linville@tuxdriver.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Tejun Heo <tj@kernel.org>
-
Felix Fietkau authored
Restricting the chainmask to 1 for legacy mode disables useful features such as MRC, and it reduces the available transmit power. I can't think of a good reason to do this in legacy mode, so let's just get rid of that code. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The commit 'ath9k_hw: Disable PAPRD for rates with low Tx power' changed the code that sets the PAPRD rate masks to use only either the HT20 mask or the HT40 mask. This is wrong, as the hardware can still use HT20 rates even when configured for HT40, and the operating channel mode does not affect PAPRD operation. The register for the HT40 rate mask is applied as a mask on top of the other registers to selectively disable PAPRD for specific rates on HT40 packets only. This patch changes the code back to the old behavior which matches the intended use of these registers. While with current cards this should not make any practical difference (according to Atheros, the HT20 and HT40 mask should always be equal), it is more correct that way, and maybe the HT40 mask will be used for some rare corner cases in the future. Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When an skb is shared, it needs to be duplicated, along with its data buffer. If the skb does not have enough headroom, using skb_copy might cause the data buffer to be copied twice (once by skb_copy and once by pskb_expand_head). Fix this by using skb_clone initially and letting ieee80211_skb_resize sort out the rest. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
If the skb is not cloned and we don't need any extra headroom, there is no point in reallocating the skb head. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs' added a check for copying the skb if it's shared, however the tx info variable still points at the cb of the old skb Signed-off-by: Felix Fietkau <nbd@openwrt.org> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
wl12xx_get_platform_data() returns an ERR_PTR on failure and it never returns a NULL. Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-