Preparation for supporting multiple radios on a single wiphy on devices
where firmware does not support actual hardware scanning.
This is also a prerequisite for full MLO support
Co-developed-by: Peter Chiu <[email protected]>
Signed-off-by: Peter Chiu <[email protected]>
Co-developed-by: Michael-CY Lee <[email protected]>
Signed-off-by: Michael-CY Lee <[email protected]>
Co-developed-by: Shayne Chen <[email protected]>
Signed-off-by: Shayne Chen <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Reset per-phy mac address slot mask in order to avoid leaking entries.
Fixes: 8a55712d124f ("wifi: mt76: mt7915: enable full system reset support")
Signed-off-by: Felix Fietkau <[email protected]>
It seems that the firmware checks the register used for detecting matching
PCIe links in order to figure out if a secondary PCIe link is enabled.
Write the register again just before starting the firmware on hw reset,
in order to fix an issue that left the second band unusable after restart.
Fixes: 9093cfff72e3 ("mt76: mt7915: add support for using a secondary PCIe link for gen1")
Signed-off-by: Felix Fietkau <[email protected]>
Setting beacon_int_min_gcd and NL80211_IFTYPE_ADHOC in the same interface
combination is invalid, which will trigger the following warning trace
and get error returned from wiphy_register().
[ 10.080325] Call trace:
[ 10.082761] wiphy_register+0xc4/0x76c [cfg80211]
[ 10.087465] ieee80211_register_hw+0x800/0xac4 [mac80211]
[ 10.092868] mt76_register_device+0x16c/0x2c0 [mt76]
[ 10.097829] mt7996_register_device+0x740/0x844 [mt7996e]
Fix this by removing unused adhoc iftype.
Fixes: 948f65249868 ("wifi: mt76: mt7996: advertize beacon_int_min_gcd")
Reported-by: Frank Wunderlich <[email protected]>
Signed-off-by: Shayne Chen <[email protected]>
Due to a limitation in available memory, the MT7916 firmware can only
handle either 5 GHz or 6 GHz at a time. It does not support runtime
switching without a full restart.
On older firmware, this accidentally worked to some degree due to missing
checks, but couldn't be supported properly, because it left the 6 GHz
channels uncalibrated.
Newer firmware refuses to start on either band if the passed EEPROM
data indicates support for both.
Deal with this limitation by using a module parameter to specify the
preferred band in case both are supported.
Fixes: b4d093e321bd ("mt76: mt7915: add 6 GHz support")
Cc: [email protected]
Signed-off-by: Shayne Chen <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The need to retry a command is really uncommon. Reduce the retries to 1 to
speed up recovery from firmware issues.
Signed-off-by: Felix Fietkau <[email protected]>
The second PCIe link is only used to improve performance on older generation
PCIe devices (e.g. MT7621) where the bus speed of one link is not enough to
saturate both wifi bands under really good conditions.
Unfortunately it seems that resetting the hardware after a firmware error
causes the second band to stop working if the second link is in use.
Disable the link until the issue is properly fixed.
For testing, the link can still be enabled via module parameter.
Fixes: 9093cfff72e3 ("mt76: mt7915: add support for using a secondary PCIe link for gen1")
Signed-off-by: Felix Fietkau <[email protected]>
Currently DFS works under assumption there could be only one channel
context in the hardware. Hence, drivers just calls the function
ieee80211_radar_detected() passing the hardware structure. However, with
MLO, this obviously will not work since number of channel contexts will be
more than one and hence drivers would need to pass the channel information
as well on which the radar is detected.
Also, when radar is detected in one of the links, other link's CAC should
not be cancelled.
Hence, in order to support DFS with MLO, do the following changes -
* Add channel context conf pointer as an argument to the function
ieee80211_radar_detected(). During MLO, drivers would have to pass on
which channel context conf radar is detected. Otherwise, drivers could
just pass NULL.
* ieee80211_radar_detected() will iterate over all channel contexts
present and
* if channel context conf is passed, only mark that as radar
detected
* if NULL is passed, then mark all channel contexts as radar
detected
* Then as usual, schedule the radar detected work.
* In the worker, go over all the contexts again and for all such context
which is marked with radar detected, cancel the ongoing CAC by calling
ieee80211_dfs_cac_cancel() and then notify cfg80211 via
cfg80211_radar_event().
* To cancel the CAC, pass the channel context as well where radar is
detected to ieee80211_dfs_cac_cancel(). This ensures that CAC is
canceled only on the links using the provided context, leaving other
links unaffected.
This would also help in scenarios where there is split phy 5 GHz radio,
which is capable of DFS channels in both lower and upper band. In this
case, simultaneous radars can be detected.
Signed-off-by: Aditya Kumar Singh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
commit c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop
period") changes the behavior of mt7915_bss_info_changed() in mesh mode
when enable_beacon becomes false: it calls mt7915_mcu_add_bss_info(...,
false) and mt7915_mcu_add_sta(..., false) while the previous code
didn't. These sends mcu commands that apparently confuse the firmware.
This breaks scanning while in mesh mode on AsiaRF MT7916 DBDC-based cards:
scanning works but no mesh frames get sent afterwards and the firmware
seems to be hosed. It breaks on MT7916 DBDC but not on MT7915 DBDC.
Fixes: c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period")
Signed-off-by: Nicolas Cavallari <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
To ensure code clarity and prevent potential errors, it's advisable
to employ the ';' as a statement separator, except when ',' are
intentionally used for specific purposes.
Signed-off-by: Shen Lichuan <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
This comparison should be >= instead of > to prevent an out of bounds
read and write.
Fixes: 9679ca7326e5 ("wifi: mt76: mt7925: fix a potential array-index-out-of-bounds issue for clc")
Signed-off-by: Dan Carpenter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
The maximum command quota of the firmware may be exceeded because the
command to retrieve the quota setting has not been taken into account.
This patch considers not only the quota usage of the command retrieving
quota settings but also limits the total quota usage.
Signed-off-by: Leon Yen <[email protected]>
Signed-off-by: Ming Yen Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Support passing customized buffer pointer and length to
mt7996_mcu_get_eeprom().
This is the preparation for adding more variants support which needs to
prefetch FEM module from efuse, and also fixes potential OOB issue when
reading the last efuse block.
Co-developed-by: StanleyYP Wang <[email protected]>
Signed-off-by: StanleyYP Wang <[email protected]>
Signed-off-by: Shayne Chen <[email protected]>
Tested-by: Daniel Golle <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
If mcu_skb_prepare_msg is not implemented, incrementing skb refcount does not
work for mcu message retry. In some cases (e.g. on SDIO), shared skbs can trigger
a BUG_ON, crashing the system.
Fix this by only incrementing refcount if retry is actually supported.
Fixes: 3688c18b65ae ("wifi: mt76: mt7915: retry mcu messages")
Reported-by: Nícolas F. R. A. Prado <[email protected]> #KernelCI
Tested-by: Alper Nebi Yasak <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Due to the lack of checks on the clc array, if the firmware supports
more clc configuration, it will cause illegal memory access.
Cc: [email protected]
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Ming Yen Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
devm_kasprintf() can return a NULL pointer on failure but this returned
value is not checked. Fix this lack and check the returned value.
Found by code review.
Cc: [email protected]
Fixes: 0bb4e9187ea4 ("mt76: mt7615: fix hwmon temp sensor mem use-after-free")
Signed-off-by: Ma Ke <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen Ni <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
In multi-channel scenarios, the granted channel must be aborted before
suspending. Otherwise, the firmware will be put into a wrong state,
resulting in an association failure after resuming.
With this patch, the granted channel will be aborted before suspending
if necessary.
Cc: [email protected]
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Michael Lo <[email protected]>
Signed-off-by: Ming Yen Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[email protected]>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `struct_group_tagged()`
helper to create a new tagged `struct mt76_connac2_mcu_rxd_hdr`.
This structure groups together all the members of the flexible
`struct mt76_connac2_mcu_rxd` except the flexible array.
As a result, the array is effectively separated from the rest of the
members without modifying the memory layout of the flexible structure.
We then change the type of the middle struct members currently causing
trouble from `struct mt76_connac2_mcu_rxd` to `struct
mt76_connac2_mcu_rxd_hdr`.
We also want to ensure that when new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.
This approach avoids having to implement `struct mt76_connac2_mcu_rxd_hdr`
as a completely separate structure, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.
So, with these changes, fix the following warnings:
drivers/net/wireless/mediatek/mt76/mt7915/mcu.h:32:37: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/mediatek/mt76/mt7915/mcu.h:40:37: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/mediatek/mt76/mt7915/mcu.h:49:37: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/mediatek/mt76/mt7915/mcu.h:58:37: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Link: https://patch.msgid.link/Zr5KsZugaEXrApQJ@elsanto
Signed-off-by: Felix Fietkau <[email protected]>
Felix Fietkau