From: Chris Packham <chris.packham@alliedtelesis.co.nz> To: stern@rowland.harvard.edu, linux@prisktech.co.nz, gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Chris Packham <chris.packham@alliedtelesis.co.nz> Subject: [PATCH] usb: host: ehci-platform: Add workaround for brcm,xgs-iproc-ehci Date: Thu, 10 Sep 2020 14:51:53 +1200 [thread overview] Message-ID: <20200910025154.20848-1-chris.packham@alliedtelesis.co.nz> (raw) 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(+) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 006c4f6188a5..0d2de8faa3c1 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -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) -- 2.28.0
WARNING: multiple messages have this Message-ID (diff)
From: Chris Packham <chris.packham@alliedtelesis.co.nz> To: stern@rowland.harvard.edu, linux@prisktech.co.nz, gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org, Chris Packham <chris.packham@alliedtelesis.co.nz>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH] usb: host: ehci-platform: Add workaround for brcm, xgs-iproc-ehci Date: Thu, 10 Sep 2020 14:51:53 +1200 [thread overview] Message-ID: <20200910025154.20848-1-chris.packham@alliedtelesis.co.nz> (raw) 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(+) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 006c4f6188a5..0d2de8faa3c1 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -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) -- 2.28.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-09-10 2:52 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-10 2:51 Chris Packham [this message] 2020-09-10 2:51 ` [PATCH] usb: host: ehci-platform: Add workaround for brcm, xgs-iproc-ehci Chris Packham 2020-09-10 15:27 ` [PATCH] usb: host: ehci-platform: Add workaround for brcm,xgs-iproc-ehci Alan Stern 2020-09-10 15:27 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200910025154.20848-1-chris.packham@alliedtelesis.co.nz \ --to=chris.packham@alliedtelesis.co.nz \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@prisktech.co.nz \ --cc=stern@rowland.harvard.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.