Received-SPF: pass (google.com: domain of linux-wireless+bounces-2193-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <1314347a-a7a7-4021-bcd5-58ff7cfa0fba@gmail.com>
Date: Thu, 18 Jan 2024 17:56:25 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] wifi: rtlwifi: Speed up firmware loading for USB
To: Ping-Ke Shih <pkshih@realtek.com>,
 "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
References: <d9bd4949-6e92-4f35-8b60-3b45f9ad74ab@gmail.com>
 <69d5e71d354b48ef839fb3d3c47f09c7@realtek.com>
Content-Language: en-US
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <69d5e71d354b48ef839fb3d3c47f09c7@realtek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18/01/2024 02:37, Ping-Ke Shih wrote:
> 
> 
>> -----Original Message-----
>> From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> Sent: Thursday, January 18, 2024 4:12 AM
>> To: linux-wireless@vger.kernel.org
>> Cc: Ping-Ke Shih <pkshih@realtek.com>; Larry Finger <Larry.Finger@lwfinger.net>
>> Subject: [PATCH v2] wifi: rtlwifi: Speed up firmware loading for USB
>>
>> Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
>> (and 11 seconds for RTL8192DU). That's because the firmware is uploaded
>> one byte at a time.
>>
>> Also, after plugging the device, the firmware gets uploaded three times
>> before a connection to the AP is established.
>>
>> Maybe this is fine for most users, but when testing changes to the
>> driver it's really annoying to wait so long.
>>
>> Speed up the firmware upload by writing chunks of 64 bytes at a time.
>> This way it takes about 110 ms for RTL8192CU (and about 210 ms for
>> RTL8192DU).
>>
>> PCI devices could upload it in chunks of 4 bytes, but I don't have any
>> to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
>> rather than as dwords") decided otherwise anyway.
>>
>> Allocate memory for the firmware image with kmalloc instead of vzalloc
>> because this memory is passed directly to usb_control_msg(), which
>> can't take memory allocated by vmalloc.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> 
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> 
> [...]
> 
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
>> index 07a7e6fa46af..1fc480fe18ad 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/usb.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
>> @@ -125,6 +125,14 @@ static void _usb_write32_sync(struct rtl_priv *rtlpriv, u32 addr, u32 val)
>>         _usb_write_sync(rtlpriv, addr, val, 4);
>>  }
>>
>> +static void _usb_write_chunk_sync(struct rtl_priv *rtlpriv, u32 addr,
>> +                                 u32 length, u8 *data)
>> +{
>> +       struct usb_device *udev = to_usb_device(rtlpriv->io.dev);
>> +
>> +       _usbctrl_vendorreq_sync(udev, REALTEK_USB_VENQT_WRITE, addr, data, length);
> 
> Just curious. Originally, it uses 1/2/4 as length for write8/16/32, and this
> patch additionally uses 8/64 as length. Any limitation of argument 'length' of
> this function? Is arbitrary number disallowed? 
> 

I didn't find anything in the usb_control_msg() documentation.
I only found this issue, where some people say 0xffff is fine,
but older hardware may have a limit of 4096:
https://github.com/libusb/libusb/issues/125

rtl8xxxu uses lengths of 32, 94, 124, 126, 128, 156, 254 bytes.
Some other Realtek wifi drivers use 196 bytes.