[PATCH v10 0/5] Add XHCI, EHCI and OHCI support for Broadcom STB SoS's

[PATCH v10 0/5] Add XHCI, EHCI and OHCI support for Broadcom STB SoS's

[Al Cooper]

v10 - Fix incorrect error return in ehci-brcmstb.c pointed out by
      Alan Stern.

v9 - Fix minor typos in patch description for ehci driver.
   - In ehci-brcm.c, use ehci_err() instead of dev_err().
   - In ehci-brcm.c, handle zero returned from platform_get_irq()
     by returning -EINVAL for 0 or actual return value for < 0.

v8 - The previous v7 had the wrong version of ehci-brcm.c. This time
     really, really add the changes Greg requested.

v7 - Cleanup ehci-brcm.c as requested by Greg Kroah-Hartman.
   - Split out Makefile re-order change into a separate commit.

v6 - Remove "contains:" from compatible section of
     brcm,bcm7445-ehci.yaml as requested by Rob Herring.

v5 - Use devm_platform_get_and_ioremap_resource() in ehci-brcm.c
     as requested by Andy Shevchenko.
   - Add pm_runtime_set_active() to ehci_resume() in ehci-brcm.c
     as requested by Alan Stern.

v4 - A few more fixes to the brcm,bcm7445-ehci.yaml dt-bindings
     document requested by Rob Herring.
   - Fixed ordering issue in MAINTAINERS as requested by
     Andy Shevchenko.

v3 - Addressed all of Andy Shevchenko's review comments for
     ehci-brcm.c.
   - Fixed the brcm,bcm7445-ehci.yaml dt-bindings document,
     dt_binding_check now passes.
   - Added the XHCI functionality to xhci-plat.c instead of creating
     new brcmstb files, as suggested by Mathias Nyman.

v2 - Addressed Andy Shevchenko's review comments.
   - Fixed dt_binding_check error pointed out by Rob Herring.
   - Removed pr_info message in ehci_brcm_init as suggested by
     Greg Kroah-Hartman.

This adds support for the XHCI, EHCI and OHCI host controllers found
in Broadcom STB SoC's. These drivers depend on getting access to the
new Broadcom STB USB PHY driver through a device-tree phandle and
will fail if the driver is not available.

Al Cooper (5):
  usb: xhci: Change the XHCI link order in the Makefile
  dt-bindings: Add Broadcom STB USB support
  usb: xhci: xhci-plat: Add support for Broadcom STB SoC's
  usb: ehci: Add new EHCI driver for Broadcom STB SoC's
  usb: host: Add ability to build new Broadcom STB USB drivers

 .../bindings/usb/brcm,bcm7445-ehci.yaml       |  59 ++++
 .../devicetree/bindings/usb/usb-xhci.txt      |   1 +
 MAINTAINERS                                   |   8 +
 drivers/usb/host/Kconfig                      |  20 ++
 drivers/usb/host/Makefile                     |  17 +-
 drivers/usb/host/ehci-brcm.c                  | 280 ++++++++++++++++++
 drivers/usb/host/xhci-plat.c                  |  10 +
 7 files changed, 389 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
 create mode 100644 drivers/usb/host/ehci-brcm.c

-- 
2.17.1

[PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Al Cooper]

Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
devices and OHCI handles <2.0 devices. Currently the Makefile
has XHCI linking at the bottom which will result in the XHIC driver
initalizing after the EHCI and OHCI drivers and any installed 3.0
device will be seen as a 2.0 device. Moving the XHCI linking
above the EHCI and OHCI linking fixes the issue.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
 drivers/usb/host/Makefile | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b191361257cc..a7f0b8ff7179 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -37,6 +37,16 @@ endif
 
 obj-$(CONFIG_USB_PCI)	+= pci-quirks.o
 
+# NOTE: BRCMSTB systems require that xhci driver be linked before the
+# ehci/ohci drivers because they share a port and need the XHCI driver
+# to come up first to properly enumerate 3.0 devices.
+obj-$(CONFIG_USB_XHCI_HCD)	+= xhci-hcd.o
+obj-$(CONFIG_USB_XHCI_PCI)	+= xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_HISTB)	+= xhci-histb.o
+obj-$(CONFIG_USB_XHCI_MTK)	+= xhci-mtk.o
+obj-$(CONFIG_USB_XHCI_TEGRA)	+= xhci-tegra.o
+
 obj-$(CONFIG_USB_EHCI_HCD)	+= ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI)	+= ehci-pci.o
 obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)	+= ehci-platform.o
@@ -69,12 +79,6 @@ obj-$(CONFIG_USB_OHCI_HCD_DAVINCI)	+= ohci-da8xx.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
-obj-$(CONFIG_USB_XHCI_HCD)	+= xhci-hcd.o
-obj-$(CONFIG_USB_XHCI_PCI)	+= xhci-pci.o
-obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
-obj-$(CONFIG_USB_XHCI_HISTB)	+= xhci-histb.o
-obj-$(CONFIG_USB_XHCI_MTK)	+= xhci-mtk.o
-obj-$(CONFIG_USB_XHCI_TEGRA)	+= xhci-tegra.o
 obj-$(CONFIG_USB_SL811_HCD)	+= sl811-hcd.o
 obj-$(CONFIG_USB_SL811_CS)	+= sl811_cs.o
 obj-$(CONFIG_USB_U132_HCD)	+= u132-hcd.o
-- 
2.17.1

[PATCH v10 2/5] dt-bindings: Add Broadcom STB USB support

[Al Cooper]

Add DT bindings for Broadcom STB USB EHCI and XHCI drivers.

NOTE: The OHCI driver is not included because it uses the generic
      platform driver.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
 .../bindings/usb/brcm,bcm7445-ehci.yaml       | 59 +++++++++++++++++++
 .../devicetree/bindings/usb/usb-xhci.txt      |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml

diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
new file mode 100644
index 000000000000..2a9acf2b5a64
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/brcm,bcm7445-ehci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom STB USB EHCI Controller Device Tree Bindings
+
+allOf:
+  - $ref: "usb-hcd.yaml"
+
+maintainers:
+  - Al Cooper <alcooperx@gmail.com>
+
+properties:
+  compatible:
+    const: brcm,bcm7445-ehci
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: Clock specifier for the EHCI clock
+
+  clock-names:
+    const: sw_usb
+
+  phys:
+    maxItems: 1
+
+  phy-names:
+    const: usbphy
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - phys
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    usb@f0b00300 {
+        compatible = "brcm,bcm7445-ehci";
+        reg = <0xf0b00300 0xa8>;
+        interrupts = <0x0 0x5a 0x0>;
+        phys = <&usbphy_0 0x0>;
+        phy-names = "usbphy";
+        clocks = <&usb20>;
+        clock-names = "sw_usb";
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index dc025f126d71..23e89d798b1b 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -24,6 +24,7 @@ Required properties:
       device
     - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 or RZ/G2 compatible
       device
+    - "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
     - "xhci-platform" (deprecated)
 
     When compatible with the generic version, nodes must list the
-- 
2.17.1

[PATCH v10 3/5] usb: xhci: xhci-plat: Add support for Broadcom STB SoC's

[Al Cooper]

Add support for Broadcom STB SoC's to the xhci platform driver

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/usb/host/xhci-plat.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1d4f6f85f0fe..44406d0eb317 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -112,6 +112,10 @@ static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen3 = {
 	SET_XHCI_PLAT_PRIV_FOR_RCAR(XHCI_RCAR_FIRMWARE_NAME_V3)
 };
 
+static const struct xhci_plat_priv xhci_plat_brcm = {
+	.quirks = XHCI_RESET_ON_RESUME,
+};
+
 static const struct of_device_id usb_xhci_of_match[] = {
 	{
 		.compatible = "generic-xhci",
@@ -147,6 +151,12 @@ static const struct of_device_id usb_xhci_of_match[] = {
 	}, {
 		.compatible = "renesas,rcar-gen3-xhci",
 		.data = &xhci_plat_renesas_rcar_gen3,
+	}, {
+		.compatible = "brcm,xhci-brcm-v2",
+		.data = &xhci_plat_brcm,
+	}, {
+		.compatible = "brcm,bcm7445-xhci",
+		.data = &xhci_plat_brcm,
 	},
 	{},
 };
-- 
2.17.1

[PATCH v10 4/5] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

[Al Cooper]

Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
was created instead of adding support to the existing ehci platform
driver because of the code required to work around bugs in the EHCI
controller. The primary workaround is for a bug where the Core
violates the SOF interval between the first two SOFs transmitted after
resume. This only happens if the resume occurs near the end of a
microframe. The fix is to intercept the ehci-hcd request to complete
RESUME and align it to the start of the next microframe.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
---
 drivers/usb/host/ehci-brcm.c | 280 +++++++++++++++++++++++++++++++++++
 1 file changed, 280 insertions(+)
 create mode 100644 drivers/usb/host/ehci-brcm.c

diff --git a/drivers/usb/host/ehci-brcm.c b/drivers/usb/host/ehci-brcm.c
new file mode 100644
index 000000000000..3e0ebe8cc649
--- /dev/null
+++ b/drivers/usb/host/ehci-brcm.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2020, Broadcom */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/iopoll.h>
+
+#include "ehci.h"
+
+#define hcd_to_ehci_priv(h) ((struct brcm_priv *)hcd_to_ehci(h)->priv)
+
+struct brcm_priv {
+	struct clk *clk;
+};
+
+/*
+ * ehci_brcm_wait_for_sof
+ * Wait for start of next microframe, then wait extra delay microseconds
+ */
+static inline void ehci_brcm_wait_for_sof(struct ehci_hcd *ehci, u32 delay)
+{
+	u32 frame_idx = ehci_readl(ehci, &ehci->regs->frame_index);
+	u32 val;
+	int res;
+
+	/* Wait for next microframe (every 125 usecs) */
+	res = readl_relaxed_poll_timeout(&ehci->regs->frame_index, val,
+					 val != frame_idx, 1, 130);
+	if (res)
+		ehci_err(ehci, "Error waiting for SOF\n");
+	udelay(delay);
+}
+
+/*
+ * ehci_brcm_hub_control
+ * The EHCI controller has a bug where it can violate the SOF
+ * interval between the first two SOF's transmitted after resume
+ * if the resume occurs near the end of the microframe. This causees
+ * the controller to detect babble on the suspended port and
+ * will eventually cause the controller to reset the port.
+ * The fix is to Intercept the echi-hcd request to complete RESUME and
+ * align it to the start of the next microframe.
+ * See SWLINUX-1909 for more details
+ */
+static int ehci_brcm_hub_control(
+	struct usb_hcd	*hcd,
+	u16		typeReq,
+	u16		wValue,
+	u16		wIndex,
+	char		*buf,
+	u16		wLength)
+{
+	struct ehci_hcd	*ehci = hcd_to_ehci(hcd);
+	int		ports = HCS_N_PORTS(ehci->hcs_params);
+	u32 __iomem	*status_reg;
+	unsigned long flags;
+	int retval, irq_disabled = 0;
+
+	status_reg = &ehci->regs->port_status[(wIndex & 0xff) - 1];
+
+	/*
+	 * RESUME is cleared when GetPortStatus() is called 20ms after start
+	 * of RESUME
+	 */
+	if ((typeReq == GetPortStatus) &&
+	    (wIndex && wIndex <= ports) &&
+	    ehci->reset_done[wIndex-1] &&
+	    time_after_eq(jiffies, ehci->reset_done[wIndex-1]) &&
+	    (ehci_readl(ehci, status_reg) & PORT_RESUME)) {
+
+		/*
+		 * to make sure we are not interrupted until RESUME bit
+		 * is cleared, disable interrupts on current CPU
+		 */
+		ehci_dbg(ehci, "SOF alignment workaround\n");
+		irq_disabled = 1;
+		local_irq_save(flags);
+		ehci_brcm_wait_for_sof(ehci, 5);
+	}
+	retval = ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+	if (irq_disabled)
+		local_irq_restore(flags);
+	return retval;
+}
+
+static int ehci_brcm_reset(struct usb_hcd *hcd)
+{
+	struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+	int len;
+
+	ehci->big_endian_mmio = 1;
+
+	ehci->caps = (void __iomem *)hcd->regs;
+	len = HC_LENGTH(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
+	ehci->regs = (void __iomem *)(hcd->regs + len);
+
+	/* This fixes the lockup during reboot due to prior interrupts */
+	ehci_writel(ehci, CMD_RESET, &ehci->regs->command);
+	mdelay(10);
+
+	/*
+	 * SWLINUX-1705: Avoid OUT packet underflows during high memory
+	 *   bus usage
+	 * port_status[0x0f] = Broadcom-proprietary USB_EHCI_INSNREG00 @ 0x90
+	 */
+	ehci_writel(ehci, 0x00800040, &ehci->regs->port_status[0x10]);
+	ehci_writel(ehci, 0x00000001, &ehci->regs->port_status[0x12]);
+
+	return ehci_setup(hcd);
+}
+
+static struct hc_driver __read_mostly ehci_brcm_hc_driver;
+
+static const struct ehci_driver_overrides brcm_overrides __initconst = {
+	.reset = ehci_brcm_reset,
+	.extra_priv_size = sizeof(struct brcm_priv),
+};
+
+static int ehci_brcm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res_mem;
+	struct brcm_priv *priv;
+	struct usb_hcd *hcd;
+	int irq;
+	int err;
+
+	err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+	if (err)
+		return err;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq <= 0)
+		return irq ? irq : -EINVAL;
+
+	/* Hook the hub control routine to work around a bug */
+	ehci_brcm_hc_driver.hub_control = ehci_brcm_hub_control;
+
+	/* initialize hcd */
+	hcd = usb_create_hcd(&ehci_brcm_hc_driver, dev, dev_name(dev));
+	if (!hcd)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, hcd);
+	priv = hcd_to_ehci_priv(hcd);
+
+	priv->clk = devm_clk_get_optional(dev, NULL);
+	if (IS_ERR(priv->clk)) {
+		err = PTR_ERR(priv->clk);
+		goto err_hcd;
+	}
+
+	err = clk_prepare_enable(priv->clk);
+	if (err)
+		goto err_hcd;
+
+	hcd->regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res_mem);
+	if (IS_ERR(hcd->regs)) {
+		err = PTR_ERR(hcd->regs);
+		goto err_clk;
+	}
+	hcd->rsrc_start = res_mem->start;
+	hcd->rsrc_len = resource_size(res_mem);
+	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
+	if (err)
+		goto err_clk;
+
+	device_wakeup_enable(hcd->self.controller);
+	device_enable_async_suspend(hcd->self.controller);
+
+	return 0;
+
+err_clk:
+	clk_disable_unprepare(priv->clk);
+err_hcd:
+	usb_put_hcd(hcd);
+
+	return err;
+}
+
+static int ehci_brcm_remove(struct platform_device *dev)
+{
+	struct usb_hcd *hcd = platform_get_drvdata(dev);
+	struct brcm_priv *priv = hcd_to_ehci_priv(hcd);
+
+	usb_remove_hcd(hcd);
+	clk_disable_unprepare(priv->clk);
+	usb_put_hcd(hcd);
+	return 0;
+}
+
+static int __maybe_unused ehci_brcm_suspend(struct device *dev)
+{
+	int ret;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct brcm_priv *priv = hcd_to_ehci_priv(hcd);
+	bool do_wakeup = device_may_wakeup(dev);
+
+	ret = ehci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+	clk_disable_unprepare(priv->clk);
+	return 0;
+}
+
+static int __maybe_unused ehci_brcm_resume(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+	struct brcm_priv *priv = hcd_to_ehci_priv(hcd);
+	int err;
+
+	err = clk_prepare_enable(priv->clk);
+	if (err)
+		return err;
+	/*
+	 * SWLINUX-1705: Avoid OUT packet underflows during high memory
+	 *   bus usage
+	 * port_status[0x0f] = Broadcom-proprietary USB_EHCI_INSNREG00
+	 * @ 0x90
+	 */
+	ehci_writel(ehci, 0x00800040, &ehci->regs->port_status[0x10]);
+	ehci_writel(ehci, 0x00000001, &ehci->regs->port_status[0x12]);
+
+	ehci_resume(hcd, false);
+
+	pm_runtime_disable(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ehci_brcm_pm_ops, ehci_brcm_suspend,
+		ehci_brcm_resume);
+
+static const struct of_device_id brcm_ehci_of_match[] = {
+	{ .compatible = "brcm,ehci-brcm-v2", },
+	{ .compatible = "brcm,bcm7445-ehci", },
+	{}
+};
+
+static struct platform_driver ehci_brcm_driver = {
+	.probe		= ehci_brcm_probe,
+	.remove		= ehci_brcm_remove,
+	.shutdown	= usb_hcd_platform_shutdown,
+	.driver		= {
+		.name	= "ehci-brcm",
+		.pm	= &ehci_brcm_pm_ops,
+		.of_match_table = brcm_ehci_of_match,
+	}
+};
+
+static int __init ehci_brcm_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	ehci_init_driver(&ehci_brcm_hc_driver, &brcm_overrides);
+	return platform_driver_register(&ehci_brcm_driver);
+}
+module_init(ehci_brcm_init);
+
+static void __exit ehci_brcm_exit(void)
+{
+	platform_driver_unregister(&ehci_brcm_driver);
+}
+module_exit(ehci_brcm_exit);
+
+MODULE_ALIAS("platform:ehci-brcm");
+MODULE_DESCRIPTION("EHCI Broadcom STB driver");
+MODULE_AUTHOR("Al Cooper");
+MODULE_LICENSE("GPL");
-- 
2.17.1

[PATCH v10 5/5] usb: host: Add ability to build new Broadcom STB USB drivers

[Al Cooper]

Add the build system changes needed to get the Broadcom STB XHCI,
EHCI and OHCI functionality working. The OHCI support does not
require anything unique to Broadcom so the standard ohci-platform
driver is being used. Also update MAINTAINERS.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
 MAINTAINERS               |  8 ++++++++
 drivers/usb/host/Kconfig  | 20 ++++++++++++++++++++
 drivers/usb/host/Makefile |  1 +
 3 files changed, 29 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 091ec22c1a23..e5e44b595bc4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3481,6 +3481,14 @@ S:	Supported
 F:	Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml
 F:	drivers/i2c/busses/i2c-brcmstb.c
 
+BROADCOM BRCMSTB USB EHCI DRIVER
+M:	Al Cooper <alcooperx@gmail.com>
+L:	linux-usb@vger.kernel.org
+L:	bcm-kernel-feedback-list@broadcom.com
+S:	Maintained
+F:	Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
+F:	drivers/usb/host/ehci-brcm.*
+
 BROADCOM BRCMSTB USB2 and USB3 PHY DRIVER
 M:	Al Cooper <alcooperx@gmail.com>
 L:	linux-kernel@vger.kernel.org
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 55bdfdf11e4c..973386bbb522 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -97,6 +97,26 @@ config USB_XHCI_TEGRA
 
 endif # USB_XHCI_HCD
 
+config USB_EHCI_BRCMSTB
+       tristate
+
+config USB_BRCMSTB
+	tristate "Broadcom STB USB support"
+	depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
+	select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
+	select USB_EHCI_BRCMSTB if USB_EHCI_HCD
+	select USB_XHCI_PLATFORM if USB_XHCI_HCD
+	help
+	  Enables support for XHCI, EHCI and OHCI host controllers
+	  found in Broadcom STB SoC's.
+
+	  To compile these drivers as modules, choose M here: the
+	  modules will be called ohci-platform.ko, ehci-brcm.ko and
+	  xhci-plat-hcd.ko
+
+	  Disabling this will keep the controllers and corresponding
+	  PHYs powered down.
+
 config USB_EHCI_HCD
 	tristate "EHCI HCD (USB 2.0) support"
 	depends on HAS_DMA && HAS_IOMEM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a7f0b8ff7179..265e26cf9209 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_USB_EHCI_HCD_STI)	+= ehci-st.o
 obj-$(CONFIG_USB_EHCI_EXYNOS)	+= ehci-exynos.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_TEGRA)	+= ehci-tegra.o
+obj-$(CONFIG_USB_EHCI_BRCMSTB)	+= ehci-brcm.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
-- 
2.17.1

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Greg Kroah-Hartman]

On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> devices and OHCI handles <2.0 devices. Currently the Makefile
> has XHCI linking at the bottom which will result in the XHIC driver
> initalizing after the EHCI and OHCI drivers and any installed 3.0
> device will be seen as a 2.0 device. Moving the XHCI linking
> above the EHCI and OHCI linking fixes the issue.

What happens if all of these are modules and they are loaded in a
different order?  This makefile change will not help with that, you need
to have logic in the code in order to properly coordinate this type of
mess, sorry.

thanks,

greg k-h

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Florian Fainelli]

On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>> devices and OHCI handles <2.0 devices. Currently the Makefile
>> has XHCI linking at the bottom which will result in the XHIC driver
>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>> device will be seen as a 2.0 device. Moving the XHCI linking
>> above the EHCI and OHCI linking fixes the issue.
> 
> What happens if all of these are modules and they are loaded in a
> different order?  This makefile change will not help with that, you need
> to have logic in the code in order to properly coordinate this type of
> mess, sorry.

I believe we should be using module soft dependencies to instruct the
module loaders to load the modules in the correct order, so something
like this would do (not tested) for xhci-plat-hcd.c:

MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");

and I am not sure whether we need to add the opposite for ehci-hcd and
ohci-hcd:

MODULE_SOFTDEP("pre: xhci-plat-hcd");

Al, do you want to test that?
-- 
Florian

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Andy Shevchenko]

On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >> devices and OHCI handles <2.0 devices. Currently the Makefile
> >> has XHCI linking at the bottom which will result in the XHIC driver
> >> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >> device will be seen as a 2.0 device. Moving the XHCI linking
> >> above the EHCI and OHCI linking fixes the issue.
> > 
> > What happens if all of these are modules and they are loaded in a
> > different order?  This makefile change will not help with that, you need
> > to have logic in the code in order to properly coordinate this type of
> > mess, sorry.
> 
> I believe we should be using module soft dependencies to instruct the
> module loaders to load the modules in the correct order, so something
> like this would do (not tested) for xhci-plat-hcd.c:
> 
> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> 
> and I am not sure whether we need to add the opposite for ehci-hcd and
> ohci-hcd:
> 
> MODULE_SOFTDEP("pre: xhci-plat-hcd");

JFYI: not all user space support this (alas, but that's current state of
affairs), OTOH I don't really care about those which do not support it
(Busybox).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Florian Fainelli]

On 5/13/2020 8:26 AM, Andy Shevchenko wrote:
> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>> above the EHCI and OHCI linking fixes the issue.
>>>
>>> What happens if all of these are modules and they are loaded in a
>>> different order?  This makefile change will not help with that, you need
>>> to have logic in the code in order to properly coordinate this type of
>>> mess, sorry.
>>
>> I believe we should be using module soft dependencies to instruct the
>> module loaders to load the modules in the correct order, so something
>> like this would do (not tested) for xhci-plat-hcd.c:
>>
>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>
>> and I am not sure whether we need to add the opposite for ehci-hcd and
>> ohci-hcd:
>>
>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> 
> JFYI: not all user space support this (alas, but that's current state of
> affairs), OTOH I don't really care about those which do not support it
> (Busybox).

I know that Gentoo's initramfs tool does not support it, however given
there are no symbols being cross referenced, I am not sure how to best
support this other than using these hints, and possibly making use of
device links too?
-- 
Florian

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Greg Kroah-Hartman]

On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> 
> 
> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >> devices and OHCI handles <2.0 devices. Currently the Makefile
> >> has XHCI linking at the bottom which will result in the XHIC driver
> >> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >> device will be seen as a 2.0 device. Moving the XHCI linking
> >> above the EHCI and OHCI linking fixes the issue.
> > 
> > What happens if all of these are modules and they are loaded in a
> > different order?  This makefile change will not help with that, you need
> > to have logic in the code in order to properly coordinate this type of
> > mess, sorry.
> 
> I believe we should be using module soft dependencies to instruct the
> module loaders to load the modules in the correct order, so something
> like this would do (not tested) for xhci-plat-hcd.c:
> 
> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> 
> and I am not sure whether we need to add the opposite for ehci-hcd and
> ohci-hcd:
> 
> MODULE_SOFTDEP("pre: xhci-plat-hcd");

That's a nice start, but what happens if that isn't honored?  This
really needs to work properly for any order as you never can guarantee
module/driver loading order in a system of modules.

thanks,

greg k-h

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Florian Fainelli]

On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>>
>>
>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>> above the EHCI and OHCI linking fixes the issue.
>>>
>>> What happens if all of these are modules and they are loaded in a
>>> different order?  This makefile change will not help with that, you need
>>> to have logic in the code in order to properly coordinate this type of
>>> mess, sorry.
>>
>> I believe we should be using module soft dependencies to instruct the
>> module loaders to load the modules in the correct order, so something
>> like this would do (not tested) for xhci-plat-hcd.c:
>>
>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>
>> and I am not sure whether we need to add the opposite for ehci-hcd and
>> ohci-hcd:
>>
>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> 
> That's a nice start, but what happens if that isn't honored?  This
> really needs to work properly for any order as you never can guarantee
> module/driver loading order in a system of modules.

I also suggested that device links may help, though I am not sure. What
do you suggest to be done?
-- 
Florian

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Greg Kroah-Hartman]

On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> 
> 
> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> >>
> >>
> >> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> >>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> >>>> has XHCI linking at the bottom which will result in the XHIC driver
> >>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >>>> device will be seen as a 2.0 device. Moving the XHCI linking
> >>>> above the EHCI and OHCI linking fixes the issue.
> >>>
> >>> What happens if all of these are modules and they are loaded in a
> >>> different order?  This makefile change will not help with that, you need
> >>> to have logic in the code in order to properly coordinate this type of
> >>> mess, sorry.
> >>
> >> I believe we should be using module soft dependencies to instruct the
> >> module loaders to load the modules in the correct order, so something
> >> like this would do (not tested) for xhci-plat-hcd.c:
> >>
> >> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> >>
> >> and I am not sure whether we need to add the opposite for ehci-hcd and
> >> ohci-hcd:
> >>
> >> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> > 
> > That's a nice start, but what happens if that isn't honored?  This
> > really needs to work properly for any order as you never can guarantee
> > module/driver loading order in a system of modules.
> 
> I also suggested that device links may help, though I am not sure. What
> do you suggest to be done?

No idea.  device links will help if you defer the probe properly until
you see the proper drivers binding correctly.

good luck!

greg k-h

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Alan Stern]

On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> > 
> > 
> > On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > > On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> > >>
> > >>
> > >> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > >>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> > >>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> > >>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> > >>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> > >>>> has XHCI linking at the bottom which will result in the XHIC driver
> > >>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> > >>>> device will be seen as a 2.0 device. Moving the XHCI linking
> > >>>> above the EHCI and OHCI linking fixes the issue.
> > >>>
> > >>> What happens if all of these are modules and they are loaded in a
> > >>> different order?  This makefile change will not help with that, you need
> > >>> to have logic in the code in order to properly coordinate this type of
> > >>> mess, sorry.
> > >>
> > >> I believe we should be using module soft dependencies to instruct the
> > >> module loaders to load the modules in the correct order, so something
> > >> like this would do (not tested) for xhci-plat-hcd.c:
> > >>
> > >> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> > >>
> > >> and I am not sure whether we need to add the opposite for ehci-hcd and
> > >> ohci-hcd:
> > >>
> > >> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> > > 
> > > That's a nice start, but what happens if that isn't honored?  This
> > > really needs to work properly for any order as you never can guarantee
> > > module/driver loading order in a system of modules.
> > 
> > I also suggested that device links may help, though I am not sure. What
> > do you suggest to be done?
> 
> No idea.  device links will help if you defer the probe properly until
> you see the proper drivers binding correctly.

I suspect that in general there is no way to do this properly.

We can't modify ehci-hcd and ohci-hcd to make them wait.  In fact, for 
all they know, xhci-hcd will _never_ be loaded.

One thing that might be possible (although not all platforms may support 
it) is if xhci-hcd could somehow disconnect all devices attached to a 
peer port when it starts up.  But that would be disruptive to any 
devices that aren't USB-3.

We faced a very similar ordering problem between ehci-hcd and 
[ou]hci-hcd many years ago, and we never found a good solution.  
We did arrange the link order so that ehci-hcd precedes the others, and 
we added a warning message to ehci-hcd which gets printed if the module 
initialization routine runs after [ou]hci-hcd is loaded.  Also, there 
are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.

Alan Stern

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Florian Fainelli]

On 5/13/2020 10:39 AM, Alan Stern wrote:
> On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
>> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
>>>
>>>
>>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
>>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>>>>>
>>>>>
>>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>>>>> above the EHCI and OHCI linking fixes the issue.
>>>>>>
>>>>>> What happens if all of these are modules and they are loaded in a
>>>>>> different order?  This makefile change will not help with that, you need
>>>>>> to have logic in the code in order to properly coordinate this type of
>>>>>> mess, sorry.
>>>>>
>>>>> I believe we should be using module soft dependencies to instruct the
>>>>> module loaders to load the modules in the correct order, so something
>>>>> like this would do (not tested) for xhci-plat-hcd.c:
>>>>>
>>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>>>>
>>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
>>>>> ohci-hcd:
>>>>>
>>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
>>>>
>>>> That's a nice start, but what happens if that isn't honored?  This
>>>> really needs to work properly for any order as you never can guarantee
>>>> module/driver loading order in a system of modules.
>>>
>>> I also suggested that device links may help, though I am not sure. What
>>> do you suggest to be done?
>>
>> No idea.  device links will help if you defer the probe properly until
>> you see the proper drivers binding correctly.
> 
> I suspect that in general there is no way to do this properly.
> 
> We can't modify ehci-hcd and ohci-hcd to make them wait.  In fact, for 
> all they know, xhci-hcd will _never_ be loaded.
> 
> One thing that might be possible (although not all platforms may support 
> it) is if xhci-hcd could somehow disconnect all devices attached to a 
> peer port when it starts up.  But that would be disruptive to any 
> devices that aren't USB-3.
> 
> We faced a very similar ordering problem between ehci-hcd and 
> [ou]hci-hcd many years ago, and we never found a good solution.  
> We did arrange the link order so that ehci-hcd precedes the others, and 
> we added a warning message to ehci-hcd which gets printed if the module 
> initialization routine runs after [ou]hci-hcd is loaded.  Also, there 
> are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.

Given that these modules are used on specific SoC platforms, where we
usually provide a reference implementation of user space and kernel
space and documentation, it seems to me that the MODULE_SOFTDEP(),
despite being a hint and best effort from user space module loaders is
probably acceptable.
-- 
Florian

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Alan Cooper]

On Wed, May 13, 2020 at 1:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 5/13/2020 10:39 AM, Alan Stern wrote:
> > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> >>>
> >>>
> >>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> >>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> >>>>>
> >>>>>
> >>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> >>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> >>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
> >>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
> >>>>>>> above the EHCI and OHCI linking fixes the issue.
> >>>>>>
> >>>>>> What happens if all of these are modules and they are loaded in a
> >>>>>> different order?  This makefile change will not help with that, you need
> >>>>>> to have logic in the code in order to properly coordinate this type of
> >>>>>> mess, sorry.
> >>>>>
> >>>>> I believe we should be using module soft dependencies to instruct the
> >>>>> module loaders to load the modules in the correct order, so something
> >>>>> like this would do (not tested) for xhci-plat-hcd.c:
> >>>>>
> >>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> >>>>>
> >>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
> >>>>> ohci-hcd:
> >>>>>
> >>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> >>>>
> >>>> That's a nice start, but what happens if that isn't honored?  This
> >>>> really needs to work properly for any order as you never can guarantee
> >>>> module/driver loading order in a system of modules.
> >>>
> >>> I also suggested that device links may help, though I am not sure. What
> >>> do you suggest to be done?
> >>
> >> No idea.  device links will help if you defer the probe properly until
> >> you see the proper drivers binding correctly.
> >
> > I suspect that in general there is no way to do this properly.
> >
> > We can't modify ehci-hcd and ohci-hcd to make them wait.  In fact, for
> > all they know, xhci-hcd will _never_ be loaded.
> >
> > One thing that might be possible (although not all platforms may support
> > it) is if xhci-hcd could somehow disconnect all devices attached to a
> > peer port when it starts up.  But that would be disruptive to any
> > devices that aren't USB-3.
> >
> > We faced a very similar ordering problem between ehci-hcd and
> > [ou]hci-hcd many years ago, and we never found a good solution.
> > We did arrange the link order so that ehci-hcd precedes the others, and
> > we added a warning message to ehci-hcd which gets printed if the module
> > initialization routine runs after [ou]hci-hcd is loaded.  Also, there
> > are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
>
> Given that these modules are used on specific SoC platforms, where we
> usually provide a reference implementation of user space and kernel
> space and documentation, it seems to me that the MODULE_SOFTDEP(),
> despite being a hint and best effort from user space module loaders is
> probably acceptable.
> --
> Florian

What I found in the past is that things work. For example if the ehci
driver starts first, the USB device will come up as a 2.0 device and
when the XHCI driver comes up the device will switch to 3.0. I've see
the same thing happen if OHCI starts before EHCI. It's just that there
are some poorly behaved USB devices that have trouble with this.

Al

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Alan Cooper]

Greg, Alan,

The other 4 related patches were accepted into usb-next and I just
realized that this one didn't make it. This patch will not fix the
"insmod out of order" issue, but will help our controllers work with
some poorly behaved USB devices when the drivers are builtin.

Thanks
Al

On Wed, May 13, 2020 at 3:42 PM Alan Cooper <alcooperx@gmail.com> wrote:
>
> On Wed, May 13, 2020 at 1:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 5/13/2020 10:39 AM, Alan Stern wrote:
> > > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> > >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> > >>>
> > >>>
> > >>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > >>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > >>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> > >>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> > >>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> > >>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> > >>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
> > >>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> > >>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
> > >>>>>>> above the EHCI and OHCI linking fixes the issue.
> > >>>>>>
> > >>>>>> What happens if all of these are modules and they are loaded in a
> > >>>>>> different order?  This makefile change will not help with that, you need
> > >>>>>> to have logic in the code in order to properly coordinate this type of
> > >>>>>> mess, sorry.
> > >>>>>
> > >>>>> I believe we should be using module soft dependencies to instruct the
> > >>>>> module loaders to load the modules in the correct order, so something
> > >>>>> like this would do (not tested) for xhci-plat-hcd.c:
> > >>>>>
> > >>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> > >>>>>
> > >>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
> > >>>>> ohci-hcd:
> > >>>>>
> > >>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> > >>>>
> > >>>> That's a nice start, but what happens if that isn't honored?  This
> > >>>> really needs to work properly for any order as you never can guarantee
> > >>>> module/driver loading order in a system of modules.
> > >>>
> > >>> I also suggested that device links may help, though I am not sure. What
> > >>> do you suggest to be done?
> > >>
> > >> No idea.  device links will help if you defer the probe properly until
> > >> you see the proper drivers binding correctly.
> > >
> > > I suspect that in general there is no way to do this properly.
> > >
> > > We can't modify ehci-hcd and ohci-hcd to make them wait.  In fact, for
> > > all they know, xhci-hcd will _never_ be loaded.
> > >
> > > One thing that might be possible (although not all platforms may support
> > > it) is if xhci-hcd could somehow disconnect all devices attached to a
> > > peer port when it starts up.  But that would be disruptive to any
> > > devices that aren't USB-3.
> > >
> > > We faced a very similar ordering problem between ehci-hcd and
> > > [ou]hci-hcd many years ago, and we never found a good solution.
> > > We did arrange the link order so that ehci-hcd precedes the others, and
> > > we added a warning message to ehci-hcd which gets printed if the module
> > > initialization routine runs after [ou]hci-hcd is loaded.  Also, there
> > > are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
> >
> > Given that these modules are used on specific SoC platforms, where we
> > usually provide a reference implementation of user space and kernel
> > space and documentation, it seems to me that the MODULE_SOFTDEP(),
> > despite being a hint and best effort from user space module loaders is
> > probably acceptable.
> > --
> > Florian
>
> What I found in the past is that things work. For example if the ehci
> driver starts first, the USB device will come up as a 2.0 device and
> when the XHCI driver comes up the device will switch to 3.0. I've see
> the same thing happen if OHCI starts before EHCI. It's just that there
> are some poorly behaved USB devices that have trouble with this.
>
> Al

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Greg Kroah-Hartman]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, May 20, 2020 at 01:29:45PM -0400, Alan Cooper wrote:
> Greg, Alan,
> 
> The other 4 related patches were accepted into usb-next and I just
> realized that this one didn't make it. This patch will not fix the
> "insmod out of order" issue, but will help our controllers work with
> some poorly behaved USB devices when the drivers are builtin.

As it doesn't solve the real issue, I did not accept this so that you
all can continue to work on creating a real solution that works for both
situations (built in and as modules.)

I thought I said that already...

thanks,

greg k-h

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

[Florian Fainelli]

On 5/20/2020 11:09 PM, Greg Kroah-Hartman wrote:
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> On Wed, May 20, 2020 at 01:29:45PM -0400, Alan Cooper wrote:
>> Greg, Alan,
>>
>> The other 4 related patches were accepted into usb-next and I just
>> realized that this one didn't make it. This patch will not fix the
>> "insmod out of order" issue, but will help our controllers work with
>> some poorly behaved USB devices when the drivers are builtin.
> 
> As it doesn't solve the real issue, I did not accept this so that you
> all can continue to work on creating a real solution that works for both
> situations (built in and as modules.)
> 
> I thought I said that already...

Your message was not clear to me at least, I understood your message as:
I acknowledge the problem you are trying to solve and accept Al's
solution for the case where modules are built-in, and another solution
should be found for when the modules are built as loadable modules.

But okay, your message is clear now :).
-- 
Florian