1. 13 Aug, 2015 4 commits
  2. 29 Jul, 2015 1 commit
    • David Liu's avatar
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu authored
      
      
      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: default avatarDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Tested-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  3. 24 Jul, 2015 1 commit
  4. 11 Jul, 2015 6 commits
  5. 01 Jul, 2015 1 commit
  6. 30 Jun, 2015 1 commit
  7. 16 Jun, 2015 2 commits
  8. 10 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg authored
      
      
      As we're running out of hardware capability flags pretty quickly,
      convert them to use the regular test_bit() style unsigned long
      bitmaps.
      
      This introduces a number of helper functions/macros to set and to
      test the bits, along with new debugfs code.
      
      The occurrences of an explicit __clear_bit() are intentional, the
      drivers were never supposed to change their supported bits on the
      fly. We should investigate changing this to be a per-frame flag.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      30686bf7
  9. 09 Jun, 2015 3 commits
    • Michal Kazior's avatar
      ath10k: fix channel switching · 0e6eb417
      Michal Kazior authored
      In the midst of chanctx patch review channel
      switching became broken which I failed to notice
      until now.
      
      Function ath10k_mac_vif_chan() reports current
      chandef which isn't updated until after
      switch_vif_chanctx() is returned from.
      Consequently the driver just restarted operation
      on channels it was residing already instead of
      switching to the new ones.
      
      Fixes: 500ff9f9
      
       ("ath10k: implement chanctx API")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0e6eb417
    • Michal Kazior's avatar
      ath10k: remove ath10k_chanctx struct · 089ab7a5
      Michal Kazior authored
      
      
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      089ab7a5
    • Michal Kazior's avatar
      ath10k: fix ar->rx_channel updating logic · d7bf4b4a
      Michal Kazior authored
      Channel contexts aren't iterable until after
      they've been added to the driver. The code assumed
      otherwise.
      
      This problem could result in:
      
       * rx_channel being NULL and forcing Rx path to go
         the slow way to get channel on QCA988X,
      
       * report incorrect channel when running
         multi-channel on QCA61X4 hw2.1,
      
       * report incorrect channel after AP channel
         switch.
      
      Fixes: 500ff9f9
      
       ("ath10k: implement chanctx API")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d7bf4b4a
  10. 22 May, 2015 1 commit
  11. 27 Apr, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: implement more versatile set_bitrate_mask · 45c9abc0
      Michal Kazior authored
      
      
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      45c9abc0
  12. 24 Apr, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: remove support for IFF_PROMISC · df140465
      Johannes Berg authored
      
      
      This support is essentially useless as typically networks are encrypted,
      frames will be filtered by hardware, and rate scaling will be done with
      the intended recipient in mind. For real monitoring of the network, the
      monitor mode support should be used instead.
      
      Removing it removes a lot of corner cases.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      df140465
  13. 22 Apr, 2015 1 commit
  14. 17 Apr, 2015 5 commits
    • Janusz Dziedzic's avatar
      ath10k: enable ibss-rsn · 0cd9bc14
      Janusz Dziedzic authored
      
      
      With latest additions to the driver it seems
      viable to enable support for IBSS-RSN.
      
      It seems to work on QCA988X and 999.999.0.636 but
      is a bit slow to exchange RSN keys for some
      reason. This may be a firmware quirk or ath10k is
      missing something. Nevertheless it makes sense to
      finally enable IBSS-RSN in ath10k even if somewhat
      handicapped.
      
      QCA6174 firmware doesn't seem to be able to Tx
      EAPOL frames at all now (they get stuck in hw
      queues for some reason) so it never gets to set
      the keys in driver. It's fairly safe to assume that
      once this is fixed IBSS-RSN will work with QCA6174
      firmware without any additional changes. Hence no
      special handling for advertising
      IEEE80211_HW_SUPPORTS_PER_STA_GTK and
      WIPHY_FLAG_IBSS_RSN is done now.
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0cd9bc14
    • Michal Kazior's avatar
      ath10k: set def key idx for ibss · 8461baf7
      Michal Kazior authored
      
      
      Some time ago there was a weird issue with AP
      using wrong multicast keys and generating
      corrupted traffic on 10.1 firmware.
      
      Apparently a very similar problem applies for
      IBSS-RSN on 999.999.0.636.
      
      ath10k doesn't have IBSS-RSN enabled yet. This
      patch is a prerequisite to support it.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      8461baf7
    • Michal Kazior's avatar
      ath10k: fix multiple key static wep with ibss · ce90b271
      Michal Kazior authored
      
      
      Apparently firmware requires both pairwise and
      groupwise keys to be installed per-peer for static
      WEP in IBSS. This wasn't necessary for AP mode
      (and installing both doesn't seem to break AP
      mode thus there's no special handling).
      
      Also there seems to be some kind of issue with
      mapping tx/rx keys in firmware properly which
      resulted in wrong keys being used and broken
      communication between devices.
      
      It can be argued the vdev param part is more of a
      workaround than a real fix. However I couldn't
      figure out how to fix this differently. It works
      and isn't super ugly.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ce90b271
    • Michal Kazior's avatar
      ath10k: don't use reassoc flag · 73dc5a1d
      Michal Kazior authored
      
      
      Firmware actually re-creates peer entry when
      reassoc flag is set. This is undesired and could
      cause trouble with IBSS crypto-wise. This is also
      important for upcomming bitrate mask improvement.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      73dc5a1d
    • Michal Kazior's avatar
      ath10k: change static wep key handling for client mode · 29a10006
      Michal Kazior authored
      
      
      mac80211 sets static WEP keys as groupwise while
      firmware requires them to be installed twice as
      both pairwise and groupwise.
      
      Until now these keys were installed once as
      pairwise only and, due to that special handling,
      needed additional tricks to support 802.1x as
      well.
      
      Without this patch in some cases (when AP and
      ath10k client use different default tx keys)
      multicast communication was broken.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      29a10006
  15. 15 Apr, 2015 2 commits
  16. 09 Apr, 2015 3 commits
  17. 01 Apr, 2015 6 commits