RE: [PATCH rtw-next v4 12/14] wifi: rtw89: Add usb.{c,h}

[Ping-Ke Shih <pkshih@realtek.com>]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Add basic USB support. No TX/RX aggregation, no switching to USB 3 mode.
> 
> RTL8851BU and RTL8832BU work.
> 
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>

Since v3 is good to me, I just checked the difference between v3 and v4, and
it looks good as well. So

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

> ---
> v2:
>  - Don't do vendor requests when unplugged.
>  - Rename rtw89_get_usb_priv() to rtw89_usb_priv().
>  - Move rtw89_usb_read_port_complete() forward declaration to the top
>    of usb.c.
>  - Remove unnecessary empty lines.
>  - Rename "error" variable to "ret".
>  - Don't call usb_kill_urb() in rtw89_usb_free_rx_bufs().
>  - Use u32_get_bits() in rtw89_usb_vendorreq().
>  - Initialise rtwdev->hci.dle_type.
>  - Delete vendor_req_mutex.
> 
> v3:
>  - Avoid skb_over_panic in rtw89_usb_fwcmd_submit() when the size is
>    a multiple of 512. We can't just extend the skb by 4 bytes, it has
>    to be copied. This was triggered by the hardware scan offload feature
>    in the "00" regulatory domain.
>  - Convert the warning in rtw89_usb_fwcmd_submit() into a debug message.
>  - Delete empty line in rtw89_usb_fwcmd_submit().
>  - Reschedule rx_work when rtw89_usb_rx_handler() finds more than 200
>    frames in the queue.
>  - Use sizeof(*rtwusb->vendor_req_buf) instead of sizeof(u32) in
>    rtw89_usb_intf_init().
> 
> v4:
>  - Implement TX queues because other parts of rtw89 expect
>    rtw89_usb_ops_tx_write() to just put a frame in a queue and
>    rtw89_usb_ops_tx_kick_off() to actually transmit.
>  - Merge rtw89_usb_write_port_complete_fwcmd() into
>    rtw89_usb_write_port_complete() because they were very similar. Add
>    txch member to struct rtw89_usb_tx_ctrl_block for this purpose.
>  - Really convert that "avoiding multiple of 512" warning into a debug
>    message. It was supposed to be done in v3 but it didn't happen.

If current version is workable for users, I'd take this version, and
then we can improve it in separated patches. Adding more and more stuffs
into this (quite big) patch is not a good idea to review and maintain.

(I knew changes of v4 is necessary.)