1. 27 Jan, 2017 6 commits
  2. 19 Jan, 2017 4 commits
    • Mohammed Shafi Shajakhan's avatar
      ath10k: dump Copy Engine registers during firmware crash · c75c398b
      Mohammed Shafi Shajakhan authored
      Dump Copy Engine source and destination ring addresses.
      This is useful information to debug firmware crashes, assertes or hangs over long run
      assessing the Copy Engine Register status. This also enables dumping CE
      register status in debugfs Crash Dump file.
      
      Screenshot:
      
      ath10k_pci 0000:02:00.0: simulating hard firmware crash
      ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf)
      ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
      ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
      ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
      ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
      ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
      ath10k_pci 0000:02:00.0: firmware register dump:
      ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000
      ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A
      ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: Copy Engine register dump:
      ath10k_pci 0000:02:00.0: [00]: 0x00057400   7   7   3   3
      ath10k_pci 0000:02:00.0: [01]: 0x00057800  18  18  85  86
      ath10k_pci 0000:02:00.0: [02]: 0x00057c00  49  49  48  49
      ath10k_pci 0000:02:00.0: [03]: 0x00058000  16  16  17  16
      ath10k_pci 0000:02:00.0: [04]: 0x00058400   4   4  44   4
      ath10k_pci 0000:02:00.0: [05]: 0x00058800  12  12  11  12
      ath10k_pci 0000:02:00.0: [06]: 0x00058c00   3   3   3   3
      ath10k_pci 0000:02:00.0: [07]: 0x00059000   0   0   0   0
      ieee80211 phy0: Hardware restart was requested
      ath10k_pci 0000:02:00.0: device successfully recovered
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: simplify the implementation]
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c75c398b
    • Mohammed Shafi Shajakhan's avatar
      ath10k: fix per station tx bit rate reporting · 0f8a2b77
      Mohammed Shafi Shajakhan authored
      Not clearing the previous tx bit rate status
      results in a ambigous tx bit rate reporting to
      mac80211/cfg80211, for example the previous bit
      rate status would have been marked as legacy rate
      , while the current rate would have been an HT/VHT
      rate with the tx bit rate flags set and this results
      in exporting tx bitrate as legacy rate but with HT/VHT
      rate flags set, fix this by clearing the tx bitrate
      status for each event. This also fixes the below
      warning when we do:
      
      iw dev wlan#N station dump
      
      WARNING: net/wireless/util.c:1222 cfg80211
      
      [<c022f104>] (warn_slowpath_null) from [<bf3b9adc>]
      (cfg80211_calculate_bitrate+0x110/0x1f4 [cfg80211])
      [<bf3b9adc>] (cfg80211_calculate_bitrate [cfg80211]) from
      [<bf3dcd54>] (nl80211_put_sta_rate+0x44/0x1dc [cfg80211])
      [<bf3dcd54>] (nl80211_put_sta_rate [cfg80211]) from
      [<bf3cbc34>] (nl80211_set_interface+0x724/0xd70 [cfg80211])
      [<bf3cbc34>] (nl80211_set_interface [cfg80211]) from
      [<bf3d0a18>] (nl80211_dump_station+0xdc/0x100 [cfg80211])
      [<bf3d0a18>] (nl80211_dump_station [cfg80211])
      
      Fixes: cec17c38 ("ath10k: add per peer htt tx stats support for 10.4")
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0f8a2b77
    • Michal Kazior's avatar
      ath10k: prevent sta pointer rcu violation · 0a744d92
      Michal Kazior authored
      Station pointers are RCU protected so driver must
      be extra careful if it tries to store them
      internally for later use outside of the RCU
      section it obtained it in.
      
      It was possible for station teardown to race with
      some htt events. The possible outcome could be a
      use-after-free and a crash.
      
      Only peer-flow-control capable firmware was
      affected (so hardware-wise qca99x0 and qca4019).
      
      This could be done in sta_state() itself via
      explicit synchronize_net() call but there's
      already a convenient sta_pre_rcu_remove() op that
      can be hooked up to avoid extra rcu stall.
      
      The peer->sta pointer itself can't be set to
      NULL/ERR_PTR because it is later used in
      sta_state() for extra sanity checks.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0a744d92
    • Wei Yongjun's avatar
      ath6kl: fix warning for using 0 as NULL · 96d179b5
      Wei Yongjun authored
      Fixes the following sparse warning:
      
      drivers/net/wireless/ath/ath6kl/sdio.c:716:55: warning:
       Using plain integer as NULL pointer
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      96d179b5
  3. 13 Jan, 2017 6 commits
    • Mohammed Shafi Shajakhan's avatar
      ath10k: fix tx legacy rate reporting · cd591027
      Mohammed Shafi Shajakhan authored
      Tx legacy rate is reported 10 fold, as below
      
      iw dev wlan#N station dump | grep "tx bitrate"
              tx bitrate:     240.0 MBit/s
      
      This is because by mistake we multiply by the hardware reported
      rate twice by 10, fix this.
      
      Fixes: cec17c38 ("ath10k: add per peer htt tx stats support for 10.4")
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      cd591027
    • Mohammed Shafi Shajakhan's avatar
      ath10k: fix wifi connectivity and warning in rx with channel 169 · c486dc57
      Mohammed Shafi Shajakhan authored
      In countries where basic operation of channel 169 is allowed,
      this fixes the below WARN_ON_ONCE in Rx and fixes the station
      connectivity failure in channel 169 as the packet is dropped
      in the driver as the current check limits to channel 165. As of
      now all the packets beyond channel 165 is dropped, fix this
      by extending the range to channel 169.
      
      Call trace:
      
      drivers/net/wireless/ath/ath10k/wmi.c:1505
      ath10k_wmi_event_mgmt_rx+0x278/0x440 [ath10k_core]()
      Call Trace:
       [<c158f812>] ? printk+0x2d/0x2f
       [<c105a182>] warn_slowpath_common+0x72/0xa0
       [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440
      
       [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440
      
       [<c105a1d2>] warn_slowpath_null+0x22/0x30
       [<f8b67b58>] ath10k_wmi_event_mgmt_rx+0x278/0x440
      
       [<f8b0e72b>] ? ath10k_pci_sleep+0x8b/0xb0 [ath10k_pci]
       [<f8b6ac63>] ath10k_wmi_10_2_op_rx+0xf3/0x3b0
      
       [<f8b6495e>] ath10k_wmi_process_rx+0x1e/0x60
      
       [<f8b5f077>] ath10k_htc_rx_completion_handler+0x347/0x4d0 [ath10k_core]
       [<f8b11dc3>] ? ath10k_ce_completed_recv_next+0x53/0x70 [ath10k_pci]
       [<f8b0f921>] ath10k_pci_ce_recv_data+0x171/0x1d0 [ath10k_pci]
       [<f8b0ec69>] ? ath10k_pci_write32+0x39/0x80 [ath10k_pci]
       [<f8b120bc>] ath10k_ce_per_engine_service+0x5c/0xa0 [ath10k_pci]
       [<f8b1215f>] ath10k_ce_per_engine_service_any+0x5f/0x70 [ath10k_pci]
       [<c1060dc0>] ? local_bh_enable_ip+0x90/0x90
       [<f8b1048b>] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci]
      
      Fixes: 34c30b0a ("ath10k: enable advertising support for channel 169, 5Ghz")
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c486dc57
    • Christian Lamparter's avatar
      ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS · 1077ec47
      Christian Lamparter authored
      Currently, the common ath9k_common module needs to have a
      dependency on RELAY and DEBUG_FS in order to built. This
      is usually not a problem. But for RAM and FLASH starved
      AR71XX devices, every little bit counts.
      
      This patch adds a new symbol CONFIG_ATH9K_COMMON_DEBUG
      which makes it possible to drop the RELAY and DEBUG_FS
      dependency there and move it to ATH_(HTC)_DEBUGFS.
      
      Note: The shared FFT/spectral code (which is the only user
      of the relayfs in ath9k*) needs DEBUG_FS to export the relayfs
      interface to dump the data to userspace. So it makes no sense
      to have the functions compiled in, if DEBUG_FS is not there.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      1077ec47
    • Christian Lamparter's avatar
      ath10k: add accounting for the extended peer statistics · c1e3330f
      Christian Lamparter authored
      The 10.4 firmware adds extended peer information to the
      firmware's statistics payload. This additional info is
      stored as a separate data field and the elements are
      stored in their own "peers_extd" list.
      
      These elements can pile up in the same way as the peer
      information elements. This is because the
      ath10k_wmi_10_4_op_pull_fw_stats() function tries to
      pull the same amount (num_peer_stats) for every statistic
      data unit.
      
      Fixes: 4a49ae94 ("ath10k: fix 10.4 extended peer stats update")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c1e3330f
    • Sebastian Gottschall's avatar
      ath10k: add VHT160 support · bc1efd73
      Sebastian Gottschall authored
      This patch adds full VHT160 support for QCA9984 chipsets Tested on Netgear
      R7800. 80+80 is possible, but disabled so far since it seems to contain
      glitches like missing vht station flags (this may be firmware or mac80211
      related).
      Signed-off-by: default avatarSebastian Gottschall <s.gottschall@dd-wrt.com>
      [kvalo@qca.qualcomm.com: refactoring and fix few warnings]
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      bc1efd73
    • Kalle Valo's avatar
      ath10k: refactor ath10k_peer_assoc_h_phymode() · 06efdbe7
      Kalle Valo authored
      When adding VHT160 support to ath10k_peer_assoc_h_phymode() the VHT mode
      selection code becomes too complex. Simplify it by refactoring the vht part to
      a separate function.
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      06efdbe7
  4. 12 Jan, 2017 12 commits
  5. 11 Jan, 2017 4 commits
  6. 10 Jan, 2017 6 commits
  7. 09 Jan, 2017 2 commits
    • Vivien Didelot's avatar
      net: dsa: select NET_SWITCHDEV · 3a89eaa6
      Vivien Didelot authored
      The support for DSA Ethernet switch chips depends on TCP/IP networking,
      thus explicit that HAVE_NET_DSA depends on INET.
      
      DSA uses SWITCHDEV, thus select it instead of depending on it.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a89eaa6
    • David S. Miller's avatar
      Merge tag 'mlx5-4kuar-for-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux · bda65b42
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 4K UAR
      
      The following series of patches optimizes the usage of the UAR area which is
      contained within the BAR 0-1. Previous versions of the firmware and the driver
      assumed each system page contains a single UAR. This patch set will query the
      firmware for a new capability that if published, means that the firmware can
      support UARs of fixed 4K regardless of system page size. In the case of
      powerpc, where page size equals 64KB, this means we can utilize 16 UARs per
      system page. Since user space processes by default consume eight UARs per
      context this means that with this change a process will need a single system
      page to fulfill that requirement and in fact make use of more UARs which is
      better in terms of performance.
      
      In addition to optimizing user-space processes, we introduce an allocator
      that can be used by kernel consumers to allocate blue flame registers
      (which are areas within a UAR that are used to write doorbells). This provides
      further optimization on using the UAR area since the Ethernet driver makes
      use of a single blue flame register per system page and now it will use two
      blue flame registers per 4K.
      
      The series also makes changes to naming conventions and now the terms used in
      the driver code match the terms used in the PRM (programmers reference manual).
      Thus, what used to be called UUAR (micro UAR) is now called BFREG (blue flame
      register).
      
      In order to support compatibility between different versions of
      library/driver/firmware, the library has now means to notify the kernel driver
      that it supports the new scheme and the kernel can notify the library if it
      supports this extension. So mixed versions of libraries can run concurrently
      without any issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bda65b42