[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Maxime Ripard]

Hi all,

This serie enables the Armada 385 AP XHCI controller.

Since the controller uses a GPIO-controlled VBUS, we used the
phy-generic driver, and made the needed additions to the xhci-plat
driver to retrieve a USB phy.

Unfortunately, some glitches were also found along the way, mostly
because of the probe deferring that was introduced by this phy
retrieval.

Since the introduction of the Armada 38x support in 3.16, the driver
was attempting to write into registers while the clock wasn't enabled
yet. This was working because the bootloader left it enabled, but in
the case of a deferred probing, the clock would have been disabled by
the error path of our driver, and this would fail. This should go in
3.19, and any stable kernel for 3.16+.

The two patches remaining are "regular" patches, and are aimed at
3.20. The last patch depend on my previous serie to introduce support
for the the A385 AP board.

Thanks,
Maxime

Changes from v1:
  - Removed the patch 1 that fixes the deferred probing that was
    merged
  - Fixed the error path of the mvebu quirks code to avoid leaking a
    clock reference and the main HCD.
  - Removed the extra PHY field private to the struct xhci, and used
    the usb_phy field in the main HCD instead
  - Fixed the error path of the phy retrieval code in order to avoid
    leaving the phy up if an error was to happen, or the remove
    callback to be called.

Maxime Ripard (3):
  usb: XHCI: platform: Move the Marvell quirks after the enabling the
    clocks
  usb: xhci: plat: Add USB phy support
  ARM: mvebu: armada-385-ap: Enable USB3 port

 arch/arm/boot/dts/armada-385-db-ap.dts | 28 +++++++++++++++++++++++++
 drivers/usb/host/xhci-plat.c           | 38 ++++++++++++++++++++++++----------
 2 files changed, 55 insertions(+), 11 deletions(-)

-- 
2.2.2

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Maxime Ripard]

The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.16+
---
 drivers/usb/host/xhci-plat.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b15482..0e11d61408ff 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	if (irq < 0)
 		return -ENODEV;
 
-
-	if (of_device_is_compatible(pdev->dev.of_node,
-				    "marvell,armada-375-xhci") ||
-	    of_device_is_compatible(pdev->dev.of_node,
-				    "marvell,armada-380-xhci")) {
-		ret = xhci_mvebu_mbus_init_quirk(pdev);
-		if (ret)
-			return ret;
-	}
-
 	/* Initialize dma_mask and coherent_dma_mask to 32-bits */
 	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
 			goto put_hcd;
 	}
 
+	if (of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-375-xhci") ||
+	    of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-380-xhci")) {
+		ret = xhci_mvebu_mbus_init_quirk(pdev);
+		if (ret)
+			goto disable_clk;
+	}
+
 	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (ret)
 		goto disable_clk;
-- 
2.2.2

[PATCH v2 2/3] usb: xhci: plat: Add USB phy support

[Maxime Ripard]

The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.

Add a call to retrieve a USB PHY to XHCI plat in order to support this.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/usb/host/xhci-plat.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 0e11d61408ff..783e819139a7 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/usb/phy.h>
 #include <linux/slab.h>
 #include <linux/usb/xhci_pdriver.h>
 
@@ -155,12 +156,27 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
 		xhci->shared_hcd->can_do_streams = 1;
 
+	hcd->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
+	if (IS_ERR(hcd->usb_phy)) {
+		ret = PTR_ERR(hcd->usb_phy);
+		if (ret == -EPROBE_DEFER)
+			goto put_usb3_hcd;
+		hcd->usb_phy = NULL;
+	} else {
+		ret = usb_phy_init(hcd->usb_phy);
+		if (ret)
+			goto put_usb3_hcd;
+	}
+
 	ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
 	if (ret)
-		goto put_usb3_hcd;
+		goto disable_usb_phy;
 
 	return 0;
 
+disable_usb_phy:
+	usb_phy_shutdown(hcd->usb_phy);
+
 put_usb3_hcd:
 	usb_put_hcd(xhci->shared_hcd);
 
@@ -184,6 +200,7 @@ static int xhci_plat_remove(struct platform_device *dev)
 	struct clk *clk = xhci->clk;
 
 	usb_remove_hcd(xhci->shared_hcd);
+	usb_phy_shutdown(hcd->usb_phy);
 	usb_put_hcd(xhci->shared_hcd);
 
 	usb_remove_hcd(hcd);
-- 
2.2.2

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts b/arch/arm/boot/dts/armada-385-db-ap.dts
index 3a51531eb37b..b891b4c897f5 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -98,6 +98,13 @@
 				status = "okay";
 			};
 
+			pinctrl at 18000 {
+				xhci0_vbus_pins: xhci0-vbus-pins {
+					marvell,pins = "mpp44";
+					marvell,function = "gpio";
+				};
+			};
+
 			ethernet at 30000 {
 				status = "okay";
 				phy = <&phy2>;
@@ -122,6 +129,11 @@
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
 			};
+
+			usb3 at f0000 {
+				status = "okay";
+				usb-phy = <&usb3_phy>;
+			};
 		};
 
 		pcie-controller {
@@ -147,4 +159,20 @@
 			};
 		};
 	};
+
+	usb3_phy: usb3_phy {
+		compatible = "usb-nop-xceiv";
+		vcc-supply = <&reg_xhci0_vbus>;
+	};
+
+	reg_xhci0_vbus: xhci0-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&xhci0_vbus_pins>;
+		regulator-name = "xhci0-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+	};
 };
-- 
2.2.2

[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Andrew Lunn]

On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> Hi all,
> 
> This serie enables the Armada 385 AP XHCI controller.
> 
> Since the controller uses a GPIO-controlled VBUS, we used the
> phy-generic driver, and made the needed additions to the xhci-plat
> driver to retrieve a USB phy.
> 
> Unfortunately, some glitches were also found along the way, mostly
> because of the probe deferring that was introduced by this phy
> retrieval.
> 
> Since the introduction of the Armada 38x support in 3.16, the driver
> was attempting to write into registers while the clock wasn't enabled
> yet. This was working because the bootloader left it enabled, but in
> the case of a deferred probing, the clock would have been disabled by
> the error path of our driver, and this would fail. This should go in
> 3.19, and any stable kernel for 3.16+.
> 
> The two patches remaining are "regular" patches, and are aimed at
> 3.20. The last patch depend on my previous serie to introduce support
> for the the A385 AP board.

Hi Maxime

I assume you want me to take 3/3? Any other route is not simple, since
this file only exists in mvebu/dt and maybe a staging branch of
arm-soc.

What route do you think the other patches will take?

Thanks

	Andrew

[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Maxime Ripard]

Hi Andrew,

On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote:
> On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> > Hi all,
> > 
> > This serie enables the Armada 385 AP XHCI controller.
> > 
> > Since the controller uses a GPIO-controlled VBUS, we used the
> > phy-generic driver, and made the needed additions to the xhci-plat
> > driver to retrieve a USB phy.
> > 
> > Unfortunately, some glitches were also found along the way, mostly
> > because of the probe deferring that was introduced by this phy
> > retrieval.
> > 
> > Since the introduction of the Armada 38x support in 3.16, the driver
> > was attempting to write into registers while the clock wasn't enabled
> > yet. This was working because the bootloader left it enabled, but in
> > the case of a deferred probing, the clock would have been disabled by
> > the error path of our driver, and this would fail. This should go in
> > 3.19, and any stable kernel for 3.16+.
> > 
> > The two patches remaining are "regular" patches, and are aimed at
> > 3.20. The last patch depend on my previous serie to introduce support
> > for the the A385 AP board.
> 
> Hi Maxime
> 
> I assume you want me to take 3/3? Any other route is not simple, since
> this file only exists in mvebu/dt and maybe a staging branch of
> arm-soc.
>
> What route do you think the other patches will take?

There should be no merge dependency, but merging the third patch alone
will probably result on a boot breakage. I don't think it really
matters though, since this is a new board, so I guess it can go
through the USB-PHY tree.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150120/8943f235/attachment.sig>

[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Andrew Lunn]

On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote:
> Hi Andrew,
> 
> On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote:
> > On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> > > Hi all,
> > > 
> > > This serie enables the Armada 385 AP XHCI controller.
> > > 
> > > Since the controller uses a GPIO-controlled VBUS, we used the
> > > phy-generic driver, and made the needed additions to the xhci-plat
> > > driver to retrieve a USB phy.
> > > 
> > > Unfortunately, some glitches were also found along the way, mostly
> > > because of the probe deferring that was introduced by this phy
> > > retrieval.
> > > 
> > > Since the introduction of the Armada 38x support in 3.16, the driver
> > > was attempting to write into registers while the clock wasn't enabled
> > > yet. This was working because the bootloader left it enabled, but in
> > > the case of a deferred probing, the clock would have been disabled by
> > > the error path of our driver, and this would fail. This should go in
> > > 3.19, and any stable kernel for 3.16+.
> > > 
> > > The two patches remaining are "regular" patches, and are aimed at
> > > 3.20. The last patch depend on my previous serie to introduce support
> > > for the the A385 AP board.
> > 
> > Hi Maxime
> > 
> > I assume you want me to take 3/3? Any other route is not simple, since
> > this file only exists in mvebu/dt and maybe a staging branch of
> > arm-soc.
> >
> > What route do you think the other patches will take?
> 
> There should be no merge dependency, but merging the third patch alone
> will probably result on a boot breakage. I don't think it really
> matters though, since this is a new board, so I guess it can go
> through the USB-PHY tree.

Hi Maxime

Humm, maybe i'm wrong, but i think

arch/arm/boot/dts/armada-385-db-ap.dts

only exists in the mvebu tree?

At least, i don't see it here:

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next

     Andrew

[PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Maxime Ripard]

On Tue, Jan 20, 2015 at 09:43:07PM +0100, Andrew Lunn wrote:
> On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote:
> > Hi Andrew,
> > 
> > On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote:
> > > On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> > > > Hi all,
> > > > 
> > > > This serie enables the Armada 385 AP XHCI controller.
> > > > 
> > > > Since the controller uses a GPIO-controlled VBUS, we used the
> > > > phy-generic driver, and made the needed additions to the xhci-plat
> > > > driver to retrieve a USB phy.
> > > > 
> > > > Unfortunately, some glitches were also found along the way, mostly
> > > > because of the probe deferring that was introduced by this phy
> > > > retrieval.
> > > > 
> > > > Since the introduction of the Armada 38x support in 3.16, the driver
> > > > was attempting to write into registers while the clock wasn't enabled
> > > > yet. This was working because the bootloader left it enabled, but in
> > > > the case of a deferred probing, the clock would have been disabled by
> > > > the error path of our driver, and this would fail. This should go in
> > > > 3.19, and any stable kernel for 3.16+.
> > > > 
> > > > The two patches remaining are "regular" patches, and are aimed at
> > > > 3.20. The last patch depend on my previous serie to introduce support
> > > > for the the A385 AP board.
> > > 
> > > Hi Maxime
> > > 
> > > I assume you want me to take 3/3? Any other route is not simple, since
> > > this file only exists in mvebu/dt and maybe a staging branch of
> > > arm-soc.
> > >
> > > What route do you think the other patches will take?
> > 
> > There should be no merge dependency, but merging the third patch alone
> > will probably result on a boot breakage. I don't think it really
> > matters though, since this is a new board, so I guess it can go
> > through the USB-PHY tree.
> 
> Hi Maxime
> 
> Humm, maybe i'm wrong, but i think
> 
> arch/arm/boot/dts/armada-385-db-ap.dts
> 
> only exists in the mvebu tree?
> 
> At least, i don't see it here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next

Yeah, but my point was that if you merge the DT bits, without having
the PHY driver quirks fix in your tree, you'll result in a kernel that
doesn't boot at all on that board.

But again, since this is a new board, I don't really see why you would
want to bisect that.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150121/f049a3da/attachment.sig>

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Maxime Ripard]

Hi Mathias, Greg,

On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
> 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> 
> However, that quirk was run before the clock the controllers needs has been
> enabled. This usually worked because the clock was first enabled by the
> bootloader, and left as such until the driver is probe, where it tries to
> access the MBUS configuration registers before enabling the clock.
> 
> Things get messy when EPROBE_DEFER is involved during the probe, since as part
> of its error path, the driver will rightfully disable the clock. When the
> driver will be reprobed, it will retry to access the MBUS registers, but this
> time with the clock disabled, which hangs forever.
> 
> Fix this by running the quirks after the clock has been enabled by the driver.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: <stable@vger.kernel.org> # v3.16+

Any chance for this to go in 3.19?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150204/6c6f3cf9/attachment.sig>

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Greg Kroah-Hartman]

On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
> Hi Mathias, Greg,
> 
> On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> > The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> > 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
> > 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> > 
> > However, that quirk was run before the clock the controllers needs has been
> > enabled. This usually worked because the clock was first enabled by the
> > bootloader, and left as such until the driver is probe, where it tries to
> > access the MBUS configuration registers before enabling the clock.
> > 
> > Things get messy when EPROBE_DEFER is involved during the probe, since as part
> > of its error path, the driver will rightfully disable the clock. When the
> > driver will be reprobed, it will retry to access the MBUS registers, but this
> > time with the clock disabled, which hangs forever.
> > 
> > Fix this by running the quirks after the clock has been enabled by the driver.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Cc: <stable@vger.kernel.org> # v3.16+
> 
> Any chance for this to go in 3.19?

For 3.19?  It's too late, I'm not sending anything else to Linus as 3.19
will be out in a few days.

thanks,

greg k-h

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Maxime Ripard]

On Wed, Feb 04, 2015 at 05:04:18AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
> > Hi Mathias, Greg,
> > 
> > On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> > > The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> > > 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
> > > 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> > > 
> > > However, that quirk was run before the clock the controllers needs has been
> > > enabled. This usually worked because the clock was first enabled by the
> > > bootloader, and left as such until the driver is probe, where it tries to
> > > access the MBUS configuration registers before enabling the clock.
> > > 
> > > Things get messy when EPROBE_DEFER is involved during the probe, since as part
> > > of its error path, the driver will rightfully disable the clock. When the
> > > driver will be reprobed, it will retry to access the MBUS registers, but this
> > > time with the clock disabled, which hangs forever.
> > > 
> > > Fix this by running the quirks after the clock has been enabled by the driver.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > Cc: <stable@vger.kernel.org> # v3.16+
> > 
> > Any chance for this to go in 3.19?
> 
> For 3.19?  It's too late, I'm not sending anything else to Linus as 3.19
> will be out in a few days.

Ok. I'll resend it when 3.20-rc1 is out then.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150209/73f78b6d/attachment.sig>

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Greg Kroah-Hartman]

On Mon, Feb 09, 2015 at 09:22:50AM +0100, Maxime Ripard wrote:
> On Wed, Feb 04, 2015 at 05:04:18AM -0800, Greg Kroah-Hartman wrote:
> > On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
> > > Hi Mathias, Greg,
> > > 
> > > On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> > > > The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> > > > 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
> > > > 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> > > > 
> > > > However, that quirk was run before the clock the controllers needs has been
> > > > enabled. This usually worked because the clock was first enabled by the
> > > > bootloader, and left as such until the driver is probe, where it tries to
> > > > access the MBUS configuration registers before enabling the clock.
> > > > 
> > > > Things get messy when EPROBE_DEFER is involved during the probe, since as part
> > > > of its error path, the driver will rightfully disable the clock. When the
> > > > driver will be reprobed, it will retry to access the MBUS registers, but this
> > > > time with the clock disabled, which hangs forever.
> > > > 
> > > > Fix this by running the quirks after the clock has been enabled by the driver.
> > > > 
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > > Cc: <stable@vger.kernel.org> # v3.16+
> > > 
> > > Any chance for this to go in 3.19?
> > 
> > For 3.19?  It's too late, I'm not sending anything else to Linus as 3.19
> > will be out in a few days.
> 
> Ok. I'll resend it when 3.20-rc1 is out then.

Why resend?  Mathias should be queueing this up properly.  Mathias?

[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Mathias Nyman]

On 09.02.2015 10:31, Greg Kroah-Hartman wrote:
> On Mon, Feb 09, 2015 at 09:22:50AM +0100, Maxime Ripard wrote:
>> On Wed, Feb 04, 2015 at 05:04:18AM -0800, Greg Kroah-Hartman wrote:
>>> On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
>>>> Hi Mathias, Greg,
>>>>
>>>> On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
>>>>> The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
>>>>> 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
>>>>> 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
>>>>>
>>>>> However, that quirk was run before the clock the controllers needs has been
>>>>> enabled. This usually worked because the clock was first enabled by the
>>>>> bootloader, and left as such until the driver is probe, where it tries to
>>>>> access the MBUS configuration registers before enabling the clock.
>>>>>
>>>>> Things get messy when EPROBE_DEFER is involved during the probe, since as part
>>>>> of its error path, the driver will rightfully disable the clock. When the
>>>>> driver will be reprobed, it will retry to access the MBUS registers, but this
>>>>> time with the clock disabled, which hangs forever.
>>>>>
>>>>> Fix this by running the quirks after the clock has been enabled by the driver.
>>>>>
>>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>>> Cc: <stable@vger.kernel.org> # v3.16+
>>>>
>>>> Any chance for this to go in 3.19?
>>>
>>> For 3.19?  It's too late, I'm not sending anything else to Linus as 3.19
>>> will be out in a few days.
>>
>> Ok. I'll resend it when 3.20-rc1 is out then.
> 
> Why resend?  Mathias should be queueing this up properly.  Mathias?
> 

Yep, I'll send it forward to Greg once 3.20-rc1 is tagged

-Mathias

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Gregory CLEMENT]

Hi Maxime,

On 19/01/2015 14:01, Maxime Ripard wrote:
> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> VBUS line. Enable the needed drivers to support this.
> 

it seems that this patch was not applied yet. Patch 1 is now in
linux-next and should be part of 4.0-rc. But what about patch 2?

Thanks,

Gregory


> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts b/arch/arm/boot/dts/armada-385-db-ap.dts
> index 3a51531eb37b..b891b4c897f5 100644
> --- a/arch/arm/boot/dts/armada-385-db-ap.dts
> +++ b/arch/arm/boot/dts/armada-385-db-ap.dts
> @@ -98,6 +98,13 @@
>  				status = "okay";
>  			};
>  
> +			pinctrl at 18000 {
> +				xhci0_vbus_pins: xhci0-vbus-pins {
> +					marvell,pins = "mpp44";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
>  			ethernet at 30000 {
>  				status = "okay";
>  				phy = <&phy2>;
> @@ -122,6 +129,11 @@
>  				phy = <&phy0>;
>  				phy-mode = "rgmii-id";
>  			};
> +
> +			usb3 at f0000 {
> +				status = "okay";
> +				usb-phy = <&usb3_phy>;
> +			};
>  		};
>  
>  		pcie-controller {
> @@ -147,4 +159,20 @@
>  			};
>  		};
>  	};
> +
> +	usb3_phy: usb3_phy {
> +		compatible = "usb-nop-xceiv";
> +		vcc-supply = <&reg_xhci0_vbus>;
> +	};
> +
> +	reg_xhci0_vbus: xhci0-vbus {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&xhci0_vbus_pins>;
> +		regulator-name = "xhci0-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
> +	};
>  };
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
> Hi Maxime,
> 
> On 19/01/2015 14:01, Maxime Ripard wrote:
> > The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> > VBUS line. Enable the needed drivers to support this.
> > 
> 
> it seems that this patch was not applied yet. Patch 1 is now in
> linux-next and should be part of 4.0-rc. But what about patch 2?

IIRC, Greg or Matthias said that Matthias would look into these
patches after the merge window.

It still didn't happen though.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150303/662951ce/attachment.sig>

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Mathias Nyman]

On 03.03.2015 11:59, Maxime Ripard wrote:
> On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
>> Hi Maxime,
>>
>> On 19/01/2015 14:01, Maxime Ripard wrote:
>>> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
>>> VBUS line. Enable the needed drivers to support this.
>>>
>>
>> it seems that this patch was not applied yet. Patch 1 is now in
>> linux-next and should be part of 4.0-rc. But what about patch 2?
> 
> IIRC, Greg or Matthias said that Matthias would look into these
> patches after the merge window.
> 
> It still didn't happen though.
> 
> Maxime
> 

Hi

I understood that you wanted the first fix patch in as soon as possible so 
I sent it forward to Greg, and it's now in his usb-linus branch.

The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?),
Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?

It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone
with more USB PHY insight could ack it first.

-Mathias 

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

Hi Matthias,

On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote:
> On 03.03.2015 11:59, Maxime Ripard wrote:
> > On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
> >> Hi Maxime,
> >>
> >> On 19/01/2015 14:01, Maxime Ripard wrote:
> >>> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> >>> VBUS line. Enable the needed drivers to support this.
> >>>
> >>
> >> it seems that this patch was not applied yet. Patch 1 is now in
> >> linux-next and should be part of 4.0-rc. But what about patch 2?
> > 
> > IIRC, Greg or Matthias said that Matthias would look into these
> > patches after the merge window.
> > 
> > It still didn't happen though.
> > 
> > Maxime
> > 
> 
> Hi
> 
> I understood that you wanted the first fix patch in as soon as possible so 
> I sent it forward to Greg, and it's now in his usb-linus branch.

Ah, so you were talking only about the first patch. My bad.

> The other two patches, 2/3 and 3/3 you said were "regual" patches
> (for usb-next?),

Indeed, at least for patch 2.

> Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go
> together?

Patch 3 doesn't need to be merged through the same tree, so I guess
it's totally fine if 2 goes through USB and 3 through arm-soc.

> It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone
> with more USB PHY insight could ack it first.

ACK.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150304/13faaa7f/attachment.sig>

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote:
> On 03.03.2015 11:59, Maxime Ripard wrote:
> > On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
> >> Hi Maxime,
> >>
> >> On 19/01/2015 14:01, Maxime Ripard wrote:
> >>> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> >>> VBUS line. Enable the needed drivers to support this.
> >>>
> >>
> >> it seems that this patch was not applied yet. Patch 1 is now in
> >> linux-next and should be part of 4.0-rc. But what about patch 2?
> > 
> > IIRC, Greg or Matthias said that Matthias would look into these
> > patches after the merge window.
> > 
> > It still didn't happen though.
> > 
> > Maxime
> > 
> 
> Hi
> 
> I understood that you wanted the first fix patch in as soon as possible so 
> I sent it forward to Greg, and it's now in his usb-linus branch.
> 
> The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?),
> Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
> 
> It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone
> with more USB PHY insight could ack it first.

There's been around two weeks, and we didn't have any additional
reviews. How can we move forward on this?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150317/aec4873c/attachment-0001.sig>

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Mathias Nyman]

On 17.03.2015 11:51, Maxime Ripard wrote:
> On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote:
>> On 03.03.2015 11:59, Maxime Ripard wrote:
>>> On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
>>>> Hi Maxime,
>>>>
>>>> On 19/01/2015 14:01, Maxime Ripard wrote:
>>>>> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
>>>>> VBUS line. Enable the needed drivers to support this.
>>>>>
>>>>
>>>> it seems that this patch was not applied yet. Patch 1 is now in
>>>> linux-next and should be part of 4.0-rc. But what about patch 2?
>>>
>>> IIRC, Greg or Matthias said that Matthias would look into these
>>> patches after the merge window.
>>>
>>> It still didn't happen though.
>>>
>>> Maxime
>>>
>>
>> Hi
>>
>> I understood that you wanted the first fix patch in as soon as possible so 
>> I sent it forward to Greg, and it's now in his usb-linus branch.
>>
>> The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?),
>> Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
>>
>> It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone
>> with more USB PHY insight could ack it first.
> 
> There's been around two weeks, and we didn't have any additional
> reviews. How can we move forward on this?
> 

Added to my for-usb-next branch and sent forward to Greg (a second a go)

-Mathias

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

On Tue, Mar 17, 2015 at 06:34:21PM +0200, Mathias Nyman wrote:
> On 17.03.2015 11:51, Maxime Ripard wrote:
> > On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote:
> >> On 03.03.2015 11:59, Maxime Ripard wrote:
> >>> On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
> >>>> Hi Maxime,
> >>>>
> >>>> On 19/01/2015 14:01, Maxime Ripard wrote:
> >>>>> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> >>>>> VBUS line. Enable the needed drivers to support this.
> >>>>>
> >>>>
> >>>> it seems that this patch was not applied yet. Patch 1 is now in
> >>>> linux-next and should be part of 4.0-rc. But what about patch 2?
> >>>
> >>> IIRC, Greg or Matthias said that Matthias would look into these
> >>> patches after the merge window.
> >>>
> >>> It still didn't happen though.
> >>>
> >>> Maxime
> >>>
> >>
> >> Hi
> >>
> >> I understood that you wanted the first fix patch in as soon as possible so 
> >> I sent it forward to Greg, and it's now in his usb-linus branch.
> >>
> >> The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?),
> >> Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
> >>
> >> It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone
> >> with more USB PHY insight could ack it first.
> > 
> > There's been around two weeks, and we didn't have any additional
> > reviews. How can we move forward on this?
> > 
> 
> Added to my for-usb-next branch and sent forward to Greg (a second a go)

Great, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150317/59c3bd41/attachment.sig>

[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Gregory CLEMENT]

Hi Maxime, Jason, Andrew, Sebastian, Greg, Felipe, Mathias,

On 19/01/2015 14:01, Maxime Ripard wrote:
> The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
> VBUS line. Enable the needed drivers to support this.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

applied on mvebu/dt

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts b/arch/arm/boot/dts/armada-385-db-ap.dts
> index 3a51531eb37b..b891b4c897f5 100644
> --- a/arch/arm/boot/dts/armada-385-db-ap.dts
> +++ b/arch/arm/boot/dts/armada-385-db-ap.dts
> @@ -98,6 +98,13 @@
>  				status = "okay";
>  			};
>  
> +			pinctrl at 18000 {
> +				xhci0_vbus_pins: xhci0-vbus-pins {
> +					marvell,pins = "mpp44";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
>  			ethernet at 30000 {
>  				status = "okay";
>  				phy = <&phy2>;
> @@ -122,6 +129,11 @@
>  				phy = <&phy0>;
>  				phy-mode = "rgmii-id";
>  			};
> +
> +			usb3 at f0000 {
> +				status = "okay";
> +				usb-phy = <&usb3_phy>;
> +			};
>  		};
>  
>  		pcie-controller {
> @@ -147,4 +159,20 @@
>  			};
>  		};
>  	};
> +
> +	usb3_phy: usb3_phy {
> +		compatible = "usb-nop-xceiv";
> +		vcc-supply = <&reg_xhci0_vbus>;
> +	};
> +
> +	reg_xhci0_vbus: xhci0-vbus {
> +		compatible = "regulator-fixed";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&xhci0_vbus_pins>;
> +		regulator-name = "xhci0-vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
> +	};
>  };
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com