Unloading the mt7915e module with a MT7916 triggers multiples WARN in
__netif_napi_del_locked() and in page_pool_disable_direct_recycling()
because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module
and reinsert it with a different enable_6ghz parameter to change the
frequency. The system generally becomes unstable after reinserting the
module.
Fix it by disabling napi before deleting it. Also, do not delete napi
on WED queues since napi is neither used nor initialized on them.
Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Nicolas Cavallari <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Felix Fietkau <[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]>
The hardware simply does not support this in DBDC mode. Remove it from
the HE capabilities.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Do not hardcode beamformee 4 space-time streams support, because
DBDC can only support up to 2.
Fixes: 00b2e16e0063 ("mt76: mt7915: add TxBF capabilities")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
mt7915 does not have a per-band number of chains unlike the other chips,
it only has a total number of chains. Yet the current code would
consider the total number as a per-band number.
For example, it would report that a 2x2 + 2x2 DBDC card have 4 chains on
each band and set chainmask to 0b1111 for the first interface and
0b11110000 for the second.
Fixes: 99ad32a4ca3a ("mt76: mt7915: add support for MT7986")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
If the nss value is zero in the eeprom, set it to the max.
This eeprom fragment from a mt7915 DBDC shows the problem:
00000190: 24 24 08 00 28 00 00 15 00 00 00 00 00 00 00 00
Fixes: 51a87540232c ("wifi: mt76: mt7915: rework eeprom tx paths and streams init")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
By default, mt7915e does not enable thermal management until the default
thermal zone does not reach a trip point. If the rest of the system
have better cooling than the wireless hardware, then it is possible that
the wireless chip can overheat while the rest of the system is fine.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The firmware-controlled actual throttle state was previously available
by reading the cooling_device, but this confused the thermal subsystem.
Add a hwmon attribute to get it instead.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
mt7915e registers a cooling_device with wrong semantics:
1. cooling_device expect that higher states values should cool more, but
mt7915e did the opposite... with the exception of state == 0, which
should "disable thermal management", but does not seem to have any
effect since the previous state is kept.
The result is that when the thermal zone heats up a bit and bumps the
cooling_device state from 0 to 1 to cool a bit, the performance is
destroyed, and when going back from 1 to 0, the performance stays bad.
2. Reading the cooling_device state does not always return the last
written state, but can return the actual hardware throttle state,
which is different.
This is a problem because the mt7915 firmware actually implement the
equivalent of a thermal zone with trip points. Setting the cooling
device state actually changes the throttles at each trip point, so the
following could occur if the first issue is fixed:
- thermal subsystem set state to 100% power (state=0)
- mt7915e driver set trip throttles to [100%, 50%, 25%, 12%]
- hardware heats up and decides to switch to 50% power
- thermal subsystem see that power is 50% (state=50), decide to increase
it to 60% (state=40) because the rest of the system is cool.
- mt7915e driver set trip throttle to [60%, 30%, 15%, 7%]
- hardware thus switches to 30% power
[race to the bottom continues...]
This patch corrects the semantics of the cooling_device to the one that
the thermal subsystem expect it.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
