@@ -42,6 +42,9 @@
#define EHCI_MAX_CLKS 4
#define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
+#define BCM_USB_FIFO_THRESHOLD 0x00800040
+#define bcm_iproc_insnreg01 hostpc[0]
+
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
struct reset_control *rsts;
@@ -75,6 +78,11 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
if (pdata->no_io_watchdog)
ehci->need_io_watchdog = 0;
+
+ if (of_device_is_compatible(pdev->dev.of_node, "brcm,xgs-iproc-ehci"))
+ ehci_writel(ehci, BCM_USB_FIFO_THRESHOLD,
+ &ehci->regs->bcm_iproc_insnreg01);
+
return 0;
}
The ehci controller found in some Broadcom switches with integrated SoCs has an issue which causes a soft lockup with large transfers like you see when running ext4 on USB3 flash drive. Port the fix from the Broadcom XLDK to increase the OUT_THRESHOLD to avoid the problem. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- I don't have much data on what this change does. I can say it is needed to avoid a soft lockup when using a USB3 Flash drive formatted has ext4 (USB2 + ext4 is OK, USB3 + fat is OK). I presume the affected combination ends up using larger transfers triggering the problem. The equivalent change in the Broadcom XLDK is if (IS_ENABLED(CONFIG_USB_EHCI_XGS_IPROC)) ehci_writel(ehci, BCM_USB_FIFO_THRESHOLD, &ehci->regs->reserved4[6]); This is problematic because it would unconditionally apply to all ehci controllers whenever CONFIG_USB_EHCI_XGS_IPROC is enabled (also reserved4 only goes to 6 so technically it's indexing off the end of the array). I wasn't sure if I should add a new property or somehow detect the affected host controller. I settled on using of_device_is_compatible() as that seemed the simplest thing to do. Changes in v2: - move workaround to ehci_platform_reset - cosmetic changes suggested by Alan drivers/usb/host/ehci-platform.c | 8 ++++++++ 1 file changed, 8 insertions(+)