dwc_otg: checking the urb->transfer_buffer too early (#3332)
authorHui Wang <hui.wang@canonical.com>
Sun, 17 Nov 2019 02:31:46 +0000 (10:31 +0800)
committerpopcornmix <popcornmix@gmail.com>
Wed, 1 Jul 2020 15:33:12 +0000 (16:33 +0100)
commit50bd23a1edbb1f80f3edc2ae510f483909f0f482
tree54526939416f316abfe8d33e60ce9cc59b3ce306
parent239cbaa1e5cc8d4bc15e6a2404135a4d4f5c0808
dwc_otg: checking the urb->transfer_buffer too early (#3332)

After enable the HIGHMEM and VMSPLIT_3G, the dwc_otg driver doesn't
work well on Pi2/3 boards with 1G physical ram. Users experience
the failure when copying a file of 600M size to the USB stick. And
at the same time, the dmesg shows:
usb 1-1.1.2: reset high-speed USB device number 8 using dwc_otg
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
blk_update_request: I/O error, dev sda, sector 3024048 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0

When this happens, the sg_buf sent to the driver is located in the
highmem region, the usb_sg_init() in the core/message.c will leave
transfer_buffer to NULL if the sg_buf is in highmem, but in the
dwc_otg driver, it returns -EINVAL unconditionally if transfer_buffer
is NULL.

The driver can handle the situation of buffer to be NULL, if it is in
DMA mode, it will convert an address from transfer_dma.

But if the conversion fails or it is in the PIO mode, we should check
buffer and return -EINVAL if it is NULL.

BugLink: https://bugs.launchpad.net/bugs/1852510
Signed-off-by: Hui Wang <hui.wang@canonical.com>
drivers/usb/host/dwc_otg/dwc_otg_hcd_linux.c