1. 29 7月, 2015 1 次提交
    • D
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu 提交于
      This patch enables raw Rx/Tx encap mode to support software based
      crypto engine. This patch introduces a new module param 'cryptmode'.
      
       cryptmode:
      
         0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
            encapsulation to the firmware. This is the default mode.
         1: Use sofware crypto engine globally with raw mode TX/RX
            encapsulation to the firmware.
      
      Known limitation:
         A-MSDU must be disabled for RAW Tx encap mode to perform well when
         heavy traffic is applied.
      
      Testing: (by Michal Kazior <michal.kazior@tieto.com>)
      
           a) Performance Testing
      
            cryptmode=1
             ap=qca988x sta=killer1525
              killer1525  ->  qca988x     194.496 mbps [tcp1 ip4]
              killer1525  ->  qca988x     238.309 mbps [tcp5 ip4]
              killer1525  ->  qca988x     266.958 mbps [udp1 ip4]
              killer1525  ->  qca988x     477.468 mbps [udp5 ip4]
              qca988x     ->  killer1525  301.378 mbps [tcp1 ip4]
              qca988x     ->  killer1525  297.949 mbps [tcp5 ip4]
              qca988x     ->  killer1525  331.351 mbps [udp1 ip4]
              qca988x     ->  killer1525  371.528 mbps [udp5 ip4]
             ap=killer1525 sta=qca988x
              qca988x     ->  killer1525  331.447 mbps [tcp1 ip4]
              qca988x     ->  killer1525  328.783 mbps [tcp5 ip4]
              qca988x     ->  killer1525  375.309 mbps [udp1 ip4]
              qca988x     ->  killer1525  403.379 mbps [udp5 ip4]
              killer1525  ->  qca988x     203.689 mbps [tcp1 ip4]
              killer1525  ->  qca988x     222.339 mbps [tcp5 ip4]
              killer1525  ->  qca988x     264.199 mbps [udp1 ip4]
              killer1525  ->  qca988x     479.371 mbps [udp5 ip4]
      
            Note:
             - only open network tested for RAW vs nwifi performance comparison
             - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
             - used iperf
             - OTA, devices a few cm apart from each other, no shielding
             - tcpX/udpX, X - means number of threads used
      
            Overview:
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
      
           b) Connectivity Testing
      
            cryptmode=1
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
      
            Note:
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
      
           c) Testbed Topology:
      
            1ap1sta:
              [ap] ---- [sta]
      
              endpoints: ap, sta
      
            1ap1sta2br:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
      
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
      
            1ap1sta2br1vlan:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                [br0]              [br1]
                  |                  |
                [vlan0_id2]        [vlan1_id2]
      
              endpoints: vlan0_id2, vlan1_id2
              note: STA works in 4addr mode, AP has wds_sta=1
      
      Credits:
      
          Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
          amsdu issue, contributed a workaround (already squashed into this
          patch), and contributed the throughput and connectivity tests results.
      Signed-off-by: NDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Tested-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  2. 12 7月, 2015 1 次提交
  3. 02 7月, 2015 3 次提交
    • R
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani 提交于
      Pre qca99X0 chipsets follows the model where dynamically allocate
      memory for frag desc on getting new skb for TX. But, this is not
      going to be the case in qca99X0. It expects frag desc memory to be
      allocated at boot time and let the driver to reuse allocated memory
      after every TX completion. So there won't be any dynamic frag memory
      memory allocation in qca99X0 during data transmission.
      
      qca99X0 hardware doesn't need fragment desc address to be programmed
      in msdu descriptor for every data transaction. It needs to know only
      starting address of fragment descriptor at the time of the boot.
      During data transmission, qca99X0 hardware can retrieve corresponding
      frag addr by adding programmed frag desc base addr + msdu id.
      
      Allocate continuous fragment descriptor memory (same size as number of
      descriptor) at the time of target initialization and configure allocated
      dma address to the target via HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG.
      
      How this is allocated continuous memory is going to be used is not
      covered in this patch. It just allocates memory and hand over to firmware.
      If we don't do it at init time, qca99X0 will stall when firmware tries
      to do TX.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
    • R
      ath10k: set max spatial stream to 4 for 10.4 fw · 5c8726ec
      Raja Mani 提交于
      10.4 fw supports upto 4 spatial stream. Limit max spatial
      stream to 4 for 10.4 firmware and to 3 for non 10.4 firmware.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5c8726ec
    • R
      ath10k: handle 10.4 firmware wmi swba event · 3cec3be3
      Raja Mani 提交于
      10.4 firmware swba event payload has space to accommodate upto
      512 client traffic indication info & one p2p noa descriptor.
      It's is not matching with exiting swba event format defined for
      non 10.4 firmware. Non 10.4 firmware swba event format is designed
      to support only upto only 128 client and four p2p notice of absence
      descriptor.
      
      following changes are done in this patch to enable ath10k to handle
      10.4 firmware swba event,
      
       - link generic ath10k_wmi_event_host_swba() to handle 10.4 swba
         event in 10.4 wmi rx handler.
      
       - add 10.4 specific swba event structure wmi_10_4_host_swba_event.
      
       - new function ath10k_wmi_10_4_op_pull_swba_ev() to parse
         10.4 swba event.
      
       - increase tim_bitmap[] size in ath10k_vif to 64 to hold 512 station
         power save state.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      3cec3be3
  4. 30 6月, 2015 4 次提交
  5. 16 6月, 2015 1 次提交
  6. 09 6月, 2015 1 次提交
    • M
      ath10k: remove ath10k_chanctx struct · 089ab7a5
      Michal Kazior 提交于
      In practice there's no point in having a copy of
      chanctx_conf.
      
      Most of the time the channel pointer (and band
      along with it) is accessed and this can't change
      after a chanctx is created because switching is
      done using explicit chanctx swapping via
      switch_vif_chanctx().
      
      The only thing that can change within a
      chanctx_conf and is used by the driver is
      radar_enabled and channel width. These are however
      always accessed in adequate mac80211 callback
      context which guarantees safe access to the
      chanctx data.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      089ab7a5
  7. 01 6月, 2015 1 次提交
  8. 29 5月, 2015 2 次提交
    • M
      ath10k: fix inconsistent survey reports · 44b7d483
      Michal Kazior 提交于
      In some cases some channel survey data was
      reported incorrect.
      
      Channel info events were expected to come in pairs
      without and with COMPLETE flag set respectively
      for each channel visit during scan.
      
      The known deviation from this is rule for last
      scan chan info and first (next) scan chan info
      both have COMPLETE flag set. This was either
      programmed with the intent of providing BSS cycle
      count info or this is an artefact of firmware scan
      state machine. Either way this is useless due to
      short wraparound time, wraparound quirks and no
      overflow notification.
      
      Survey dumps now include only data gathered during
      scan channel visits that can be computed
      correctly.
      
      This should improve hostapd ACS a little bit.
      Reported-by: NSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      44b7d483
    • M
      ath10k: handle cycle counter wraparound · 587f7031
      Michal Kazior 提交于
      When QCA988X cycle counter HW register wraps
      around it resets to 0x7fffffff instead of 0. All
      other cycle counter related registers are divided
      by 2 so they never wraparound themselves. QCA61X4
      has a uniform CC and it wraparounds in a regular
      fashion though.
      
      Worst case wraparound time is approx 24 seconds
      (2**31 / 88MHz). Since scan channel visit times
      are max 5 seconds (offchannel case) it is
      guaranteed there's been at most 1 wraparound and
      it is possible to compute survey active time
      value. It is, however, impossible to determine the
      point at which Rx Clear Count has been divided by
      two so it is not reported upon wraparound.
      
      This fixes some occasional incorrect survey data
      on QCA988X as some channels (depending on how/when
      scan/offchannel requests were requested) would
      have approx 24 sec active time which wasn't
      actually the case.
      
      This should improve hostapd ACS a little bit.
      Reported-by: NSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      587f7031
  9. 22 5月, 2015 1 次提交
    • M
      ath10k: add new 4addr related fw_feature · 48f4ca34
      Michal Kazior 提交于
      Some firmware revisions pad 4th hw address in
      Native Wifi Rx decap. This is the case with 10.x
      and it was assumed that this is true for all
      firmware images.
      
      However QCA988X with 999.999.0.636 and QCA61X4
      with WLAN.RM.2.0-00088 don't have the padding.
      Hence add a feature flag indicating that the
      padding isn't present so firmware images can
      advertise it appropriately. This way driver will
      behave as it was before with old firmware blobs
      and doesn't cause any regressions from user
      perspective.
      
      Effectively this patch enables QCA988X with
      999.999.0.636 and QCA61X4 with WLAN.RM.2.0-00088
      to set up client bridging provided user has an
      updated firmware blob.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      48f4ca34
  10. 05 5月, 2015 1 次提交
    • K
      ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT · d9153546
      Kalle Valo 提交于
      qca6174 otp binary seems to always return an error to the host, even if the
      calibration succeeded. Add a firmware feature flag to detect if the firmware
      image which have this problem and workaround the issue in ath10k by ignoring
      the error code.
      
      I was also considering making this hw specific flag but as this is strictly a
      firmware issue it's best to handle this via a firmware feature flag so that it
      will be easy to disable the workaround.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9153546
  11. 27 4月, 2015 1 次提交
    • M
      ath10k: implement more versatile set_bitrate_mask · 45c9abc0
      Michal Kazior 提交于
      Until now only a single fixed tx rate or nss was
      allowed to be set.
      
      The patch attempts to improve this by allowing
      most bitrate masks. The limitation is VHT MCS
      rates cannot be expressed separately using
      existing firmware interfaces and only the
      following VHT MCS ranges are supported: none, 0-7,
      0-8, and 0-9.
      
      This keeps the old behaviour when requesting
      single tx rate or single nss. The new bitrate mask
      logic is only applied to other cases that would
      return -EINVAL until now.
      
      Depending on firmware revisions some combinations
      may crash firmware so use with care, please.
      
      This depends on "ath10k: don't use reassoc flag".
      Without it key cache would effectively be
      invalidated upon bitrate change leading to
      communication being no longer possible.
      
      These work:
      
        iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
        iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
        iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
      
      These won't work:
      
        iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
        iw wlan0 set bitrates vht-mcs-5 2:7-9
      
      (note the invalid VHT MCS ranges)
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      45c9abc0
  12. 22 4月, 2015 1 次提交
    • M
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior 提交于
      Some devices differ slightly and require different
      board files. If wrong board data is used they
      crash or behave incorrectly.
      
      These devices can be differentiated by looking at
      PCI subsystem device id. That is the case for
      qca61x4 devices at least.
      
      The board specific filename is constructed as:
      
       board-<bus>-<id>.bin
      
      For PCI in particular it is:
      
       board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin
      
      These files are looked in device/hw specific
      directories. Hence for Killer 1525 (qca6174 hw2.1)
      ath10k will request:
      
        /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin
      
      To not break any existing setups (e.g. in case
      some devices in the wild already have subsys ids)
      if a board specific file isn't found a generic one
      is used which is the one which would be used until
      now. This guarantees that after upgrading a driver
      device will not suddenly stop working due to
      now-missing specific board file. If this is the
      case a "fallback" string is appended to the info
      string when driver boots.
      
      Keep in mind this is distinct from cal-pci-*.bin
      files which contain full calibration data and MAC
      address. Cal data is aimed at systems where
      calibration data is stored out of band, e.g. on
      nand flash instead of device EEPROM - an approach
      taken by some AP/router vendors.
      
      Board files are more of a template and needs some
      bits to be filled in by the OTP program using
      device EEPROM contents.
      
      One could argue to map subsystem ids to some board
      design codename strings instead of using raw ids
      when building the board filename. Using a mapping
      however would make it a lot more cumbersome and
      time consuming (due to how patches propagate over
      various kernel trees) to add support for some new
      device board designs. Adding a board file is a lot
      quicker and doesn't require recompilation.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
  13. 09 4月, 2015 1 次提交
  14. 02 4月, 2015 4 次提交
  15. 30 3月, 2015 3 次提交
  16. 23 3月, 2015 2 次提交
  17. 12 3月, 2015 1 次提交
  18. 07 3月, 2015 1 次提交
    • M
      ath10k: fix AP/IBSS CSA with template based fw · 81a9a17d
      Michal Kazior 提交于
      qca6174 with wmi-tlv firmware uses offloaded
      beaconing scheme (i.e. templates). This requires a
      little different approach when implementing CSA.
      
      Add missing code to update CS count and report CSA
      completion to mac80211. Without it channel switch
      was never finished.
      
      To avoid races during interface teardown data_lock
      has been used to protect is_up and is_started so
      they can be compared against before scheduling
      count down work.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      81a9a17d
  19. 04 3月, 2015 1 次提交
  20. 15 2月, 2015 1 次提交
  21. 04 2月, 2015 3 次提交
    • S
      ath10k: add log level configuration for fw_dbglog · 467210a6
      SenthilKumar Jegadeesan 提交于
      Introduce an optional log level configuration for the existing debugfs fw_dbglog file. It
      allows users to configure the desired log level for firmware dbglog messages.
      
      To configure log level as WARN:
      
      echo 0xffffffff  2 > /sys/kernel/debug/ieee80211/phy0/ath10k/fw_dbglog
      
      The values are:
      
      VERBOSE		0
      INFO		1
      WARN		2
      ERR		3
      Signed-off-by: NSenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      467210a6
    • M
      ath10k: fix beacon deadlock · af21319f
      Michal Kazior 提交于
      This should fix a very rare occurrence of the following deadlock:
      
        [<ffffffffa018265e>] ath10k_wmi_tx_beacons_nowait+0x1e/0x50 [ath10k_core]
        [<ffffffffa01829b6>] ath10k_wmi_op_ep_tx_credits+0x16/0x40 [ath10k_core]
        [<ffffffffa017d685>] ath10k_htc_send+0x285/0x3d0 [ath10k_core]
        [<ffffffffa0184b81>] ath10k_wmi_cmd_send_nowait+0x81/0x110 [ath10k_core]
        [<ffffffffa0184c61>] ath10k_wmi_tx_beacon_nowait.part.33+0x51/0x90 [ath10k_core]
        [<ffffffffa0184cd0>] ath10k_wmi_tx_beacons_iter+0x30/0x40 [ath10k_core]
        [<ffffffff81882246>] __iterate_active_interfaces+0xa6/0x100
        [<ffffffffa0184ca0>] ? ath10k_wmi_tx_beacon_nowait.part.33+0x90/0x90 [ath10k_core]
        [<ffffffff818822ae>] ieee80211_iterate_active_interfaces_atomic+0xe/0x10
        [<ffffffffa0182676>] ath10k_wmi_tx_beacons_nowait+0x36/0x50 [ath10k_core]
        [<ffffffffa01829b6>] ath10k_wmi_op_ep_tx_credits+0x16/0x40 [ath10k_core]
        [<ffffffffa017d140>] ath10k_htc_rx+0x280/0x410 [ath10k_core]
        [<ffffffffa01bcbf0>] ? ath10k_ce_completed_recv_next+0x60/0x80 [ath10k_pci]
        [<ffffffffa01bc6ab>] ath10k_pci_ce_recv_data+0x11b/0x1d0 [ath10k_pci]
        [<ffffffffa01bcf44>] ath10k_ce_per_engine_service+0x64/0xc0 [ath10k_pci]
        [<ffffffffa01bcfc2>] ath10k_ce_per_engine_service_any+0x22/0x50 [ath10k_pci]
        [<ffffffffa01bc4d0>] ath10k_pci_tasklet+0x30/0x90 [ath10k_pci]
        [<ffffffff81055a55>] tasklet_action+0xc5/0x100
      
      To prevent this make sure to release ar->data_lock
      while calling to ath10k_wmi_beacon_send_ref_nowait().
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      af21319f
    • S
      ath10k: prevent setting wrong key idx for station · 627613f8
      SenthilKumar Jegadeesan 提交于
      Ath10k driver sets wrong default key idx that results in
      sending unicast frames with multicast key.
      
      The reason for this behavior is that cached broadcast key
      is installed for station MAC address on association. After
      dot1x completes, unicast key is installed for station
      MAC address. Default key idx is set to broadcast key id when
      driver tries to send broadcast frame. This causes firmware
      to use broadcast key id to transmit unicast frames to stations.
      
      Used TX_USAGE flag to set default key for stations.
      
      Added callback for setting unicast default idx which will be
      invoked on every default key idx configuration.
      Signed-off-by: NSenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      627613f8
  22. 29 1月, 2015 1 次提交
  23. 27 1月, 2015 3 次提交
  24. 13 1月, 2015 1 次提交
    • R
      ath10k: Implement sta_add_debugfs · f5045988
      Rajkumar Manoharan 提交于
      Add per station debugfs files when a station is added to mac80211's
      station list. This helps to group peer specific debugfs entries
      altogether. Right now this callback adds support to test aggregation
      procedures (addba/addba_resp/delba) manually.
      
      To enable automatic aggregation in target,
      echo 0 >/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/
      	stations/XX:XX:XX:XX:XX:XX/aggr_mode
      
      For manual mode,
      echo 1 >/sys/kernel/debug/ieee80211/phyX/netdev:wlanX/
      	stations/XX:XX:XX:XX:XX:XX/aggr_mode
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      f5045988