Skip to content
  1. Feb 12, 2019
    • Rakesh Pillai's avatar
      ath10k: fix shadow register implementation for WCN3990 · 18630083
      Rakesh Pillai authored
      
      
      WCN3990 supports shadow registers write operation support
      for copy engine for regular operation in powersave mode.
      
      Since WCN3990 is a 64-bit target, the shadow register
      implementation needs to be done in the copy engine handlers
      for 64-bit target. Currently the shadow register implementation
      is present in the 32-bit target handlers of copy engine.
      
      Fix the shadow register copy engine write operation
      implementation for 64-bit target(WCN3990).
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Fixes: b7ba83f7 ("ath10k: add support for shadow register for WNC3990")
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      18630083
    • Rakesh Pillai's avatar
      ath10k: enable Factory Test Mode for WCN3990 · 3c545a25
      Rakesh Pillai authored
      
      
      The support to put WCN3990 firmware into Factory
      test mode is not present currently. The WCN3990
      firmware can operate in Factory test mode based
      on the mode it receives in the wlan enable message
      from the host driver.
      
      When the host driver is started in testmode send
      the operating mode as UTF mode, to the WCN3990
      firmware, in the wlan enable message to start the
      firmware in Factory test mode.
      
      Tested on: WCN3990
      Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      3c545a25
    • Brian Norris's avatar
      ath10k: pci: use mutex for diagnostic window CE polling · 25733c4e
      Brian Norris authored
      
      
      The DIAG copy engine is only used via polling, but it holds a spinlock
      with softirqs disabled. Each iteration of our read/write loops can
      theoretically take 20ms (two 10ms timeout loops), and this loop can be
      run an unbounded number of times while holding the spinlock -- dependent
      on the request size given by the caller.
      
      As of commit 39501ea6 ("ath10k: download firmware via diag Copy
      Engine for QCA6174 and QCA9377."), we transfer large chunks of firmware
      memory using this mechanism. With large enough firmware segments, this
      becomes an exceedingly long period for disabling soft IRQs. For example,
      with a 500KiB firmware segment, in testing QCA6174A, I see 200 loop
      iterations of about 50-100us each, which can total about 10-20ms.
      
      In reality, we don't really need to block softirqs for this duration.
      The DIAG CE is only used in polling mode, and we only need to hold
      ce_lock to make sure any CE bookkeeping is done without screwing up
      another CE. Otherwise, we only need to ensure exclusion between
      ath10k_pci_diag_{read,write}_mem() contexts.
      
      This patch moves to use fine-grained locking for the shared ce_lock,
      while adding a new mutex just to ensure mutual exclusion of diag
      read/write operations.
      
      Tested on QCA6174A, firmware version WLAN.RM.4.4.1-00132-QCARMSWPZ-1.
      
      Fixes: 39501ea6 ("ath10k: download firmware via diag Copy Engine for QCA6174 and QCA9377.")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      25733c4e
    • Govind Singh's avatar
      ath10k: request credit report if flow control enabled on ep · c40e448e
      Govind Singh authored
      
      
      FW credit flow control is enabled for only WMI ctrl
      service(CE3) but credit update is requested unconditionally
      on all HTC services as part of HTC tx in CE3/CE0/CE4.
      
      This is causing WOW failure as FW is not expecting credit
      report request on other end-points(CE0/CE4).
      
      Request credit report only on those endpoints where
      credit flow control is enabled.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      c40e448e
    • Govind Singh's avatar
      ath10k: disable interface pause wow config for integrated chipset · de8781d7
      Govind Singh authored
      
      
      wow pause iface config controls the PCI D0/D3-WOW cases for pcie
      bus state. Firmware does not expects WOW_IFACE_PAUSE_ENABLED config
      for bus/link that cannot be suspended ex:snoc and does not trigger
      common subsystem shutdown.
      Disable interface pause wow config for integrated chipset(WCN3990)
      for correct WOW configuration in the firmware.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      de8781d7
    • Govind Singh's avatar
      ath10k: enable bus layer suspend/resume for WCN3990 · 185be1c6
      Govind Singh authored
      
      
      Register snoc bus layer suspend/resume PM ops and configure
      the wakeup source(CE2) for the device.
      
      Testing:
          Tested on WCN3990 HW.
          Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1.
      
      Signed-off-by: default avatarGovind Singh <govinds@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      185be1c6
    • Christian Lamparter's avatar
      ath10k: implement set_base_macaddr to fix rx-bssid mask in multiple APs conf · 05e7ba24
      Christian Lamparter authored
      Many integrated QCA9984 WiFis in various IPQ806x platform routers
      from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600,
      etc.) have either blank, bogus or non-unique MAC-addresses in
      their calibration data.
      
      As a result, OpenWrt utilizes a discouraged binary calibration data
      patching method that allows to modify the device's MAC-addresses right
      at the source. This is because the ath10k' firmware extracts the MAC
      address from the supplied radio/calibration data and issues a response
      to the ath10k linux driver. Which was designed to take the main MAC in
      ath10k_wmi_event_ready().
      
      Part of the "setting an alternate MAC" issue was already tackled by a
      patch from Brian Norris:
      commit 9d580466
      ("ath10k: retrieve MAC address from system firmware if provided")
      by allowing the option to specify an alternate MAC-address with the
      established device_get_mac_address() function which extracts the right
      address from DeviceTree/fwnode mac-address or local-mac-address
      properties and saves it for later.
      
      However, Ben Greear noted that the Qualcomm's ath10k firmware is liable
      to not properly calculate its rx-bssid mask in this case. This can cause
      issues in the popluar "multiple AP with a single ath10k instance"
      configurations.
      
      To improve MAC address handling, Felix Fietkau suggested to call
      pdev_set_base_macaddr_cmdid before bringing up the first vif and
      use the first vif MAC address there. Which is in ath10k_core_start().
      
      This patch implement Felix Fietkau's request to
      "call pdev_set_base_macaddr_cmdid before bringing up the first vif".
      The pdev_set_base_macaddr_cmdid is already declared for all devices
      and version. The driver just needed the support code for this
      function.
      
      Tested on:
      QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041
      QCA9887/MR33 firmware:10.2.4-1.0-00033
      QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057
      QCA9984/R7800 firmware: Candela Technologies (CT) Firmware
      
      BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html
      
      
      Fixes: 9d580466 ("ath10k: retrieve MAC address from system firmware if provided")
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Mathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Tested-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      05e7ba24
    • Abhishek Ambure's avatar
      ath10k: update GCMP & GCMP-256 cipher suite number for WCN3990 · 7d94f862
      Abhishek Ambure authored
      
      
      TLV based firmware ex. QCA6174, WCN3990 expects key cipher value
      set to 9 while non-TLV firmware expects key cipher value set to 8
      for enabling GCMP and GCMP-256 cipher suites.
      
      To fix this problem, attach the key cipher suite values based on
      wmi version.
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Signed-off-by: default avatarAbhishek Ambure <aambure@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      7d94f862
    • Abhishek Ambure's avatar
      ath10k: assign 'n_cipher_suites = 11' for WCN3990 to enable WPA3 · 7ba31e6e
      Abhishek Ambure authored
      
      
      Hostapd uses CCMP, GCMP & GCMP-256 as 'wpa_pairwise' option to run WPA3.
      In WCN3990 firmware cipher suite numbers 9 to 11 are for CCMP,
      GCMP & GCMP-256.
      
      To enable CCMP, GCMP & GCMP-256 cipher suites in WCN3990 firmware,
      host sets 'n_cipher_suites = 11' while initializing hardware parameters.
      
      Tested HW: WCN3990
      Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
      
      Signed-off-by: default avatarAbhishek Ambure <aambure@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      7ba31e6e
  2. Feb 08, 2019
  3. Feb 07, 2019