- 08 Feb, 2024 40 commits
-
-
Aditya Kumar Singh authored
Add changes to start a channel switch as well as finalize it on link basis in order to support CSA with MLO as well. Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-5-quic_adisi@quicinc.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Aditya Kumar Singh authored
In order to support CSA with MLO, there is a need to handle the functions ieee80211_set_csa_beacon() and ieee80211_set_after_csa_beacon() on a per link basis. Implement this by making the function argument accept the the link data instead of the sdata. Currently, deflink would only be passed. Proper link data will be passed in a subsequent patch. Signed-off-by:
-
Aditya Kumar Singh authored
Currently, function to update beacon counter uses deflink to fetch the beacon and then update the counter. However, with MLO, there is a need to update the counter for the beacon in a particular link. Add support to use link_id in order to fetch the beacon from a particular link data during beacon update counter. Signed-off-by:
-
Aditya Kumar Singh authored
Currently, during channel switch, no link id information is passed down. In order to support channel switch during Multi Link Operation, it is required to pass link id as well. Add changes to pass link id in the channel_switch cfg80211_ops. Signed-off-by:
-
Michael-CY Lee authored
The new Wi-Fi Standard (IEEE Std 802.11-2020 9.4.2.160) specifies that the Wide Bandwidth Channel Switch (WBCS) Element subfields have the same definitions as VHT operation information if the operating band is not S1G. The problem comes when the BSS is in 6 GHz band, the STA parses the WBCS Element by ieee80211_chandef_vht_oper(), which checks the capabilities for HT/VHT mode, not HE/EHT mode. This patch refactors STA CSA parsing flow so that the corresponding capabilities can be checked. Also, it adds the way to use op_class in ECSA Element to build a new chandef. In summary, the new steps for STA to handle CSA event are: 1. build the new chandef from one of the CSA-related (Sub)Elements in following order, - Bandwidth Indication (Sub)Element - Wide Bandwidth Channel Switch (Sub)Element - Operating class in Extended Channel Switch Announcement Element - Channel Switch Announcement Element 2. convert the new chandef into operation information according to the operating band in order to check if the new chandef fits STA's capabilities. 3. downgrade the bandwidth until current bandwidth is not disabled. Co-developed-by:
Money Wang <money.wang@mediatek.com> Signed-off-by:
Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://msgid.link/20231222010914.6521-3-michael-cy.lee@mediatek.com [rebase on top of the changes with struct ieee80211_conn_settings, prefer leXY_encode_bits()] Signed-off-by:
-
Michael-CY Lee authored
This utility is used in STA CSA handling. The op_class in the ECSA Element can be converted into chandef. Co-developed-by:
-
Dan Carpenter authored
The '-' character is missing in -EINVAL. Fixes: fc7214c3 ("wifi: iwlwifi: read DSM functions from UEFI") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://msgid.link/f0391316-ab30-4664-96ac-03445ab2aeba@moroto.mountainSigned-off-by:
-
Johannes Berg authored
Some drivers may (notably mt76 does) not set up sband->band before registering, and cfg80211 will fill it in later. But since the HT/HE capability check mac80211 required it to be initialized already, otherwise failing things. This really isn't necessary though since the code is iterating the list of bands, and has the 'band' variable available. Fix it to not require the sband->band to be initialized already. Fixes: f04d2c24 ("wifi: mac80211: disallow drivers with HT wider than HE") Reported-by:
Bert Karwatzki <spasswolf@web.de> Debugged-by:
-
Johannes Berg authored
Some kernel-doc is missing here, add it. Link: https://msgid.link/20240206134555.eb95c1dfc1f0.Ibaf8b3249d9de59358bf6503fe4a186d9ac6544d@changeidSigned-off-by:
-
Johannes Berg authored
This was added earlier, add kernel-doc for it. Link: https://msgid.link/20240206134555.6354b0ac8610.Ib90d3651834c556b73697388f59bd396a1f6f9b0@changeidSigned-off-by:
-
Johannes Berg authored
The vif pointer at least looks like it can actually be NULL in some cases such as the monitor-mode vif, causing static checkers to complain with the immediate derefence. In these cases the sta pointer will also be NULL, but clarify it in the code anyway. Link: https://msgid.link/20240131164910.60066625a239.Idfb6a5a9876f9f631eae760055e1c4018259a971@changeidSigned-off-by:
-
Johannes Berg authored
This could be used e.g. for temporarily sending quiet (mode=1 in CSA/ECSA), or updating bandwidth. This is also useful for testing, since it's something that an AP may do and the client needs to be prepared. Simply allow it. Link: https://msgid.link/20240129203544.ef7258d5790d.Idafe22e41621757458d4960659b9621853f7104d@changeidSigned-off-by:
-
Johannes Berg authored
Convert ieee80211_ie_build_eht_cap() to the SKB-put function style, renaming it to ieee80211_put_eht_cap(). Link: https://msgid.link/20240129202041.ece9769e3c94.Ibd17bea6311f0c7ba56f6c1803fa3208abaaebb9@changeidSigned-off-by:
-
Johannes Berg authored
Convert ieee80211_ie_build_he_cap() to the SKB-put function style, renaming it to ieee80211_put_he_cap(). Link: https://msgid.link/20240129202041.e6ef888980d9.Ied9e014314b5d27611e693e3d4cb63bdc8d7de17@changeidSigned-off-by:
-
Johannes Berg authored
This code got really big, move it to a new file. Pure code move. Link: https://msgid.link/20240129202041.7f27f7c895e4.I0adfc28bd656a4d44c2bf47966277eecf56cbaa0@changeidSigned-off-by:
-
Johannes Berg authored
The building of elements is really mess, and really the only reason we're not doing it in SKBs in the first place is that the scan code in ieee80211_build_preq_ies() doesn't. Convert ieee80211_build_preq_ies() to use an SKB internally so that we can gradually convert other things to ..._put_*() style interfaces. Link: https://msgid.link/20240129202041.c3a8e3c2cc99.I9d9920858c30ae5154719783933de0d7bc2a2cb9@changeidSigned-off-by:
-
Johannes Berg authored
Make this a new-style "put" function, and change the parameters to pass more information directly, this makes it usable also for the MLME code. Link: https://msgid.link/20240129202041.f604a03bd728.I8c798ea45b8479ac9982e77d0378af11a09ccdaf@changeidSigned-off-by:
-
Johannes Berg authored
We don't need to use the write function here since we already have an SKB, so use ieee80211_put_he_6ghz_cap() with the SMPS mode taken from the link we're using. Link: https://msgid.link/20240129202041.6454ac78ff8c.I7152e3c27645105478c68d40ca493feb27cac6bf@changeidSigned-off-by:
-
Johannes Berg authored
The term 'IE' isn't really in use in the spec, and I want to rework all of this to use SKBs as the primary method for building elements. Rename this one already. Link: https://msgid.link/20240129202041.b8064a4e73b5.I8d2f4526562029107c6414c6cda378b300b1b0b0@changeidSigned-off-by:
-
Johannes Berg authored
When limiting a station's supported bandwidth while connecting, also limit various other HE capabilities according to the bandwidth needed for them. Link: https://msgid.link/20240129202041.34be99efca25.I02a695961bc6aadd37768b17c50fcdec4427d460@changeidSigned-off-by:
-
Johannes Berg authored
If intending to associate with a lower bandwidth, remove capabilities related to 320 MHz from the EHT capabilities element. Also change the EHT MCS-NSS set accordingly: if just reducing 320->160 or similar the format doesn't change, just cut off the last bytes. If changing from higher bandwidth to 20 MHz only EHT STA, adjust the format. Note that this also requires adjusting the caller in mlme.c since the data written can now be shorter than it determined. We need to clean all that up. Since the other callers pass NULL for the conn limit, we don't need to change things there. Link: https://msgid.link/20240129202041.b5f6df108c77.I0d8ea04079c61cb3744cc88625eeaf0d4776dc2b@changeidSigned-off-by:
-
Johannes Berg authored
We don't need to pass the iftype there, we already have it in the sdata. Simplify this code. Link: https://msgid.link/20240129202041.5890eb1d4184.Ibce7e5abcc7887630da03ac2263d8004ec541418@changeidSigned-off-by:
-
Johannes Berg authored
There really shouldn't be a basic multi-link element in any per-STA profile in an association response, it's not clear what that would really mean. Refuse connecting in this case since the AP isn't following the spec. Link: https://msgid.link/20240129200652.23f1e3b337f1.Idd2e43cdbfe3ba15b3e9b8aeb54c8115587177a0@changeidSigned-off-by:
-
Johannes Berg authored
Let the element parsing function return what kind of error was encountered, as a bitmap, even if nothing currently checks for which specific error it was, we'll use it later. Link: https://msgid.link/20240129200652.1a69f2a31ec7.I55b86561d64e7ef1504c73f6f2813c33030c8136@changeidSigned-off-by:
-
Johannes Berg authored
If the vif is an MLD then it may receive multicast from different links, and should drop those frames according to the SN. Implement that. Link: https://msgid.link/20240129200456.693b77d14b44.I491846f2bea0058c14eab6422962c10bfae9b675@changeidSigned-off-by:
-
Johannes Berg authored
This will also be useful for MLO duplicate multicast detection, but add it already here and use it in one place that trivially converts. Link: https://msgid.link/20240129200456.f0ff49c80006.I850d2785ab1640e56e262d3ad7343b87f6962552@changeidSigned-off-by:
-
Johannes Berg authored
Aloka originally suggested that puncturing should be part of the chandef, so that it's treated correctly. At the time, I disagreed and it ended up not part of the chandef, but I've now realized that this was wrong. Even for clients, the RX, and perhaps more importantly, CCA configuration needs to take puncturing into account. Move puncturing into the chandef, and adjust all the code accordingly. Also add a few tests for puncturing in chandef compatibility checking. Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/Suggested-by:
Aloka Dixit <quic_alokad@quicinc.com> Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeidSigned-off-by:
-
Johannes Berg authored
Instead of calculating the new primary 40/80/160 MHz center frequency here, use the new helper function from cfg80211. Link: https://msgid.link/20240129194108.eb59d6433d18.I74b745f0d1a32e779fb25d50c56407be7c35b840@changeidSigned-off-by:
-
Johannes Berg authored
Simplify cfg80211_chandef_compatible() a bit by switching c1 and c2 around so that c1 is always the narrower one (once they're not identical or narrow/S1G). Then we can just check the various primary channels and exit with the wider one (c2), or NULL. Also refactor the primary 40/80/160 function to not have all the calculations hard-coded, and use a wrapper around it to check primary 40/80/160 compatibility. While at it, add some kunit tests for this functionality. Also expose the new cfg80211_chandef_primary_freq() to drivers, mac80211 will use it. Link: https://msgid.link/20240129194108.be3e6eccaba3.I8399c2ff1435d7378e5837794cb5aa6dd2ee1416@changeidSigned-off-by:
-
Johannes Berg authored
It doesn't look like we can get into this code, but make it more robust and declare two S1G chandefs to be incompatible unless they're identical. Link: https://msgid.link/20240129194108.b28fb0644a8c.I9297ada5cf1baf00dbbdf8fcffd1806883489fc9@changeidSigned-off-by:
-
Johannes Berg authored
Add a new inline helper function to ieee80211.h to extract the disabled subchannels bitmap from an EHT operation element, and use that in mac80211 where we do that. Link: https://msgid.link/20240129194108.d9f50dcec8d0.I8b08cbc2490a734fafcce0fa0fc328211ba6f10b@changeidSigned-off-by:
-
Johannes Berg authored
Upcoming patches will move the puncturing bitmap into the chandef, so chandef validation will need to check for correct puncturing. Purely move the code first so later changes are easier to review. Link: https://msgid.link/20240129194108.1ca184427c76.I077deb8d52c4648eac145b63f88b6c5a3b920ddc@changeidSigned-off-by:
-
Johannes Berg authored
Due to the earlier restructuring we now mostly ignore the channel configuration in the association response, apart from the HT/VHT checks we had. Don't do that, but parse it and update, also dropping the association if the AP changed its mode in the response. Link: https://msgid.link/20240129194108.b3efa5eae60c.I1b70c9fd56781b22cdfdca55d34d69f7d0733e31@changeidSigned-off-by:
-
Johannes Berg authored
EHT requires that stations are able to participate in wider bandwidth OFDMA, i.e. parse downlink OFDMA and uplink OFDMA triggers when they're not capable of (or not connected at) the (wider) bandwidth that the AP is using. This requires hardware configuration, since the entity responsible for parsing (possibly hardware) needs to know the AP bandwidth. To support this, change the channel request to have the AP's bandwidth for clients, and track that in the channel context in mac80211. This means that the same chandef might need to be split up into two different contexts, if the APs are different. Interfaces other than client are not participating in OFDMA the same way, so they don't request any AP setting. Note that this doesn't introduce any API to split a channel context, so that there are cases where this might lead to a disconnect, e.g. if there are two client interfaces using the same channel context, e.g. both 160 MHz connected to different 320 MHz APs, and one of the APs switches to 160 MHz. Note also there are possible cases where this can be optimised, e.g. when using the upper or lower 160 Mhz, but I haven't been able to really fully understand the spec and/or hardware limitations. If, for some reason, there are no hardware limits on this because the OFDMA (downlink/trigger) parsing is done in firmware and can take the transmitter into account, then drivers can set the new flag IEEE80211_VIF_IGNORE_OFDMA_WIDER_BW on interfaces to not have them request any AP bandwidth in the channel context and ignore this issue entirely. The bss_conf still contains the AP configuration (if any, i.e. EHT) in the chanreq. Link: https://msgid.link/20240129194108.d3d5b35dd783.I939d04674f4ff06f39934b1591c8d36a30ce74c2@changeidSigned-off-by:
-
Johannes Berg authored
In the channel context code we have quite a few instances of nested loops iterating the interfaces and then links. Add a new for_each_sdata_link() macro and use it. Also, since it's easier, convert all the loops and a few other places away from RCU as we now hold the wiphy mutex everywhere anyway. This does cause a little bit more work (such as checking interface types for each link of an interface rather than not iterating links in some cases), but that's not a huge issue and seems like an acceptable trade-off, readability is important too. Link: https://msgid.link/20240129194108.7240829bd96d.I5ccbb8dd019cbcb5326c85d76121359225d6541a@changeidSigned-off-by:
-
Johannes Berg authored
For channel contexts, mac80211 currently uses the cfg80211 chandef struct (control channel, center freq(s), width) to define towards drivers and internally how these behave. In fact, there are _two_ such structs used, where the min_def can reduce bandwidth according to the stations connected. Unfortunately, with EHT this is longer be sufficient, at least not for all hardware. EHT requires that non-AP STAs that are connected to an AP with a lower bandwidth than it (the AP) advertises (e.g. 160 MHz STA connected to 320 MHz AP) still be able to receive downlink OFDMA and respond to trigger frames for uplink OFDMA that specify the position and bandwidth for the non-AP STA relative to the channel the AP is using. Therefore, they need to be aware of this, and at least for some hardware (e.g. Intel) this awareness is in the hardware. As a result, use of the "same" channel may need to be split over two channel contexts where they differ by the AP being used. As a first step, introduce a concept of a channel request ('chanreq') for each interface, to control the context it requests. This step does nothing but reorganise the code, so that later the AP's chandef can be added to the request in order to handle the EHT case described above. Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeidSigned-off-by: -
Johannes Berg authored
The last caller of this with a NULL argument was related to the non-chanctx code, so we can now remove this odd logic. Reviewed-by:
Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129194108.bad8ec1e76c8.I12287452f42c54baf75821e75491cf6d021af20a@changeidSigned-off-by:
-
Johannes Berg authored
There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeidSigned-off-by:
-
Johannes Berg authored
In the code we currently check for support 80+80, 160 and 320 channel widths, but really the way this should be (and is otherwise) handled is that we compute the highest channel bandwidth given there, and then cut it down to what we support. This is also needed for wider bandwidth OFDMA support. Change the code to remove this limitation and always parse the highest possible channel width. Reviewed-by:
-
Johannes Berg authored
Rewrite the station-side connection handling. The connection flags (IEEE80211_DISABLE_*) are rather confusing, and they're not always maintained well. Additionally, for wider-bandwidth OFDMA support we need to know the precise bandwidth of the AP, which is currently somewhat difficult. Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit on the bandwidth. This is not entirely clean because some of those modes aren't completely sequenced (as this assumes in some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does. However, it still simplifies things and gives us a good idea what we're operating as, so we can parse elements accordingly etc. This leaves a FIXME for puncturing, this is addressed in a later patch. Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Reviewed-by:
-
