- 19 Jan, 2010 16 commits
-
-
Johannes Berg authored
When mac80211 asks a driver to encrypt a frame, it must assign the control.hw_key pointer for it to know which key to use etc. Currently, mac80211 does this whenever it would software-encrypt a frame. Change the logic of this code to assign the hw_key pointer when selecting the key, and later check it when deciding whether to encrypt the frame or let it be encrypted by the hardware. This allows us to later simply skip the encryption function since it no longer modifies the TX control. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
There's no value in setting a flag that will never be checked after this point, this seems to be legacy code -- I think previously the flag was used to check whether to encrypt the frame or not. Now, however, the flag need not be set, and setting it actually interferes if the frame will be processed again later. Signed-off-by:
-
Johannes Berg authored
When an skb survived a round-trip through the driver and needs to be re-used, its control information is definitely not valid any more, the driver will have overwritten it. Signed-off-by:
-
Johannes Berg authored
This TX handler is used only for assigning the station pointer in the control information, so give it a better name. Also move it before rate control. Signed-off-by:
-
Bob Copeland authored
Code directly scaling by HZ and rounding can be more efficiently and clearly performed with msecs_to_jiffies. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Reinette Chatre authored
Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
When reading current ucode statistics information from debugfs, in current implementation, it will always send a new "statistics request" to uCode. In normal operation, uCode should report the statistics per beacon interval. Remove this extra request to reduce the additional command exchanges between driver and uCode. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
Flowhandler handle the communication between driver and uCode, when any uCode error happen, we also like to know what is the status of the flowhandler; it can help to debug flowhandler related problem. Also adding debugfs file to dump current value of flowhandler registers. Signed-off-by:
-
Wey-Yi Guy authored
This is a w/a for a hardware bug. the h/w bug may cause the Rx bit (bit 15 before shifting it to 31) to clear when using interrupt coalescing. This does not mean frames are lost - their processing is just delayed until next interrupt arrives. Signed-off-by:
-
Wey-Yi Guy authored
For interrupt coalescing timer, the CSR_INT_COALESCING is an 8 bit register in 32-usec unit, the range can go from 0x00 - 0xFF. set the range and default timeout value for both calibration mode and operation mode. Signed-off-by:
-
Wey-Yi Guy authored
When dumping event log in debugfs, iwl_dump_nic_event_log() should return the correct error code instead of let the calling function makes it own assumption. Signed-off-by:
-
Wey-Yi Guy authored
When uCode detects number of beacon missed consecutively above the internal missed beacon threshold (set by uCode), it will reset and re-tune the radio in order to get out of bad PHY state. This "num_of_sos_states" counter monitors number of time uCode encounters this bad condition and has to re-tune the radio. Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
To help debug uCode related problem, adding "delta" and "max" information in debugfs statistics counters display. Those information show the delta between two statistics report from uCode, user can monitor the counters for any "un-normal" behavior. Signed-off-by:
-
Wey-Yi Guy authored
When receive reply statistics command with "clear" mask, just reset the accumulated statistics counters, but not the current statistics counters, so the accumulated statistics counter can provide the correct information. Signed-off-by:
-
Felix Fietkau authored
The WMM AC selection added to the monitor mode selection function accidentally assigns non-QoS data frames to the same AC as mgmt frames (VO). This is not serious, but should be fixed anyway. This patch assigns them to the BE AC instead. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
-
- 18 Jan, 2010 5 commits
-
-
Hin-Tak Leung authored
Yasuhiro ABE <yadiary@gmail.com> reported success in sourceforge zd1211-dev list. The device is a NEC Aterm WL54GU usb wireless stick. The brand and retail product name NEC, Aterm PA-WL54GU The USB ID's (duh) ID 0409:0248 The chip ID string zd1211rw 1-1:1.0: zd1211b chip 0409:0248 v4810 high 00-1b-8b AL2230S_RF pa0 g--N- The FCC ID unknown Signed-off-by:Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
Yasuhiro ABE <yadiary@gmail.com> Signed-off-by:
-
Christian Lamparter authored
A long time ago, a user reported several crashes due to data corruptions which are likely the result of a not-100%-supported, or faulty? PCI bridge. ( http://patchwork.kernel.org/patch/53004/ ) This patch fixes entry #1. "1. p54p_check_rx_ring - skb_over_panic: Under a ping flood or just left running for a bit would panic with a skb_over_panic." As described in the mail: The invalid frame length causes skb_put to bailout and trigger a crash. Note: Simply dropping the frame is problematic, because if its content contains a tx feedback we would lose some portion of the device memory space.... And the driver/mac80211 should handle all other invalid data. Reported-by:
Quintin Pitts <geek4linux@gmail.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Bob Copeland authored
While testing the pid rate controller in mac80211_hwsim, I noticed that once the controller reached 54 Mbit rates, it would fail to lower the rate when necessary. The debug log shows: 1945 186786 pf_sample 50 3534 3577 50 My interpretation is that the fixed point scaling of the target error value (pf) is incorrect: the error value of 50 compared to a target of 14 case should result in a scaling value of (14-50) = -36 * 256 or -9216, but instead it is (14 * 256)-50, or 3534. Correct this by doing fixed point scaling after subtraction. Signed-off-by:
Stefano Brivio <stefano.brivio@polimi.it> Acked-by:
Mattias Nissler <mattias.nissler@gmx.de> Signed-off-by:
-
Reinette Chatre authored
Signed-off-by:
-
Wey-Yi Guy authored
Similar to 6000 and 1000 series, RTS/CTS is the recommended protection mechanism for 5000 series in HT mode based on the HW design. Using RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment, it also prevent uCode encounter TX FIFO underrun and other HT mode related performance issues. Signed-off-by:
-
- 15 Jan, 2010 19 commits
-
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>a Signed-off-by: -
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>` Signed-off-by: -
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
