aboutsummaryrefslogtreecommitdiff
path: root/net/mac80211
AgeCommit message (Collapse)AuthorFilesLines
2024-03-04wifi: mac80211: fix supported rate masking in scanJohannes Berg1-4/+4
We have an nl80211 attribute to mask supported rates from probe responses in scanning, e.g. for use in P2P, but in the refactoring I stopped applying this mask. Restore it. Fixes: 07095d167749 ("wifi: mac80211: start building elements in SKBs") Link: https://msgid.link/20240301175451.7ad8ab0bd90c.I46b49e4fc27fe60b75d4559c01104e55ed381c37@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: check link exists before useJohannes Berg1-1/+1
If the assoc link doesn't exist yet at this point, we cannot use it yet. This isn't normally the case, but e.g. in case of FT-DS (or just broken userspace) the link might not be set up yet and will only be created later in this function. Check that the link exists. Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/3151f5d0-c18f-413d-b34b-b94f095b947c@moroto.mountain Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240301193633.c886d300e90a.Ie1d5e23b2a033d934d343c37249f6f4dfddcc5fe@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: always initialize match_authJohannes Berg1-4/+4
My previous patch only initialized match_auth when the ifmgd->auth_data exists, but that was wrong, it should always be set. Fix that. Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/3151f5d0-c18f-413d-b34b-b94f095b947c@moroto.mountain Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240301193633.1a3fc370f211.I979dd222b3b5eb5e1437886e5f7c2355eeccb9f7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-21wifi: mac80211: align ieee80211_mle_get_bss_param_ch_cnt()Johannes Berg1-4/+5
Align the prototype of ieee80211_mle_get_bss_param_ch_cnt() to also take a u8 * like the other functions, and make it return -1 when the field isn't found, so that mac80211 can check that instead of explicitly open-coding the check. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240216135047.583309181bc3.Ia61cb0b4fc034d5ac8fcfaf6f6fb2e115fadafe7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-21wifi: mac80211: clean up assignments to pointer cache.Colin Ian King1-5/+1
The assignment to pointer cache in function mesh_fast_tx_gc can be made at the declaration time rather than a later assignment. There are also 3 functions where pointer cache is being initialized at declaration time and later re-assigned again with the same value, these are redundant and can be removed. Cleans up code and three clang scan build warnings: warning: Value stored to 'cache' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://msgid.link/20240215232151.2075483-1-colin.i.king@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-21wifi: mac80211: make associated BSS pointer visible to the driverMiri Korenblit2-11/+9
Some drivers need the data in it, so move it to the link conf, which is exposed to the driver. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.6fe9782b87b4.Ifbffef638f07ca7f5c2b27f40d2cf2942d21de0b@changeid [remove bss pointer from internal struct, update docs] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-21wifi: mac80211: check beacon countdown is complete on per link basisAditya Kumar Singh1-2/+12
Currently, function to check if beacon countdown is complete uses deflink to fetch the beacon and check the counter. However, with MLO, there is a need to check 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. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240216144621.514385-2-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-15Merge wireless into wireless-nextJohannes Berg1-1/+2
There's a conflict already and some upcoming changes also depend on changes in wireless for being conflict- free, so pull wireless in to make all that easier. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: drop injection on disabled-chan monitorJohannes Berg1-1/+9
If the driver uses the new IEEE80211_CHAN_CAN_MONITOR, we may monitor on channels that are, e.g. via regulatory, otherwise considered disabled. However, we really shouldn't transmit on them, so prevent that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.9c03dcf67dbe.Ib86a851c274c440908c663f6dd774b79bfc3965d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: remove only own link stations during stop_apAditya Kumar Singh1-1/+1
Currently, whenever AP link is brought down via ieee80211_stop_ap() function, all stations connected to the sdata are flushed. However, in case of MLO there is a requirement to flush only stations connected to that link and not all. For instance - Consider 2 GHz and 5 GHz are AP MLD. Now due to some reason 5 GHz link of this AP is going down (link removal or any other case). All stations connected, even legacy stations connected to 2 GHz link AP would also be flushed. Flushing of other link stations is not desirable. Fix this issue by passing self link ID to sta_flush() function. This would then only remove the stations which are still using the passed link ID as their link sta. Other stations will not be affected. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-4-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: flush only stations using requests linksAditya Kumar Singh8-18/+33
Whenever sta_flush() function is invoked, all STAs present in that interface are flushed. In case of MLO, it is desirable to only flush such STAs that are at least using a given link id as one of their links. Add support for this by making change in the __sta_info_flush API argument to accept a link ID. And then, only if the STA is using the given link as one of its links, it would be flushed. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-3-quic_adisi@quicinc.com [reword commit message, in particular this isn't about "active" links] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12wifi: mac80211: remove gfp parameter from ieee80211_obss_color_collision_notifyLorenzo Bianconi2-3/+2
Get rid of gfp parameter from ieee80211_obss_color_collision_notify since it is no longer used. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/f91e1c78896408ac556586ba8c99e4e389aeba02.1707389901.git.lorenzo@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add support to call csa_finish on a linkAditya Kumar Singh1-2/+13
Currently ieee80211_csa_finish() function finalizes CSA by scheduling a finalizing worker using the deflink. With MLO, there is a need to do it on a given link basis. Pass link ID of the link on which CSA needs to be finalized. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: start and finalize channel switch on link basisAditya Kumar Singh2-24/+37
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.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: handle set csa/after_csa beacon on per link basisAditya Kumar Singh1-13/+15
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 <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-4-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: update beacon counters per link basisAditya Kumar Singh1-3/+11
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 <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-3-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: refactor STA CSA parsing flowsMichael-CY Lee1-52/+250
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: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: don't use sband->band earlyJohannes Berg1-1/+1
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: f04d2c247e04 ("wifi: mac80211: disallow drivers with HT wider than HE") Reported-by: Bert Karwatzki <spasswolf@web.de> Debugged-by: Bert Karwatzki <spasswolf@web.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218466 Link: https://msgid.link/20240207115920.43cbedffb5c3.I4968e12275a3f95926e3f3ccae81e50f23fe4d4d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add missing kernel-doc for fast_tx_checkJohannes Berg1-1/+2
This was added earlier, add kernel-doc for it. Link: https://msgid.link/20240206134555.6354b0ac8610.Ib90d3651834c556b73697388f59bd396a1f6f9b0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: clarify vif handling in TX dequeueJohannes Berg1-1/+2
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: allow CSA to same channelJohannes Berg1-4/+0
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: convert ieee80211_ie_build_eht_cap() to SKB useJohannes Berg5-119/+42
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: convert ieee80211_ie_build_he_cap() to SKB useJohannes Berg5-93/+37
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: move element parsing to a new fileJohannes Berg3-892/+927
This code got really big, move it to a new file. Pure code move. Link: https://msgid.link/20240129202041.7f27f7c895e4.I0adfc28bd656a4d44c2bf47966277eecf56cbaa0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: start building elements in SKBsJohannes Berg3-185/+189
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: simplify adding supported ratesJohannes Berg6-131/+77
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: tdls: use ieee80211_put_he_6ghz_cap()Johannes Berg3-11/+3
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: rename ieee80211_ie_build_he_6ghz_cap()Johannes Berg4-8/+10
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: limit HE RU capabilities when limiting bandwidthJohannes Berg1-2/+33
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: adjust EHT capa when lowering bandwidthJohannes Berg5-37/+103
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: simplify HE/EHT element length functionsJohannes Berg4-19/+16
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: disallow basic multi-link element in per-STA profileJohannes Berg3-1/+8
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: disambiguate element parsing errorsJohannes Berg2-38/+81
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: implement MLO multicast deduplicationJohannes Berg3-3/+26
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add/use ieee80211_get_sn()Johannes Berg1-3/+2
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: cfg80211/mac80211: move puncturing into chandefJohannes Berg5-186/+53
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: reload info pointer in ieee80211_tx_dequeue()Johannes Berg1-2/+3
This pointer can change here since the SKB can change, so we actually later open-coded IEEE80211_SKB_CB() again. Reload the pointer where needed, so the monitor-mode case using it gets fixed, and then use info-> later as well. Cc: stable@vger.kernel.org Fixes: 531682159092 ("mac80211: fix VLAN handling with TXQs") Link: https://msgid.link/20240131164910.b54c28d583bc.I29450cec84ea6773cff5d9c16ff92b836c331471@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: use cfg80211_chandef_primary_freq()Johannes Berg1-19/+11
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: refactor puncturing bitmap extractionJohannes Berg1-35/+17
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: validate assoc response channel configJohannes Berg1-2/+17
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: support wider bandwidth OFDMA configJohannes Berg4-70/+201
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: add and use a link iteration macroJohannes Berg2-170/+89
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: introduce 'channel request'Johannes Berg19-288/+330
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: chan: chandef is non-NULL for reservedJohannes Berg1-3/+3
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: simplify non-chanctx driversJohannes Berg10-201/+243
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@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: clean up HE 6 GHz and EHT chandef parsingJohannes Berg5-93/+29
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: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129194108.d06f85082e29.I47e68ed3d97b0a2f4ee61e5d8abfcefc8a5b9c08@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: clean up connection processJohannes Berg10-997/+1268
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: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129194108.9451722c0110.I3e61f4cfe9da89008e1854160093c76a1e69dc2a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: clean up band switch in durationJohannes Berg1-11/+8
Most devices now do duration calculations, so we don't hit this code at all any more. Clearly the approach of warning at compile time here when new bands are added didn't work, the new bands were just added with "TODO". Clean it up, it won't matter for new bands since they'll just not have any need to calculate durations in software. While at it, also clean up and unify the code a bit. Link: https://msgid.link/20240129194108.70a97bd69265.Icdd8b0ac60a382244466510090eb0f5868151f39@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: remove extra shadowing variableJohannes Berg1-1/+0
Not sure how this happened or how nothing complained, but this variable already exists in the outer function scope with the same value (and the SKB isn't changed either.) Remove the extra one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: remove unused MAX_MSG_LEN defineJohannes Berg1-2/+0
This got unused when the tracing was converted to dynamic strings, so the define can be removed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Powered by cgit, Gruvboxed by Blaster4385.