- 25 Jan, 2011 3 commits
-
-
Bruno Randolf authored
Remove useless test_bit - it's not going to happen because of the way this function is called only when that bit is set. And fix some whitespace. Signed-off-by:
Bruno Randolf <br1@einfach.org> Acked-by:
Bob Copeland <me@bobcopeland.com> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
We need to read and backup AR_WA register value permanently and reading this after the chip is awakened results in this register being zeroed out. This seems to fix the ASPM with L1 enabled issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. Cc: Stable Kernel <stable@kernel.org> Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Senthil Balasubramanian authored
There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Cc: Stable Kernel <stable@kernel.org> Signed-off-by:
-
- 21 Jan, 2011 27 commits
-
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Bruno Randolf authored
Simplify confusing code and get rid of an unnecessary variable. Signed-off-by:
-
Felix Fietkau authored
When beacons are being added or removed for an interface, ieee80211_beacon_get will sometimes not return a beacon. This is normal and should not result in useless logspam. Signed-off-by:
-
Bruno Randolf authored
Remove sc->curband because the band is already stored in the current channel. Signed-off-by:
-
Bruno Randolf authored
sc->curmode is set but never used. Remove it and the helper function. Also the ath5k_rate_update which is refered to in the comment does not exist (any more?) so we don't need to setup the band in that place. Signed-off-by:
-
Bruno Randolf authored
They are unused in ath5k and a more detailled definition is in ath/regd_common.h. Signed-off-by:
-
Bruno Randolf authored
Add the 802.11j (20MHz channel width) channels to the allowed channels. This still does not enable 802.11j in ath5k since these frequencies are out of the configured range. A later patch will deal with that. Signed-off-by:
-
Bruno Randolf authored
Rename ath5k_copy_channels() to ath5k_setup_channels() - nothing is copied here. Signed-off-by:
-
Bruno Randolf authored
Use mac80211 channel mapping function instead of own homegrown version. Signed-off-by:
-
Ben Greear authored
Try all xmit queues until the hardware buffers are full. Signed-off-by:
Ben Greear <greearb@candelatech.com> Acked-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 10 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:
-
