On 01/07/2025 05:21, Ping-Ke Shih wrote: > Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> 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@xxxxxxxxx> > > 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@xxxxxxxxxxx> > >> --- >> 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 completely agree, this is big enough. > (I knew changes of v4 is necessary.) >
