mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 11:18:45 +07:00
a2113cc44d
Consider the following flow:
1. Driver starts to sync the rx queues due to a delba.
mvm->queue_sync_cookie=1.
This rx-queues-sync is synchronous, so it doesn't increment the
cookie until all rx queues handle the notification from FW.
2. During this time, driver starts to sync rx queues due to nssn sync
required.
The cookie's value is still 1, but it doesn't matter since this
rx-queue-sync is non-synchronous so in the notification handler the
cookie is ignored.
What _does_ matter is that this flow increments the cookie to 2
immediately.
Remember though that the FW won't start servicing this command until
it's done with the previous one.
3. FW is still handling the first command, so it sends a notification
with internal_notif->sync=1, and internal_notif->cookie=0, which
triggers a WARN_ONCE.
The solution for this race is to only use the mvm->queue_sync_cookie in
case of a synchronous sync-rx-queues. This way in step 2 the cookie's
value won't change so we avoid the WARN.
The commit in the "fixes" field is the first commit to introduce
non-synchronous sending of this command to FW.
Fixes:
|
||
|---|---|---|
| .. | ||
| admtek | ||
| ath | ||
| atmel | ||
| broadcom | ||
| cisco | ||
| intel | ||
| intersil | ||
| marvell | ||
| mediatek | ||
| quantenna | ||
| ralink | ||
| realtek | ||
| rsi | ||
| st | ||
| ti | ||
| zydas | ||
| Kconfig | ||
| mac80211_hwsim.c | ||
| mac80211_hwsim.h | ||
| Makefile | ||
| ray_cs.c | ||
| ray_cs.h | ||
| rayctl.h | ||
| rndis_wlan.c | ||
| virt_wifi.c | ||
| wl3501_cs.c | ||
| wl3501.h | ||