- 20 May, 2009 40 commits
-
-
Luis R. Rodriguez authored
There is a race on access to last_request and its alpha2 through reg_is_valid_request() and us possibly processing first another regulatory request on another CPU. We avoid this improbably race by locking with the cfg80211_mutex as we should have done in the first place. While at it add the assert on locking on reg_is_valid_request(). Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This has no functional change, but it will make the race fix easier to spot in my next patch. Cc: stable@kernel.org Signed-off-by:
-
Luis R. Rodriguez authored
This has no functional change except we save a kfree(rd) and allows us to clean this code up a bit after this. We do avoid an unnecessary kfree(NULL) but calling that was OK too. Cc: stable@kernel.org Signed-off-by:
-
Wei Yongjun authored
This patch fix to set dev->broadcast correctly, since dev->broadcast is defined as: unsigned char broadcast[MAX_ADDR_LEN]; Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
-
Alexander Beregalov authored
Fix this build error: drivers/staging/agnx/pci.c: In function 'agnx_config_interface': drivers/staging/agnx/pci.c:315: error: dereferencing pointer to incomplete type .. drivers/staging/agnx/pci.c:424: error: unknown field 'config_interface' specified in initializer config_interface was removed in 2d0ddec5 ("mac80211: unify config_interface and bss_info_changed") Signed-off-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
We do not need to do this in ath_isr() and it looks like the modified version ends up being more stable as far as being able receive beacon frames is concerned. Furthermore, this reduces need to move between AWAKE and NETWORK SLEEP states when processing some unrelated interrupts. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by:
-
Johannes Berg authored
Some applications using wireless extensions expect to be able to remove a key that doesn't exist. One example is wpa_supplicant which doesn't actually change behaviour when running into an error while trying to do that, but it prints an error message which users interpret as wpa_supplicant having problems. The safe thing to do is not change the behaviour of wireless extensions any more, so when the driver reports -ENOENT let the wext bridge code return success to userspace. To guarantee this, also document that drivers should return -ENOENT when the key doesn't exist. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Daniel Wagner authored
Currently all radios receive all traffic on the simulated air if they are tuned to the same channel. This patch introduces the concept of grouping, which allows to assign a radio to certain group. Only radios in the same group can 'see' each other. Each bit in /debug/ieee80211/phy*/hwsim/group represents one group. By default all radios belong to the same group "1", e.g. bit 1 is set. Additionally a radio can belong to several groups. Signed-off-by:
Daniel Wagner <wagi@monom.org> Signed-off-by:
-
Bob Copeland authored
ath5k only generated the beacon when bss_info_changed() was called, but for AP mode this is not enough, because the TIM IE would never get updated and consequently PS mode clients wouldn't know about buffered frames. Instead, get a new beacon on every SWBA interrupt. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Max Filippov authored
Drop test for FW_STATE_RESET in p54spi_work as fw_state is never assigned this value. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Johannes Berg authored
Process beacon change even if the BSSID doesn't change at the same time. Also fix what I think is a small locking error in b43legacy, there's a spin_unlock_irqrestore that looks out of place. Signed-off-by:
-
Max Filippov authored
Under high load first data word, read after available data size is sometimes lost in p54spi_rx. It seems to depend on frequency of interrupts and latency of data read request relatively to 'data available' interrupt. The worst consequence of this bug is loss of packet transmission acknowledgement, which in turn causes overflow of tx queues and permanent link loss. Read data size and first data word in one SPI transaction. No packets from LMAC should have length less than 1 word, so this shouldn't interfere with the next read transaction. Also call p54spi_sleep if p54spi_wake succeeded. Signed-off-by:
-
Max Filippov authored
Put chip into sleep state, once it's been awaken. Also, propagate error code to the caller. Signed-off-by:
-
Max Filippov authored
Return whether wakeup operation succeeded. Make use of this return value. Signed-off-by:
-
Max Filippov authored
When SPI write of odd length is requested, p54spi_write splits it into two parts: one for all data, except the last byte, and one for last byte and padding byte. Unfortunately, the length of first part is not amended. It works because all meaningful bytes have proper value and the last byte of odd length SPI write transaction is ignored. p54spi_work has dummy HOST_INTERRUPTS register read at the end. Drop it, as its result is not used and it has no side effects. Signed-off-by:
-
Max Filippov authored
Host is not allowed to modify DMA_WRITE_CTRL register if bit HOST_ALLOWED in it is not set. Wait for HOST_ALLOWED first. Also get rid of timeout in p54spi_wait_bit as it's been playing a role of workaround for such an incorrect register access. Signed-off-by:
-
Julia Lawall authored
Eliminate direct accesses to the driver_data field. cf 82ab13b26f15f49be45f15ccc96bfa0b81dfd015 The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ struct device *dev; expression E; type T; @@ - dev->driver_data = (T)E + dev_set_drvdata(dev, E) @@ struct device *dev; type T; @@ - (T)dev->driver_data + dev_get_drvdata(dev) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
David Kilroy authored
This allows drivers to use a const pointer as the privid without a cast. Signed-off-by:
David Kilroy <kilroyd@gmail.com> Acked-by:
-
David Kilroy authored
This allows drivers to mark their cfg80211_ops tables const. Signed-off-by:
David Kilroy <kilroyd@googlemail.com> Acked-by:
-
Tomas Winkler authored
This patch is one of the incremental steps for unifying iwl_station_entry for all HWs, i.e. removing of iwl3945_station_entry This patch drops iwl3945_tid_data and use iwl_tid_data instead. Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Tomas Winkler authored
This patch replaces struct iwl3945_hw_key by struct iwl_hw_key. It's not used directly with any host command therefore removal is trivial Signed-off-by:
-
Stefano Brivio authored
This removes unnecessary MMIO accesses in the interrupt hotpath. The patch by Michael Buesch for b43 has been ported to b43legacy. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
This patch configures the beacon timers with beacon interval and beacon period passed through vif.bss_conf. Also cache the currecnt beacon configuration which will be used to configure the beacon timers when the driver triggers it after reset. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
-
Johannes Berg authored
We forgot to cancel all timers in mac80211 when suspending. In particular we forgot to deal with some things that can cause hardware reconfiguration -- while it is down. While at it we go ahead and add a warning in ieee80211_sta_work() if its run while the suspend->resume cycle is in effect. This should not happen and if it does it would indicate there is a bug lurking in either mac80211 or mac80211 drivers. With this now wpa_supplicant doesn't blink when I go to suspend and resume where as before there where issues with some timers running during the suspend->resume cycle. This caused a lot of incorrect assumptions and would at times bring back the device in an incoherent, but mostly recoverable, state. Signed-off-by:
-
Johannes Berg authored
The channel switch code is currently in the spectrum management file, where arguably it belongs. However, it is for managed mode only and uses the structures for that mode only so having it in a more generic file can be confusing. Additionally, my next patch gets simpler with the code here. When/if we ever implement this for IBSS or mesh then we will need to rework the structures it uses anyway at which point we could move the code back. Signed-off-by:
-
Jouni Malinen authored
Validate RSC (NL80211_ATTR_KEY_SEQ) length in nl80211/cfg80211 instead of having to do this in all the drivers. Signed-off-by:
-
Jouni Malinen authored
The previous implementation was moving back to NETWORK SLEEP state immediately after receiving a Beacon frame. This means that we are unlikely to receive all the buffered broadcast/multicast frames that would be sent after DTIM Beacon frames. Fix this by parsing the Beacon frame and remaining awake, if needed, to receive the buffered broadcast/multicast frames. The last buffered frame will trigger the move back into NETWORK SLEEP state. If the last broadcast/multicast frame is not received properly (or if the AP fails to send it), the next Beacon frame will work as a backup trigger for returning into NETWORK SLEEP. A new debug type, PS (debug=0x800 module parameter), is added to make it easier to debug potential power save issues in the future. Currently, this is only used for the Beacon frame and buffered broadcast/multicast receiving. Signed-off-by:
-
Jouni Malinen authored
This makes use of the local fc variable in bit more places and uses a common helper macro. The part of RX process that delivers skb's to mac80211 is moved to a separate function in preparation for future changes that will need to do this from two places. The modifications here should not result in any functional changes. Signed-off-by:
-
Jouni Malinen authored
The broadcast bit is in the first, not the last octet.. Signed-off-by:
-
Jouni Malinen authored
While the probe request poll is expected to work, it looks like it does not always result in getting a response. The exact reason for this is unclear, but anyway, if we do receive a Beacon frame from our AP, there is no need to disconnect based on the probereq poll. This seems to help keep the connection bit more stable in cases where beacon loss is occurring semi-frequently. Signed-off-by:
-
Gábor Stefanik authored
According to my tests, all that ZD_CS_MULTICAST does is to disable retrying/waiting for an ACK. Reflect this by renaming the bit to ZD_CS_NO_ACK and setting it based on IEEE80211_TX_CTL_NO_ACK, instead of is_multicast_ether_addr. Signed-off-by:
Gábor Stefanik <netrolller.3d@gmail.com> Signed-off-by:
-
Senthil Balasubramanian authored
The STA may drop the very first frame if it happens to be a retried frame. This is because we maintian the last received sequence number per TID for QoS frames and it is initialized to zero through kzalloc during sta_info_alloc and the sequence number of the very first date frame received would be ZERO (as per IEEE 802.11-2007, 7.1.3.4.1). If the frame dropped happens to be an EAP Request Identity(very first frame from the AP), then wpa_supplicnat disconnects the STA and the whole procedure starts again. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
Here's a screenshot of what this looks like with ath9k: mcgrof@pogo /debug/ieee80211/phy0 $ cat ht40allow_map 2412 HT40 + 2417 HT40 + 2422 HT40 + 2427 HT40 + 2432 HT40 -+ 2437 HT40 -+ 2442 HT40 -+ 2447 HT40 - 2452 HT40 - 2457 HT40 - 2462 HT40 - 2467 Disabled 2472 Disabled 2484 Disabled 5180 HT40 + 5200 HT40 -+ 5220 HT40 -+ 5240 HT40 -+ 5260 HT40 -+ 5280 HT40 -+ 5300 HT40 -+ 5320 HT40 - 5500 HT40 + 5520 HT40 -+ 5540 HT40 -+ 5560 HT40 -+ 5580 HT40 -+ 5600 HT40 -+ 5620 HT40 -+ 5640 HT40 -+ 5660 HT40 -+ 5680 HT40 -+ 5700 HT40 - 5745 HT40 + 5765 HT40 -+ 5785 HT40 -+ 5805 HT40 -+ 5825 HT40 - Signed-off-by:
-
Luis R. Rodriguez authored
This moves the cfg80211 specific stuff to new cfg80211 debugfs entries. Non-mac80211 will also get these entries now. There were only 4 which we take: rts_threshold fragmentation_threshold short_retry_limit long_retry_limit Signed-off-by:
-
Luis R. Rodriguez authored
Thanks to nl80211 userspace can be very specific upon device configuration. Before processing the request for the new HT40 channel types (HT40- or HT40+) we need to ensure we can use them regulatory-wise. This wasn't required with wireless extensions as specifying the channel type wasn't not available and configuration was done towards the end implicitly upon association or reception of beacons from the AP. For the new nl80211 we have to check this when configuring the interfaces explicitly. Signed-off-by:
-
Luis R. Rodriguez authored
We weren't checking this at all. Signed-off-by:
-
Luis R. Rodriguez authored
This is more consistent with our nl80211 naming convention for HT40-/+. Signed-off-by:
-
Luis R. Rodriguez authored
We are not correctly listening to the regulatory max bandwidth settings. To actually make use of it we need to redesign things a bit. This patch does the work for that. We do this to so we can obey to regulatory rules accordingly for use of HT40. We end up dealing with HT40 by having two passes for each channel. The first check will see if a 20 MHz channel fits into the channel's center freq on a given frequency range. We check for a 20 MHz banwidth channel as that is the maximum an individual channel will use, at least for now. The first pass will go ahead and check if the regulatory rule for that given center of frequency allows 40 MHz bandwidths and we use this to determine whether or not the channel supports HT40 or not. So to support HT40 you'll need at a regulatory rule that allows you to use 40 MHz channels but you're channel must also be enabled and support 20 MHz by itself. The second pass is done after we do the regulatory checks over an device's supported channel list. On each channel we'll check if the control channel and the extension both: o exist o are enabled o regulatory allows 40 MHz bandwidth on its frequency range This work allows allows us to idependently check for HT40- and HT40+. Signed-off-by:
-
