1. 16 6月, 2015 2 次提交
  2. 09 6月, 2015 3 次提交
    • M
      ath10k: fix channel switching · 0e6eb417
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0e6eb417
    • 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
    • M
      ath10k: fix ar->rx_channel updating logic · d7bf4b4a
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d7bf4b4a
  3. 22 5月, 2015 1 次提交
  4. 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
  5. 24 4月, 2015 1 次提交
    • J
      mac80211: remove support for IFF_PROMISC · df140465
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      df140465
  6. 22 4月, 2015 1 次提交
  7. 17 4月, 2015 5 次提交
    • J
      ath10k: enable ibss-rsn · 0cd9bc14
      Janusz Dziedzic 提交于
      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: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0cd9bc14
    • M
      ath10k: set def key idx for ibss · 8461baf7
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8461baf7
    • M
      ath10k: fix multiple key static wep with ibss · ce90b271
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ce90b271
    • M
      ath10k: don't use reassoc flag · 73dc5a1d
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      73dc5a1d
    • M
      ath10k: change static wep key handling for client mode · 29a10006
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      29a10006
  8. 15 4月, 2015 2 次提交
  9. 09 4月, 2015 3 次提交
  10. 02 4月, 2015 8 次提交
  11. 30 3月, 2015 13 次提交