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: <25f998e2-20e9-fcb5-2518-8aef1033ecc0@gmail.com>
Date:   Wed, 28 Sep 2022 12:52:27 +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:     Kalle Valo <kvalo@kernel.org>
Cc:     Jes Sorensen <jes.sorensen@gmail.com>,
        linux-wireless@vger.kernel.org, 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>
 <5ba1e0f4-6eda-43bb-d426-e2a9447cd06e@gmail.com> <8735cb7v0c.fsf@kernel.org>
From:   Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <8735cb7v0c.fsf@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 28/09/2022 11:39, Kalle Valo wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> 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.