- Dec 16, 2010
-
-
Larry Finger authored
Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Dec 14, 2010
-
-
Wolfgang Kufner authored
Commit 6175ddf0 changes the way memcpy_toio() works for x86_64, causing firmware loading to fail for some Ralink WLAN devices with the rt2800pci driver since linux 2.6.34. This causes the log message: "phy0 -> rt2800pci_load_firmware: Error - PBF system register not ready.". Fix this by using __iowrite32_copy instead of memcpy_toio(). Signed-off-by:
Wolfgang Kufner <wolfgang.kufner@gmail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Wolfgang Kufner authored
Pad beacon to a multiple of 32 bits in preparation for the change from memcpy_toio() to __iowrite32_copy() in register_multiwrite(). Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Johannes Stezenbach authored
The stray semicolon after DEBUG_PRINTK_MSG causes things like "if (...) WARNING(...); else {}" to fail with syntax error. Signed-off-by:Johannes Stezenbach <js@sig21.net> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Ivo van Doorn authored
The Queue names were incorrectly copied from the legacy drivers, as a result the queue names were inversed to what was expected. This renames the queues using this mapping: QID_AC_BK -> QID_AC_VO (priority 0) QID_AC_BE -> QID_AC_VI (priority 1) QID_AC_VI -> QID_AC_BE (priority 2) QID_AC_VO -> QID_AC_BK (priority 3) Note that this was a naming problem only, which didn't affect the assignment of frames to their respective queues. Signed-off-by:
-
Ivo van Doorn authored
Add a queue entry flag ENTRY_DATA_STATUS_PENDING, which can be used to indicate a queue entry has returned from the hardware and is waiting for status processing. Using this flag we can add some extra sanity checks to prevent queue corruption. Signed-off-by:
-
Ivo van Doorn authored
Add the rt2x00_dmastart function to rt2x00lib which marks the queue_entry as "owned by device", and increased the Q_INDEX number. This cleanups up the index handling by rt2x00lib which at until so far used hackish approaches to keep the RX queue index numbering sane. The rt2x00pci.c changes are from Helmut Schaa Signed-off-by:
-
Ivo van Doorn authored
Add a new command to the queue handlers: "flush", this moves the flush() callback from mac80211 into rt2x00queue and adds support for flushing the RX queue as well. Signed-off-by:
-
Ivo van Doorn authored
Add wrapper functions in rt2x00queue.c to start & stop queues. This control must be protected using a mutex. Queues can also be paused which will halt the flow of packets between the driver and mac80211. This doesn't require a mutex protection. Signed-off-by:
-
Ivo van Doorn authored
As part of the queue refactoring, change the queue callback function names to have 3 different actions: start, kick & stop. We can now also remove the STATE_RADIO_RX_ON/STATE_RADIO_RX_OFF device_state flags, and replace the usage with using the start_queue/stop_queue callback functions. This streamlines the RX queue handling to the similar approach as all other queues. Signed-off-by:
-
Ivo van Doorn authored
As part of the queue refactoring, we now introduce 3 queue commands: start, kick, stop. - Start: will enable a queue, for TX this will not mean anything, while for beacons and RX this will update the registers to enable the queue. - Kick: This will kick all pending frames to the hardware. This is needed for the TX queue to push all frames to the HW after the queue has been started - Stop: This will stop the queue in the hardware, and cancel any pending work (So this doesn't mean the queue is empty after a stop!). Move all code from the drivers into the appropriate functions, and link those calls to the old rt2x00lib callback functions (we will fix this later when we refactor the queue control inside rt2x00lib). Signed-off-by:
-
Johannes Stezenbach authored
Signed-off-by:
-
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:
-
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:
-
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:
-
RA-Jay Hung authored
Add RF chip definition Signed-off-by:
RA-Jay Hung <jay_hung@ralinktech.com> Signed-off-by:
-
Helmut Schaa authored
Implement the get_survey callback to allow user space to read statistics about the current channel condition. Signed-off-by:
-
RA-Jay Hung authored
Add and modify NIC Configuration and LED definition of EEPROM Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
Reduces the likelihood of false pulse detects in the hardware Signed-off-by:
-
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 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 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 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 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:
-
Sujith Manoharan authored
Signed-off-by:
Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
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 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 authored
Also add a comment about a potential array overrun that needs to be reviewed. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
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 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 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:
-
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:
-
Sujith Manoharan authored
The HW has to be awake when accessing registers. Signed-off-by:
-
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:
-
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: -
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:
-
