All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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: link
Be 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.