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;
Message-ID: <5ba1e0f4-6eda-43bb-d426-e2a9447cd06e@gmail.com>
Date:   Tue, 27 Sep 2022 22:49:05 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH 1/4] wifi: rtl8xxxu: gen2: Turn on the rate control
Content-Language: en-US
To:     Jes Sorensen <jes.sorensen@gmail.com>,
        linux-wireless@vger.kernel.org
Cc:     chris.chiu@canonical.com, Barry Day <briselec@gmail.com>
References: <56712d04-1505-2cbb-b6ac-3af4e73de108@gmail.com>
 <78cec57b-2678-acf3-99b3-271e0f9bdbad@gmail.com>
 <ac73924f-4c52-b8e6-1628-e34fc673a35d@gmail.com>
From:   Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <ac73924f-4c52-b8e6-1628-e34fc673a35d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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/7fa4819a-4f20-b2af-b7a6-8ee01ac49295@gmail.com/