1. 05 4月, 2017 2 次提交
  2. 20 3月, 2017 1 次提交
  3. 16 3月, 2017 1 次提交
    • M
      ath10k: disallow DFS simulation if DFS channel is not enabled · ca07baab
      Mohammed Shafi Shajakhan 提交于
      If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
      not be available for use even though the hardware may have the capability
      to support DFS. With this configuration (DFS disabled in hostapd) trying to
      bring up ath10k device in DFS channel for AP mode fails and trying to
      simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
      invalid channel and this should be avoided in the driver itself rather than
      false propogating RADAR detection to mac80211/cfg80211. Fix this by
      checking for the first vif 'is_started' state(should work for client mode
      as well) as all the vifs shall be configured for the same channel
      
      sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar
      
      WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
      Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
      [<c022f2d4>] (warn_slowpath_null) from
      [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
      [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
      [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
      [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
      [<c0242320>] (process_one_work+0x20c/0x32c)
      
      WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
       Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
      [<c022f2d4>] (warn_slowpath_null) from
      [<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
      [<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
      [<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
      [<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
      [<c0242320>] (process_one_work+0x20c/0x32c)
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ca07baab
  4. 15 2月, 2017 1 次提交
  5. 19 1月, 2017 1 次提交
    • M
      ath10k: dump Copy Engine registers during firmware crash · c75c398b
      Mohammed Shafi Shajakhan 提交于
      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: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: simplify the implementation]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c75c398b
  6. 13 1月, 2017 1 次提交
  7. 30 12月, 2016 1 次提交
    • A
      ath10k: support dev_coredump for crash dump · 727000e6
      Arun Khandavalli 提交于
      Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
      CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
      devcoredump device. Dump can be read from userspace for further analysis from:
      
      /sys/class/devcoredump/devcd*/data
      
      As until now we have provided the firmware crash dump file via fw_crash_dump
      debugfs keep it still available but deprecate and a warning print that the user
      should switch to using dev_coredump.
      
      Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
      might be systems which want to get the firmware crash dump but not enable
      debugfs. How to handle memory consumption is also something which needs to be
      taken into account.
      Signed-off-by: NArun Khandavalli <akhandav@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: rebase, fixes, improve commit log]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      727000e6
  8. 13 10月, 2016 1 次提交
    • M
      ath10k: cache calibration data when the core is stopped · f67b107d
      Marty Faltesek 提交于
      Commit 0b8e3c4c ("ath10k: move cal data len to hw_params") broke retrieving
      the calibration data from cal_data debugfs file. The length of file was always
      zero. The reason is:
      
          static ssize_t ath10k_debug_cal_data_read(struct file *file,
                                                char __user *user_buf,
                                                size_t count, loff_t *ppos)
          {
              struct ath10k *ar = file->private_data;
              void *buf = file->private_data;
      
      This is obviously bogus, private_data cannot contain both struct ath10k and the
      buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
      allows it to be accessed when the device is not active (interface is down).
      
      The cal_data buffer is fixed size because during the first firmware probe we
      don't yet know what will be the lenght of the calibration data. It was simplest
      just to use a fixed length. There's a WARN_ON() in
      ath10k_debug_cal_data_fetch() if the buffer is too small.
      
      Tested with qca988x and firmware 10.2.4.70.56.
      Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
      Fixes: 0b8e3c4c ("ath10k: move cal data len to hw_params")
      Cc: stable@vger.kernel.org # 4.7+
      Signed-off-by: NMarty Faltesek <mfaltesek@google.com>
      [kvalo@qca.qualcomm.com: improve commit log and minor other changes]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      f67b107d
  9. 02 9月, 2016 1 次提交
  10. 04 8月, 2016 1 次提交
    • M
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada 提交于
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  11. 08 7月, 2016 1 次提交
    • M
      ath10k: fix 10.4 extended peer stats update · 4a49ae94
      Mohammed Shafi Shajakhan 提交于
      10.4 'extended peer stats' will be not be appended with normal peer stats
      data and they shall be coming in separate chunks. Fix this by maintaining
      a separate linked list 'extender peer stats' for 10.4 and update
      rx_duration for per station statistics. Also parse through beacon filter
      (if enabled), to make sure we parse the extended peer stats properly.
      This issue was exposed when more than one client is connected and
      extended peer stats for 10.4 is enabled
      
      The order for the stats is as below
      S - standard peer stats, E- extended peer stats, B - beacon filter stats
      
      {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
      
      Fixes: f9575793 ("ath10k: enable parsing per station rx duration for 10.4")
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      4a49ae94
  12. 02 6月, 2016 2 次提交
  13. 21 4月, 2016 3 次提交
  14. 19 4月, 2016 1 次提交
  15. 23 3月, 2016 2 次提交
  16. 22 3月, 2016 1 次提交
  17. 18 3月, 2016 1 次提交
  18. 04 3月, 2016 2 次提交
  19. 26 2月, 2016 2 次提交
  20. 26 1月, 2016 3 次提交
  21. 08 12月, 2015 1 次提交
  22. 30 11月, 2015 6 次提交
  23. 05 11月, 2015 1 次提交
    • Y
      ath10k: debugfs file to enable Bluetooth coexistence feature · 844fa572
      Yanbo Li 提交于
      As not all QCA98XX radios are not connected to Bluetooth modules, enabling the
      BT coex feature in firmware will have side effects if the radio's GPIO are
      connected with other (non-BT) HW modules. Add debugfs file to control the
      firmware BT coex logic and set the feature as disable by default to avoid that
      btcoex is accidentally enabled.
      
      To enable this feature, execute:
      
      echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btcoex
      
      To disable:
      
      echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btcoex
      
      The firmware support this feature since 10.2.4.54 on 2G-only board, dual band
      or 5G boards don't support this. The feature's name is WMI_SERVICE_COEX_GPIO
      and the btcoex file is not created if firmware doesn't support it.
      Signed-off-by: NYanbo Li <yanbol@qca.qualcomm.com>
      [kvalo@qca.qualcomm.com: use btcoex filename and other smaller fixes]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      844fa572
  24. 19 10月, 2015 1 次提交
  25. 14 10月, 2015 2 次提交
    • M
      ath10k: select board data based on BMI chip id and board id · db0984e5
      Manikanta Pubbisetty 提交于
      QCA99X0 uses radio specific board names based on chip id and
      board id combinations. We get these IDs from the target using BMI after otp.bin
      has been started.
      
      This patch reorders the call to the function ath10k_core_fetch_board_file
      so that we have OTP binary before requesting for boardid-chipid. We get this
      OTP data after parsing firmware-N.bin.
      
      [kvalo@qca.qualcomm.com: try BMI_PARAM_GET_EEPROM_BOARD_ID with
       all boards and detect if command is not supported]
      Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      db0984e5
    • M
      ath10k: add board 2 API support · 0a51b343
      Manikanta Pubbisetty 提交于
      QCA6174 needs different board files based on board type. To make it easier to
      distribute multiple board files and automatically choose correct board file
      create a simple TLV file format following the same principles as with FW IEs.
      The file is named board-2.bin and contain multiple board files. Each board file
      then can have multiple names.
      
      ath10k searches for file board-N.bin (where N is the interface version number
      for the board file, just like we for firmware files) in /lib/firmware/*, for
      example for qca99x0 it will try to find it here:
      
      /lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin
      
      If ath10k doesn't find board-2.bin then it will fallback to the old board.bin file.
      
      This patch adds a simple name scheme using pci device id which for now will be
      used by qca6174:
      
      bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x
      
      This removes the old method of having subsystem ids in ar->spec_board_id and
      using that in the board file name.
      Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: simplified the file format, rewrote commit log, other smaller changes]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0a51b343