@@ -53,6 +53,9 @@ struct ehci_platform_priv {
static const char hcd_name[] = "ehci-platform";
+#define bcm_iproc_insnreg01 hostpc
+#define BCM_USB_FIFO_THRESHOLD 0x00800040
+
static int ehci_platform_reset(struct usb_hcd *hcd)
{
struct platform_device *pdev = to_platform_device(hcd->self.controller);
@@ -358,6 +361,9 @@ static int ehci_platform_probe(struct platform_device *dev)
device_wakeup_enable(hcd->self.controller);
device_enable_async_suspend(hcd->self.controller);
+ if (of_device_is_compatible(dev->dev.of_node, "brcm,xgs-iproc-ehci"))
+ ehci_writel(ehci, BCM_USB_FIFO_THRESHOLD,
+ ehci->regs->bcm_iproc_insnreg01);
platform_set_drvdata(dev, hcd);
if (priv->quirk_poll)
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. drivers/usb/host/ehci-platform.c | 6 ++++++ 1 file changed, 6 insertions(+)