An error occurred fetching the project authors.
  1. 13 May, 2022 10 commits
  2. 11 Apr, 2022 1 commit
    • Sriram R's avatar
      mac80211: prepare sta handling for MLO support · 046d2e7c
      Sriram R authored
      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: default avatarSriram 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: default avatarJohannes Berg <johannes.berg@intel.com>
      046d2e7c
  3. 16 Mar, 2022 7 commits
  4. 24 Feb, 2022 5 commits
  5. 23 Feb, 2022 4 commits
    • Shayne Chen's avatar
      mt76: mt7915: fix potential memory leak of fw monitor packets · b962252b
      Shayne Chen authored
      Free the skb of fw monitor packets.
      Signed-off-by: default avatarShayne Chen <shayne.chen@mediatek.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      b962252b
    • Bo Jiao's avatar
      mt76: mt7915: Fix channel state update error issue · cef37c78
      Bo Jiao authored
      Fix channel state update error issue due to wrong
      register access for mt7916.
      Signed-off-by: default avatarSujuan Chen <sujuan.chen@mediatek.com>
      Signed-off-by: default avatarBo Jiao <Bo.Jiao@mediatek.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      cef37c78
    • Lorenzo Bianconi's avatar
      mt76: fix endianness errors in reverse_frag0_hdr_trans · d0c0cefb
      Lorenzo Bianconi authored
      Fix ht ctl field size in mt{7615,7915,7921}_reverse_frag0_hdr_trans.
      Fix the following endianness warnings in mt{7615,7915,7921}_reverse_frag0_hdr_trans:
      
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: cast to restricted __le32
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: warning: incorrect type in assignment (different base types)
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27:    expected restricted __le16 [usertype] frame_control
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27:    got unsigned long
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: cast to restricted __le32
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: warning: incorrect type in assignment (different base types)
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22:    expected restricted __le16 [usertype] seq_ctrl
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22:    got unsigned long
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: cast to restricted __le32
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: warning: incorrect type in assignment (different base types)
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18:    expected restricted __le32 [usertype] qos_ctrl
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18:    got unsigned long
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: cast to restricted __le32
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: warning: incorrect type in assignment (different base types)
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17:    expected restricted __le32 [usertype] ht_ctrl
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17:    got unsigned long
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:25: warning: restricted __be16 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:38: warning: restricted __be16 degrades to integer
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: warning: incorrect type in assignment (different base types)
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23:    expected unsigned int [usertype] *cur_info
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23:    got restricted __le32 *
      drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1451:34: warning: cast to restricted __le32
      
      Fixes: dc5399a5 ("mt76: reverse the first fragmented frame to 802.11")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      d0c0cefb
    • Johan Almbladh's avatar
      mt76: mt7915: fix injected MPDU transmission to not use HW A-MSDU · 28225a6e
      Johan Almbladh authored
      Before, the hardware would be allowed to transmit injected 802.11 MPDUs
      as A-MSDU. This resulted in corrupted frames being transmitted. Now,
      injected MPDUs are transmitted as-is, without A-MSDU.
      
      The fix was verified with frame injection on MT7915 hardware, both with
      and without the injected frame being encrypted.
      
      If the hardware cannot do A-MSDU aggregation on MPDUs, this problem
      would also be present in the TX path where mac80211 does the 802.11
      encapsulation. However, I have not observed any such problem when
      disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode.
      Therefore this fix is isolated to injected frames only.
      
      The same A-MSDU logic is also present in the mt7921 driver, so it is
      likely that this fix should be applied there too. I do not have access
      to mt7921 hardware so I have not been able to test that.
      Signed-off-by: default avatarJohan Almbladh <johan.almbladh@anyfinetworks.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      28225a6e
  6. 03 Feb, 2022 12 commits
  7. 19 Dec, 2021 1 commit