- 11 Sep, 2023 26 commits
-
-
Johannes Berg authored
This work should be made per link as well, and then will have cancellation issues. Moving it to a wiphy work already fixes those beforehand. Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This again is intended for future cleanups that are possible when mac80211 and drivers can assume the wiphy is locked. Reviewed-by:
-
Johannes Berg authored
One more work that will now execute with the wiphy locked, for future cleanups. Reviewed-by:
-
Johannes Berg authored
This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have. Reviewed-by:
-
Johannes Berg authored
Again, to have the wiphy locked for it. Reviewed-by:
-
Johannes Berg authored
This also has the wiphy locked here then. We need to use the _locked version of cfg80211_sched_scan_stopped() now, which also fixes an old deadlock there. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Reviewed-by:
-
Johannes Berg authored
Along with everything else, move the dynamic PS work to be a wiphy work, to simplify locking later. Reviewed-by:
-
Johannes Berg authored
We want to have the wiphy locked for these as well, so move it to be a wiphy work. Signed-off-by: -
Johannes Berg authored
Make the offchannel works wiphy works to have the wiphy locked for executing them. Signed-off-by: -
Johannes Berg authored
Lock the wiphy in the IP address notifier as another place that should have it locked before calling into the driver. This needs a bit of attention since the notifier can be called while the wiphy is already locked, when we remove an interface. Handle this by not running the notifier in this case, and instead calling out to the driver directly. Signed-off-by: -
Johannes Berg authored
Again this serves to simplify the locking in mac80211 in the future, since this is a relatively complex work. Reviewed-by:
-
Johannes Berg authored
Move the scan work to wiphy work, which also simplifies the way we handle the work vs. the scan configuration. Reviewed-by:
-
Johannes Berg authored
Move the radar detect work to wiphy work in order to lock the wiphy for it without doing it manually. Reviewed-by:
-
Johannes Berg authored
Move the DFS CAC work over to hold the wiphy lock there without worry about work cancellation. Reviewed-by:
-
Johannes Berg authored
Add more might_sleep() checks and check sdata-in-driver for one additional place. type=feature ticket=jira:WIFI-314309 Reviewed-by:
-
Johannes Berg authored
Convert the A-MPDU work to wiphy work so it holds the wiphy mutex and we can later guarantee that to drivers. It might seem that we could run these concurrently for different stations, but they're all on the ordered mac80211 workqueue, so this shouldn't matter for that. Reviewed-by:
-
Johannes Berg authored
Before converting more works to wiphy work, add flushing in mac80211 where we also flush the mac80211 workqueue. Not needed in suspend since cfg80211 will have taken care of it. Signed-off-by: -
Johannes Berg authored
There may be sometimes reasons to actually run the work if it's pending, add flush functions for both regular and delayed wiphy work that will do this. Signed-off-by: -
Johannes Berg authored
Add a new "for_each_rdev()" macro and check that we hold the RTNL when calling it. Signed-off-by: -
Johannes Berg authored
To change aggregation status may call into the driver, lock the wiphy for this. Signed-off-by: -
Johannes Berg authored
It's no longer really needed to ensure that the debugfs file isn't going away, debugfs handles that. So there's no point in holding dev_base_lock or RTNL here, but we should instead hold the wiphy lock since drivers will be allowed to depend on that. Do that, which requires splitting the sdata and link macros a bit. Signed-off-by: -
Johannes Berg authored
Since we no longer really use the RTNL, there's no point in locking it here. Most drivers don't really need to have any locks here anyway, and the rest are probably completely broken, but it's a debugfs-only callback so it really doesn't matter much. Signed-off-by: -
Johannes Berg authored
The current SMPS status handling isn't per link, so we only ever change the deflink, which is obviously wrong, it's not even used for multi-link connections, but the request API actually includes the link ID. Use the new status_data changes to move the handling to the right link, this also saves parsing the frame again on the status report, instead we can now check only if it was an SMPS frame. Of course, move the worker to be a wiphy work so that we're able to cancel it safely for the link. Signed-off-by: -
Ilan Peer authored
When the connection is a MLO connection, a SMPS request should be sent on a specific link, as SMPS is BSS specific, and the DA and BSSID used for the action frame transmission should be the AP MLD address, as the underlying driver is expected to perform the address translation (based on the link ID). Fix the SMPS request handling to use the AP MLD address and provide the link ID for the request processing during Tx. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
Take one more free bit to indicate it's IDR vs. internal usage, to be able to carve out some bits here for other internal usage, other than IDR handling with a full ACK SKB, that is. Reviewed-by:
Benjamin Berg <benjamin.berg@intel.com> Reviewed-by:
-
Johannes Berg authored
This really just reformats the statement, but makes it more readable. Signed-off-by:
-
- 07 Sep, 2023 14 commits
-
-
Rand Deeb authored
In ssb_calc_clock_rate(), there is a potential issue where the value of m1 could be zero due to initialization using clkfactor_f6_resolv(). This situation raised concerns about the possibility of a division by zero error. We fixed it by following the suggestions provided by Larry Finger <Larry.Finger@lwfinger.net> and Michael Büsch <m@bues.ch>. The fix involves returning a value of 1 instead of 0 in clkfactor_f6_resolv(). This modification ensures the proper functioning of the code and eliminates the risk of division by zero errors. Signed-off-by:
Rand Deeb <rand.sec96@gmail.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Michael Büsch <m@bues.ch> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230904232346.34991-1-rand.sec96@gmail.com
-
Ping-Ke Shih authored
Secure firmware is protected by public/private key cryptography. To help firmware self verify integrity, configure a heap address for these data before downloading firmware. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
To support download more than one firmware, adjust flow to download firmware by unit of firmware suit. Then, flow becomes 1. initial setup - disable/enable_wcpu 2. for all firmware suits 2.1. download WiFi CPU, and check ready 2.2. download BB MCU, and check ready 3. check status code to make sure all ready Signed-off-by:
-
Ping-Ke Shih authored
Before downloading firmware for BB MCU, call this ops to enable baseband hardware. Signed-off-by:
-
Ping-Ke Shih authored
Though WiFi 7 chips need BB MCU firmware, we don't download it in probe stage. Instead, only bring interface up under normal operation or WoWLAN mode. So, add an argument to assist download flow to setup download settings properly. Signed-off-by:
-
Ping-Ke Shih authored
For WiFi 6 chips, there is only single one firmware i.e. WiFi CPU firmware, so no need an argument to discriminate them. For WiFi 7 chips, BB MCU firmware is introduced, and we need to check it ready after downloading. For each type of firmware, we need to check corresponding hardware ready bit. After downloading all firmware, check status code to determine if all things are ready. Signed-off-by:
-
Ping-Ke Shih authored
To work with generalized flow of download firmware, implement WiFi 7 specific functions to support it. These functions include disable/enable WiFi CPU, status of path ready, and status of firmware. Signed-off-by:
-
Ping-Ke Shih authored
In order to reuse the flow to download firmware, define some mac_gen::ops to implement them for WiFi 6 and 7 chips individually. This doesn't change logic at all. Signed-off-by:
-
Ping-Ke Shih authored
To download firmware, we need to check path is ready. There are two kinds of path -- one is to download firmware header, and the other is to download firmware body. Since the polling method is different from WiFi 7 chips, make it to be an individual function, and then we can reuse the download flow. Signed-off-by:
-
Zong-Zhe Yang authored
According to Wi-Fi/BT roles' settings, we fill corresponding H2Cs (host to chip packets). Then, following MCC (multi-channel concurrency) pattern, we send these H2Cs as planned. Eventually, the trigger H2Cs will be sent to tell FW to really start/stop MCC. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. Signed-off-by:
-
Zong-Zhe Yang authored
After the previous works, we can now expand and display the MCC pattern in more detail, as shown below. |< MCC interval >| |< duration ref >| (if mid bt) |< duration aux >| (if tail bt) | |<tob ref >|< toa ref>| ... |<tob aux >|< toa aux>| ... | V V tbtt ref tbtt aux |< beacon offset >| (where tob means `time offset behind` and toa means `time offset ahead`) There are two key points. 1. decide position of BT slot if MCC pattern needs to handle BT duration. 2. calculate all parameters related to tob and toa in MCC pattern. For point (1), when BT duration needs to be handled, BT position will rely on beacon offset, either middle or tail. For point (2), to ensure durations of the Wi-Fi roles cover their beacons, we have to calculate tob and toa for them according to their TBTT. And, there are two strategies to calculate parameters, strict and loose. In strict pattern, all parameters take HW time into account as limitation. But, the strict calculation are not always successful. In loose pattern, it only tries to give positive parameters to reference role and doesn't care much about auxiliary role. If unfortunately auxiliary role gets negative parameters in loose pattern, FW will be notified and then deal with it. So, the loose calculation won't fail. In general, we always try strict pattern cases before using a loose pattern. Signed-off-by: -
Zong-Zhe Yang authored
Before calculating MCC pattern, we have to determine whether to handle BT duration in it or not. The decision will depend on the channels that Wi-Fi roles use. And, we have three cases shown below. 1. non-2GHz + non-2GHz 2. non-2GHz + 2GHz (different band) 3. 2GHz + 2GHz (dual 2GHz) For case (1), we don't care BT duration in MCC pattern. For case (2), we still don't care BT duration in MCC pattern. Instead, we try to satisfy it by modifying duration of Wi-Fi role on non-2GHz channel. For case (3), we need to modify Wi-Fi durations and also need to handle BT duration in MCC pattern. Signed-off-by:
-
Zong-Zhe Yang authored
We determine the fundamental settings shown below. |< MCC interval >| |< duration ref >|< duration aux >| | | | | |< beacon offset >| | | V V (tbtt ref) (tbtt aux) (where `ref` (reference) and `aux` (auxiliary) mean the two MCC roles) Based on MCC mode (GO+STA or GC+STA), we fill configurations of MCC interval and beacon offset. And, we make sure each MCC role have a basically required duration in the MCC interval. The beacon offset mentioned above is a parameter for further MCC pattern calculation. If MCC is in GC+STA mode, we will calculate the real beacon offset through TSFs shown in beacons of both MCC roles. Otherwise, we will use a default beacon offset, and make GO sync STA's TSF timer with this offset. MCC pattern calculation will break down each MCC role's duration in more detail. We will implement it in the following. Signed-off-by:
-
