Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Jes Sorensen <jes.sorensen@gmail.com>
Message-ID: <ac73924f-4c52-b8e6-1628-e34fc673a35d@gmail.com>
Date:   Sun, 25 Sep 2022 12:53:46 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.0
Subject: Re: [PATCH 1/4] wifi: rtl8xxxu: gen2: Turn on the rate control
Content-Language: en-US
To:     Bitterblue Smith <rtl8821cerfe2@gmail.com>,
        linux-wireless@vger.kernel.org
Cc:     chris.chiu@canonical.com
References: <56712d04-1505-2cbb-b6ac-3af4e73de108@gmail.com>
 <78cec57b-2678-acf3-99b3-271e0f9bdbad@gmail.com>
In-Reply-To: <78cec57b-2678-acf3-99b3-271e0f9bdbad@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

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 <rtl8821cerfe2@gmail.com>
> ---
>  .../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)