wireguard-linux/drivers/usb/dwc2/hcd.c, branch jd/unified-crypt-queue

usb: dwc2: Fix NULL qh in dwc2_queue_transaction

2020-01-15T09:39:20Z

When a usb device disconnects in a certain way, dwc2_queue_transaction still gets called after dwc2_hcd_cleanup_channels. dwc2_hcd_cleanup_channels does "channel->qh = NULL;" but dwc2_queue_transaction still wants to dereference qh. This adds a check for a null qh. Acked-by: Minas Harutyunyan Signed-off-by: Alexandru M Stan [dianders: rebased to mainline] Signed-off-by: Douglas Anderson Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: add a HCD_DMA flag instead of guestimating DMA capabilities

2019-08-21T17:03:35Z

The usb core is the only major place in the kernel that checks for a non-NULL device dma_mask to see if a device is DMA capable. This is generally a bad idea, as all major busses always set up a DMA mask, even if the device is not DMA capable - in fact bus layers like PCI can't even know if a device is DMA capable at enumeration time. This leads to lots of workaround in HCD drivers, and also prevented us from setting up a DMA mask for platform devices by default last time we tried. Replace this guess with an explicit HCD_DMA that is set by drivers that appear to have DMA support. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190816062435.881-4-hch@lst.de Signed-off-by: Greg Kroah-Hartman

usb: add a hcd_uses_dma helper

2019-08-15T13:18:05Z

The USB buffer allocation code is the only place in the usb core (and in fact the whole kernel) that uses is_device_dma_capable, while the URB mapping code uses the uses_dma flag in struct usb_bus. Switch the buffer allocation to use the uses_dma flag used by the rest of the USB code, and create a helper in hcd.h that checks this flag as well as the CONFIG_HAS_DMA to simplify the caller a bit. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de Signed-off-by: Greg Kroah-Hartman

Revert "usb: dwc2: host: Setting qtd to NULL after freeing it"

2019-06-18T08:58:29Z

This reverts commit b0d659022e5c96ee5c4bd62d22d3da2d66de306b. The reverted commit does nothing but adding two unnecessary lines of code. It sets a local variable to NULL in two functions, but that variable is not used anywhere in the rest of those functions. This is just confusing, so let's remove it. Cc: Vardan Mikayelyan Cc: John Youn Cc: Douglas Anderson Cc: Felipe Balbi Acked-by: Minas Harutyunyan Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Felipe Balbi

USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled

2019-06-18T08:58:28Z

If the 'snps,need-phy-for-wake' is set in the device tree then: - We know that we can wakeup, so call device_set_wakeup_capable(). The USB core will use this knowledge to enable wakeup by default. - We know that we should keep the PHY on during suspend if something on our root hub needs remote wakeup. This requires the patch (USB: Export usb_wakeup_enabled_descendants()). Note that we don't keep the PHY on at suspend time if it's not needed because it would be a power draw. If we later find some users of dwc2 that can support wakeup without keeping the PHY on we may want to add a way to call device_set_wakeup_capable() without keeping the PHY on at suspend time. Signed-off-by: Douglas Anderson Signed-off-by: Chris Zhong Signed-off-by: Felipe Balbi

usb: dwc2: Fix DMA cache alignment issues

2019-06-06T10:51:57Z

Insert a padding between data and the stored_xfer_buffer pointer to ensure they are not on the same cache line. Otherwise, the stored_xfer_buffer gets corrupted for IN URBs on non-cache-coherent systems. (In my case: Lantiq xRX200 MIPS) Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way") Fixes: 56406e017a88 ("usb: dwc2: Fix DMA alignment to start at allocated boundary") Cc: Tested-by: Douglas Anderson Reviewed-by: Douglas Anderson Acked-by: Minas Harutyunyan Signed-off-by: Martin Schiller Signed-off-by: Felipe Balbi

usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression)

2019-06-06T10:51:41Z

In commit abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size") the API to usb_endpoint_maxp() changed. It used to just return wMaxPacketSize but after that commit it returned wMaxPacketSize with the high bits (the multiplier) masked off. If you wanted to get the multiplier it was now up to your code to call the new usb_endpoint_maxp_mult() which was introduced in commit 541b6fe63023 ("usb: add helper to extract bits 12:11 of wMaxPacketSize"). Prior to the API change most host drivers were updated, but no update was made to dwc2. Presumably it was assumed that dwc2 was too simplistic to use the multiplier and thus just didn't support a certain class of USB devices. However, it turns out that dwc2 did use the multiplier and many devices using it were working quite nicely. That means that many USB devices have been broken since the API change. One such device is a Logitech HD Pro Webcam C920. Specifically, though dwc2 didn't directly call usb_endpoint_maxp(), it did call usb_maxpacket() which in turn called usb_endpoint_maxp(). Let's update dwc2 to work properly with the new API. Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size") Cc: stable@vger.kernel.org Acked-by: Minas Harutyunyan Reviewed-by: Matthias Kaehlcke Signed-off-by: Douglas Anderson Signed-off-by: Felipe Balbi

usb: dwc2: Fix channel disable flow

2019-05-03T06:13:48Z

Channel disabling/halting should performed for enabled only channels to avoid warnings "Unable to clear enable on channel N" which seen if host works in Slave mode. Signed-off-by: Minas Harutyunyan Signed-off-by: Felipe Balbi

usb: dwc2: Move phy init into core

2019-05-03T06:13:48Z

As the phy initialization is almost the same in host and gadget mode. This only move the phy initialization functions into core.c for now, the goal is to share theses functions between the two modes. Acked-by: Minas Harutyunyan Signed-off-by: Jules Maselbas Signed-off-by: Felipe Balbi

usb: dwc2: optionally assert phy reset when waking up

2019-05-03T06:13:47Z

On the rk3288 USB host-only port (the one that's not the OTG-enabled port) the PHY can get into a bad state when a wakeup is asserted (not just a wakeup from full system suspend but also a wakeup from autosuspend). We can get the PHY out of its bad state by asserting its "port reset", but unfortunately that seems to assert a reset onto the USB bus so it could confuse things if we don't actually deenumerate / reenumerate the device. We can also get the PHY out of its bad state by fully resetting it using the reset from the CRU (clock reset unit), which does a more full reset. The CRU-based reset appears to actually cause devices on the bus to be removed and reinserted, which fixes the problem (albeit in a hacky way). It's unfortunate that we need to do a full re-enumeration of devices at wakeup time, but this is better than alternative of letting the bus get wedged. Signed-off-by: Douglas Anderson Signed-off-by: Yunzhi Li Signed-off-by: Felipe Balbi