1. 24 Apr, 2018 4 commits
    • Daniel Mack's avatar
      wcn36xx: pass correct BSS index when deleting BSS keys · 0fc8bb50
      Daniel Mack authored
      The firmware message to delete BSS keys expects a BSS index to be passed.
      This field is currently hard-coded to 0. Fix this by passing in the index
      we received from the firmware when the BSS was configured.
      
      The encryption type in that message also needs to be set to what was used
      when the key was set, so the assignment of vif_priv->encrypt_type is now
      done after the firmware command was sent. This reportedly fixes the
      following error in AP mode:
      
        wcn36xx: ERROR hal_remove_bsskey response failed err=6
      
      Also, AFAIU, when a BSS is deleted, the firmware apparently drops all the
      keys associated with it. Trying to remove the key explicitly afterwards
      will hence lead to the following message:
      
        wcn36xx: ERROR hal_remove_bsskey response failed err=16
      
      This is now suppressed with an extra check for the BSS index validity.
      Signed-off-by: default avatarDaniel Mack <daniel@zonque.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      0fc8bb50
    • Wen Gong's avatar
      ath10k: convert wow pattern from 802.3 to 802.11 · fa3440fa
      Wen Gong authored
      When trying to set wow wakeup patterns it fails with this command:
      
      iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx
      
      The reason is that the wow pattern from upper layer is in 802.3 format
      for this case, it need to convert it to 802.11 format. The input
      offset parameter is used for 802.3, but the actual offset firmware
      need depends on rx_decap_mode, so that it needs to be recalculated.
      Pattern of 802.3 packet is not same with 802.11 packet. If the
      rx_decap_mode is ATH10K_HW_TXRX_NATIVE_WIFI, then firmware will
      receive data packet with 802.11 format from hardware.
      
      Tested with QCA6174 hw3.0 with firmware
      WLAN.RM.4.4.1-00099-QCARMSWPZ-1, but this will also affect QCA9377.
      This has always failed, so it's not a regression with new firmware
      releases.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      fa3440fa
    • Carl Huang's avatar
      ath10k: support MAC address randomization in scan · 60e1d0fb
      Carl Huang authored
      The ath10k reports the random_mac_addr capability to upper layer
      based on the service bit firmware reported. Driver sets the
      spoofed flag in scan_ctrl_flag to firmware if upper layer has
      enabled this feature in scan request.
      
      Test with QCA6174 hw3.0 and firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1,
      but QCA9377 is also affected.
      Signed-off-by: default avatarCarl Huang <cjhuang@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      60e1d0fb
    • Carl Huang's avatar
      ath10k: add WMI_SERVICE_AVAILABLE_EVENT support · cea19a6c
      Carl Huang authored
      Add WMI_SERVICE_AVAILABLE_EVENT to extend WMI_SERVICE_READY_EVENT,
      the 128bit service map in WMI_SERVICE_READY_EVENT is not enough
      for firmware to notice new WLAN service to host driver. Hereby,
      for thoese new WLAN service, firmware will notice host driver by
      WMI_SERVICE_AVAILABLE_EVENT.
      Signed-off-by: default avatarAlan Liu <alanliu@codeaurora.org>
      Signed-off-by: default avatarCarl Huang <cjhuang@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      cea19a6c
  2. 19 Apr, 2018 23 commits
  3. 10 Apr, 2018 11 commits
  4. 29 Mar, 2018 2 commits