summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-07-25ath10k: handle attention flags correctly when using A-MSDUJanusz Dziedzic
In case of A-MSDU RX we should check attention flags correctly to be sure we report correct FCS status for A-MSDU subframes. Without a patch we could report A-MSDU subframes with wrong FCS as a correct to the stack, next get a lot of DUP ACK TCP packets. Finally TP drop is seen and this drop depends on FCS errors ratio for A-MSDU frame. Example test case when TP drop is seen: - ath10k configured as an AP - used ath10k station - forced A-MSDU (7 frames) on STA - other traffic on channel (often FCS errors) - monitor iface added on AP - TCP STA -> AP traffic (iperf) a) Iperf logs for case without the patch: echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 56.6 MBytes 95.0 Mbits/sec [ 3] 5.0-10.0 sec 60.4 MBytes 101 Mbits/sec [ 3] 10.0-15.0 sec 60.2 MBytes 101 Mbits/sec [ 3] 15.0-20.0 sec 60.2 MBytes 101 Mbits/sec [ 3] 20.0-25.0 sec 63.8 MBytes 107 Mbits/sec [ 3] 25.0-30.0 sec 64.9 MBytes 109 Mbits/sec echo "7 64" > htt_max_amsdu_ampdu // set 7 A-MSDU subframes [ 3] 30.0-35.0 sec 40.0 MBytes 67.1 Mbits/sec [ 3] 35.0-40.0 sec 35.9 MBytes 60.2 Mbits/sec [ 3] 40.0-45.0 sec 36.9 MBytes 61.9 Mbits/sec [ 3] 45.0-50.0 sec 37.9 MBytes 63.5 Mbits/sec [ 3] 50.0-55.0 sec 34.5 MBytes 57.9 Mbits/sec [ 3] 55.0-60.0 sec 25.4 MBytes 42.6 Mbits/sec [ 3] 60.0-65.0 sec 48.2 MBytes 81.0 Mbits/sec [ 3] 65.0-70.0 sec 28.8 MBytes 48.2 Mbits/sec [ 3] 70.0-75.0 sec 29.2 MBytes 49.1 Mbits/sec [ 3] 75.0-80.0 sec 22.9 MBytes 38.4 Mbits/sec [ 3] 80.0-85.0 sec 26.4 MBytes 44.2 Mbits/sec [ 3] 85.0-90.0 sec 31.5 MBytes 52.8 Mbits/sec b) Iperf logs for case with patch: echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU [ 3] local 192.168.12.2 port 57512 connected with 192.168.12.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 60.8 MBytes 102 Mbits/sec [ 3] 5.0-10.0 sec 62.2 MBytes 104 Mbits/sec [ 3] 10.0-15.0 sec 60.9 MBytes 102 Mbits/sec echo "7 64" > htt_max_amsdu_ampdu // set 7 A-MSDU subframes [ 3] 15.0-20.0 sec 68.1 MBytes 114 Mbits/sec [ 3] 20.0-25.0 sec 80.5 MBytes 135 Mbits/sec [ 3] 25.0-30.0 sec 83.0 MBytes 139 Mbits/sec [ 3] 30.0-35.0 sec 79.1 MBytes 133 Mbits/sec [ 3] 35.0-40.0 sec 77.1 MBytes 129 Mbits/sec [ 3] 40.0-45.0 sec 77.4 MBytes 130 Mbits/sec Reported-by: Denton Gentry <denton.gentry@gmail.com> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-25ath10k: don't advertise IBSS iftype for 10.xMichal Kazior
The 10.x firmware does not support IBSS mode at all. It can't beacon and it crashes when trying to scan. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-25ath10k: fix Rx aggregation reorderingMichal Kazior
Firmware doesn't perform Rx reordering so it is left to the host driver to do that. Use mac80211 to perform reordering instead of re-inventing the wheel. This fixes TCP throughput issues in some environments. Reported-by: Denton Gentry <denton.gentry@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-24Merge remote-tracking branch 'wireless-next/master' into ath-nextKalle Valo
2014-07-23b43: enable 5 GHz support for N-PHY devicesRafał Miłecki
This has been tested on 14e4:4328 (BCM4321), 14e4:432b (BCM4322), 14e4:4353 (BCM43224) and 14e4:4359 (BCM43228) which is an almost complete list of 5 GHz capable device (only BCM43222 is missing). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: register limited amount of 5G channels for BCM43228Rafał Miłecki
We don't have all needed channel tables due to RE process for this device. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: N-PHY: don't calculate values for TSSI if we can't transmitRafał Miłecki
This process requires sending some sample tone, so make sure we're allowed to transmit first. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: report correct rate to mac80211 for 5 GHz packetsRafał Miłecki
So far we were assuming only A-PHY supports 5 GHz. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23mac80211_hwsim: fix compiler warning on MIPSAndrew Bresticker
The dividend in do_div() is expected to be an unsigned 64-bit integer, which leads to the following warning when building for 32-bit MIPS: drivers/net/wireless/mac80211_hwsim.c: In function 'mac80211_hwsim_set_tsf': drivers/net/wireless/mac80211_hwsim.c:664:98: warning: comparison of distinct pointer types lacks a cast [enabled by default] data->bcn_delta = do_div(delta, bcn_int); Since we care about the signedness of delta when adjusting tsf_offset and bcm_delta, use the absolute value for the division and compare the two timestamps to determine the sign. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23b43: N-PHY: fix rev7+ typos at random placesRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-23Merge branch 'for-john' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
2014-07-22iwlwifi: mvm: teardown TDLS peers during chan-switch and AP DCMArik Nemtsov
The DCM condition was not checked well for channel switch in both AP and station scenarios. Teardown was also not done for AP/GO DCM. Add the missing checks. Reported-by: Peer, Ilan <ilan.peer@intel.com> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22Merge remote-tracking branch 'wireless-next/master' into iwlwifi-nextEmmanuel Grumbach
2014-07-22ath10k: prevent endless pci rx loopMichal Kazior
It was possible to enter an endless loop while processing a single pci copy engine pipe. This could effectively render ath10k incapable of responding to any requests. An example case when this could happen is when firmware generates a lot of events, e.g. spectral scan phyerr via WMI. Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-22b43: extract one more radio parameter: versionRafał Miłecki
Some radios may share the same ID and revision but differ by a version. E.g. radio in BCM5357B0 is version 1 and requires specific handling. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: enable radio 0x2057 rev 14 support (AKA BCM43217)Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: final fixes to rev7+ workaroundsRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: add rev7+ workarounds for radio revs 9 and 14Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: allow applying separated workarounds per coreRafał Miłecki
Newer devices need different workarounds for cores 0 and 1. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: update generic rev7+ workaroundsRafał Miłecki
Add some missing ops and prepare for new devices support. This patch is a great stability improvement for BCM43217. Earlier Tenda W322E used to disconnect every 2 minutes (16 times over 30 minutes). With this fix I got it running for 4 hours (with iperf) without any disconnection. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: update digital filters setupRafał Miłecki
This fixes handling channel 14 and adds code for BCM43217. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22b43: N-PHY: add helper for setting digital filtersRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22mwifiex: card reset: enable rescan of non-removable cardAndreas Fenkart
mmc_rescan will scan for non-removable cards only once, hence the card will not be rediscovered. Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-22Merge branch 'for-upstream' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
2014-07-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-nextJohn W. Linville
2014-07-22Merge branch 'iwlwifi-fixes' into iwlwifi-nextEmmanuel Grumbach
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Conflicts: drivers/net/wireless/iwlwifi/mvm/mac80211.c
2014-07-22iwlwifi: mvm: reset beacon filtering and BT Coex data upon FW restartEmmanuel Grumbach
When the firmware asserts, we restart the device and reset the relevant data we hold in the driver. BT Coex data was not reset and because of that, the driver wouldn't reconfigure the firmware properly after firmware restart. Same for beacon filtering. Fix that. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: update smart fifo / beacon filtering upon associationEran Harary
When we associate, we may have heard the beacon before the association. In that case, BSS_CHANGED_BEACON_INFO will be set along with BSS_CHANGED_ASSOC in changes in bss_info_change. In this case, we didn't update the smart fifo nor beacon filtering leaving those two feature disabled. Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: dump CSRs to fw-error-dumpEmmanuel Grumbach
Add the Control Status Registers to the firmware error dump infrastructure. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: dump periphery registers to fw-error-dumpEmmanuel Grumbach
Use the fw-error-dump infrastructure to dump the periphery registers. Only certain ranges are readable, so dump only these. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: split fw-error-dump between transport and mvmEmmanuel Grumbach
The mvm op_mode won't allocate the buffer for the transport any more. The transport allocates its own buffer and mvm is in charge of splicing the buffers in the debugfs hook. This makes the repartition easier to handle. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: fix inconsistency about power_save module parameterEmmanuel Grumbach
modinfo and kerneldoc disagreed on the meaning of this field. Reported-by: Andrea Oliveri <oliveriandrea@gmail.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: minor change in debug printEran Harary
Add OTP to the string: "can't parse empty OTP/NVM section" NVM usually refers to nvm_file while the problem can be in the OTP. Signed-off-by: Eran Harary <eran.harary@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: wait for handlers when stopping scansEliad Peller
The recent unified scan api change introduced issues when stopping ongoing scans, since both regular and sched scan now use same stopped notification. When issuing a new scan right after a running one, we get the "old" notification and handle it wrongly as notification for the current scan. Fix it by introducing a new function that make sure we consume the pending notifications before issuing a new scan. Signed-off-by: Eliad Peller <eliad@wizery.com> Reviewed-by: ArikX Nemtsov <arik@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: BT Coex - don't change AP SMPS modeEmmanuel Grumbach
Leave it to default instead - regardless of the BT activity. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: BT Coex - fix the ACK / CTS kill maskEmmanuel Grumbach
According to new requirements, the ACK / CTS kill mask is not related to reduced TX power anymore. This allows to remove the code that tracked reduced TX power enablement across different interfaces. The ACK / CTS kill mask is now fetch from a table. It depends on the Activity grading (activity from BT) and on the Look Up Table (LUT) type. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22iwlwifi: mvm: add Aux ROC request/response flowAriej Marjieh
The Remain On Channel framework added to the firmare is a bit like time events. It allows the driver to request the firmware to be on a certain channel for a certain time. Unlike the time events, the ROC infrastructure doesn't need a MAC context in the firmware - it uses a generic context called "auxiliary framework". This is useful for any offchannel activity that is not bound to a specific MAC. The flow is synchronized much like with time events: 1) The driver receives an action frame from the wpa_supplicant via nl80211 that requests to be sent offchannel. 2) The driver sends an Aux ROC command (0x53) to the firmware. 3) The firmware responds with the unique id of the time event. 4) When time event starts, the driver puts the frame in the Aux queue. Special care needs to be taken when the time events ends: the queue needs to be cleaned-up. Signed-off-by: Ariej Marjieh <ariej.marjieh@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-07-22ath10k: workaround qos nullfunc bugMichal Kazior
Apparently fw/hw generates a corrupted QoS Control Field in Qos NullFunc frames. The only way to workaround this is to downgrade frames to NullFunc. This should be okay since powersave is done by fw/hw and these frames are only used for CQM purposes (e.g. from hostapd to check if station is still connected). This doesn't fix any user visible bug that I know of. It just prevents from sending out funky frames on the air. Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-22ath10k: simplify tx helpersMichal Kazior
It always bugged me how tid is computed and stored in a temporary var before written to the control buffer. It was confusing and it made it difficult to work with tx helpers. While at it rename the qos workaround function as it was misleading - it's not a workaround but preparation for nwifi tx mode. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-21ath10k: prevent some tx flushing failuresMichal Kazior
Firmware could request inspection of some submitted tx requests. Since the callback wasn't implemented it was possible to bleed tx msdu_ids which could translate to tx flushing timeouts. There's nothing ath10k can do to help firmware with tx processing now so just report all tx frames as already inspected to prevent firmware from sending up inspection events and force it to report regular tx completion indications with discard status. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-21ath10k: workaround boot issues with KVM/PCI-passthroughMichal Kazior
Apparently iomap writes that unmask CE irqs aren't propagated properly sometimes. Before failing try to poll for the control response message as it may have been delivered without an interrupt. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2014-07-21mac80211: add support for Rx reordering offloadingMichal Kazior
Some drivers may be performing most of Tx/Rx aggregation on their own (e.g. in firmware) including AddBa/DelBa negotiations but may otherwise require Rx reordering assistance. The patch exports 2 new functions for establishing Rx aggregation sessions in assumption device driver has taken care of the necessary negotiations. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [fix endian bug] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21mac80211: fix Rx reordering with RX_FLAG_AMSDU_MOREMichal Kazior
Some drivers (e.g. ath10k) report A-MSDU subframes individually with identical seqno. The A-MPDU Rx reorder code did not account for that which made it practically unusable with drivers using RX_FLAG_AMSDU_MORE because it would end up dropping a lot of frames resulting in confusion in upper network transport layers. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21mac80211: remove useless NULL checksEytan Lifshitz
sdata can't be NULL, and key being NULL is really not possible unless the code is modified. The sdata check made a static analyze (klocwork) unhappy because we would get pointer to local (sdata->local) and only then check if sdata is non-NULL. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [remove !key check as well] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboardMarcel Holtmann
The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth controller on the USB bus. However vendor and product ID are listed as ASUSTek Computer. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17cf Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=54271E910064 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Reported-by: Jerome Leclanche <jerome@leclan.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-07-21Bluetooth: Prefer sizeof(*ptr) when allocating memoryJohan Hedberg
It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when allocating memory in case the type changes. This also fixes the following style of warnings from static analyzers: CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...) + ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL); Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-07-21mac80211: fix a potential NULL access in ieee80211_crypto_hw_decryptMax Stepanov
The NULL pointer access could happen when ieee80211_crypto_hw_decrypt is called from ieee80211_rx_h_decrypt with the following condition: 1. rx->key->conf.cipher is not WEP, CCMP, TKIP or AES_CMAC 2. rx->sta is NULL When ieee80211_crypto_hw_decrypt is called, it verifies rx->sta->cipher_scheme and it will cause Oops if rx->sta is NULL. This path adds an addirional rx->sta == NULL verification in ieee80211_crypto_hw_decrypt for this case. Signed-off-by: Max Stepanov <Max.Stepanov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21wireless: fixup genregdb.awk for remove of antenna gain from wireless-regdLuis R. Rodriguez
Since "wireless-regdb: remove antenna gain" was merged in the wireless-regdb tree, the awk script parser has been incompatible with the 'official' regulatory database. This fixes that up. Without this change the max EIRP is set to 0 making 802.11 devices useless. The fragile nature of the awk parser must be replaced, but ideas over how to do that in the most scalable way are being reviewed. In the meantime update the documentation for CFG80211_INTERNAL_REGDB so folks are aware of expectations for now. Reported-by: John Walker <john@x109.net> Reported-by: Krishna Chaitanya <chaitanya.mgit@gmail.com> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21mac80211: remove redundant IEEE80211_STA_CSA_RECEIVED flagLuciano Coelho
The csa_active flag was added in sdata a while ago and made IEEE80211_STA_CSA_RECEIVED redundant. The new flag is also used to mark when CSA is ongoing on other iftypes and took over the old one as the preferred method for checking whether we're in the middle of a channel switch. Remove the old, redundant flag. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-07-21mac80211: make sure TDLS teardown packet is sent on timeLiad Kaufman
Since the teardown packet is created while the queues are stopped, it isn't sent immediately, but rather is pending. To be sure that when we flush the queues prior to destroying the station we also send this packet - the tasklet handling pending packets is invoked to flush the packets. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Reviewed-by: ArikX Nemtsov <arik@wizery.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 13:34:21 +0000