From: Chris Chiu <[email protected]>
The HAS_RATE_CONTROL hw capability needs to be unset for the rate
control of mac80211 to work. Since the ieee80211_start_tx_ba_session
is started by the method .get_rate of rate_control_ops. We need to
unset it so the ampdu can be handled by mac80211.
Signed-off-by: Chris Chiu <[email protected]>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 9ff09cf7eb62..4cf13d2f86b1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6678,7 +6678,6 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
/*
* The firmware handles rate control
*/
- ieee80211_hw_set(hw, HAS_RATE_CONTROL);
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
--
2.20.1
[email protected] writes:
> From: Chris Chiu <[email protected]>
>
> The HAS_RATE_CONTROL hw capability needs to be unset for the rate
> control of mac80211 to work. Since the ieee80211_start_tx_ba_session
> is started by the method .get_rate of rate_control_ops. We need to
> unset it so the ampdu can be handled by mac80211.
The commit log is not really describing in detail _why_ you are doing
this. Switching the rate control from hardware/firmware to mac80211 is a
major change and I want to see a good explanation why this is the right
thing to do and does not cause any regressions.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches