- 29 8月, 2013 1 次提交
-
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 8月, 2013 1 次提交
-
-
由 John W. Linville 提交于
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c: In function 'ar9003_hw_ant_ctrl_apply': >> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3618: warning: 'regval' is used uninitialized in this function It seems obvious that 'regval' should have been 'value'... Reported-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 8月, 2013 4 次提交
-
-
由 Sujith Manoharan 提交于
Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
There is no need to call ath_txq_unlock_complete() in the TX poll routine - frame completion is not done here, so use ath_txq_unlock(). Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The PCIE Workaround register (AR_WA/0x4004) is used to handle various hardware quirks. For AR9002 chips, AR_WA_D3_L1_DISABLE is used to prevent the HW from automatically entering L1 state when D3 is enforced. AR_WA_D3_L1_DISABLE has to be enabled for a few AR9280 based cards, mark them based on their PCI subdevice/subvendor IDs and enforce it in ar9002_hw_configpcipowersave(). Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
If the L1 entrance latency is not calibrated properly in the EEPROM in WB222 boards, there could be problems in connectivity. Check and correct the calibrated value if it doesn't match the optimal value for WB222, 4us. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 8月, 2013 5 次提交
-
-
由 Sujith Manoharan 提交于
This is a AR9485/WB225 based card. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
This improves RX diversity and performance for AR9485. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The PLL hang workaround is required only for AR9330 and AR9340. This issue was first observed on an AP121 and the WAR is enabled for AR9340 also (DB120 etc.), since it uses a PLL design identical to AR9330. This is not required for AR9485 and AR9550. Various bugs have been reported regarding this: https://bugzilla.redhat.com/show_bug.cgi?id=997217 https://bugzilla.redhat.com/show_bug.cgi?id=994648 Cc: stable@vger.kernel.org Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
ath9k_htc adds padding between the 802.11 header and the payload during TX by moving the header. When handing the frame back to mac80211 for TX status handling the header is not moved back into its original position. This can result in a too small skb headroom when entering ath9k_htc again (due to a soft retransmission for example) causing an skb_under_panic oops. Fix this by moving the 802.11 header back into its original position before returning the frame to mac80211 as other drivers like rt2x00 or ath5k do. Reported-by: NMarc Kleine-Budde <mkl@blackshift.org> Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Tested-by: NMarc Kleine-Budde <mkl@blackshift.org> Signed-off-by: NMarc Kleine-Budde <mkl@blackshift.org> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 21 8月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
brcm80211 cannot handle sending frames with CCK rates as part of an A-MPDU session. Other drivers may have issues too. Set the flag in all drivers that have been tested with CCK rates. This fixes a reported brcmsmac regression introduced in commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 "mac80211/minstrel_ht: fix cck rate sampling" Cc: stable@vger.kernel.org # 3.10 Reported-by: NTom Gundersen <teg@jklm.no> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 8月, 2013 6 次提交
-
-
由 Simon Wunderlich 提交于
CSA is only enabled for one interface, but the same limitation applies for mac80211 too. It checks whether the beacon has been sent (different approaches for non-EDMA-enabled and EDMA-enabled devices), and completes the channel switch after that. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Simon Wunderlich 提交于
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Simon Wunderlich 提交于
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Simon Wunderlich 提交于
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Simon Wunderlich 提交于
To enable support for 5/10 MHz, some internal functions must be converted from using the (old) channel_type to chandef. This is a good chance to change all remaining occurences. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Simon Wunderlich 提交于
5/10 MHz channels should always use SIFS times as defined in IEEE 802.11-2012 18.4.4 (OFDM PHY characteristics). This makes it compatible to ath5k, which does the same. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 8月, 2013 22 次提交
-
-
由 Sujith Manoharan 提交于
Since the rx_fifo queue is accessed only using the various lockless SKB queue routines, there is no need to initialize the lock and __skb_queue_head_init() can be used. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The documentation for antenna diversity says: "The decision of diversity is done at 802.11 preamble. So, for 11G/11B, for every MAC packet hardware will do a decision. But in 11N with aggregation, the decision is made only at the preamble and all other MPDUs will use the same LNA as the first MPDU." Make use of rs_firstaggr to avoid needlessly scanning for LNA changes. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The combined RSSI can be invalid which is indicated by the value -128. Use RX_FLAG_NO_SIGNAL_VAL for such cases. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
In case a descriptor has the "done" bit clear and the next descriptor has it set, we drop both of them. If the packet that is received after these two packets is dropped for some reason, "discard_next" will not cleared. Fix this. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The MIC/PHYERR/CRC error bits are valid only for the last desc. for chained packets. Check this early in the preprocess() routine and bail out. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Make sure that chained descriptors are handled correctly before the packet is parsed to determine if it is a beacon. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Handle chained descriptors and increment the RX counter only for valid packets. Since this is used only by MCI, use CONFIG_ATH9K_BTCOEX_SUPPORT. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The various error bits that ath_debug_stat_rx() checks are valid only for the last descriptor for a chained packet, handle this correctly. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Parse the PHY error details only for the last fragment in case descriptors are chained. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
There is no need to calculate the mactime for chained descriptor packets, so make sure that this is done only for the last fragment of valid packets. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The keymiss events are valid only in the last descriptor of a packet. Fix this by making sure that we return early in case of chained descriptors. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Frames with invalid or zero length can be discarded early, there is no need to check the crypto bits. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Since the DFS code appears to process the phy errors ATH9K_PHYERR_RADAR and ATH9K_PHYERR_FALSE_RADAR_EXT, check for the correct phyerr status in the main RX tasklet routine. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Oleksij Rempel 提交于
If usb auto suspend is enabled or system run in to suspend/resume cycle, ath9k-htc adapter will stop to response. It is reproducible on xhci HCs. Host part of problem: XHCI do timing calculation based on Transfer Type and bInterval, immediately after device was detected. Ath9k-htc try to overwrite this parameters on module probe and some changes in FW, since we do not initiate usb reset from the driver this changes are not took to account. So, before any kind of suspend or reset, host controller will operate with old parameters. Only after suspend/resume and if interface id stay unchanged, new parameters will by applied. Host will send bulk data with no intervals (?), which will cause overflow on FIFO of EP4. Firmware part of problem: By default, ath9k-htc adapters configured with EP3 and EP4 as interrupt endpoints. Current firmware will try to overwrite ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints stay not reconfigured, so under the hood it is still Int EP. This patch is revert of 4a0e8ecc commit which trying to reduce CPU usage on some systems. Since it will produce more bug as fixes, we will need to find other way to fix it. here is comment from kernel source which has some more explanation: * Some buggy high speed devices have bulk endpoints using * maxpacket sizes other than 512. High speed HCDs may not * be able to handle that particular bug, so let's warn... in our case EP3 and EP4 have maxpacket sizes = 64!!! Signed-off-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
If that flag stays set for a buffer that already ran through the tx path once, it might cause issues in tx completion processing. Better clear it early to ensure that this does not happen Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
ath_tid_drain is only called when a station entry is being removed, so there is no point in still tracking BAW state. Remove some unnecessary code and a bogus TODO comment related to this. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
They are not implemented, and accessing them might trigger errors Cc: stable@vger.kernel.org Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-