- 02 May, 2011 2 commits
-
-
Christian Lamparter authored
Currently, mac80211 handles MIC failures differently depending on whenever they are detected by the stack's own software crypto or when are handed down from the driver. This patch tries to unify both by moving the special branch out of mac80211 rx hotpath and into into the software crypto part. This has the advantage that we can run a few more sanity checks on the data and verify if the key type was TKIP. This is very handy because several devices generate false postive MIC failure reports. Like carl9170, ath9k and wl12xx: <http://www.spinics.net/lists/linux-wireless/msg68494.html> "mac80211: report MIC failure for truncated packets in AP mode" Cc: Luciano Coelho <coelho@ti.com> Cc: Arik Nemtsov <arik@wizery.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.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:
-
- 30 Apr, 2011 14 commits
-
-
Wey-Yi Guy authored
After driver split, no need for debugfs callback, remove those Signed-off-by:Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
If an interface type changes from a type that is only supported on the PAN context (e.g. P2P GO) to a type that is supported on the BSS context, and the BSS context is not in use, then we need to use the BSS context instead of changing the device type within the context. To achieve this, refuse the type change, which causes a down/up cycle that will allocate the BSS context for the interface. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
The current RXON checking doesn't verify that the channel is valid (or at least non-zero), so add that. Also, add a WARN() so we get a stacktrace, and capture a bitmask of errors in order to capture all necessary information in the warning itself (in case the previous messages are snipped off.) Signed-off-by:
-
Johannes Berg authored
This header file isn't used, and if we ever need these definitions they shouldn't be added to a driver but rather to the common 802.11 include file that has all frame definitions. Thus, just remove it. Signed-off-by:
-
Don Fry authored
All agn devices use the same eeprom semaphore and calib version routines. Delete the indirection and move the semaphore routines to where they are used and make static. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
-
Don Fry authored
All agn devices use the same module parameter structure. Delete the indirection and access the structure diretly. Signed-off-by:
-
Wey-Yi Guy authored
Correction for new 105 series devices Signed-off-by: -
Johannes Berg authored
New microcode versions use the good CRC threshold field differently, as a flag, and in that case we should set it to 1/0 instead of 1/65535 for an active/passive scan. The new behaviour is advertised by the uCode with a feature flag. Signed-off-by:
-
Wey-Yi Guy authored
No functional changes, separate the connect and disconnect sequences in RXON commit function, easier to read and understand. Signed-off-by: -
Wey-Yi Guy authored
The data structure is shared by all _agn devices, remove the reference to 5000 Signed-off-by: -
Wey-Yi Guy authored
Move rxon_assoc to static function from ops Signed-off-by: -
Johannes Berg authored
The WoWLAN resume code will have to essentially do a restart, but without going through the work struct. To support that, refactor the restart by splitting out the preparation code into a new function. Signed-off-by:
-
Johannes Berg authored
There are a few cases like the WoWLAN support I'm writing that require attempting to access the NIC when it is known that it might not be accessible, e.g. after the system woke up and the platform might have reset the device. To avoid messages in this case, introduce the new function iwl_grab_nic_access_silent(), it will only return an error status. Signed-off-by:
-
Johannes Berg authored
If a device error happens while the uCode is being loaded or initialised, we will attempt to restart the device (which will likely fail again, but that's not the issue here). During this new restart, we turn off the device, but as the uCode failed to initialise it already is turned off. As a consequence, grabbing NIC access will fail and cause excessive messages and hangs. To fix this issue, introduce a new status bit and only attempt to reprogram the device when it isn't already disabled. Signed-off-by:
-
- 29 Apr, 2011 20 commits
-
-
Yogesh Ashok Powar authored
The tx_headroom required for mwl8k driver is 32 bytes and it can use the space for 802.11 header received from mac80211. mwl8k considers the smallest 802.11 frame (CTS2self of 10 bytes) that can be received from mac80211 to compute the extra_tx_headroom as 22 (32 - 10) bytes. When the wireless interface is part of bridge, this extra_tx_headroom requirement results in a memcpy in mac80211 (in function pskb_expand_head) for all the data frames needing L2 forwarding/bridging, when NET_SKB_PAD is defined as 32. This patch reduces the extra_tx_headroom by 8 bytes so that memcpy of data frames in mac80211 is avoided in this case. The resize will be required in driver for frames with 802.11 header size of less than 18 bytes. Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by:
-
Sujith Manoharan authored
Remove all the convoluted hacks in the driver and simplify things by making use of mac80211's LED triggers. Signed-off-by:
Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Stanislaw Gruszka authored
We now use priv->mutex to serialize sync command, remove old priv->sync_cmd_mutex and add assertion that priv->mutex must be locked. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Stanislaw Gruszka authored
Check status bits with mutex taken, because when we wait for mutex unlock, status can change. Patch should also make remaining sync commands be send with priv->mutex taken. That will prevent execute these commands when we are currently reset firmware, what could possibly cause troubles. Signed-off-by:
-
Stanislaw Gruszka authored
We mark command as huge by using meta->flags from other (non huge) command, but flags can be possibly overridden, when non huge command is enqueued, what can lead to: WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0() DMA-API: device driver has pending DMA allocations while released from device [count=1] To fix introduce additional CMD_MAPPED to mark command as mapped and serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using hcmd_lock. Serialization will also fix possible race conditions, because q->read_ptr, q->write_ptr are modified/used in parallel. Do not change callback, I did (and fixed) that mistake in iwlagn. Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
struct iwl_queue is not part of firmware interface, so __packed is not needed. Remove it since is may affect performance. Signed-off-by:
-
Stanislaw Gruszka authored
We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan check is unneeded. Correct debug message while at it. Signed-off-by:
-
Stanislaw Gruszka authored
Don't need to use conditional as ch->band is already assigned to IEEE80211_BAND_5GHZ or IEEE80211_BAND_2GHZ Signed-off-by:
-
Stanislaw Gruszka authored
Add two below iwlwifi commits to iwlegacy: commit 554d1d02 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Thu Dec 23 12:38:21 2010 +0100 iwlagn: enable only rfkill interrupt when device is down commit 3dd823e6 Author: Don Fry <donald.h.fry@intel.com> Date: Sun Feb 6 09:29:45 2011 -0800 iwlagn: Re-enable RF_KILL interrupt when down Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
Since commit f844a709 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Jan 28 16:47:44 2011 +0100 iwlwifi: do not set tx power when channel is changing we set device tx power during initialization to priv->tx_power_next, which itself is initialized to minimum power. That changed default behaviour of driver. Previously we initialized device to transmit at maximum available power by default. Patch change again to previous behaviour and cleanup tx power initialization. Fortunately this is not critical fix, as mac80211 layer setup tx power lately to 14dB, hence device does not operate at minimal transmit power all the time. Signed-off-by:
-
Sujith Manoharan authored
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/modal_eeprom Signed-off-by:
-
Sujith Manoharan authored
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom Signed-off-by:
-
-
John W. Linville authored
CC [M] drivers/net/wireless/p54/eeprom.o drivers/net/wireless/p54/eeprom.c: In function ‘p54_parse_rssical’: drivers/net/wireless/p54/eeprom.c:494:8: warning: ‘freq’ may be used uninitialized in this function Signed-off-by: -
John W. Linville authored
CC [M] drivers/net/wireless/mwifiex/join.o drivers/net/wireless/mwifiex/join.c: In function ‘mwifiex_cmd_802_11_associate’: drivers/net/wireless/mwifiex/join.c:119:8: warning: ‘tsf_val’ may be used uninitialized in this function drivers/net/wireless/mwifiex/join.c:103:12: note: ‘tsf_val’ was declared here Looks like a copy-n-paste error, identical lines are a few lines below the ones removed, with an actual memcpy to tsf_val in between... Signed-off-by: -
John W. Linville authored
CC [M] drivers/net/wireless/b43/phy_n.o drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_set_channel’: drivers/net/wireless/b43/phy_n.c:3848:47: warning: ‘tabent_r2’ may be used uninitialized in this function drivers/net/wireless/b43/phy_n.c:3849:47: warning: ‘tabent_r3’ may be used uninitialized in this function drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_poll_rssi.clone.14’: drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$7’ may be used uninitialized in this function drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$8’ may be used uninitialized in this function FWIW, the usage of these variables is goverened by checks that match their initializations. So, I think these are actually false warnings. Still, I would rather avoid the warning SPAM... Signed-off-by: -
John W. Linville authored
CC [M] drivers/net/wireless/ath/ath5k/reset.o drivers/net/wireless/ath/ath5k/reset.c: In function ‘ath5k_hw_init_core_clock’: drivers/net/wireless/ath/ath5k/reset.c:100:51: warning: ‘txf2txs’ may be used uninitialized in this function Signed-off-by:
-
- 28 Apr, 2011 4 commits
-
-
Johan Hedberg authored
In some circumstances hci_get_auth_req will return a value different from the current conn->auth_type. In these cases update conn->auth_type so that when a user confirm request comes it doesn't falsely trigger auto-accept. Signed-off-by:
Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi>
-
Johan Hedberg authored
Even for keys that shouldn't be stored some use cases require the knowledge of a new key having been created so that the conclusion of a successful pairing can be made. Therefore, always send the mgmt_new_key event but add a store_hint parameter to it to indicate to user space whether the key should be stored or not. Signed-off-by:
-
Johan Hedberg authored
User space shouldn't have any need for the old key type so remove it from the corresponding Management interface event. Signed-off-by:
-
Johan Hedberg authored
If a controller generates a changed combination key as its first key the connection key type will not be correctly set. In these situations make sure the update the connection key type when such a buggy controller is detected. Signed-off-by:
-
