1. 10 11月, 2022 1 次提交
  2. 06 9月, 2022 1 次提交
  3. 20 6月, 2022 1 次提交
    • J
      wifi: mac80211: move some future per-link data to bss_conf · d0a9123e
      Johannes Berg 提交于
      To add MLD, reuse the bss_conf structure later for per-link
      information, so move some things into it that are per link.
      
      Most transformations were done with the following spatch:
      
          @@
          expression sdata;
          identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
          @@
          -sdata->vif.var
          +sdata->vif.bss_conf.var
      
          @@
          struct ieee80211_vif *vif;
          identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
          @@
          -vif->var
          +vif->bss_conf.var
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d0a9123e
  4. 11 4月, 2022 1 次提交
    • S
      mac80211: prepare sta handling for MLO support · 046d2e7c
      Sriram R 提交于
      Currently in mac80211 each STA object is represented
      using sta_info datastructure with the associated
      STA specific information and drivers access ieee80211_sta
      part of it.
      
      With MLO (Multi Link Operation) support being added
      in 802.11be standard, though the association is logically
      with a single Multi Link capable STA, at the physical level
      communication can happen via different advertised
      links (uniquely identified by Channel, operating class,
      BSSID) and hence the need to handle multiple link
      STA parameters within a composite sta_info object
      called the MLD STA. The different link STA part of
      MLD STA are identified using the link address which can
      be same or different as the MLD STA address and unique
      link id based on the link vif.
      
      To support extension of such a model, the sta_info
      datastructure is modified to hold multiple link STA
      objects with link specific params currently within
      sta_info moved to this new structure. Similarly this is
      done for ieee80211_sta as well which will be accessed
      within mac80211 as well as by drivers, hence trivial
      driver changes are expected to support this.
      
      For current non MLO supported drivers, only one link STA
      is present and link information is accessed via 'deflink'
      member.
      
      For MLO drivers, we still need to define the APIs etc. to
      get the correct link ID and access the correct part of
      the station info.
      
      Currently in mac80211, all link STA info are accessed directly
      via deflink. These will be updated to access via link pointers
      indexed by link id with MLO support patches, with link id
      being 0 for non MLO supported cases.
      
      Except for couple of macro related changes, below spatch takes
      care of updating mac80211 and driver code to access to the
      link STA info via deflink.
      
        @ieee80211_sta@
        struct ieee80211_sta *s;
        struct sta_info *si;
        identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
        @@
      
        (
          s->
        -    var
        +    deflink.var
        |
         si->sta.
        -    var
        +    deflink.var
        )
      
        @sta_info@
        struct sta_info *si;
        identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
        @@
      
        (
          si->
        -    var
        +    deflink.var
        )
      Signed-off-by: NSriram R <quic_srirrama@quicinc.com>
      Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
      [remove MLO-drivers notes from commit message, not clear yet; run spatch]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      046d2e7c
  5. 18 2月, 2022 4 次提交
  6. 03 2月, 2022 1 次提交
  7. 21 12月, 2021 2 次提交
  8. 09 12月, 2021 1 次提交
  9. 27 11月, 2021 1 次提交
    • E
      iwlwifi: integrate with iwlmei · 6d19a5eb
      Emmanuel Grumbach 提交于
      iwlmei needs to know about the follwing events:
      
      * Association
      * De-association
      * Country Code change
      * SW Rfkill change
      * SAR table changes
      
      iwlmei can take the device away from us, so report the new
      rfkill type when this happens.
      Advertise the required data from the CSME firmware to the
      usersapce: mostly, the AP that the CSME firmware is currently
      associated to in case there is an active link protection
      session.
      Generate the HOST_ASSOC / HOST_DISSASSOC messages.
      
      Don't support WPA1 (non-RSNA) for now.
      Don't support shared wep either.
      We can then determine the AUTH parameter by checking the AKM.
      Feed the cipher from the key installation.
      
      SW Rfkill will be implemented later when cfg80211 will
      allow us to read the SW Rfkill state.
      Co-Developed-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      
      v7: Ayala added her signed-off
          remove pointless function declaration
          fix a bug due to merge conflict in the HOST_ASSOC message
      v8: leave a print if we have a SAP connection on a device we do
          not support (yet)
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211112062814.7502-4-emmanuel.grumbach@intel.com
      6d19a5eb
  10. 22 10月, 2021 5 次提交
  11. 23 6月, 2021 1 次提交
  12. 10 2月, 2021 1 次提交
  13. 05 2月, 2021 4 次提交
  14. 27 1月, 2021 1 次提交
  15. 12 12月, 2020 1 次提交
  16. 10 12月, 2020 2 次提交
  17. 09 10月, 2020 3 次提交
  18. 08 10月, 2020 1 次提交
    • L
      iwlwifi: mvm: tx: Demote misuse of kernel-doc headers · 91b4780f
      Lee Jones 提交于
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1379: warning: Function parameter or member 'rate_n_flags' not described in 'iwl_mvm_hwrate_to_tx_status'
       drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1379: warning: Function parameter or member 'info' not described in 'iwl_mvm_hwrate_to_tx_status'
       drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1431: warning: Function parameter or member 'mvm' not described in 'iwl_mvm_get_scd_ssn'
      
      Cc: Johannes Berg <johannes.berg@intel.com>
      Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Cc: Luca Coelho <luciano.coelho@intel.com>
      Cc: Intel Linux Wireless <linuxwifi@intel.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200910065431.657636-14-lee.jones@linaro.org
      91b4780f
  19. 02 10月, 2020 1 次提交
  20. 08 5月, 2020 1 次提交
  21. 09 1月, 2020 1 次提交
  22. 24 12月, 2019 2 次提交
  23. 23 12月, 2019 1 次提交
    • J
      iwlwifi: pcie: allocate smaller dev_cmd for TX headers · a89c72ff
      Johannes Berg 提交于
      As noted in the previous commit, due to the way we allocate the
      dev_cmd headers with 324 byte size, and 4/8 byte alignment, the
      part we use of them (bytes 20..40-68) could still cross a page
      and thus 2^32 boundary.
      
      Address this by using alignment to ensure that the allocation
      cannot cross a page boundary, on hardware that's affected. To
      make that not cause more memory consumption, reduce the size of
      the allocations to the necessary size - we go from 324 bytes in
      each allocation to 60/68 on gen2 depending on family, and ~120
      or so on gen1 (so on gen1 it's a pure reduction in size, since
      we don't need alignment there).
      
      To avoid size and clearing issues, add a new structure that's
      just the header, and use kmem_cache_zalloc().
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      a89c72ff
  24. 15 11月, 2019 2 次提交