* [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
@ 2015-01-19 13:01 Maxime Ripard
2015-01-19 13:01 ` [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Maxime Ripard
` (3 more replies)
0 siblings, 4 replies; 21+ messages in thread
From: Maxime Ripard @ 2015-01-19 13:01 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-01-19 13:01 [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Maxime Ripard @ 2015-01-19 13:01 ` Maxime Ripard 2015-02-04 9:35 ` Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 2/3] usb: xhci: plat: Add USB phy support Maxime Ripard ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-01-19 13:01 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-01-19 13:01 ` [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Maxime Ripard @ 2015-02-04 9:35 ` Maxime Ripard 2015-02-04 13:04 ` Greg Kroah-Hartman 0 siblings, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-02-04 9:35 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-02-04 9:35 ` Maxime Ripard @ 2015-02-04 13:04 ` Greg Kroah-Hartman 2015-02-09 8:22 ` Maxime Ripard 0 siblings, 1 reply; 21+ messages in thread From: Greg Kroah-Hartman @ 2015-02-04 13:04 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-02-04 13:04 ` Greg Kroah-Hartman @ 2015-02-09 8:22 ` Maxime Ripard 2015-02-09 8:31 ` Greg Kroah-Hartman 0 siblings, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-02-09 8:22 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-02-09 8:22 ` Maxime Ripard @ 2015-02-09 8:31 ` Greg Kroah-Hartman 2015-02-16 13:43 ` Mathias Nyman 0 siblings, 1 reply; 21+ messages in thread From: Greg Kroah-Hartman @ 2015-02-09 8:31 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks 2015-02-09 8:31 ` Greg Kroah-Hartman @ 2015-02-16 13:43 ` Mathias Nyman 0 siblings, 0 replies; 21+ messages in thread From: Mathias Nyman @ 2015-02-16 13:43 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 2/3] usb: xhci: plat: Add USB phy support 2015-01-19 13:01 [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Maxime Ripard @ 2015-01-19 13:01 ` Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port Maxime Ripard 2015-01-19 21:35 ` [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Andrew Lunn 3 siblings, 0 replies; 21+ messages in thread From: Maxime Ripard @ 2015-01-19 13:01 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-01-19 13:01 [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 2/3] usb: xhci: plat: Add USB phy support Maxime Ripard @ 2015-01-19 13:01 ` Maxime Ripard 2015-03-02 19:23 ` Gregory CLEMENT 2015-03-18 10:59 ` Gregory CLEMENT 2015-01-19 21:35 ` [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Andrew Lunn 3 siblings, 2 replies; 21+ messages in thread From: Maxime Ripard @ 2015-01-19 13:01 UTC (permalink / raw) To: linux-arm-kernel 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 = <®_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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-01-19 13:01 ` [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port Maxime Ripard @ 2015-03-02 19:23 ` Gregory CLEMENT 2015-03-03 9:59 ` Maxime Ripard 2015-03-18 10:59 ` Gregory CLEMENT 1 sibling, 1 reply; 21+ messages in thread From: Gregory CLEMENT @ 2015-03-02 19:23 UTC (permalink / raw) To: linux-arm-kernel 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 = <®_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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-02 19:23 ` Gregory CLEMENT @ 2015-03-03 9:59 ` Maxime Ripard 2015-03-03 16:12 ` Mathias Nyman 0 siblings, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-03-03 9:59 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-03 9:59 ` Maxime Ripard @ 2015-03-03 16:12 ` Mathias Nyman 2015-03-04 16:13 ` Maxime Ripard 2015-03-17 9:51 ` Maxime Ripard 0 siblings, 2 replies; 21+ messages in thread From: Mathias Nyman @ 2015-03-03 16:12 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-03 16:12 ` Mathias Nyman @ 2015-03-04 16:13 ` Maxime Ripard 2015-03-17 9:51 ` Maxime Ripard 1 sibling, 0 replies; 21+ messages in thread From: Maxime Ripard @ 2015-03-04 16:13 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-03 16:12 ` Mathias Nyman 2015-03-04 16:13 ` Maxime Ripard @ 2015-03-17 9:51 ` Maxime Ripard 2015-03-17 16:34 ` Mathias Nyman 1 sibling, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-03-17 9:51 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-17 9:51 ` Maxime Ripard @ 2015-03-17 16:34 ` Mathias Nyman 2015-03-17 17:00 ` Maxime Ripard 0 siblings, 1 reply; 21+ messages in thread From: Mathias Nyman @ 2015-03-17 16:34 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-03-17 16:34 ` Mathias Nyman @ 2015-03-17 17:00 ` Maxime Ripard 0 siblings, 0 replies; 21+ messages in thread From: Maxime Ripard @ 2015-03-17 17:00 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port 2015-01-19 13:01 ` [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port Maxime Ripard 2015-03-02 19:23 ` Gregory CLEMENT @ 2015-03-18 10:59 ` Gregory CLEMENT 1 sibling, 0 replies; 21+ messages in thread From: Gregory CLEMENT @ 2015-03-18 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 = <®_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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP 2015-01-19 13:01 [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Maxime Ripard ` (2 preceding siblings ...) 2015-01-19 13:01 ` [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port Maxime Ripard @ 2015-01-19 21:35 ` Andrew Lunn 2015-01-20 20:30 ` Maxime Ripard 3 siblings, 1 reply; 21+ messages in thread From: Andrew Lunn @ 2015-01-19 21:35 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP 2015-01-19 21:35 ` [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Andrew Lunn @ 2015-01-20 20:30 ` Maxime Ripard 2015-01-20 20:43 ` Andrew Lunn 0 siblings, 1 reply; 21+ messages in thread From: Maxime Ripard @ 2015-01-20 20:30 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP 2015-01-20 20:30 ` Maxime Ripard @ 2015-01-20 20:43 ` Andrew Lunn 2015-01-21 9:09 ` Maxime Ripard 0 siblings, 1 reply; 21+ messages in thread From: Andrew Lunn @ 2015-01-20 20:43 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP 2015-01-20 20:43 ` Andrew Lunn @ 2015-01-21 9:09 ` Maxime Ripard 0 siblings, 0 replies; 21+ messages in thread From: Maxime Ripard @ 2015-01-21 9:09 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-03-18 10:59 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-19 13:01 [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks Maxime Ripard 2015-02-04 9:35 ` Maxime Ripard 2015-02-04 13:04 ` Greg Kroah-Hartman 2015-02-09 8:22 ` Maxime Ripard 2015-02-09 8:31 ` Greg Kroah-Hartman 2015-02-16 13:43 ` Mathias Nyman 2015-01-19 13:01 ` [PATCH v2 2/3] usb: xhci: plat: Add USB phy support Maxime Ripard 2015-01-19 13:01 ` [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port Maxime Ripard 2015-03-02 19:23 ` Gregory CLEMENT 2015-03-03 9:59 ` Maxime Ripard 2015-03-03 16:12 ` Mathias Nyman 2015-03-04 16:13 ` Maxime Ripard 2015-03-17 9:51 ` Maxime Ripard 2015-03-17 16:34 ` Mathias Nyman 2015-03-17 17:00 ` Maxime Ripard 2015-03-18 10:59 ` Gregory CLEMENT 2015-01-19 21:35 ` [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP Andrew Lunn 2015-01-20 20:30 ` Maxime Ripard 2015-01-20 20:43 ` Andrew Lunn 2015-01-21 9:09 ` Maxime Ripard
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.