- 27 Jul, 2010 20 commits
-
-
Dan Williams authored
Slightly different approach here since there are so many arguments to the firmware command. Just let the caller fill them in before pushing the command to the firmware. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
For now; it's a pretty easy command to hook up and whenever OLPC figures out how they want the userspace interface to look (ie, not iwpriv commands) we can easily add it back in. Since the cfg80211 conversion it wasn't working anyway. Signed-off-by:
-
Dan Williams authored
It hasn't been hooked up to anything in a long time and it's not even listed in any of the firmware documentation I have (and I have v5.1, v8, v9, and v10). Signed-off-by:
-
Dan Williams authored
These were no longer used but were left around; Transmit Power Control is done through the lbs_set_tpc_cfg() function. Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Convert to a full direct command; previous code rolled a direct command by hand but left the original indirect command code intact but disabled. Signed-off-by:
-
Dan Williams authored
Convert to a full direct command; previous code rolled a direct command by handle but left the original indirect command code lying around. Signed-off-by:
-
Stanislaw Gruszka authored
On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter), setting any WEP key with non zero index, cause rx frames corruption. Note: perhaps (I did not check) this can be fixed differently - by using hw_key_idx the same as true MAC key index. But according to the comment in rt2x00mac_set_key(): "the hardware requires keys to be assigned in correct order (When key 1 is provided but key 0 is not, then the key is not found by the hardware during RX)" this will be quite problematic. Since WEP should not be used, disabling hardware crypto offload for it will not hurt much. Beside static one key WEP will still be offloaded. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
Without cipher part nullify of TXRX_CSR0 register we can receive corrupted frames (removed IV or IVC), after reloading rt2500usb module with nohwcrypt=1 option, if previous some keys were configured into the hardware. Signed-off-by:
-
Stanislaw Gruszka authored
Fix rt2500usb hardware encryption broken by commit 96b61baf "rt2x00: Clean up USB vendor request buffer functions" Signed-off-by:
-
Senthil Balasubramanian authored
base index is not used anymore and so remove it. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Senthil Balasubramanian authored
The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser than MCS15 rate. This incorrect rate may affect switching to higher rates as the rate control algorithm always finds MCS15 is better than MCS15 ShortGI and results in lower throughput. Fix this by feeding the correct user ratekbs for MCS15 ShortGI rate. This issue affects 3 stream case very badly as the 3 stream rates are not used at all once we scale down to MCS15 from 3 stream rates. Signed-off-by:
-
Senthil Balasubramanian authored
This patch adds 3 stream rate control support for AR938X family chipsets which supports 3 streams. Signed-off-by:
-
Senthil Balasubramanian authored
replace valid and valid_single_stream in rate table with bit masks and reorganize the code so adding 3x3 rate control would be easier. Signed-off-by:
-
Jouni Malinen authored
Key locking simplification removed key->sdata != NULL verification from ieee80211_key_free(). While that is fine for most use cases, there is one path where this function can be called with an unlinked key (i.e., key->sdata == NULL && key->local == NULL). This results in a NULL pointer dereference with the current implementation. This is known to happen at least with FT protocol when wpa_supplicant tries to configure the key before association. Avoid the issue by passing in the local pointer to ieee80211_key_free(). In addition, do not clear the key from hw_accel or debugfs if it has not yet been added. At least the hw_accel one could trigger another NULL pointer dereference. Signed-off-by:
Jouni Malinen <j@w1.fi> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
John W. Linville authored
Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6John W. Linville authored
Conflicts: drivers/net/wireless/iwlwifi/iwl-commands.h
-
- 26 Jul, 2010 20 commits
-
-
Ivo van Doorn authored
Since commit: commit f1aa4c54 Author: Ivo van Doorn <ivdoorn@gmail.com> Date: Tue Jun 29 21:38:55 2010 +0200 rt2x00: Write the BSSID to register when interface is added mananged mode in rt2500pci was broken, due to intf->bssid containing random data rather then the expected 00:00:00:00:00:00 This is corrected by sending the BSSID to rt2x00lib_config_intf only in AP mode where the bssid is set to a valid value. Signed-off-by:Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Sujith authored
In AP mode, there is no need to notify the driver about QoS changes for the monitor interface that is created. The warning in ieee80211_bss_info_change_notify() would be hit otherwise. Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Acked-by:
-
Felix Fietkau authored
The noisefloor array index always corresponds to the rx chain number it belongs to (with an offset of 3 for the extension chain). It's much simpler (and actually more correct) to directly use the chainmask to calculate the bitmask for the noisefloor array, instead of using these weird chip revision checks and hardcoded mask values. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
In the noisefloor array, the extension channel values start at index 3 Signed-off-by:
-
Felix Fietkau authored
When the hardware is configured in HT20 mode, noise floor readings for the extension channel often return invalid values, which keep the values in the NF history buffer at the hardware-specific maximum limit. Fix this by discarding the extension channel values when in HT20 mode. Signed-off-by:
-
Felix Fietkau authored
When an aggregation session is being cleaned up, while the tx status for some frames is being processed, the TID is flushed and its buffers are sent out. Unfortunately that left the pending un-acked frames unprocessed, thus leaking buffers. Fix this by reordering the code so that those frames are processed first, before the TID is flushed. Signed-off-by:
-
Johannes Berg authored
I just had the following: WARNING: at drivers/net/wireless/iwlwifi/iwl-agn-tx.c:574 iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]() Call Trace: <IRQ> [<ffffffff8105c5df>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8105c63a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0290b46>] iwlagn_tx_skb+0x1576/0x15f0 [iwlagn] [<ffffffffa027076c>] iwl_mac_tx+0x5c/0x260 [iwlagn] [<ffffffffa01bdf5b>] __ieee80211_tx+0x10b/0x1a0 [mac80211] [<ffffffffa01bfb86>] ieee80211_tx_pending+0x186/0x2d0 [mac80211] [<ffffffff81062ea5>] tasklet_action+0x125/0x130 [<ffffffff810634a6>] __do_softirq+0x106/0x270 [<ffffffff8100c09c>] call_softirq+0x1c/0x30 iwlagn 0000:02:00.0: Attempting to modify non-existing station 107 Note that 107 == 0x6b which is slab poison. The reason is that mac80211 passed a freed station pointer to mac80211, because as it happened iwlwifi reset itself while mac80211 was disconnecting from the network. It turns out that we do take care to look up the station pointer in ieee80211_tx_pending_skb, but then don't use it, which obviously is a bug. Fix this by removing the ieee80211_tx_h_sta handler and assigning the station pointer directly. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Dan Carpenter authored
Negate has precedence over comparison so the original test was always false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR). Signed-off-by:
Dan Carpenter <error27@gmail.com> Acked-by:
-
Johannes Berg authored
When wireless extensions are used to control an encrypted IBSS, we erroneously can try to set the default management key. Fix this. Signed-off-by:
-
Johannes Berg authored
Another remnant of the previous key locking scheme needs to be removed -- this causes a warning otherwise as ieee80211_set_default_mgmt_key will acquire a mutex. Signed-off-by:
-
Dan Carpenter authored
The "rd" variable isn't needed any more since 4f366c5d "wireless: only use alpha2 regulatory information from country IE" Signed-off-by:
-
Dan Carpenter authored
The intent was to free "msp->ratelist" here. "msp->sample_table" is always NULL at this point. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Sometimes txq state(txq->stopped) can be marked as started but the actual queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Dan Carpenter authored
snprintf() returns the number of characters that would have been written (not counting the NUL character). So we can't use it as the limiter to simple_read_from_buffer() without capping it first at sizeof(buf). Signed-off-by:
-
Dan Carpenter authored
The snprintf() function returns the number of characters that would have been written (not counting the NUL character on the end). It could potentially be larger than the size of the buffer. Signed-off-by:
-
Julia Lawall authored
Use kmemdup when some other buffer is immediately copied into the allocated region. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S - memcpy(to, from, size); // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
John W. Linville authored
Signed-off-by: -
John W. Linville authored
"It's not problematic if minstrel gets feedback for rates that it doesn't have in its list, it should just ignore it. - Felix" Signed-off-by: -
John W. Linville authored
If sta is NULL, we will have problems long before we get here... Reported-by:
-
John W. Linville authored
The current practice of checking vif for NULL in one place but not another seems to confuse some static checkers, smatch in particular. Since vif will only be NULL in the case of internal scans, adjust the checks accordingly. Reported-by:
-
