wcn36xx: Fix (QoS) null data frame bitrate/modulation
authorLoic Poulain <loic.poulain@linaro.org>
Mon, 25 Oct 2021 13:12:18 +0000 (16:12 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 18 Nov 2021 18:15:59 +0000 (19:15 +0100)
commit3883dbfcce484e383f9a1e93d3549db66dfc17c6
treedd9684d37d47fbdac61b70065d41e57d6aa6111a
parentbfe4950d90e2a2ca2ef5475e021c8c54b7c38818
wcn36xx: Fix (QoS) null data frame bitrate/modulation

commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream.

We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capture, we noticed that null frames are
submitted at standard data bitrate and that the given APs are
in trouble with that.

After setting the null frame bitrate to control bitrate, all
null frames are acked as expected and connection is maintained.

Not sure if it's a requirement of the specification, but it seems
the right thing to do anyway, null frames are mostly used for control
purpose (power-saving, keep-alive...), and submitting them with
a slower/simpler bitrate/modulation is more robust.

Cc: stable@vger.kernel.org
Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/net/wireless/ath/wcn36xx/txrx.c