aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2023-09-11wifi: iwlwifi: increase number of RX buffers for EHT devicesJohannes Berg2-11/+7
EHT devices can support 512 MPDUs in an A-MPDU, each of which might be an A-MSDU and thus further contain multiple MSDUs, which need their own buffer each. Increase the number of buffers to avoid running out in high-throughput scenarios. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.824e522927f1.Ie5b4a2d3953072b9d76054ae67e2e45900d6bba4@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: pcie: fix RB status readingJohannes Berg3-13/+9
On newer hardware, a queue's RB status / write pointer can be bigger than 4095 (0xFFF), so we cannot mask the value by 0xFFF unconditionally. Since anyway that's only necessary on older hardware, move the masking to the helper function and apply it only for older HW. This also moves the endian conversion in to handle it more easily. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.7be2a3fff6f4.I94f11dee314a4f7c1941d2d223936b1fa8aa9ee4@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: reduce maximum RX A-MPDU sizeJohannes Berg3-4/+4
Since 1024 isn't being tested right now, allow only 512 for now. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.6e80366716ad.I19022084ac978b9960b12b205c052a83ab141203@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: check link more carefullyJohannes Berg1-1/+2
Some cases of restart crashing here have been reported, while we figure out where this is going wrong, check the link more carefully to avoid the crash. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.2b81f52ce18e.I8f3b1962013107e2d7491d817c3349359341c6ee@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: move RU alloc B2 placementJohannes Berg2-10/+8
The firmware was trying to report the B2 RU allocation in the place previously used here as well, but there's a HW block that clears the lower 8 bits in this metadata word even in sniffer mode. Thus, firmware moved B2 to another place, follow that. There's no need to detect the version since moving it to the other place if firmware didn't just means that we'll continue to report the (erroneous) zero value, and it's not really something we can detect from the firmware now. While debugging this we realized that the comments about placement in the metadata dwords are wrong, update them. Reported-by: Youhan Kim <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.dec7f1e07ff8.I623fee2d710cc7b6f392d65b708883ed58632b45@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: fw: reconstruct the API/CAPA enum numberJohannes Berg1-9/+18
The last member of the enum is meant to count the items, but sparse cannot increment the previous member due to its bitwise type. Declaring the last entry with a value doesn't work either (cannot mix bitwise/non-bitwise) and declaring it with a bitwise value doesn't work due to the way it gets used. This led to the current construct. However, that construct the kernel-doc script doesn't understand this construct due to the use of #ifdef/#else. Find another solution that makes both tools happy, we do now do declare it as the bitwise value but then just redefine it so that doesn't get used, all still under __CHECKER__ conditional. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.44bdf6a5fa9e.I9f1ea129f89e53043d48676aed0a3b8f6c31ac08@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: fix kernel-docJohannes Berg4-21/+40
Fix kernel-doc, adding various documentation, but in some cases (notably rate scaling) just removing the erroneous comment format. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.4ce1159b51ab.I2021ae335f6b8e50ee2c1c78a79c5eac1c1aa103@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: pcie: fix kernel-doc issuesJohannes Berg1-15/+36
Fix various missing kernel-doc annotations etc. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.a11b39f9a07e.Ia7b189f003db8f6ccaf0a547e71c80e00b85fb5a@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: dvm: remove kernel-doc warningsJohannes Berg4-29/+39
Mostly remove kernel-doc comment annotation since the comments really aren't kernel-doc, and fix a few other places. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.7178fb7c96fb.I6af1f291e306c50a3c4f5afcdc2ba0bbd4bea01f@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: queue: fix kernel-docJohannes Berg1-2/+4
Fix the kernel-doc annotations here, adding the trans parameter and fixing the syntax. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.247919faf4fd.I489f8b3b2ebb49a421bd5d76ea0201262134fb67@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: don't use an uninitialized variableMiri Korenblit1-3/+0
Don't use variable err uninitialized. The reason for removing the check instead of initializing it in the beginning of the function is because that way static checkers will be able to catch issues if we do something wrong in the future. Fixes: bf976c814c86 ("wifi: iwlwifi: mvm: implement link change ops") Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.431b01bd8779.I31fc4ab35f551b85a10f974a6b18fc30191e9c35@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: fix some kernel-doc issuesJohannes Berg9-27/+24
Fix kernel-doc issues. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.2edc4d82f717.Ic7c6f1153939903b067062c9aec8fb70e0a2c30d@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: honor the enable_ini valueEmmanuel Grumbach4-36/+25
In case the user sets the enable_ini to some preset, we want to honor the value. Remove the ops to set the value of the module parameter is runtime, we don't want to allow to modify the value in runtime since we configure the firmware once at the beginning on its life. Fixes: b49c2b252b58 ("iwlwifi: Configure FW debug preset via module param.") Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.5734e0f374bb.I6698eda8ed2112378dd47ac5d62866ebe7a94f77@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: disconnect long CSA only w/o alternativeJohannes Berg1-1/+2
If there's an alternative link to use while the CSA is in progress, there's no need to disconnect since another link is still usable during the switching time. Change the code here to handle that accordingly. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.dd1b96a37e51.Idafdcbfcb36ca4c486f4221aef77643869331514@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: increase session protection after CSAJohannes Berg1-1/+1
In the spec, CSA is defined roughly as follows: - TBTT x: beacon with CSA, count=n (old channel) - TBTT x+1: beacon with CSA, count=n-1 (old channel) - TBTT x+n-1: beacon with CSA, count=1 (old channel) "A Channel Switch Count field set to 1 indicates that the switch occurs immediately before the next TBTT. - TBTT x+n: beacon without CSA (new channel) When we detect it, we currently schedule the CSA event to be at 10 TUs before TBTT x+n-1, for a beacon interval, to give us quiet time. When this event *starts*, we currently notify mac80211 that the channel switch happened, which causes us to add a session protection event to listen for the first beacon (and enable TX etc. when that arrives). We don't even ask for a notification when this event ends so the code that handles that is effectively dead code. The session protection duration is 3 beacon intervals, scheduled at 10 TU before TBTT x+n-1. It will thus end just before TBTT x+n+2. Unfortunately, if the AP doesn't transmit or we miss just the first two beacons on the new channel, then this will cause us to disconnect. Or even just one, if the AP isn't quite aligned with the TBTT after the switch. However, listening to the _end_ of the time event isn't what we want either, because we want all the new PHY and other config that needs to come from mac80211 to start early, so we have a head-start for the new channel, since we're not going to use the old one anyway for this time. So since we don't really have anything better to do at this time, and this is relatively rare, just make the session protection use 5x the beacon interval instead of just 3x, so it's more likely we catch a beacon even if the AP neglected to send it, or we just miss it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.a74176bac37c.I029a2ebcd1b5012327c728ffa1d33fac19cfdf4b@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: iwlwifi: mvm: support CSA with MLDEmmanuel Grumbach2-3/+6
Pass the right link_id to ieee80211_chswitch_done. Use the link_conf parameter passed to post_channel_switch() to get the right ap_sta_id. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230830112059.19470584fa51.Iad38b5369bededaa126b3eb3cff79f23d61bd783@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211_hwsim: clean up kernel-docJohannes Berg1-10/+9
Clean up kernel-doc in hwsim's header file. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.6127359dba54.I8a9ab3d5fc0c0041624b96ab7350097f3f60fbe0@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: add support for mld in ieee80211_chswitch_doneEmmanuel Grumbach9-16/+19
This allows to finalize the CSA per link. In case the switch didn't work, tear down the MLD connection. Also pass the ieee80211_bss_conf to post_channel_switch to let the driver know which link completed the switch. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230828130311.3d3eacc88436.Ic2d14e2285aa1646216a56806cfd4a8d0054437c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11iwlwifi: mvm: handle PS changes in vif_cfg_changedGregory Greenman1-58/+63
Handling of BSS_CHANGED_PS was missing in vif_cfg_changed callback. Fix it. Fixes: 22c588343529 ("wifi: iwlwifi: mvm: replace bss_info_changed() with vif_cfg/link_info_changed()") Reported-by: Sultan Alsawaf <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230905162939.5ef0c8230de6.Ieed265014988c50ec68fbff6d33821e4215f987f@changeid [note: patch looks bigger than it is due to reindentation] Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: annotate iftype_data pointer with sparseJohannes Berg11-58/+48
There were are a number of cases in mac80211 and iwlwifi (at least) that used the sband->iftype_data pointer directly, instead of using the accessors to find the right array entry to use. Make sparse warn when such a thing is done. To not have a lot of casts, add two helper functions/macros - ieee80211_set_sband_iftype_data() - for_each_sband_iftype_data() Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211_hwsim: fix clang-specific fortify warningDmitry Antipov1-1/+1
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/virtual/mac80211_hwsim.c:18: In file included from ./include/linux/slab.h:16: In file included from ./include/linux/gfp.h:7: In file included from ./include/linux/mmzone.h:8: In file included from ./include/linux/spinlock.h:56: In file included from ./include/linux/preempt.h:79: In file included from ./arch/x86/include/asm/preempt.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/x86/include/asm/thread_info.h:53: In file included from ./arch/x86/include/asm/cpufeature.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'mac80211_hwsim_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'mac80211_hwsim_gstrings_stats' array from its first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: Dmitry Antipov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: remove wdev mutexJohannes Berg3-6/+6
Since we're now protecting everything with the wiphy mutex (and were really using it for almost everything before), there's no longer any real reason to have a separate wdev mutex. It may feel better, but really has no value. Signed-off-by: Johannes Berg <[email protected]>
2023-09-07wifi: rtw89: 8922a: set memory heap address for secure firmwarePing-Ke Shih2-0/+6
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: refine download flow to support variant firmware suitsPing-Ke Shih1-19/+65
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: 8922a: add chip_ops::bb_preinit to enable BB before downloading ↵Ping-Ke Shih6-0/+20
firmware Before downloading firmware for BB MCU, call this ops to enable baseband hardware. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: propagate an argument include_bb for BB MCU firmwarePing-Ke Shih12-14/+31
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: add checking type for variant type of firmwarePing-Ke Shih6-15/+45
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: implement supported functions of download firmware for WiFi ↵Ping-Ke Shih2-0/+238
7 chips 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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: generalize download firmware flow by mac_gen pointersPing-Ke Shih3-18/+29
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fw: move polling function of firmware path ready to an ↵Ping-Ke Shih4-9/+17
individual function 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: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: mcc: trigger FW to start/stop MCCZong-Zhe Yang1-0/+173
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 <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap()Zong-Zhe Yang2-2/+2
Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: mcc: decide pattern and calculate parametersZong-Zhe Yang2-0/+235
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 <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: mcc: consider and determine BT durationZong-Zhe Yang1-0/+169
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 <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: mcc: fill fundamental configurationsZong-Zhe Yang3-0/+187
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: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-07wifi: rtw89: mcc: initialize start flowZong-Zhe Yang4-0/+502
We prepare to support TDMA-based MCC (multi-channel concurrency) which allows two kinds of modes below. * P2P GO + normal STA * P2P GC + normal STA Each mode has two vif and two chanctx. Then, each vif binds one separate chanctx and becomes one MCC role. We name the two MCC roles as follows. * MCC role - reference (ref) We calculate the baseline of our TDMA things accodring to its info, e.g. TBTT. In normal case, it will be put at the first slot of TDMA. * MCC role - auxiliary (aux) MCC state machine will be running in FW eventually, but before that, we have to fill and calculate things that are needed by FW. We fill the information of MCC role according to its vif and its chanctx. Then, we calculate the start time for MCC. Note that the parameters used in the calculation now is assigned by default rules. The precise parameters for better MCC behavior will be derived in the following. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-05wifi: ath11k: fix tid bitmap is 0 in peer rx mu statsMuna Sinada2-13/+14
Correct parsing of reading offset for rx tid 16 bit bitmap. Incorrect offset caused peer rx mu stats tid bitmap to always be zero. This correction is in the software context and does not affect the firmware interface. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00356-QCAHKSWPL_SILICONZ-1 Signed-off-by: Muna Sinada <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-05wifi: ath11k: move references from rsvd2 to info fieldsMuna Sinada2-8/+13
Remove references to reserved fields and add new info fields for struct hal_rx_ppdu_end_user_stats. Reserved fields should not be accessed, therefore existing references to it are to be changed to referencing specific info fields. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00356-QCAHKSWPL_SILICONZ-1 Signed-off-by: Muna Sinada <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-05wifi: ath12k: fix undefined behavior with __fls in dpHarshitha Prem1-1/+1
When max virtual ap interfaces are configured in all the bands with ACS and hostapd restart is done every 60s, a crash is observed at random times because of handling the uninitialized peer fragments with fragment id of packet as 0. "__fls" would have an undefined behavior if the argument is passed as "0". Hence, added changes to handle the same. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Harshitha Prem <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-05wifi: ath12k: Ignore fragments from uninitialized peer in dpHarshitha Prem3-0/+13
When max virtual ap interfaces are configured in all the bands with ACS and hostapd restart is done every 60s, a crash is observed at random times. In the above scenario, a fragmented packet is received for self peer, for which rx_tid and rx_frags are not initialized in datapath. While handling this fragment, crash is observed as the rx_frag list is uninitialized and when we walk in ath12k_dp_rx_h_sort_frags, skb null leads to exception. To address this, before processing received fragments we check dp_setup_done flag is set to ensure that peer has completed its dp peer setup for fragment queue, else ignore processing the fragments. Call trace: PC points to "ath12k_dp_process_rx_err+0x4e8/0xfcc [ath12k]" LR points to "ath12k_dp_process_rx_err+0x480/0xfcc [ath12k]". The Backtrace obtained is as follows: ath12k_dp_process_rx_err+0x4e8/0xfcc [ath12k] ath12k_dp_service_srng+0x78/0x260 [ath12k] ath12k_pci_write32+0x990/0xb0c [ath12k] __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Harshitha Prem <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-05wifi: ath11k: mhi: add a warning message for MHI_CB_EE_RDDM crashArowa Suliman1-0/+1
Currently, the ath11k driver does not print a crash signature when a MHI_CB_EE_RDDM crash happens. Checked by triggering a simulated crash using the command and checking dmesg for logs: echo assert > /sys/kernel/debug/ath11k/../simulate_fw_crash Add a warning when firmware crash MHI_CB_EE_RDDM happens. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Signed-off-by: Arowa Suliman <[email protected]> Reviewed-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: rtw89: 8852c: Fix TSSI causes transmit power inaccuracyKuan-Chung Chen3-23/+46
Modify TSSI ADC FIFO Clock follow RX ADC Clock can avoid transmit power inaccuracy. Signed-off-by: Kuan-Chung Chen <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: rtw89: 8852c: Update bandedge parameters for better performanceKuan-Chung Chen3-3/+15
TSSI configures bandedge to TX proper waveform, these new bandedge parameters improve the accuracy of transmit power compensation. This helps to avoid throughput degradation. Signed-off-by: Kuan-Chung Chen <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: plfxlc: fix clang-specific fortify warningDmitry Antipov1-1/+1
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/purelifi/plfxlc/mac.c:6: In file included from ./include/linux/netdevice.h:24: In file included from ./include/linux/timer.h:6: In file included from ./include/linux/ktime.h:24: In file included from ./include/linux/time.h:60: In file included from ./include/linux/time32.h:13: In file included from ./include/linux/timex.h:67: In file included from ./arch/x86/include/asm/timex.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'plfxlc_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'et_strings' array from its first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: rtl8xxxu: mark TOTOLINK N150UA V5/N150UA-B as testedZenm Chen1-0/+1
TOTOLINK N150UA V5/N150UA-B (VID=0x0bda, PID=0x2005) works fine with the rtl8xxxu driver, so mark as tested. Signed-off-by: Zenm Chen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: rtw88: fix typo rtw8822cu_probePo-Hao Huang1-2/+2
The probe function of 8822cu is misplaced to 8822bu, so we fix it. Just cosmetics, no changes in functionality. Signed-off-by: Po-Hao Huang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-04wifi: mwifiex: Sanity check tlv_len and tlv_bitmap_lenGustavo A. R. Silva1-0/+16
Add sanity checks for both `tlv_len` and `tlv_bitmap_len` before decoding data from `event_buf`. This prevents any malicious or buggy firmware from overflowing `event_buf` through large values for `tlv_len` and `tlv_bitmap_len`. Suggested-by: Dan Williams <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/d4f8780527d551552ee96f17a0229e02e1c200d1.1692931954.git.gustavoars@kernel.org
2023-09-04wifi: mwifiex: Replace one-element array with flexible-array member in ↵Gustavo A. R. Silva2-2/+2
struct mwifiex_ie_types_rxba_sync One-element and zero-length arrays are deprecated. So, replace one-element array in struct mwifiex_ie_types_rxba_sync with flexible-array member, and refactor the rest of the code, accordingly. This results in no differences in binary output. Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/79c801c69c8beece2f80502c60166036d3c047cc.1692931954.git.gustavoars@kernel.org
2023-09-04wifi: mwifiex: Fix tlv_buf_left calculationGustavo A. R. Silva1-2/+2
In a TLV encoding scheme, the Length part represents the length after the header containing the values for type and length. In this case, `tlv_len` should be: tlv_len == (sizeof(*tlv_rxba) - 1) - sizeof(tlv_rxba->header) + tlv_bitmap_len Notice that the `- 1` accounts for the one-element array `bitmap`, which 1-byte size is already included in `sizeof(*tlv_rxba)`. So, if the above is correct, there is a double-counting of some members in `struct mwifiex_ie_types_rxba_sync`, when `tlv_buf_left` and `tmp` are calculated: 968 tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len); 969 tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba); in specific, members: drivers/net/wireless/marvell/mwifiex/fw.h:777 777 u8 mac[ETH_ALEN]; 778 u8 tid; 779 u8 reserved; 780 __le16 seq_num; 781 __le16 bitmap_len; This is clearly wrong, and affects the subsequent decoding of data in `event_buf` through `tlv_rxba`: 970 tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp; Fix this by using `sizeof(tlv_rxba->header)` instead of `sizeof(*tlv_rxba)` in the calculation of `tlv_buf_left` and `tmp`. This results in the following binary differences before/after changes: | drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o | @@ -4698,11 +4698,11 @@ | drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:968 | tlv_buf_left -= (sizeof(tlv_rxba->header) + tlv_len); | - 1da7: lea -0x11(%rbx),%edx | + 1da7: lea -0x4(%rbx),%edx | 1daa: movzwl %bp,%eax | drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:969 | tmp = (u8 *)tlv_rxba + sizeof(tlv_rxba->header) + tlv_len; | - 1dad: lea 0x11(%r15,%rbp,1),%r15 | + 1dad: lea 0x4(%r15,%rbp,1),%r15 The above reflects the desired change: avoid counting 13 too many bytes; which is the total size of the double-counted members in `struct mwifiex_ie_types_rxba_sync`: $ pahole -C mwifiex_ie_types_rxba_sync drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o struct mwifiex_ie_types_rxba_sync { struct mwifiex_ie_types_header header; /* 0 4 */ |----------------------------------------------------------------------- | u8 mac[6]; /* 4 6 */ | | u8 tid; /* 10 1 */ | | u8 reserved; /* 11 1 */ | | __le16 seq_num; /* 12 2 */ | | __le16 bitmap_len; /* 14 2 */ | | u8 bitmap[1]; /* 16 1 */ | |----------------------------------------------------------------------| | 13 bytes| ----------- /* size: 17, cachelines: 1, members: 7 */ /* last cacheline: 17 bytes */ } __attribute__((__packed__)); Fixes: 99ffe72cdae4 ("mwifiex: process rxba_sync event") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/06668edd68e7a26bbfeebd1201ae077a2a7a8bce.1692931954.git.gustavoars@kernel.org
2023-09-04wifi: mt76: fix lock dependency problem for wed_lockLorenzo Bianconi1-4/+4
Fix the following kernel depency lock holding wed_lock with BH disabled. [ 40.579696] mt798x-wmac 18000000.wifi: attaching wed device 0 version 2 [ 40.604648] platform 15010000.wed: MTK WED WO Firmware Version: DEV_000000, Build Time: 20221208202138 [ 40.613972] platform 15010000.wed: MTK WED WO Chip ID 00 Region 3 [ 40.943617] [ 40.945118] ======================================================== [ 40.951457] WARNING: possible irq lock inversion dependency detected [ 40.957797] 5.15.127 #0 Not tainted [ 40.961276] -------------------------------------------------------- [ 40.967614] insmod/2329 just changed the state of lock: [ 40.972827] ffffff8004003b08 (&dev->wed_lock){+.+.}-{2:2}, at: mt76_get_rxwi+0x1c/0xac [mt76] [ 40.981387] but this lock was taken by another, SOFTIRQ-safe lock in the past: [ 40.988592] (&q->lock){+.-.}-{2:2} [ 40.988602] [ 40.988602] [ 40.988602] and interrupts could create inverse lock ordering between them. [ 40.988602] [ 41.003445] [ 41.003445] other info that might help us debug this: [ 41.009957] Possible interrupt unsafe locking scenario: [ 41.009957] [ 41.016729] CPU0 CPU1 [ 41.021245] ---- ---- [ 41.025761] lock(&dev->wed_lock); [ 41.029241] local_irq_disable(); [ 41.035145] lock(&q->lock); [ 41.040620] lock(&dev->wed_lock); [ 41.046616] <Interrupt> [ 41.049223] lock(&q->lock); [ 41.052356] [ 41.052356] *** DEADLOCK *** [ 41.052356] [ 41.058260] 1 lock held by insmod/2329: [ 41.062085] #0: ffffff80003b9988 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x190 [ 41.070442] [ 41.070442] the shortest dependencies between 2nd lock and 1st lock: [ 41.078257] -> (&q->lock){+.-.}-{2:2} { [ 41.082177] HARDIRQ-ON-W at: [ 41.085396] lock_acquire+0xfc/0x2c0 [ 41.090787] _raw_spin_lock_bh+0x84/0xa0 [ 41.096525] mt76_dma_cleanup+0x24c/0x650 [mt76] [ 41.102977] mt76_dma_cleanup+0x614/0x650 [mt76] [ 41.109428] mt7915_eeprom_get_power_delta+0x1168/0x2464 [mt7915e] [ 41.117435] mt7915_eeprom_init+0x40/0x340 [mt7915e] [ 41.124222] cleanup_module+0x94/0xb28 [mt7915e] [ 41.130662] platform_probe+0x64/0xbc [ 41.136139] really_probe.part.0+0x98/0x2f4 [ 41.142134] __driver_probe_device+0x94/0x16c [ 41.148303] driver_probe_device+0x40/0x120 [ 41.154299] __driver_attach+0x94/0x190 [ 41.159947] bus_for_each_dev+0x5c/0x94 [ 41.165594] driver_attach+0x20/0x30 [ 41.170983] bus_add_driver+0x104/0x1f4 [ 41.176631] driver_register+0x74/0x120 [ 41.182280] __platform_driver_register+0x24/0x30 [ 41.188797] 0xffffffc000cb1074 [ 41.193754] do_one_initcall+0x70/0x2cc [ 41.199403] do_init_module+0x44/0x240 [ 41.204968] load_module+0x1f5c/0x2874 [ 41.210532] __do_sys_init_module+0x1d8/0x2ac [ 41.216702] __arm64_sys_init_module+0x18/0x20 [ 41.222958] invoke_syscall.constprop.0+0x4c/0xe0 [ 41.229474] do_el0_svc+0x50/0xf0 [ 41.234602] el0_svc+0x4c/0xcc [ 41.239471] el0t_64_sync_handler+0xe0/0x110 [ 41.245556] el0t_64_sync+0x15c/0x160 [ 41.251029] IN-SOFTIRQ-W at: [ 41.254249] lock_acquire+0xfc/0x2c0 [ 41.259638] _raw_spin_lock_bh+0x84/0xa0 [ 41.265372] mt76_queue_tx_complete+0x34/0x70 [mt76] [ 41.272170] mt76_free_pending_rxwi+0x36c/0x5d0 [mt76] [ 41.279140] mt76_free_pending_rxwi+0x5c0/0x5d0 [mt76] [ 41.286111] mt7915_eeprom_get_power_delta+0x620/0x2464 [mt7915e] [ 41.294026] __napi_poll.constprop.0+0x5c/0x230 [ 41.300372] net_rx_action+0xe4/0x294 [ 41.305847] _stext+0x154/0x4cc [ 41.310801] do_softirq+0xa4/0xbc [ 41.315930] __local_bh_enable_ip+0x168/0x174 [ 41.322097] napi_threaded_poll+0xbc/0x140 [ 41.328007] kthread+0x13c/0x150 [ 41.333049] ret_from_fork+0x10/0x20 [ 41.338437] INITIAL USE at: [ 41.341568] lock_acquire+0xfc/0x2c0 [ 41.346869] _raw_spin_lock_bh+0x84/0xa0 [ 41.352519] mt76_dma_cleanup+0x24c/0x650 [mt76] [ 41.358882] mt76_dma_cleanup+0x614/0x650 [mt76] [ 41.365245] mt7915_eeprom_get_power_delta+0x1168/0x2464 [mt7915e] [ 41.373160] mt7915_eeprom_init+0x40/0x340 [mt7915e] [ 41.379860] cleanup_module+0x94/0xb28 [mt7915e] [ 41.386213] platform_probe+0x64/0xbc [ 41.391602] really_probe.part.0+0x98/0x2f4 [ 41.397511] __driver_probe_device+0x94/0x16c [ 41.403594] driver_probe_device+0x40/0x120 [ 41.409502] __driver_attach+0x94/0x190 [ 41.415063] bus_for_each_dev+0x5c/0x94 [ 41.420625] driver_attach+0x20/0x30 [ 41.425926] bus_add_driver+0x104/0x1f4 [ 41.431487] driver_register+0x74/0x120 [ 41.437049] __platform_driver_register+0x24/0x30 [ 41.443479] 0xffffffc000cb1074 [ 41.448346] do_one_initcall+0x70/0x2cc [ 41.453907] do_init_module+0x44/0x240 [ 41.459383] load_module+0x1f5c/0x2874 [ 41.464860] __do_sys_init_module+0x1d8/0x2ac [ 41.470944] __arm64_sys_init_module+0x18/0x20 [ 41.477113] invoke_syscall.constprop.0+0x4c/0xe0 [ 41.483542] do_el0_svc+0x50/0xf0 [ 41.488582] el0_svc+0x4c/0xcc [ 41.493364] el0t_64_sync_handler+0xe0/0x110 [ 41.499361] el0t_64_sync+0x15c/0x160 [ 41.504748] } [ 41.506489] ... key at: [<ffffffc000c65ba0>] __this_module+0x3e0/0xffffffffffffa840 [mt76] [ 41.515371] ... acquired at: [ 41.518413] _raw_spin_lock+0x60/0x74 [ 41.522240] mt76_get_rxwi+0x1c/0xac [mt76] [ 41.526608] mt76_dma_cleanup+0x3e0/0x650 [mt76] [ 41.531410] mt76_dma_cleanup+0x614/0x650 [mt76] [ 41.536211] mt7915_dma_init+0x408/0x7b0 [mt7915e] [ 41.541177] mt7915_register_device+0x310/0x620 [mt7915e] [ 41.546749] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e] [ 41.551973] platform_probe+0x64/0xbc [ 41.555802] really_probe.part.0+0x98/0x2f4 [ 41.560149] __driver_probe_device+0x94/0x16c [ 41.564670] driver_probe_device+0x40/0x120 [ 41.569017] __driver_attach+0x94/0x190 [ 41.573019] bus_for_each_dev+0x5c/0x94 [ 41.577018] driver_attach+0x20/0x30 [ 41.580758] bus_add_driver+0x104/0x1f4 [ 41.584758] driver_register+0x74/0x120 [ 41.588759] __platform_driver_register+0x24/0x30 [ 41.593628] init_module+0x74/0x1000 [mt7915e] [ 41.598248] do_one_initcall+0x70/0x2cc [ 41.602248] do_init_module+0x44/0x240 [ 41.606162] load_module+0x1f5c/0x2874 [ 41.610078] __do_sys_init_module+0x1d8/0x2ac [ 41.614600] __arm64_sys_init_module+0x18/0x20 [ 41.619209] invoke_syscall.constprop.0+0x4c/0xe0 [ 41.624076] do_el0_svc+0x50/0xf0 [ 41.627555] el0_svc+0x4c/0xcc [ 41.630776] el0t_64_sync_handler+0xe0/0x110 [ 41.635211] el0t_64_sync+0x15c/0x160 [ 41.639037] [ 41.640517] -> (&dev->wed_lock){+.+.}-{2:2} { [ 41.644872] HARDIRQ-ON-W at: [ 41.648003] lock_acquire+0xfc/0x2c0 [ 41.653219] _raw_spin_lock+0x60/0x74 [ 41.658520] mt76_free_pending_rxwi+0xc0/0x5d0 [mt76] [ 41.665232] mt76_dma_cleanup+0x1dc/0x650 [mt76] [ 41.671508] mt7915_eeprom_get_power_delta+0x1830/0x2464 [mt7915e] [ 41.679336] mt7915_unregister_device+0x5b4/0x910 [mt7915e] [ 41.686555] mt7915_eeprom_get_target_power+0xb8/0x230 [mt7915e] [ 41.694209] mt7986_wmac_enable+0xc30/0xcd0 [mt7915e] [ 41.700909] platform_remove+0x4c/0x64 [ 41.706298] __device_release_driver+0x194/0x240 [ 41.712554] driver_detach+0xc0/0x100 [ 41.717857] bus_remove_driver+0x54/0xac [ 41.723418] driver_unregister+0x2c/0x54 [ 41.728980] platform_driver_unregister+0x10/0x20 [ 41.735323] mt7915_ops+0x244/0xffffffffffffed58 [mt7915e] [ 41.742457] __arm64_sys_delete_module+0x170/0x23c [ 41.748887] invoke_syscall.constprop.0+0x4c/0xe0 [ 41.755229] do_el0_svc+0x50/0xf0 [ 41.760183] el0_svc+0x4c/0xcc [ 41.764878] el0t_64_sync_handler+0xe0/0x110 [ 41.770788] el0t_64_sync+0x15c/0x160 [ 41.776088] SOFTIRQ-ON-W at: [ 41.779220] lock_acquire+0xfc/0x2c0 [ 41.784435] _raw_spin_lock+0x60/0x74 [ 41.789737] mt76_get_rxwi+0x1c/0xac [mt76] [ 41.795580] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e] [ 41.802540] mtk_wed_start+0x970/0xaa0 [ 41.807929] mt7915_dma_start+0x26c/0x630 [mt7915e] [ 41.814455] mt7915_dma_start+0x5a4/0x630 [mt7915e] [ 41.820981] mt7915_dma_init+0x45c/0x7b0 [mt7915e] [ 41.827420] mt7915_register_device+0x310/0x620 [mt7915e] [ 41.834467] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e] [ 41.841167] platform_probe+0x64/0xbc [ 41.846469] really_probe.part.0+0x98/0x2f4 [ 41.852291] __driver_probe_device+0x94/0x16c [ 41.858286] driver_probe_device+0x40/0x120 [ 41.864107] __driver_attach+0x94/0x190 [ 41.869582] bus_for_each_dev+0x5c/0x94 [ 41.875056] driver_attach+0x20/0x30 [ 41.880270] bus_add_driver+0x104/0x1f4 [ 41.885745] driver_register+0x74/0x120 [ 41.891221] __platform_driver_register+0x24/0x30 [ 41.897564] init_module+0x74/0x1000 [mt7915e] [ 41.903657] do_one_initcall+0x70/0x2cc [ 41.909130] do_init_module+0x44/0x240 [ 41.914520] load_module+0x1f5c/0x2874 [ 41.919909] __do_sys_init_module+0x1d8/0x2ac [ 41.925905] __arm64_sys_init_module+0x18/0x20 [ 41.931989] invoke_syscall.constprop.0+0x4c/0xe0 [ 41.938331] do_el0_svc+0x50/0xf0 [ 41.943285] el0_svc+0x4c/0xcc [ 41.947981] el0t_64_sync_handler+0xe0/0x110 [ 41.953892] el0t_64_sync+0x15c/0x160 [ 41.959192] INITIAL USE at: [ 41.962238] lock_acquire+0xfc/0x2c0 [ 41.967365] _raw_spin_lock+0x60/0x74 [ 41.972580] mt76_free_pending_rxwi+0xc0/0x5d0 [mt76] [ 41.979206] mt76_dma_cleanup+0x1dc/0x650 [mt76] [ 41.985395] mt7915_eeprom_get_power_delta+0x1830/0x2464 [mt7915e] [ 41.993137] mt7915_unregister_device+0x5b4/0x910 [mt7915e] [ 42.000270] mt7915_eeprom_get_target_power+0xb8/0x230 [mt7915e] [ 42.007837] mt7986_wmac_enable+0xc30/0xcd0 [mt7915e] [ 42.014450] platform_remove+0x4c/0x64 [ 42.019753] __device_release_driver+0x194/0x240 [ 42.025922] driver_detach+0xc0/0x100 [ 42.031137] bus_remove_driver+0x54/0xac [ 42.036612] driver_unregister+0x2c/0x54 [ 42.042087] platform_driver_unregister+0x10/0x20 [ 42.048344] mt7915_ops+0x244/0xffffffffffffed58 [mt7915e] [ 42.055391] __arm64_sys_delete_module+0x170/0x23c [ 42.061735] invoke_syscall.constprop.0+0x4c/0xe0 [ 42.067990] do_el0_svc+0x50/0xf0 [ 42.072857] el0_svc+0x4c/0xcc [ 42.077466] el0t_64_sync_handler+0xe0/0x110 [ 42.083289] el0t_64_sync+0x15c/0x160 [ 42.088503] } [ 42.090157] ... key at: [<ffffffc000c65c10>] __this_module+0x450/0xffffffffffffa840 [mt76] [ 42.098951] ... acquired at: [ 42.101907] __lock_acquire+0x718/0x1df0 [ 42.105994] lock_acquire+0xfc/0x2c0 [ 42.109734] _raw_spin_lock+0x60/0x74 [ 42.113561] mt76_get_rxwi+0x1c/0xac [mt76] [ 42.117929] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e] [ 42.123415] mtk_wed_start+0x970/0xaa0 [ 42.127328] mt7915_dma_start+0x26c/0x630 [mt7915e] [ 42.132379] mt7915_dma_start+0x5a4/0x630 [mt7915e] [ 42.137430] mt7915_dma_init+0x45c/0x7b0 [mt7915e] [ 42.142395] mt7915_register_device+0x310/0x620 [mt7915e] [ 42.147967] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e] [ 42.153192] platform_probe+0x64/0xbc [ 42.157019] really_probe.part.0+0x98/0x2f4 [ 42.161367] __driver_probe_device+0x94/0x16c [ 42.165887] driver_probe_device+0x40/0x120 [ 42.170234] __driver_attach+0x94/0x190 [ 42.174235] bus_for_each_dev+0x5c/0x94 [ 42.178235] driver_attach+0x20/0x30 [ 42.181974] bus_add_driver+0x104/0x1f4 [ 42.185974] driver_register+0x74/0x120 [ 42.189974] __platform_driver_register+0x24/0x30 [ 42.194842] init_module+0x74/0x1000 [mt7915e] [ 42.199460] do_one_initcall+0x70/0x2cc [ 42.203460] do_init_module+0x44/0x240 [ 42.207376] load_module+0x1f5c/0x2874 [ 42.211290] __do_sys_init_module+0x1d8/0x2ac [ 42.215813] __arm64_sys_init_module+0x18/0x20 [ 42.220421] invoke_syscall.constprop.0+0x4c/0xe0 [ 42.225288] do_el0_svc+0x50/0xf0 [ 42.228768] el0_svc+0x4c/0xcc [ 42.231989] el0t_64_sync_handler+0xe0/0x110 [ 42.236424] el0t_64_sync+0x15c/0x160 [ 42.240249] [ 42.241730] [ 42.241730] stack backtrace: [ 42.246074] CPU: 1 PID: 2329 Comm: insmod Not tainted 5.15.127 #0 [ 42.252157] Hardware name: GainStrong Oolite-MT7981B V1 Dev Board (NAND boot) (DT) [ 42.259712] Call trace: [ 42.262147] dump_backtrace+0x0/0x174 [ 42.265802] show_stack+0x14/0x20 [ 42.269108] dump_stack_lvl+0x84/0xac [ 42.272761] dump_stack+0x14/0x2c [ 42.276066] print_irq_inversion_bug.part.0+0x1b0/0x1c4 [ 42.281285] mark_lock+0x8b8/0x8bc [ 42.284678] __lock_acquire+0x718/0x1df0 [ 42.288592] lock_acquire+0xfc/0x2c0 [ 42.292158] _raw_spin_lock+0x60/0x74 [ 42.295811] mt76_get_rxwi+0x1c/0xac [mt76] [ 42.300008] mt7915_debugfs_rx_log+0x804/0xb74 [mt7915e] [ 42.305320] mtk_wed_start+0x970/0xaa0 [ 42.309059] mt7915_dma_start+0x26c/0x630 [mt7915e] [ 42.313937] mt7915_dma_start+0x5a4/0x630 [mt7915e] [ 42.318815] mt7915_dma_init+0x45c/0x7b0 [mt7915e] [ 42.323606] mt7915_register_device+0x310/0x620 [mt7915e] [ 42.329005] mt7915_mmio_probe+0xcec/0x1d44 [mt7915e] [ 42.334056] platform_probe+0x64/0xbc [ 42.337711] really_probe.part.0+0x98/0x2f4 [ 42.341885] __driver_probe_device+0x94/0x16c [ 42.346232] driver_probe_device+0x40/0x120 [ 42.350407] __driver_attach+0x94/0x190 [ 42.354234] bus_for_each_dev+0x5c/0x94 [ 42.358061] driver_attach+0x20/0x30 [ 42.361627] bus_add_driver+0x104/0x1f4 [ 42.365454] driver_register+0x74/0x120 [ 42.369282] __platform_driver_register+0x24/0x30 [ 42.373977] init_module+0x74/0x1000 [mt7915e] [ 42.378423] do_one_initcall+0x70/0x2cc [ 42.382249] do_init_module+0x44/0x240 [ 42.385990] load_module+0x1f5c/0x2874 [ 42.389733] __do_sys_init_module+0x1d8/0x2ac [ 42.394082] __arm64_sys_init_module+0x18/0x20 [ 42.398518] invoke_syscall.constprop.0+0x4c/0xe0 [ 42.403211] do_el0_svc+0x50/0xf0 [ 42.406517] el0_svc+0x4c/0xcc [ 42.409565] el0t_64_sync_handler+0xe0/0x110 [ 42.413827] el0t_64_sync+0x15c/0x160 [ 42.674858] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10, Build Time: 20221208201745a [ 42.674858] [ 42.692078] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000, Build Time: 20221208201806 [ 42.735606] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000, Build Time: 20221208202048 Tested-by: Daniel Golle <[email protected]> Fixes: 2666bece0905 ("wifi: mt76: introduce rxwi and rx token utility routines") Signed-off-by: Lorenzo Bianconi <[email protected]> Acked-by: Felix Fietkau <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/ee80be41c2a8d8749d83c6950a272a5e77aadd45.1693228333.git.lorenzo@kernel.org
Powered by cgit, Gruvboxed by Blaster4385.