> -----Original Message-----
> From: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx>
> Sent: Thursday, January 18, 2024 4:12 AM
> To: linux-wireless@xxxxxxxxxxxxxxx
> Cc: Ping-Ke Shih <pkshih@xxxxxxxxxxx>; Larry Finger <Larry.Finger@xxxxxxxxxxxx>
> 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@xxxxxxxxx>
Acked-by: Ping-Ke Shih <pkshih@xxxxxxxxxxx>
[...]
> 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?
> +}
> +
