- 13 Dec, 2010 40 commits
-
-
Johannes Stezenbach authored
Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Commit 02044643 "Check for specific changed flags when updating the erp config" changed the way in which a new beacon interval gets handled. However, due to a bug in rt2800usb and rt2800pci the beacon interval was reset during each scan, thus causing problems in AdHoc mode. Fix this by not cleaning up the beacon interval when killing the beacon queue but just prevent the device from sending out beacons. Reported-by: Wolfgang Kufner <wolfgang.kufner@gmail.com> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
Recent changes to the TX-done code of rt2x00 resulted in TX-ed frames not being returned to mac80211 in the original state, and therefore with insufficient headroom for re-transmissions. Fix this by reverting the changes done and by ensuring we remove the inserted L2pad by moving the header backwards instead of the data forwards. At the same time also make sure that the rt2x00queue_remove_l2pad will not move any memory when a frame has no data at all. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Jay Hung <Jay_Hung@ralinktech.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Stezenbach authored
When an rt2x00 USB device is unplugged while in use, it reliably hangs the whole system. After some time the watchdog prints: BUG: soft lockup - CPU#0 stuck for 64s! [kworker/u:0:5] ... [<c01a88d8>] (usb_submit_urb+0x0/0x2ac) from [<bf0e752c>] (rt2x00usb_kick_rx_entry+0xb4/0xe8 [rt2x00usb]) [<bf0e7478>] (rt2x00usb_kick_rx_entry+0x0/0xe8 [rt2x00usb]) from [<bf0e7588>] (rt2x00usb_clear_entry+x28/0x2c [rt2x00usb]) [<bf0e7560>] (rt2x00usb_clear_entry+0x0/0x2c [rt2x00usb]) from [<bf0d5bc4>] (rt2x00lib_rxdone+0x2e0/0x2f8 [rt2x00lib]) [<bf0d58e4>] (rt2x00lib_rxdone+0x0/0x2f8 [rt2x00lib]) from [<bf0e7e00>] (rt2x00usb_work_rxdone+0x54/0x74 [rt2x00usb]) [<bf0e7dac>] (rt2x00usb_work_rxdone+0x0/0x74 [rt2x00usb]) from [<c00542b4>] (process_one_work+0x20c/0x35c) Clear the DEVICE_STATE_PRESENT flag when usb_submit_urb() returns -ENODEV to fix this. Signed-off-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
RA-Jay Hung authored
Add RF chip definition Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Implement the get_survey callback to allow user space to read statistics about the current channel condition. 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>
-
RA-Jay Hung authored
Add and modify NIC Configuration and LED definition of EEPROM Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Reduces the likelihood of false pulse detects in the hardware Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The EEPROM contains scale factors for the tx power, which define the range of allowable difference between target power and training power. If the difference is too big, PA predistortion cannot be used. For 2.4 GHz there is only one scale factor, for 5 GHz there are three, depending on the specific frequency range. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The EEPROM PAPRD rate mask fields only contain mask values for actual rates in the low 25 bits. The upper bits are reserved for tx power scale values. Add the proper mask definitions and use them before writing the values to the register. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
To be able to measure the thermal values correctly for PAPRD, we need to send training frames before setting up the gain table for the measurement, and then again afterwards for the actual training. For further improvement, send training frames at MCS0 instead of 54 MBit/s legacy. That way we can use the No-ACK flag for the transmission, which speeds up PAPRD training in general, as the hardware won't have to retransmit and wait for ACK timeout (was previously set to 4 * 6 transmission attempts). Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Testing shows that adjusting the slot time based on the coverage class produces very high latencies and very low throughput on long distance links. Adjusting only the ACK timeout and leaving the slot time at the regular values - while technically not optimal for CSMA - works a lot better on long links (tested with 10 km distance) Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
(u32) -1 is not particularly useful as a slottime default, so even though the ath9k_hw default should never get used, it's better to pick something sane here. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
There's no need to have separate callbacks for pre-AR9003 vs AR9003 SREV version checks, so just merge those into one function. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
AR9280 based hardware with 3 antennas and slow antenna diversity has not been seen in the wild and ath9k does not support that form of antenna diversity, so remove the EEPROM ops for it. These EEPROM ops are currently only used for setting the AR_PHY_SWITCH_COM register, which is being done in the EEPROM specific file already. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Also add a comment about a potential array overrun that needs to be reviewed. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
AR*_MAX_RATE_POWER => MAX_RATE_POWER AR*_EEPROM_MODAL_SPURS => AR_EEPROM_MODAL_SPURS AR*_OPFLAGS_* => AR5416_OPFLAGS_* ... Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Newer chips do not need this, and maybe these register writes could have negative side effects on newer hardware. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
wireless-testing commit 04caf863 ('ath9k: more tx setup cleanups') merged tx path code for HT vs non-HT frames, however it did not pass the tid pointer to ath_tx_send_normal, causing an inconsistency between AMPDU vs non-AMPDU sequence number handling. Fix this by always passing in the tid pointer for all QoS data frames. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When software crypto is used, mac80211 will support IBSS RSN, it doesn't depend on the driver in that case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
The HW has to be awake when accessing registers. Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
WMM IE QoS Info field lower 4 bits: Parameter Set Count Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tim Harvey authored
The 802.11 spec states that the STA that generated the last Beacon frame shall be the STA that response to a probe request. This is important for congestion reduction when a probe request is received - only 1 node in an adhoc BSS will transmit a response. While mac80211 drivers should provide the tx_last_beacon function to report if they transmitted the last beacon many do not. As an attempt to reduce probe response congestion default this to 0 such that a node not implementing this capability does not contribute to unnecessary congestion. In a modern medium sized office environment I see upwards of 100 probe requests per second received at a given node from various hardware/OS/drivers doing zeroconf 'active probing' as opposed to passively listening for beacons. With a modest 10-node adhoc network consisting of drivers that do not implement this tx_last_beacon feature, I have seen this result in the simultaneous xmit of probe responses accumulating to 500 probe responses per second because of collisions which brings the adhoc network to its knees as well as causes needless congestion. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
As discussed we do not know band width at core reset time and it is not a good idea to reset whole just to change band. So just set unconditionally 20 MHz band width as default during core reset. As for defines PHY clock changed to band width in specs and it makes much more sens to call defines by band width which is self-explainable. Updated specs do not mention 0 value, but comparing to old ones you can notice lineral relation between PHY clock speed and band width. So it makes sense for 0x0 value to be 10 MHz band width. 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
I missed that part in previous reordering. 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>
-
Johannes Berg authored
Add support for split default keys (unicast and multicast) in mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Allow userspace to specify that a given key is default only for unicast and/or multicast transmissions. Only WEP keys are for both, WPA/RSN keys set here are GTKs for multicast only. For more future flexibility, allow to specify all combiations. Wireless extensions can only set both so use nl80211; WEP keys (connect keys) must be set as default for both (but 802.1X WEP is still possible). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Using the default key for "any key set" isn't quite what we should do. It works, but with the upcoming changes it makes life unnecessarily complex, so do something better here and really check for "any key". Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
The registers TBTT_TIMER ,DMA_BEACON_ALERT ,NEXT_SWBA are need to be configured only for AP and IBSS mode. SWBA register is used for generating software interrupts so that beacon frames will be created by the software.DMA beacon alert register is to indicate the hardware to DMA the contents of beacon buffer to PCU buffer and TBTT to start transmitting the packet buffer to the base band. Clearly these things are not needed for station/monitor mode so remove configuring them. Cc: doug dahlby <ddahlby@atheros.com> Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sven Neumann authored
When a cached BSS struct is updated because a new beacon was received, the code replaces the cached information elements by the IEs from the new beacon. However it did not update the pub.information_elements and pub.len_information_elements fields leaving them either pointing to the old beacon IEs or in an inconsistent state where the data is replaced by the new beacon IEs but len_information_elements still has its value from the first beacon. Fix this by updating the information elements fields if they are pointing to beacon IEs. Signed-off-by: Sven Neumann <s.neumann@raumfeld.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set. But is not cleared on key cache reset. Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
Add support to change interface type without bringing down the interface. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Add a field to wiphy for the hardware to report the availble antennas for configuration. Only if this is set to something bigger than zero, will the anntenna configuration ops be executed. Allthough this could be a simple number of antennas, I defined it as a bitmap of antennas which are available for configuration, since it's more consistent with the rest of the antenna API and there could be cases where the hardware allows only configuration of certain antennas. As it does not make much of a difference in size or normal usage, I think it's better to be able to support this, in case the need arises. The antenna configuration is now also checked against the availabe antennas and rejected if it does not match. Signed-off-by: Bruno Randolf <br1@einfach.org> -- v3: always apply available antenna mask (for "all" antennas case). v2: reject antenna configurations which don't match the available antennas Signed-off-by: John W. Linville <linville@tuxdriver.com>
-