1. 27 10月, 2017 6 次提交
  2. 13 10月, 2017 4 次提交
  3. 25 9月, 2017 1 次提交
  4. 21 9月, 2017 1 次提交
    • A
      ath10k: mark PM functions as __maybe_unused · 6af1de2e
      Arnd Bergmann 提交于
      When CONFIG_PM_SLEEP is disabled, we get a compile-time
      warning:
      
      drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume' defined but not used [-Werror=unused-function]
       static int ath10k_pci_pm_resume(struct device *dev)
                  ^~~~~~~~~~~~~~~~~~~~
      drivers/net/wireless/ath/ath10k/pci.c:3401:12: error: 'ath10k_pci_pm_suspend' defined but not used [-Werror=unused-function]
       static int ath10k_pci_pm_suspend(struct device *dev)
      
      Rather than fixing the #ifdef, this just marks both functions
      as __maybe_unused, which is a more robust way to do this.
      
      Fixes: 32faa3f0 ("ath10k: add the PCI PM core suspend/resume ops")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      6af1de2e
  5. 01 9月, 2017 2 次提交
    • R
      ath10k: configure and enable the wakeup capability · 393b706c
      Ryan Hsu 提交于
      ACPI will rely on device driver to tell it if the device could support
      wakeup function when system in D3 state.
      
      This has caused some platform can't support remote wakeup correctly,
      because the ACPI wakeup GPE is not enabled, hence registers the .set_wakeup
      callback to handle it if device supports wakeup.
      
      Tested with QCA6174 hw3.0, firmware ('WLAN.RM.4.4.1-00008-QCARMSWP-1')
      Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      393b706c
    • R
      ath10k: add the PCI PM core suspend/resume ops · 32faa3f0
      Ryan Hsu 提交于
      The actual PCI suspend/resume in ath10k has been handled in wow.c,
      but in the case of the device doesn't support remote wakeup,
      the .hif_suspend() and .hif_resume() will never be handled.
      
        ath10k_wow_op_suspend()
        {
      	if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
      		    ar->running_fw->fw_file.fw_features))) {
      		ret = 1;
      		goto exit;
      	}
      
      	....
      
      	ret = ath10k_hif_suspend(ar);
        }
      
      So register the PCI PM core to support the suspend/resume if the device
      doesn't support remote wakeup.
      Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      32faa3f0
  6. 31 8月, 2017 3 次提交
  7. 08 8月, 2017 3 次提交
  8. 03 8月, 2017 8 次提交
  9. 06 7月, 2017 4 次提交
  10. 29 6月, 2017 2 次提交
  11. 21 6月, 2017 3 次提交
    • S
      ath10k: set rxnss_override for QCA9888 · 68248349
      Sven Eckelmann 提交于
      QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or
      VHT80+80. Inform userspace and the the QCA firmware about that limitation
      whenever VHT80+80 or VHT160 is configured.
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      [kvalo@qca.qualcomm.com: use hw_params]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      68248349
    • B
      ath10k: configure rxnss_override for QCA9984 · cc914a55
      Ben Greear 提交于
      QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.
      
      First, report this to user-space by setting the max-tx-speed
      and max-rx-speed vht capabilities.
      
      Second, if the peer rx-speed is configured, and if we
      are in 160 or 80+80 mode, and the peer rx-speed matches
      the max speed for 2x2 or 1x1 at 160Mhz (long guard interval),
      then use that info to set the peer_bw_rxnss_override appropriately.
      
      Without this, a 9984 firmware will not use 2x2 ratesets when
      transmitting to peer (it will be stuck at 1x1), because
      the firmware would not have configured the rxnss_override.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      [sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup]
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      [kvalo@qca.qualcomm.com: use hw_params, rename the title]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      cc914a55
    • B
      ath10k: use complete VHT chan width for 160MHz workaround · e509e594
      Ben Greear 提交于
      The ath10k firmware doesn't announce its VHT channel width capabilities in
      the vht_cap information from the "service ready event" arguments. The
      driver must therefore check whether the 160MHz short GI bit is set and
      whether the driver still doesn't set the bits for the 160/80+80 MHz
      capabilities.
      
      The two bits for the channel width are a two bit integer and not two
      separate bits which cannot be parsed without the knowledge of the other
      bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a
      mask for this task doesn't make any sense. The correct mask for the VHT
      channel width should be used instead to make this check more readable.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      [sven.eckelmann@openmesh.com: separate 160Mhz workaround cleanup, add commit
       message]
      Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e509e594
  12. 16 6月, 2017 3 次提交