- 21 Jan, 2011 19 commits
-
-
Bruno Randolf authored
Use mac80211 channel mapping function instead of own homegrown version. Signed-off-by:
Bruno Randolf <br1@einfach.org> Acked-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Try all xmit queues until the hardware buffers are full. Signed-off-by:
Ben Greear <greearb@candelatech.com> Acked-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Ben Greear authored
Add a misc file to show hardware op-mode, irq setup, number of various types of VIFs and more. Also, previous patches were using the wrong xmit queue indexes. Change to use the internal ath9k indexes instead of the mac80211 queue indexes. Signed-off-by:
-
Bruno Randolf authored
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping channel numbers in the 2GHz and 5GHz band we can't map from channel to frequency without knowing the band. This is no problem as in most contexts we know the band. In places where we don't know the band (and WEXT compatibility) we assume the 2GHz band for channels below 14. This patch does not implement all channel to frequency mappings defined in 802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz channels as well as 802.11y channels have been omitted. The following drivers have been updated to reflect the API changes: iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx. The drivers have been compile-tested only. Signed-off-by:
Brian Prodoehl <bprodoehl@gmail.com> Acked-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Ben Greear authored
The system can get into a state where the xmit queue is stopped, but there are no packets pending, so the queue will not be restarted. Add logic to the xmit watchdog to attempt to restart the xmit logic if this situation is detected. Example 'dmesg' output: ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link: f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0 Attempting to restart tx logic. Signed-off-by:
-
Ben Greear authored
To try to figure out why xmit logic hangs. Signed-off-by:
-
Ben Greear authored
The stations hold the ath_node, which holds the tid and other xmit logic structures. In order to debug stuck xmit logic, we need a way to print out the tid state for the stations. Signed-off-by:
-
Ben Greear authored
Show counters for pkts sent directly to hardware and those queued in software. Signed-off-by:
-
Ben Greear authored
If the txq->axq_q is empty, the code was breaking out of the tx_processq logic without checking to see if it should transmit other queued AMPDU frames (txq->axq_acq). This patches ensures ath_txq_schedule is called. This needs review. Signed-off-by:
-
Ben Greear authored
Signed-off-by:
-
Ben Greear authored
Should help debug strange tx lockup type issues. Signed-off-by:
-
Ben Greear authored
Previous code left it NULL. Signed-off-by:
-
Ben Greear authored
I thought this might help track down stuck queues, etc. Signed-off-by:
-
Ben Greear authored
This particular error isn't about multicast. Signed-off-by:
-
Johannes Berg authored
The notification wait support code is shared between 4965 and other AGN devices, so 4965 also has to initialize the data structures for it, otherwise it crashes. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Johannes Berg authored
Signed-off-by:
-
Johannes Berg authored
Previously I hacked this with an msleep(300) which was fine since we never had longer PAN time slots, but now that we will have them I need to fix that. Use the new notification wait support to properly wait for the WIPAN deactivation complete signal from the ucode. Signed-off-by:
-
Johannes Berg authored
In order to implement waiting for notifications, add a structure that captures the information, and a list of such structures that will be traversed when a command is received from the ucode. Use sparse checking to make sure calls to the prepare/wait/cancel functions are always nested correctly. Signed-off-by:
-
Johannes Berg authored
It's not used or likely to be needed from other files, so it can be static. Signed-off-by:
-
- 19 Jan, 2011 21 commits
-
-
Felix Fietkau authored
When running as a 4-addr station against an AP that has the 4-addr VLAN interface and the main 3-addr AP interface bridged together, sometimes frames originating from the station were looping back from the 3-addr AP interface, causing the bridge code to emit warnings about receiving frames with its own source address. I'm not sure why this is happening yet, but I think it's a good idea to drop all frames (except 802.1x/EAP frames) that do not match the configured addressing mode, including 4-address frames sent to a 3-address station. User test reports indicate that the problem goes away with this patch. Signed-off-by:
-
Johannes Berg authored
Currently, mac80211 always advertises that it may send up to 64 subframes in an aggregate. This is fine, since it's the max, but might as well be set to zero instead since it doesn't have any information. However, drivers might have that information, so allow them to set a variable giving it, which will then be used. The default of zero will be fine since to the peer that means we don't know and it will just use its own limit for the buffer size. Signed-off-by:
-
Johannes Berg authored
The aggregation code currently doesn't implement the buffer size negotiation. It will always request a max buffer size (which is fine, if a little pointless, as the mac80211 code doesn't know and might just use 0 instead), but if the peer requests a smaller size it isn't possible to honour this request. In order to fix this, look at the buffer size in the addBA response frame, keep track of it and pass it to the driver in the ampdu_action callback when called with the IEEE80211_AMPDU_TX_OPERATIONAL action. That way the driver can limit the number of subframes in aggregates appropriately. Note that this doesn't fix any drivers apart from the addition of the new argument -- they all need to be updated separately to use this variable! Signed-off-by:
-
Johannes Berg authored
When mesh is disabled, mac80211 was returning beacons with an empty mesh ID. That isn't desirable, even if drivers shouldn't be trying to get beacons to start with. Signed-off-by:
-
Ben Greear authored
When using a mixture of AP and Station interfaces, the hardware mode was using the type of the last VIF registered. Instead, we should keep track of the number of different types of vifs and set the mode accordingly. In addtion, use the vif type instead of hardware opmode when dealing with beacons. Attempt to move some of the common setup code into smaller methods so we can re-use it when changing vif mode as well as adding/deleting vifs. Signed-off-by:
-
Felix Fietkau authored
Because the sendbar variable was not reset to zero, the stack would send Block ACK requests for all subframes following the one that failed, which could mess up the receiver side block ack window. Signed-off-by:
-
Felix Fietkau authored
Sometimes the first TID in the first AC's list is not available for forming a new aggregate (the BAW might not allow it), however other TIDs may have data available for sending. Prevent a slowdown of other TIDs by going through multiple entries until we've either hit the last one or enough AMPDUs are pending in the hardware queue. Signed-off-by:
-
Rajkumar Manoharan authored
AR9285 carrier leakage calibration related workaround on high temperature is not applicable for AR9271. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Rajkumar Manoharan authored
The ath9k_hw assumes that caldata is valid only for oper channel. But with ath9k_htc case, the caldata is passed for all channels on hw_reset though we are not doing calibration on that channel. So the oper channel's nf history got cleared to default due to mismatch in channel flags. This patch also saves some space. Signed-off-by:
-
Rajkumar Manoharan authored
caldata's channel info is never filled with operating channel info which is causing the operating channel's noise floor history buffer is reset to default nf during channel change. Signed-off-by:
-
Ben Greear authored
Signed-off-by:
-
Wey-Yi Guy authored
mppath is mesh related parameter and maybe unused Signed-off-by:
-
Felix Fietkau authored
The rx error bit parsing was changed to consider PHY errors and various decryption errors separately. While correct according to the documentation, this is causing spurious decryption error reports in some situations. Fix this by restoring the original order of the checks in those places, where the errors are meant to be mutually exclusive. If a CRC error is reported, then MIC failure and decryption errors are irrelevant, and a PHY error is unlikely. Signed-off-by:
-
Luciano Coelho authored
Some devices don't support the maximum AMDPU buffer size of 64, so we need to add an option to configure this in the hardware configuration. This value will be used in the ADDBA response instead of the value suggested in the request, if the latter is greater than the max supported. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by:
-
Nick Ledovskikh authored
Replace MESH_WORK_GROW_MPATH_TABLE by MESH_WORK_GROW_MPP_TABLE in mesh_mpp_table_grow call condition. (Clearly the original was a typo... -- JWL) Signed-off-by:
Nickolay Ledovskikh <nledovskikh@gmail.com> Signed-off-by:
-
Wojciech Dubowik authored
Eeprom read functions are of bool type and not int. Signed-off-by:
Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by:
-
Felix Fietkau authored
Since baseband hangs are rare, but the hang check function has a high false positive rate in some situations, we need to add more reliable indicators. In AP mode we can use blocked beacon transmissions as an indicator, they should be rare enough. In station mode, we can skip the hang check entirely, since a true hang will trigger beacon loss detection, and mac80211 will rescan, which leads to a hw reset that will bring the hardware back to life. To make this more reliable, we need to skip fast channel changes if the hardware appears to be stuck. Signed-off-by:
-
Felix Fietkau authored
There might be some old stale data left, which could confuse tracking of pending tx frames. Signed-off-by:
-
Felix Fietkau authored
txtid->seq_start may not always be up to date, when there is HT non-AMPDU traffic just before starting an AMPDU session. Relying on txtid->seq_next is better, since it is also used to generate the sequence numbers for all QoS data frames. Signed-off-by:
-
Felix Fietkau authored
When a tid pointer is passed to ath_tx_send_normal(), it increases the starting sequence number for the next AMPDU action frame, which should only be done if the sequence number assignment is fresh. In this case it is clearly not. Signed-off-by:
-
RA-Jay Hung authored
Basically fix and fine-tune RT3070/RT3071/RT3090 chip RF initial value when call rt2800_init_rfcsr 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:
-
