I found these problems in my quest to make rtl8xxxu as fast as the
rtl8188fu driver. With these changes at least the download speed is
almost as good. The upload speed gets better but it's not there yet,
possibly because there is no MSDU aggregation.
Bitterblue Smith (4):
wifi: rtl8xxxu: gen2: Turn on the rate control
wifi: rtl8xxxu: gen2: Enable 40 MHz channel width
wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM
wifi: rtl8xxxu: Improve rtl8xxxu_queue_select
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 92 ++++++++++++++++---
2 files changed, 82 insertions(+), 16 deletions(-)
--
2.37.2
Inform the firmware when connecting to a network. This makes the
firmware enable the rate control, which makes the upload faster.
Don't inform the firmware when disconnecting from a network, because
that makes reconnecting impossible for some reason:
wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 1/3)
wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 2/3)
wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 3/3)
wlp0s20f0u3: authentication with 90:55:de:__:__:__ timed out
Not informing the firmware about disconnecting doesn't seem to have
any downside.
Tested only with RTL8188FU. Someone should test the other gen2 chips:
RTL8723BU and RTL8192EU.
Fixes: c59f13bbead4 ("rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconn…")
Signed-off-by: Bitterblue Smith <[email protected]>
---
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 32ab6ed5b9b6..7978d5dcc826 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4471,25 +4471,34 @@ void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect)
{
-#ifdef RTL8XXXU_GEN2_REPORT_CONNECT
/*
* Barry Day reports this causes issues with 8192eu and 8723bu
* devices reconnecting. The reason for this is unclear, but
* until it is better understood, leave the code in place but
* disabled, so it is not lost.
*/
+ /*
+ * It also affects 8188FU. However, without this the rate control
+ * is not on. Probably it only enables the rate control when it
+ * knows it's connected to a network.
+ *
+ * Hack: don't report the disconnect. This way the rate control
+ * is on and reconnecting also works. TODO Test 8192EU and 8723BU.
+ */
struct h2c_cmd h2c;
memset(&h2c, 0, sizeof(struct h2c_cmd));
h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
- if (connect)
+ if (connect) {
h2c.media_status_rpt.parm |= BIT(0);
+ /*
else
h2c.media_status_rpt.parm &= ~BIT(0);
+ */
- rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
-#endif
+ rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
+ }
}
void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
--
2.37.2
The module parameter ht40_2g was supposed to enable 40 MHz operation,
but it didn't.
Tell the firmware about the channel width when updating the rate mask.
This makes it work with my gen 2 chip RTL8188FU.
I'm not sure if anything needs to be done for the gen 1 chips, if 40
MHz channel width already works or not. They update the rate mask with
a different structure which doesn't have a field for the channel width.
Also set the channel width correctly for sta_statistics.
Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips")
Signed-off-by: Bitterblue Smith <[email protected]>
---
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +++---
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 21 +++++++++++++------
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 501900c07fac..9950a2ee00aa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1477,7 +1477,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, u8 rateid, int sgi);
+ u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1565,9 +1565,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, u8 rateid, int sgi);
+ u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, u8 rateid, int sgi);
+ u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 7978d5dcc826..7724ee8033a8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4407,7 +4407,7 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
}
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, u8 rateid, int sgi)
+ u32 ramask, u8 rateid, int sgi, int txbw_40mhz)
{
struct h2c_cmd h2c;
@@ -4427,10 +4427,15 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, u8 rateid, int sgi)
+ u32 ramask, u8 rateid, int sgi, int txbw_40mhz)
{
struct h2c_cmd h2c;
- u8 bw = RTL8XXXU_CHANNEL_WIDTH_20;
+ u8 bw;
+
+ if (txbw_40mhz)
+ bw = RTL8XXXU_CHANNEL_WIDTH_40;
+ else
+ bw = RTL8XXXU_CHANNEL_WIDTH_20;
memset(&h2c, 0, sizeof(struct h2c_cmd));
@@ -4717,7 +4722,11 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
RATE_INFO_FLAGS_SHORT_GI;
}
- rarpt->txrate.bw |= RATE_INFO_BW_20;
+ if (rtl8xxxu_ht40_2g &&
+ (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
+ rarpt->txrate.bw = RATE_INFO_BW_40;
+ else
+ rarpt->txrate.bw = RATE_INFO_BW_20;
}
bit_rate = cfg80211_calculate_bitrate(&rarpt->txrate);
rarpt->bit_rate = bit_rate;
@@ -4726,7 +4735,7 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
priv->vif = vif;
priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
- priv->fops->update_rate_mask(priv, ramask, 0, sgi);
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi, rarpt->txrate.bw == RATE_INFO_BW_40);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -6440,7 +6449,7 @@ static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
}
priv->rssi_level = rssi_level;
- priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi, txbw_40mhz);
}
}
--
2.37.2
ieee80211_tx_queue_params.aifs is not supposed to be written directly
to the REG_EDCA_*_PARAM registers. Instead process it like the vendor
drivers do. It's kinda hacky but it works.
This change boosts the download speed and makes it more stable.
Tested with RTL8188FU but all the other supported chips should also
benefit.
Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <[email protected]>
---
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 49 +++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 7724ee8033a8..9ddff43b5cfc 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4656,6 +4656,53 @@ rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
return network_type;
}
+static void rtl8xxxu_set_aifs(struct rtl8xxxu_priv *priv, u8 slot_time)
+{
+ u32 reg_edca_param[IEEE80211_NUM_ACS] = {
+ [IEEE80211_AC_VO] = REG_EDCA_VO_PARAM,
+ [IEEE80211_AC_VI] = REG_EDCA_VI_PARAM,
+ [IEEE80211_AC_BE] = REG_EDCA_BE_PARAM,
+ [IEEE80211_AC_BK] = REG_EDCA_BK_PARAM,
+ };
+ u32 val32;
+ u16 wireless_mode = 0;
+ u8 aifs, aifsn, sifs;
+ int i;
+
+ if (priv->vif) {
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(priv->vif, priv->vif->bss_conf.bssid);
+ if (sta)
+ wireless_mode = rtl8xxxu_wireless_mode(priv->hw, sta);
+ rcu_read_unlock();
+ }
+
+ if (priv->hw->conf.chandef.chan->band == NL80211_BAND_5GHZ ||
+ (wireless_mode & WIRELESS_MODE_N_24G))
+ sifs = 16;
+ else
+ sifs = 10;
+
+ for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ val32 = rtl8xxxu_read32(priv, reg_edca_param[i]);
+
+ /* It was set in conf_tx. */
+ aifsn = val32 & 0xff;
+
+ /* aifsn not set yet or already fixed */
+ if (aifsn < 2 || aifsn > 15)
+ continue;
+
+ aifs = aifsn * slot_time + sifs;
+
+ val32 &= ~0xff;
+ val32 |= aifs;
+ rtl8xxxu_write32(priv, reg_edca_param[i], val32);
+ }
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u64 changed)
@@ -4775,6 +4822,8 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
else
val8 = 20;
rtl8xxxu_write8(priv, REG_SLOT, val8);
+
+ rtl8xxxu_set_aifs(priv, val8);
}
if (changed & BSS_CHANGED_BSSID) {
--
2.37.2
Remove the unused ieee80211_hw* parameter, and pass ieee80211_hdr*
instead of relying on skb->data having the right value at the time
the function is called.
This doesn't change the functionality at all.
Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
Signed-off-by: Bitterblue Smith <[email protected]>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 9ddff43b5cfc..7715680d8bea 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4863,9 +4863,8 @@ static u32 rtl8xxxu_80211_to_rtl_queue(u32 queue)
return rtlqueue;
}
-static u32 rtl8xxxu_queue_select(struct ieee80211_hw *hw, struct sk_buff *skb)
+static u32 rtl8xxxu_queue_select(struct ieee80211_hdr *hdr, struct sk_buff *skb)
{
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
u32 queue;
if (ieee80211_is_mgmt(hdr->frame_control))
@@ -5215,7 +5214,7 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
if (control && control->sta)
sta = control->sta;
- queue = rtl8xxxu_queue_select(hw, skb);
+ queue = rtl8xxxu_queue_select(hdr, skb);
tx_desc = skb_push(skb, tx_desc_size);
--
2.37.2
On 9/18/22 08:42, Bitterblue Smith wrote:
> ieee80211_tx_queue_params.aifs is not supposed to be written directly
> to the REG_EDCA_*_PARAM registers. Instead process it like the vendor
> drivers do. It's kinda hacky but it works.
>
> This change boosts the download speed and makes it more stable.
>
> Tested with RTL8188FU but all the other supported chips should also
> benefit.
>
> Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
> Signed-off-by: Bitterblue Smith <[email protected]>
Acked-by: Jes Sorensen <[email protected]>
Jes
On 9/18/22 08:35, Bitterblue Smith wrote:
> Inform the firmware when connecting to a network. This makes the
> firmware enable the rate control, which makes the upload faster.
>
> Don't inform the firmware when disconnecting from a network, because
> that makes reconnecting impossible for some reason:
Have you dug through the vendor driver to see what it does here?
Thanks,
Jes
> wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 1/3)
> wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 2/3)
> wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 3/3)
> wlp0s20f0u3: authentication with 90:55:de:__:__:__ timed out
>
> Not informing the firmware about disconnecting doesn't seem to have
> any downside.
>
> Tested only with RTL8188FU. Someone should test the other gen2 chips:
> RTL8723BU and RTL8192EU.
>
> Fixes: c59f13bbead4 ("rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconn…")
> Signed-off-by: Bitterblue Smith <[email protected]>
> ---
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 32ab6ed5b9b6..7978d5dcc826 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -4471,25 +4471,34 @@ void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
> void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
> u8 macid, bool connect)
> {
> -#ifdef RTL8XXXU_GEN2_REPORT_CONNECT
> /*
> * Barry Day reports this causes issues with 8192eu and 8723bu
> * devices reconnecting. The reason for this is unclear, but
> * until it is better understood, leave the code in place but
> * disabled, so it is not lost.
> */
> + /*
> + * It also affects 8188FU. However, without this the rate control
> + * is not on. Probably it only enables the rate control when it
> + * knows it's connected to a network.
> + *
> + * Hack: don't report the disconnect. This way the rate control
> + * is on and reconnecting also works. TODO Test 8192EU and 8723BU.
> + */
> struct h2c_cmd h2c;
>
> memset(&h2c, 0, sizeof(struct h2c_cmd));
>
> h2c.media_status_rpt.cmd = H2C_8723B_MEDIA_STATUS_RPT;
> - if (connect)
> + if (connect) {
> h2c.media_status_rpt.parm |= BIT(0);
> + /*
> else
> h2c.media_status_rpt.parm &= ~BIT(0);
> + */
>
> - rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
> -#endif
> + rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
> + }
> }
>
> void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
On 9/18/22 08:47, Bitterblue Smith wrote:
> Remove the unused ieee80211_hw* parameter, and pass ieee80211_hdr*
> instead of relying on skb->data having the right value at the time
> the function is called.
>
> This doesn't change the functionality at all.
>
> Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
> Signed-off-by: Bitterblue Smith <[email protected]>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Acked-by: Jes Sorensen <[email protected]>
Jes
On 9/18/22 08:40, Bitterblue Smith wrote:
> The module parameter ht40_2g was supposed to enable 40 MHz operation,
> but it didn't.
>
> Tell the firmware about the channel width when updating the rate mask.
> This makes it work with my gen 2 chip RTL8188FU.
>
> I'm not sure if anything needs to be done for the gen 1 chips, if 40
> MHz channel width already works or not. They update the rate mask with
> a different structure which doesn't have a field for the channel width.
>
> Also set the channel width correctly for sta_statistics.
>
> Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
> Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips")
> Signed-off-by: Bitterblue Smith <[email protected]>
Acked-by: Jes Sorensen <[email protected]>
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +++---
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 21 +++++++++++++------
> 2 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index 501900c07fac..9950a2ee00aa 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1477,7 +1477,7 @@ struct rtl8xxxu_fileops {
> void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
> bool ht40);
> void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
> - u32 ramask, u8 rateid, int sgi);
> + u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
> void (*report_connect) (struct rtl8xxxu_priv *priv,
> u8 macid, bool connect);
> void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
> @@ -1565,9 +1565,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
> void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
> void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
> void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, u8 rateid, int sgi);
> + u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
> void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, u8 rateid, int sgi);
> + u32 ramask, u8 rateid, int sgi, int txbw_40mhz);
> void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
> u8 macid, bool connect);
> void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 7978d5dcc826..7724ee8033a8 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -4407,7 +4407,7 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
> }
>
> void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, u8 rateid, int sgi)
> + u32 ramask, u8 rateid, int sgi, int txbw_40mhz)
> {
> struct h2c_cmd h2c;
>
> @@ -4427,10 +4427,15 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
> }
>
> void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
> - u32 ramask, u8 rateid, int sgi)
> + u32 ramask, u8 rateid, int sgi, int txbw_40mhz)
> {
> struct h2c_cmd h2c;
> - u8 bw = RTL8XXXU_CHANNEL_WIDTH_20;
> + u8 bw;
> +
> + if (txbw_40mhz)
> + bw = RTL8XXXU_CHANNEL_WIDTH_40;
> + else
> + bw = RTL8XXXU_CHANNEL_WIDTH_20;
>
> memset(&h2c, 0, sizeof(struct h2c_cmd));
>
> @@ -4717,7 +4722,11 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> RATE_INFO_FLAGS_SHORT_GI;
> }
>
> - rarpt->txrate.bw |= RATE_INFO_BW_20;
> + if (rtl8xxxu_ht40_2g &&
> + (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
> + rarpt->txrate.bw = RATE_INFO_BW_40;
> + else
> + rarpt->txrate.bw = RATE_INFO_BW_20;
> }
> bit_rate = cfg80211_calculate_bitrate(&rarpt->txrate);
> rarpt->bit_rate = bit_rate;
> @@ -4726,7 +4735,7 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> priv->vif = vif;
> priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
>
> - priv->fops->update_rate_mask(priv, ramask, 0, sgi);
> + priv->fops->update_rate_mask(priv, ramask, 0, sgi, rarpt->txrate.bw == RATE_INFO_BW_40);
>
> rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
>
> @@ -6440,7 +6449,7 @@ static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
> }
>
> priv->rssi_level = rssi_level;
> - priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
> + priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi, txbw_40mhz);
> }
> }
>
Bitterblue Smith <[email protected]> writes:
> ieee80211_tx_queue_params.aifs is not supposed to be written directly
> to the REG_EDCA_*_PARAM registers. Instead process it like the vendor
> drivers do. It's kinda hacky but it works.
>
> This change boosts the download speed and makes it more stable.
>
> Tested with RTL8188FU but all the other supported chips should also
> benefit.
>
> Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
> Signed-off-by: Bitterblue Smith <[email protected]>
[...]
> +static void rtl8xxxu_set_aifs(struct rtl8xxxu_priv *priv, u8 slot_time)
> +{
> + u32 reg_edca_param[IEEE80211_NUM_ACS] = {
> + [IEEE80211_AC_VO] = REG_EDCA_VO_PARAM,
> + [IEEE80211_AC_VI] = REG_EDCA_VI_PARAM,
> + [IEEE80211_AC_BE] = REG_EDCA_BE_PARAM,
> + [IEEE80211_AC_BK] = REG_EDCA_BK_PARAM,
> + };
static const?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 25/09/2022 19:53, Jes Sorensen wrote:
> On 9/18/22 08:35, Bitterblue Smith wrote:
>> Inform the firmware when connecting to a network. This makes the
>> firmware enable the rate control, which makes the upload faster.
>>
>> Don't inform the firmware when disconnecting from a network, because
>> that makes reconnecting impossible for some reason:
>
> Have you dug through the vendor driver to see what it does here?
>
> Thanks,
> Jes
>
I hadn't investigated, but since you asked :) I looked into it today.
The vendor driver doesn't do anything weird. Our report_connect
function *should* work.
And it turns out it does work! I restored the original form of the
function to test something and reconnecting worked. I couldn't
reproduce the problem anymore. Not much has changed in rtl8xxxu since
the last time I tried this, so it was easy to find the reason: fixing
the queue selection [0] fixed the reconnecting problem. Before, it was
sending the auth attempts using queue 0x7 (TXDESC_QUEUE_VO). With the
queue selection fix it uses queue 0x12 (TXDESC_QUEUE_MGNT). Perhaps
queue 0x7 is not functional when the firmware knows it's not connected
to a network?
I guess I have to send a different patch for this now.
[0] https://lore.kernel.org/linux-wireless/[email protected]/
Bitterblue Smith <[email protected]> writes:
> On 25/09/2022 19:53, Jes Sorensen wrote:
>> On 9/18/22 08:35, Bitterblue Smith wrote:
>>> Inform the firmware when connecting to a network. This makes the
>>> firmware enable the rate control, which makes the upload faster.
>>>
>>> Don't inform the firmware when disconnecting from a network, because
>>> that makes reconnecting impossible for some reason:
>>
>> Have you dug through the vendor driver to see what it does here?
>>
>> Thanks,
>> Jes
>>
>
> I hadn't investigated, but since you asked :) I looked into it today.
>
> The vendor driver doesn't do anything weird. Our report_connect
> function *should* work.
>
> And it turns out it does work! I restored the original form of the
> function to test something and reconnecting worked. I couldn't
> reproduce the problem anymore. Not much has changed in rtl8xxxu since
> the last time I tried this, so it was easy to find the reason: fixing
> the queue selection [0] fixed the reconnecting problem. Before, it was
> sending the auth attempts using queue 0x7 (TXDESC_QUEUE_VO). With the
> queue selection fix it uses queue 0x12 (TXDESC_QUEUE_MGNT). Perhaps
> queue 0x7 is not functional when the firmware knows it's not connected
> to a network?
>
> I guess I have to send a different patch for this now.
So what should I do with this patchset? Can I take patches 2-4?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 28/09/2022 11:39, Kalle Valo wrote:
> Bitterblue Smith <[email protected]> writes:
>
>> On 25/09/2022 19:53, Jes Sorensen wrote:
>>> On 9/18/22 08:35, Bitterblue Smith wrote:
>>>> Inform the firmware when connecting to a network. This makes the
>>>> firmware enable the rate control, which makes the upload faster.
>>>>
>>>> Don't inform the firmware when disconnecting from a network, because
>>>> that makes reconnecting impossible for some reason:
>>>
>>> Have you dug through the vendor driver to see what it does here?
>>>
>>> Thanks,
>>> Jes
>>>
>>
>> I hadn't investigated, but since you asked :) I looked into it today.
>>
>> The vendor driver doesn't do anything weird. Our report_connect
>> function *should* work.
>>
>> And it turns out it does work! I restored the original form of the
>> function to test something and reconnecting worked. I couldn't
>> reproduce the problem anymore. Not much has changed in rtl8xxxu since
>> the last time I tried this, so it was easy to find the reason: fixing
>> the queue selection [0] fixed the reconnecting problem. Before, it was
>> sending the auth attempts using queue 0x7 (TXDESC_QUEUE_VO). With the
>> queue selection fix it uses queue 0x12 (TXDESC_QUEUE_MGNT). Perhaps
>> queue 0x7 is not functional when the firmware knows it's not connected
>> to a network?
>>
>> I guess I have to send a different patch for this now.
>
> So what should I do with this patchset? Can I take patches 2-4?
>
Yes, please. They're all independent.
Bitterblue Smith <[email protected]> writes:
> On 28/09/2022 11:39, Kalle Valo wrote:
>
>> Bitterblue Smith <[email protected]> writes:
>>
>>> I guess I have to send a different patch for this now.
>>
>> So what should I do with this patchset? Can I take patches 2-4?
>
> Yes, please. They're all independent.
Very good, so I'll then take patches 2-4. I'll drop patch 1 and wait for
the next version.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Bitterblue Smith <[email protected]> wrote:
> The module parameter ht40_2g was supposed to enable 40 MHz operation,
> but it didn't.
>
> Tell the firmware about the channel width when updating the rate mask.
> This makes it work with my gen 2 chip RTL8188FU.
>
> I'm not sure if anything needs to be done for the gen 1 chips, if 40
> MHz channel width already works or not. They update the rate mask with
> a different structure which doesn't have a field for the channel width.
>
> Also set the channel width correctly for sta_statistics.
>
> Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function")
> Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips")
> Signed-off-by: Bitterblue Smith <[email protected]>
> Acked-by: Jes Sorensen <[email protected]>
3 patches applied to wireless-next.git, thanks.
a8b5aef2cca1 wifi: rtl8xxxu: gen2: Enable 40 MHz channel width
5574d3290449 wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM
2fc6de5c6924 wifi: rtl8xxxu: Improve rtl8xxxu_queue_select
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches