1. 09 3月, 2021 3 次提交
  2. 24 2月, 2021 4 次提交
  3. 22 2月, 2021 2 次提交
    • S
      Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference" · 14ebaeef
      Shuah Khan 提交于
      This reverts commit a56c14bb.
      
      ath_tx_process_buffer() doesn't dereference or check sta and passes it
      to ath_tx_complete_aggr() and ath_tx_complete_buf().
      
      ath_tx_complete_aggr() checks the pointer before use. No problem here.
      
      ath_tx_complete_buf() doesn't check or dereference sta and passes it on
      to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
      but assigns it to tx_info->status.status_driver_data[0]
      
      ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
      null ieee80211_sta pointer.
      
      There is a potential for dereference later on, if and when the
      tx_info->status.status_driver_data[0]is referenced. In addition, the
      rcu read lock might be released before referencing the contents.
      
      ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
      looking into.
      
      Reverting this patch because it doesn't solve the problem and introduces
      memory leak by skipping buffer completion if the pointer (sta) is NULL.
      
      Fixes: a56c14bb ("ath9k: fix ath_tx_process_buffer() potential null ptr dereference")
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210217211801.22540-1-skhan@linuxfoundation.org
      14ebaeef
    • K
      ath11k: print hardware name and version during initialisation · 6b7abacb
      Kalle Valo 提交于
      This way it's easy for the user to find what device is actually installed. This
      also helps reporting bugs.
      
      Screenshot:
      
      [  459.988812] ath11k_pci 0000:06:00.0: BAR 0: assigned [mem 0xdb000000-0xdbffffff 64bit]
      [  459.988867] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002)
      [  459.997048] ath11k_pci 0000:06:00.0: qca6390 hw2.0
      [  460.058093] mhi mhi0: Requested to power ON
      [  460.059741] mhi mhi0: Power on setup success
      [  460.476924] ath11k_pci 0000:06:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
      [  460.477032] ath11k_pci 0000:06:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id
      
      Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1613589400-18891-1-git-send-email-kvalo@codeaurora.org
      6b7abacb
  4. 18 2月, 2021 2 次提交
  5. 17 2月, 2021 11 次提交
  6. 16 2月, 2021 2 次提交
  7. 12 2月, 2021 12 次提交
  8. 11 2月, 2021 4 次提交
    • S
      ath10k: change ath10k_offchan_tx_work() peer present msg to a warn · 83bae265
      Shuah Khan 提交于
      Based on the comment block in this function and the FIXME for this, peer
      being present for the offchannel tx is unlikely. Peer is deleted once tx
      is complete. Change peer present msg to a warn to detect this condition.
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/3b1f71272d56ee1d7f567fbce13bdb56cc06d342.1612915444.git.skhan@linuxfoundation.org
      83bae265
    • L
      ath9k: fix data bus crash when setting nf_override via debugfs · 12c8f3d1
      Linus Lüssing 提交于
      When trying to set the noise floor via debugfs, a "data bus error"
      crash like the following can happen:
      
      [   88.433133] Data bus error, epc == 80221c28, ra == 83314e60
      [   88.438895] Oops[#1]:
      [   88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0
      [   88.447174] task: 838a1c20 task.stack: 82d5e000
      [   88.451847] $ 0   : 00000000 00000030 deadc0de 83141de4
      [   88.457248] $ 4   : b810a2c4 0000a2c4 83230fd4 00000000
      [   88.462652] $ 8   : 0000000a 00000000 00000001 00000000
      [   88.468055] $12   : 7f8ef318 00000000 00000000 77f802a0
      [   88.473457] $16   : 83230080 00000002 0000001b 83230080
      [   88.478861] $20   : 83a1c3f8 00841000 77f7adb0 ffffff92
      [   88.484263] $24   : 00000fa4 77edd860
      [   88.489665] $28   : 82d5e000 82d5fda8 00000000 83314e60
      [   88.495070] Hi    : 00000000
      [   88.498044] Lo    : 00000000
      [   88.501040] epc   : 80221c28 ioread32+0x8/0x10
      [   88.505671] ra    : 83314e60 ath9k_hw_loadnf+0x88/0x520 [ath9k_hw]
      [   88.512049] Status: 1000fc03 KERNEL EXL IE
      [   88.516369] Cause : 5080801c (ExcCode 07)
      [   88.520508] PrId  : 00019374 (MIPS 24Kc)
      [   88.524556] Modules linked in: ath9k ath9k_common pppoe ppp_async l2tp_ppp cdc_mbim batman_adv ath9k_hw ath sr9700 smsc95xx sierra_net rndis_host qmi_wwan pppox ppp_generic pl2303 nf_conntrack_ipv6 mcs7830 mac80211 kalmia iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm ftdi_sio dm9601 cfg80211 cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY usbserial usbnet usbhid slhc rtl8150 r8152 pegasus nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack
      [   88.597894]  libcrc32c kaweth iptable_mangle iptable_filter ipt_ECN ipheth ip_tables hso hid_generic crc_ccitt compat cdc_wdm cdc_acm br_netfilter hid evdev input_core nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 l2tp_netlink l2tp_core udp_tunnel ip6_udp_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 tun xfrm_user xfrm_ipcomp af_key xfrm_algo sha256_generic sha1_generic jitterentropy_rng drbg md5 hmac echainiv des_generic deflate zlib_inflate zlib_deflate cbc authenc crypto_acompress ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common crc16 mii aead crypto_null cryptomgr crc32c_generic
      [   88.671671]  crypto_hash
      [   88.674292] Process sh (pid: 7263, threadinfo=82d5e000, task=838a1c20, tls=77f81efc)
      [   88.682279] Stack : 00008060 00000008 00000200 00000000 00000000 00000000 00000000 00000002
      [   88.690916]         80500000 83230080 82d5fe22 00841000 77f7adb0 00000000 00000000 83156858
      [   88.699553]         00000000 8352fa00 83ad62b0 835302a8 00000000 300a00f8 00000003 82d5fe38
      [   88.708190]         82d5fef4 00000001 77f54dc4 77f80000 77f7adb0 c79fe901 00000000 00000000
      [   88.716828]         80510000 00000002 00841000 77f54dc4 77f80000 801ce4cc 0000000b 41824292
      [   88.725465]         ...
      [   88.727994] Call Trace:
      [   88.730532] [<80221c28>] ioread32+0x8/0x10
      [   88.734765] Code: 00000000  8c820000  0000000f <03e00008> 00000000  08088708  00000000  aca40000  03e00008
      [   88.744846]
      [   88.746464] ---[ end trace db226b2de1b69b9e ]---
      [   88.753477] Kernel panic - not syncing: Fatal exception
      [   88.759981] Rebooting in 3 seconds..
      
      The "REG_READ(ah, AR_PHY_AGC_CONTROL)" in ath9k_hw_loadnf() does not
      like being called when the hardware is asleep, leading to this crash.
      
      The easiest way to reproduce this is trying to set nf_override while
      the hardware is down:
      
        $ ip link set down dev wlan0
        $ echo "-85" > /sys/kernel/debug/ieee80211/phy0/ath9k/nf_override
      
      Fixing this crash by waking the hardware up before trying to set the
      noise floor. Similar to what other ath9k debugfs files do.
      
      Tested on a Lima board from 8devices, which has a QCA 4531 chipset.
      
      Fixes: b9018975 ("ath9k: add noise floor override option")
      Cc: Simon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NLinus Lüssing <ll@simonwunderlich.de>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210209184352.4272-1-linus.luessing@c0d3.blue
      12c8f3d1
    • R
      ath11k: add support to configure spatial reuse parameter set · b56b08ae
      Rajkumar Manoharan 提交于
      The SPR parameter set comprises OBSS PD threshold for SRG
      and non SRG and Bitmap of BSS color and partial BSSID. This adds
      support to configure fields of SPR element to firmware.
      
      Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01238-QCAHKSWPL_SILICONZ-2
      Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01164-QCAHKSWPL_SILICONZ-1
      Tested-by: NMuna Sinada <msinada@codeaurora.org>
      Signed-off-by: NRajkumar Manoharan <rmanohar@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1612843714-29174-1-git-send-email-rmanohar@codeaurora.org
      b56b08ae
    • W
      ath10k: restore tx sk_buff of htt header for SDIO · e6f1c0d2
      Wen Gong 提交于
      ieee80211_report_used_skb of mac80211 use the frame_control of
      ieee80211_hdr in sk_buff and indicate it to another function
      ieee80211_mgd_conn_tx_status, then it queue work ieee80211_sta_work,
      but ieee80211_is_auth(fc) in ieee80211_sta_work check fail when the
      authentication has transmitted by ath10k.
      
      When the ath10k report it with HTT_TX_COMPL_STATE_DISCARD, it will be
      set without flag IEEE80211_TX_STAT_ACK, then mac80211 should try the
      next authentication immeditely, but in fact mac80211 wait 1 second for
      it, the reason is ieee80211_is_auth(fc) in ieee80211_sta_work check
      fail for the sk_buff which is not restored, the data of sk_buff is not
      the begin of ieee80211_hdr, in fact it is the begin of htt_cmd_hdr.
      
      dmesg without this patch, it wait 1 second for the next retry when
      ath10k report without IEEE80211_TX_STAT_ACK for authentication:
      [ 6973.883116] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 1/3)
      [ 6974.705471] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 2/3)
      [ 6975.712962] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 3/3)
      
      Restore the sk_buff make mac8011 retry the next authentication
      immeditely which meet logic of mac80211.
      
      dmesg with this patch, it retry the next immeditely when ath10k
      report without IEEE80211_TX_STAT_ACK for authentication:
      [  216.734813] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 1/3)
      [  216.739914] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 2/3)
      [  216.745874] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 3/3)
      
      Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
      Signed-off-by: NWen Gong <wgong@codeaurora.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1612839530-2263-1-git-send-email-wgong@codeaurora.org
      e6f1c0d2