- 13 Oct, 2010 4 commits
-
-
Johannes Berg authored
Drivers may need to adjust their filters according to frame registrations, so notify them about them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
This fix updates the documenation in Rate Control Table structure Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
This automatically keeps things proper when wiphy is renamed. Based on patch by Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gerrit Renker authored
wext: fix alignment problem in serializing 'struct iw_point' This fixes a typo in the definition of the serialized length of struct iw_point: a) wireless.h is exported to userspace, the typo causes IW_EV_POINT_PK_LEN to be 12 on 64-bit, and 8 on 32-bit systems (causing misalignment); b) in compat-64 mode iwe_stream_add_point() memcpys overlap (see below). The second case in in compat-64 mode looks like (variable names are as in include/net/iw_handler.h:iwe_stream_add_point()): point_len = IW_EV_COMPAT_POINT_LEN = 8 lcp_len = IW_EV_COMPAT_LCP_LEN = 4 2nd memcpy: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8 IW_EV_LCP_PK_LEN <--------------> *---> 'extra' data area +-------+-------+-------+-------+---------------+------- ...-+ | len | cmd |length | flags | (empty) -> extra ... | +-------+-------+-------+-------+---------------+------- ...-+ 2 2 2 2 4 lcp_len <--------------> <-!! OVERLAP !!> <--1st memcpy--><------- 2nd memcpy -----------> <---- 3rd memcpy ------- ... > <--------- point_len ----------> This case could cause overrun whenever iw_point.length < 4. The other two cases are - * 32-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 8 - 4 = 4, the second memcpy copies exactly the 4 required bytes; * 64-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8, the second memcpy copies a superfluous (but non overlapping) 4 bytes. The patch changes IW_EV_POINT_PK_LEN to be 8, so that in all 3 cases always only the requested iw_point.{length,flags} (both __u16) are copied, avoiding overrrun (compat-64) and superfluous copy (64-bit). In addition, the userspace header is sanitized (in agreement with version 30 of the wireless tools). Many thanks to Johannes Berg for help and review with this patch. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 12 Oct, 2010 6 commits
-
-
Joe Perches authored
Also improve ath_opmode_to_string usage by having it return UNKNOWN rather than NULL in the event of failure to map the opmode value to a representative string. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
The index cannot be used to reliably reconstruct a phy name, so explicitly add the phy name to sysfs so that scripts can figure out the parent phy device for a particular wireless interface. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
-
Johannes Berg authored
commit 6f98613258b966ffe0e6def18129b386514d10e0 Author: Jay Sternberg <jay.e.sternberg@intel.com> Date: Sat Sep 18 09:07:04 2010 -0700 iwlagn: reduce redundant parameter definitions broke 3945 because Jay accidentally removed the num_of_queues parameter for 3945, so that we now attempt to allocate a zero-sized queue array, which leads to SLUB returning ZERO_SIZE_PTR (0x10) which we then try to dereference thus crashing the system. Restore the necessary num_of_queues param. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2254Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
For WiFi/BT combo devices, priority table always need to download before perform any calibration operation. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
For advance BT/WiFi co-exist, always download bt priority table before sending bt_config command Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 11 Oct, 2010 30 commits
-
-
Ivo van Doorn authored
kill_urb guarentees that when the function returns, the URB has been fully killed. This means we don't need the extra sleeping after the call to kill_urb. kill_urb can however also guarentee the submit_urb to fail, as a result, we must catch the return value from submit_urb an correctly mark the entry as owned by the driver, and the status as broken. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
The currently used watchdog functions cannot be applied to empty queues. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
All access to the queue_entry->flags can be done concurrently, so all flags must use the atomic operators. On most locations this was already done, so just fix the last few non-atomic versions. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
When the RX skb allocation failed, we should recycle the previously allocated skbuffer. By calling return we would kill the RX queue completely since the entry would be invalidated. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
Similar to the PLCP signal and bitrates values, we should validate the MCS value from the RX descriptor before sending it to mac80211. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
The watchdog function must run on a work_queue which is independent of any other work inside rt2x00. The main reasons, being that a broken work on the mac80211 work_queue can otherwise prevent the watchdog to run (while in fact the watchdog could fix the issue). And on the other hand because the watchdog relies on the completion of the completion handlers for RX/TX which for the USB case, occur on the mac80211 workqueue. This fixes some "Queue %d failed to flush" errors, which were caused by the watchdog function waiting on the completion handler which was scheduled to run right after the watchdog. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
A lot of functions accept a struct rt2x00_dev combined with either a struct queue_entry or struct data_queue argument. This can be simplified by only passing on the queue/entry argument. In cases where rt2x00_dev and a sk_buff are send together, we can send the queue_entry instead. rt2x00usb_alloc_urb and rt2x00usb_free_urb have a bit of vague naming. Instead they allocate all the data which belongs to a rt2x00 data queue entry. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jiri Slaby authored
Stanse found that urb cannot be NULL in at76_rx_tasklet because it is dereferenced earlier, so remove the unneeded check. Signed-off-by: Jiri Slaby <jslaby@suse.cz> 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>
-
Björn Smedman authored
This patch attempts to ensure that ath9k's built-in rate control algorithm does not rely on the value of the ampdu_len and ampdu_ack_len tx status fields unless the IEEE80211_TX_STAT_AMPDU flag is set. This patch has not been tested. Cc: <stable@kernel.org> Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Björn Smedman authored
This patch fixes the following problems with the rate control feedback generated by ath9k for A-MPDU frames: 1. Rate control feedback is carried on the first frame of an aggregate that is either ACKed, or has execeeded the software retry count and is considered failed. However, ath9k would incorrectly assume the aggregate had the length 1 if one of these conditions did not apply to the first frame of the aggregate, but instead a later frame. This fix therefor copies the bf_nframes field of the buffer in the same manner as the rates field of the tx status. 2. Sometimes the ampdu_len and ampdu_ack_len fields of the tx status was left uninitialized eventhough the IEEE80211_TX_STAT_AMPDU flag was set. This is now avoid by setting flag and fields in the same place. 3. Even if a frame has been selected for aggregation by mac80211 and marked with the IEEE80211_TX_CTL_AMPDU flag it can sometimes happen that ath9k transmits the frame without aggregation. In these cases the ampdu_ack_len field could be incorrectly computed because the nbad parameter to ath_tx_rc_status was incorrect. Cc: <stable@kernel.org> Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Björn Smedman authored
This patch fixes two problems with the minstrel_ht rate control algorithms handling of A-MPDU frames: 1. The ampdu_len field of the tx status is not always initialized for non-HT frames (and it would probably be unreasonable to require all drivers to do so). This could cause rate control statistics to be corrupted. We now trust the ampdu_len and ampdu_ack_len fields only when the frame is marked with the IEEE80211_TX_STAT_AMPDU flag. 2. Successful transmission attempts where only recognized when the A-MPDU subframe carrying the rate control status information was marked with the IEEE80211_TX_STAT_ACK flag. If this information happed to be carried on a frame that failed to be ACKed then the other subframes (which may have succeeded) where not correctly registered. We now update rate control statistics regardless of whether the subframe carrying the information was ACKed or not. Cc: <stable@kernel.org> Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Since this small buffer isn't used for DMA, we can simply allocate it on the stack, it just needs to be 16 bytes of which only 8 will be used for WEP40 keys. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
wl1251 is grown up now and can have its own room^H^H^H^Hdirectory. Signed-off-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
wl1271 driver is under heavy development but on the other hand the older wl1251 driver is currently considered more as a legacy driver. To make it easier to develop wl1271 features move wl1251 to it's own directory, drivers/net/wireless/wl1251. There are no functional changes, only moving of files. One regression is that Kconfig won't be updated automatically and user needs to enable wl1251 manually with an older config file. Signed-off-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
In preparation of moving wl1251 out from drivers/net/wireless/wl12xx create a separate copy of wl12xx_80211.h. This file should not even exist, we should instead use generic ieee80211 definitions. This will be fixed in the future so that the file can be removed. Signed-off-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
In the past, carl9170 has been plagued by mysterious ghosts. e.g.: wlan4: deauthenticated from 02:04:d8:3c:ac:c1 (Reason: 0) Apparently, the AP sent us a bogus deauthentication notification. But upon closer inspection the "management frame" turned out to be a corrupted scrap of an unsuccessful A-MPDU. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
The total/fatal error bit was erroneously prefixed with AR9170_RX_ERROR instead of AR9170_RX_STATUS. Luckily, the hardware specification confirmed that the 0x80 flag will never be set for mac->error. So, it was always just a dead branch. This patch also imports the latest version of shared wlan.h header from the firmware git. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch replaces several identical frame drop paths with a single shared rx frame error handler. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
The patches "rt2x00: Improve TX status entry validation" and "rt2x00: rework tx status handling in rt2800pci" together were causing problems with tx status processing in rt2800pci: phy1 -> rt2800pci_txdone: Warning - Got TX status for an empty queue 3, dropping phy1 -> rt2800pci_txdone: Warning - Got TX status for an unavailable queue 7, dropping Fix this by using the correct field definition for getting the QID out of the tx status report. Reported-by: Luis Correia <luis.f.correia@gmail.com> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Tested-by: Luis Correia <luis.f.correia@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
There is no need to initialize qidx to zero as it will ever be overwritten by the correct value. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
This is an error condition that is not supposed to happen. Hence, it is safe to add unlikely to this check. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Since no skb will be mapped for RX and TX at the same time we can simply shortcut the check for SKBDESC_DMA_MAPPED_TX. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Steve deRosier authored
This patch updates IEEE802.11 mesh constants to be consistent with newly approved values. It modifies some values, as well as adds many new constants in preparation for updating mesh code to the current 802.11s drafts. ANA numbers were taken from: https://mentor.ieee.org/802.11/dcn/09/11-09-0031-12-0000-ana-database-assigned-number-authority.xls A few notes are in order: 1. This will break backwards compatibility with existing Linux kernels as over-the-air constants have changed. 2. Some old and obsolete constants have been retained for now as the mesh code itself hasn't been updated yet to the new 802.11s draft. This was desired to keep the existing mesh scheme working until it can be updated. Adding the approved values is the first step in updating the mesh code. 3. Obsolete constants have been clearly marked. 4. All ANA approved 802.11s constants have been added. Signed-off-by: Steve deRosier <steve@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Results for the active channel are updated whenever a new survey dump is requested, the old data is kept to allow multiple processes to make their own channel utilization averages. All other channels only contain the data for the last time that the hardware was on the channel, i.e. the last scan result or other off-channel activity. Running a background scan does not clear the data for the active channel. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-