[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

A number of ARM platforms were changed in linux-3.9 so they can be enabled
at a single kernel configuration. Unfortunately, the necessary changes for
the EHCI driver were not ready in time and the first attempt to split out
the EHCI bus glues into separate modules had to get reverted before the
merge window.

This means we are still stuck with a situation where enabling any
combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
platforms at the same time leaves us with an EHCI driver that does
not work properly and spits out this build warning:

ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
In file included from ehci-hcd.c:1256:0:
ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used [-Wunused-variable]
In file included from ehci-hcd.c:1276:0:
ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition

This is the simplest patch I could come up with that will restore some
sanity in multiplatform configuration and allow us to build an ARM
allyesconfig kernel. Disallowing the broken configuration in Kconfig
would actually end up in a larger patch and more regression potential
than this one.

We had a similar situation in 3.8 with a conflict between Orion and MXC,
and Alan Stern objected to the simple hack back then and instead provided
a better full conversion of the MXC backend in patch dba63b2f7. A proper
patch for OMAP was submitted in January but also did not make it into 3.9,
see https://patchwork.kernel.org/patch/2055131.

I expect that for 3.10 we will be able to do this correctly and
turn all ARM bus glues into separate modules, ripping out the
code that this patch changes.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Andrew Lunn <andrew@lunn.ch>
CC: Jason Cooper <jason@lakedaemon.net>
---
 drivers/usb/host/ehci-hcd.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index dd1d41d..c750d71 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1254,7 +1254,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_USB_EHCI_HCD_OMAP
 #include "ehci-omap.c"
-#define        PLATFORM_DRIVER         ehci_hcd_omap_driver
+#define	OMAP_PLATFORM_DRIVER	ehci_hcd_omap_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1274,7 +1274,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_ORION
 #include "ehci-orion.c"
-#define	PLATFORM_DRIVER		ehci_orion_driver
+#define	ORION_PLATFORM_DRIVER	ehci_orion_driver
 #endif
 
 #ifdef CONFIG_USB_W90X900_EHCI
@@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void)
 	if (retval < 0)
 		goto clean4;
 #endif
+
+#ifdef OMAP_PLATFORM_DRIVER
+	retval = platform_driver_register(&OMAP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto clean5;
+#endif
 	return retval;
 
+#ifdef OMAP_PLATFORM_DRIVER
+	/* platform_driver_unregister(&OMAP_PLATFORM_DRIVER); */
+clean5:
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
-	/* platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER); */
+	platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 clean4:
 #endif
 #ifdef OF_PLATFORM_DRIVER
@@ -1423,6 +1433,10 @@ clean3:
 	ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 clean2:
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 clean0:
@@ -1439,12 +1453,18 @@ module_init(ehci_hcd_init);
 
 static void __exit ehci_hcd_cleanup(void)
 {
+#ifdef OMAP_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP_PLATFORM_DRIVER);
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
 	platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 #endif
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
-- 
1.8.1.2

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Arnd Bergmann wrote:
> @@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void)
>         if (retval < 0)
>                 goto clean4;
>  #endif
> +
> +#ifdef OMAP_PLATFORM_DRIVER
> +       retval = platform_driver_register(&OMAP_PLATFORM_DRIVER);
> +       if (retval < 0)
> +               goto clean5;
> +#endif

There was a missing hunk for the ORION part like the one above since
I unfortunately had done this patch on the wrong base.  I will resubmit
a proper patch if we get an agreement on the approach taken.

	Arnd

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> A number of ARM platforms were changed in linux-3.9 so they can be enabled
> at a single kernel configuration. Unfortunately, the necessary changes for
> the EHCI driver were not ready in time and the first attempt to split out
> the EHCI bus glues into separate modules had to get reverted before the
> merge window.
> 
> This means we are still stuck with a situation where enabling any
> combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
> platforms at the same time leaves us with an EHCI driver that does
> not work properly and spits out this build warning:
> 
> ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1257:0: note: this is the location of the previous definition
> ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1277:0: note: this is the location of the previous definition
> In file included from ehci-hcd.c:1256:0:
> ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used [-Wunused-variable]
> In file included from ehci-hcd.c:1276:0:
> ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
> ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1257:0: note: this is the location of the previous definition
> ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1277:0: note: this is the location of the previous definition

Roger just submitted my patch to split out ehci-omap.

> This is the simplest patch I could come up with that will restore some
> sanity in multiplatform configuration and allow us to build an ARM
> allyesconfig kernel. Disallowing the broken configuration in Kconfig
> would actually end up in a larger patch and more regression potential
> than this one.
> 
> We had a similar situation in 3.8 with a conflict between Orion and MXC,
> and Alan Stern objected to the simple hack back then and instead provided
> a better full conversion of the MXC backend in patch dba63b2f7. A proper
> patch for OMAP was submitted in January but also did not make it into 3.9,
> see https://patchwork.kernel.org/patch/2055131.
> 
> I expect that for 3.10 we will be able to do this correctly and
> turn all ARM bus glues into separate modules, ripping out the
> code that this patch changes.

What happened to Manjunath Goudar?  I haven't heard from him since his 
first round of submissions a month ago.  Fixing them up shouldn't be 
too much work.

As far as I can tell, your scheme should be okay for now.  It would be 
good to hear from other people, though.

I'd guess that the only reason it wasn't done this way from the
beginning is that nobody considered the possibility of building a
multi-platform driver.

Alan Stern

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> Roger just submitted my patch to split out ehci-omap.

Ok, if we can merge that for 3.9, the main issue will be resolved, because
an OMAP+Orion config is much more interesting in practice than adding
VT8500 to the mix.

An alternative for VT8500 would be to remove drivers/usb/host/ehci-vt8500.c
completely and use the generic ehci-platform.c bus glue with added DT
support, as the patch below that I just hacked up. Not sure if that
anyone would prefer that over the hot-fix for 3.9, but it's possibly
a better solution in the long run.

> What happened to Manjunath Goudar?  I haven't heard from him since his 
> first round of submissions a month ago.  Fixing them up shouldn't be 
> too much work.

He's still around and working on his patches for 3.10. I'm currently working
with him to resolve a few of the remaining problems in his series and he
will post the lot soon.

> As far as I can tell, your scheme should be okay for now.  It would be 
> good to hear from other people, though.
> 
> I'd guess that the only reason it wasn't done this way from the
> beginning is that nobody considered the possibility of building a
> multi-platform driver.

Right. It's been a long way until it became possible on ARM. The four
PowerPC bus glues have already been mutually exclusive like this all
the time.

	Arnd


---
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..2e4ddd4 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
  *
  * Licensed under the GNU/GPL. See COPYING for details.
  */
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/kernel.h>
 #include <linux/hrtimer.h>
 #include <linux/io.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
@@ -41,17 +43,21 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
 	struct ehci_hcd *ehci = hcd_to_ehci(hcd);
 	int retval;
 
-	hcd->has_tt = pdata->has_tt;
-	ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug;
-	ehci->big_endian_desc = pdata->big_endian_desc;
-	ehci->big_endian_mmio = pdata->big_endian_mmio;
+	ehci->caps = hcd->regs;
+
+	if (pdata) {
+		hcd->has_tt = pdata->has_tt;
+		ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug;
+		ehci->big_endian_desc = pdata->big_endian_desc;
+		ehci->big_endian_mmio = pdata->big_endian_mmio;
+	 	ehci->caps += pdata->caps_offset;
+	}
 
-	ehci->caps = hcd->regs + pdata->caps_offset;
 	retval = ehci_setup(hcd);
 	if (retval)
 		return retval;
 
-	if (pdata->no_io_watchdog)
+	if (pdata && pdata->no_io_watchdog)
 		ehci->need_io_watchdog = 0;
 	return 0;
 }
@@ -70,11 +76,6 @@ static int ehci_platform_probe(struct platform_device *dev)
 	int irq;
 	int err = -ENOMEM;
 
-	if (!pdata) {
-		WARN_ON(1);
-		return -ENODEV;
-	}
-
 	if (usb_disabled())
 		return -ENODEV;
 
@@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev)
 		return -ENXIO;
 	}
 
-	if (pdata->power_on) {
+	if (pdata && pdata->power_on) {
 		err = pdata->power_on(dev);
 		if (err < 0)
 			return err;
 	}
 
+	if (!dev->dev.dma_mask) {
+		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+		dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+	}
+
 	hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev,
 			     dev_name(&dev->dev));
 	if (!hcd) {
@@ -121,7 +127,7 @@ static int ehci_platform_probe(struct platform_device *dev)
 err_put_hcd:
 	usb_put_hcd(hcd);
 err_power:
-	if (pdata->power_off)
+	if (pdata && pdata->power_off)
 		pdata->power_off(dev);
 
 	return err;
@@ -136,7 +142,7 @@ static int ehci_platform_remove(struct platform_device *dev)
 	usb_put_hcd(hcd);
 	platform_set_drvdata(dev, NULL);
 
-	if (pdata->power_off)
+	if (pdata && pdata->power_off)
 		pdata->power_off(dev);
 
 	return 0;
@@ -155,7 +161,7 @@ static int ehci_platform_suspend(struct device *dev)
 
 	ret = ehci_suspend(hcd, do_wakeup);
 
-	if (pdata->power_suspend)
+	if (pdata && pdata->power_suspend)
 		pdata->power_suspend(pdev);
 
 	return ret;
@@ -168,7 +174,7 @@ static int ehci_platform_resume(struct device *dev)
 	struct platform_device *pdev =
 		container_of(dev, struct platform_device, dev);
 
-	if (pdata->power_on) {
+	if (pdata && pdata->power_on) {
 		int err = pdata->power_on(pdev);
 		if (err < 0)
 			return err;
@@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev)
 #define ehci_platform_resume	NULL
 #endif /* CONFIG_PM */
 
+static const struct of_device_id vt8500_ehci_ids[] = {
+	{ .compatible = "via,vt8500-ehci", },
+	{ .compatible = "wm,prizm-ehci", },
+	{}
+};
+
 static const struct platform_device_id ehci_platform_table[] = {
 	{ "ehci-platform", 0 },
 	{ }
@@ -203,6 +215,7 @@ static struct platform_driver ehci_platform_driver = {
 		.owner	= THIS_MODULE,
 		.name	= "ehci-platform",
 		.pm	= &ehci_platform_pm_ops,
+		.of_match_table = of_match_ptr(vt8500_ehci_ids),
 	}
 };
 

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> On Friday 15 March 2013, Alan Stern wrote:
> > Roger just submitted my patch to split out ehci-omap.
> 
> Ok, if we can merge that for 3.9, the main issue will be resolved, because
> an OMAP+Orion config is much more interesting in practice than adding
> VT8500 to the mix.

I don't know if the patch will get into 3.9.  That's up to Greg; IIRC 
Roger did not ask for it.

> An alternative for VT8500 would be to remove drivers/usb/host/ehci-vt8500.c
> completely and use the generic ehci-platform.c bus glue with added DT
> support, as the patch below that I just hacked up. Not sure if that
> anyone would prefer that over the hot-fix for 3.9, but it's possibly
> a better solution in the long run.

Getting rid of driver files is always worthwhile.

> @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev)
>  		return -ENXIO;
>  	}
>  
> -	if (pdata->power_on) {
> +	if (pdata && pdata->power_on) {
>  		err = pdata->power_on(dev);
>  		if (err < 0)
>  			return err;
>  	}

Instead of adding these tests for non-NULL pdata all over the place, 
you could define a static structure with default settings and store a 
pointer to it if pdata wasn't set initially.

Alan Stern

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> On Friday 15 March 2013, Alan Stern wrote:
> > Roger just submitted my patch to split out ehci-omap.
> 
> Ok, if we can merge that for 3.9, the main issue will be resolved, because
> an OMAP+Orion config is much more interesting in practice than adding
> VT8500 to the mix.

I just got an automated message from Greg:

--------------------------------------------------------------------------
This is a note to let you know that I've just added the patch titled

    USB: EHCI: split ehci-omap out to a separate driver

to my usb git tree which can be found at
    git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
--------------------------------------------------------------------------

Unless something is changed, this patch won't get into 3.9-final.  
Do you want Greg to move it to his usb-linus branch?

Alan Stern

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Greg Kroah-Hartman]

On Fri, Mar 15, 2013 at 03:19:08PM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Arnd Bergmann wrote:
> 
> > On Friday 15 March 2013, Alan Stern wrote:
> > > Roger just submitted my patch to split out ehci-omap.
> > 
> > Ok, if we can merge that for 3.9, the main issue will be resolved, because
> > an OMAP+Orion config is much more interesting in practice than adding
> > VT8500 to the mix.
> 
> I just got an automated message from Greg:
> 
> --------------------------------------------------------------------------
> This is a note to let you know that I've just added the patch titled
> 
>     USB: EHCI: split ehci-omap out to a separate driver
> 
> to my usb git tree which can be found at
>     git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> in the usb-next branch.
> --------------------------------------------------------------------------
> 
> Unless something is changed, this patch won't get into 3.9-final.  
> Do you want Greg to move it to his usb-linus branch?

It's a bit too "big" for 3.9-final, sorry.

greg k-h

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> On Fri, 15 Mar 2013, Arnd Bergmann wrote:
> > @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev)
> >  		return -ENXIO;
> >  	}
> >  
> > -	if (pdata->power_on) {
> > +	if (pdata && pdata->power_on) {
> >  		err = pdata->power_on(dev);
> >  		if (err < 0)
> >  			return err;
> >  	}
> 
> Instead of adding these tests for non-NULL pdata all over the place, 
> you could define a static structure with default settings and store a 
> pointer to it if pdata wasn't set initially.

Yes, good idea. Here is a new version. Maybe Alexey or Tony can verify if
that works for them on wm8850. That should be independent of the decision
into which kernel to merge this patch.

	Arnd

8<------
>From 016f7ecd1bce61c18d621acf746776491cc8487e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 15 Feb 2013 23:12:28 +0100
Subject: [PATCH] USB: EHCI: DT support for generic bus glue

This lets us use the ehci-generic driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Prisk <linux@prisktech.co.nz>
Cc: Alexey Charkov <alchark@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
---
 drivers/usb/host/ehci-hcd.c      |   5 --
 drivers/usb/host/ehci-platform.c |  25 +++--
 drivers/usb/host/ehci-vt8500.c   | 150 -------------------------------
 3 files changed, 19 insertions(+), 161 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c750d71..9dfcef6 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1292,11 +1292,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ehci_octeon_driver
 #endif
 
-#ifdef CONFIG_ARCH_VT8500
-#include "ehci-vt8500.c"
-#define	PLATFORM_DRIVER		vt8500_ehci_driver
-#endif
-
 #ifdef CONFIG_PLAT_SPEAR
 #include "ehci-spear.c"
 #define PLATFORM_DRIVER		spear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..e7777af 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
  *
  * Licensed under the GNU/GPL. See COPYING for details.
  */
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/kernel.h>
 #include <linux/hrtimer.h>
 #include <linux/io.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
@@ -62,22 +64,26 @@ static const struct ehci_driver_overrides platform_overrides __initdata = {
 	.reset =	ehci_platform_reset,
 };
 
+static struct usb_ehci_pdata ehci_platform_defaults;
+
 static int ehci_platform_probe(struct platform_device *dev)
 {
 	struct usb_hcd *hcd;
 	struct resource *res_mem;
-	struct usb_ehci_pdata *pdata = dev->dev.platform_data;
+	struct usb_ehci_pdata *pdata;
 	int irq;
 	int err = -ENOMEM;
 
-	if (!pdata) {
-		WARN_ON(1);
-		return -ENODEV;
-	}
-
 	if (usb_disabled())
 		return -ENODEV;
 
+	if (!dev->dev.platform_data) {
+		dev->dev.platform_data = &ehci_platform_defaults;
+		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+		dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+	}
+	pdata = dev->dev.platform_data;
+
 	irq = platform_get_irq(dev, 0);
 	if (irq < 0) {
 		dev_err(&dev->dev, "no irq provided");
@@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev)
 #define ehci_platform_resume	NULL
 #endif /* CONFIG_PM */
 
+static const struct of_device_id vt8500_ehci_ids[] = {
+	{ .compatible = "via,vt8500-ehci", },
+	{ .compatible = "wm,prizm-ehci", },
+	{}
+};
+
 static const struct platform_device_id ehci_platform_table[] = {
 	{ "ehci-platform", 0 },
 	{ }
@@ -203,6 +215,7 @@ static struct platform_driver ehci_platform_driver = {
 		.owner	= THIS_MODULE,
 		.name	= "ehci-platform",
 		.pm	= &ehci_platform_pm_ops,
+		.of_match_table = of_match_ptr(vt8500_ehci_ids),
 	}
 };
 
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..0000000
--- a/drivers/usb/host/ehci-vt8500.c
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
- * drivers/usb/host/ehci-vt8500.c
- *
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
- *
- * Based on ehci-au1xxx.c
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/err.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-
-static const struct hc_driver vt8500_ehci_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "VT8500 EHCI",
-	.hcd_priv_size		= sizeof(struct ehci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq			= ehci_irq,
-	.flags			= HCD_MEMORY | HCD_USB2,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset			= ehci_setup,
-	.start			= ehci_run,
-	.stop			= ehci_stop,
-	.shutdown		= ehci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue		= ehci_urb_enqueue,
-	.urb_dequeue		= ehci_urb_dequeue,
-	.endpoint_disable	= ehci_endpoint_disable,
-	.endpoint_reset		= ehci_endpoint_reset,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number	= ehci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data	= ehci_hub_status_data,
-	.hub_control		= ehci_hub_control,
-	.bus_suspend		= ehci_bus_suspend,
-	.bus_resume		= ehci_bus_resume,
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	.clear_tt_buffer_complete	= ehci_clear_tt_buffer_complete,
-};
-
-static u64 vt8500_ehci_dma_mask = DMA_BIT_MASK(32);
-
-static int vt8500_ehci_drv_probe(struct platform_device *pdev)
-{
-	struct usb_hcd *hcd;
-	struct ehci_hcd *ehci;
-	struct resource *res;
-	int ret;
-
-	if (usb_disabled())
-		return -ENODEV;
-
-	/*
-	 * Right now device-tree probed devices don't get dma_mask set.
-	 * Since shared usb code relies on it, set it here for now.
-	 * Once we have dma capability bindings this can go away.
-	 */
-	if (!pdev->dev.dma_mask)
-		pdev->dev.dma_mask = &vt8500_ehci_dma_mask;
-
-	if (pdev->resource[1].flags != IORESOURCE_IRQ) {
-		pr_debug("resource[1] is not IORESOURCE_IRQ");
-		return -ENOMEM;
-	}
-	hcd = usb_create_hcd(&vt8500_ehci_hc_driver, &pdev->dev, "VT8500");
-	if (!hcd)
-		return -ENOMEM;
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	hcd->rsrc_start = res->start;
-	hcd->rsrc_len = resource_size(res);
-
-	hcd->regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(hcd->regs)) {
-		ret = PTR_ERR(hcd->regs);
-		goto err1;
-	}
-
-	ehci = hcd_to_ehci(hcd);
-	ehci->caps = hcd->regs;
-
-	ret = usb_add_hcd(hcd, pdev->resource[1].start,
-			  IRQF_SHARED);
-	if (ret == 0) {
-		platform_set_drvdata(pdev, hcd);
-		return ret;
-	}
-
-err1:
-	usb_put_hcd(hcd);
-	return ret;
-}
-
-static int vt8500_ehci_drv_remove(struct platform_device *pdev)
-{
-	struct usb_hcd *hcd = platform_get_drvdata(pdev);
-
-	usb_remove_hcd(hcd);
-	usb_put_hcd(hcd);
-	platform_set_drvdata(pdev, NULL);
-
-	return 0;
-}
-
-static const struct of_device_id vt8500_ehci_ids[] = {
-	{ .compatible = "via,vt8500-ehci", },
-	{ .compatible = "wm,prizm-ehci", },
-	{}
-};
-
-static struct platform_driver vt8500_ehci_driver = {
-	.probe		= vt8500_ehci_drv_probe,
-	.remove		= vt8500_ehci_drv_remove,
-	.shutdown	= usb_hcd_platform_shutdown,
-	.driver = {
-		.name	= "vt8500-ehci",
-		.owner	= THIS_MODULE,
-		.of_match_table = of_match_ptr(vt8500_ehci_ids),
-	}
-};
-
-MODULE_ALIAS("platform:vt8500-ehci");
-MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> I just got an automated message from Greg:
> 
> --------------------------------------------------------------------------
> This is a note to let you know that I've just added the patch titled
> 
>     USB: EHCI: split ehci-omap out to a separate driver
> 
> to my usb git tree which can be found at
>     git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> in the usb-next branch.
> --------------------------------------------------------------------------
> 
> Unless something is changed, this patch won't get into 3.9-final.  
> Do you want Greg to move it to his usb-linus branch?

I don't care much which way we do it, but I'd certainly like to
see one of these two solutions for the bug:

a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
   for generic bus glue" patch on top after it has been tested
b) Apply my "USB: EHCI: hot-fix OMAP and Orion multiplatform config"
   when I send a version based on the proper tree for 3.9, and leave
   the other ones to do it properly for 3.10.

	Arnd

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Sergei Shtylyov wrote:
> >
> > a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
> >     for generic bus glue" patch on top after it has been tested
> 
>     Arnd, sorry, where can I find this patch? Archive search doesn't 
> turn up anything...

It's in this email thread, in one of my earlier replies to Alan. Since
Greg already said that he won't take Roger's patch for 3.9, taking
this one would be pointless as well. I can resubmit it for 3.10
once we know what to do about my hot-fix.

	Arnd

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Greg Kroah-Hartman wrote:
> > Unless something is changed, this patch won't get into 3.9-final.  
> > Do you want Greg to move it to his usb-linus branch?
> 
> It's a bit too "big" for 3.9-final, sorry.

Would you consider the hot fix at the start of this thread for 3.9
then? I can resubmit it as a patch for inclusion with the missing
hunk added in if there are no objections.

	Arnd

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Sergei Shtylyov]

Hello.

On 03/15/2013 11:15 PM, Arnd Bergmann wrote:

> On Friday 15 March 2013, Alan Stern wrote:
>> I just got an automated message from Greg:
>>
>> --------------------------------------------------------------------------
>> This is a note to let you know that I've just added the patch titled
>>
>>      USB: EHCI: split ehci-omap out to a separate driver
>>
>> to my usb git tree which can be found at
>>      git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>> in the usb-next branch.
>> --------------------------------------------------------------------------
>>
>> Unless something is changed, this patch won't get into 3.9-final.
>> Do you want Greg to move it to his usb-linus branch?
> I don't care much which way we do it, but I'd certainly like to
> see one of these two solutions for the bug:
>
> a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
>     for generic bus glue" patch on top after it has been tested

    Arnd, sorry, where can I find this patch? Archive search doesn't 
turn up anything...

WBR, Sergei

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Sergei Shtylyov]

Hello.

On 03/16/2013 12:11 AM, Arnd Bergmann wrote:

> On Friday 15 March 2013, Sergei Shtylyov wrote:
>>> a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
>>>      for generic bus glue" patch on top after it has been tested
>>      Arnd, sorry, where can I find this patch? Archive search doesn't
>> turn up anything...
> It's in this email thread, in one of my earlier replies to Alan.

    Ah, found it now. I thought however that it already handles the DT 
properties for the EHCI platform data.
Of course, that can be added later...

WBR, Sergei

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Greg Kroah-Hartman]

On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote:
> On Friday 15 March 2013, Greg Kroah-Hartman wrote:
> > > Unless something is changed, this patch won't get into 3.9-final.  
> > > Do you want Greg to move it to his usb-linus branch?
> > 
> > It's a bit too "big" for 3.9-final, sorry.
> 
> Would you consider the hot fix at the start of this thread for 3.9
> then? I can resubmit it as a patch for inclusion with the missing
> hunk added in if there are no objections.

Feel free to resend, but remember, I am _very_ leery of pushing this
type of patch in at the moment, given my past history with it...

greg k-h

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Saturday 16 March 2013, Greg Kroah-Hartman wrote:
> On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote:
> > On Friday 15 March 2013, Greg Kroah-Hartman wrote:
> > > > Unless something is changed, this patch won't get into 3.9-final.  
> > > > Do you want Greg to move it to his usb-linus branch?
> > > 
> > > It's a bit too "big" for 3.9-final, sorry.
> > 
> > Would you consider the hot fix at the start of this thread for 3.9
> > then? I can resubmit it as a patch for inclusion with the missing
> > hunk added in if there are no objections.
> 
> Feel free to resend, but remember, I am very leery of pushing this
> type of patch in at the moment, given my past history with it...

Sure, it's your decision. I just don't want to be accused of abandoning the
issue that I caused. It's not strictly a regression because no configuration
that was working in 3.8 is broken in 3.9, and embedded systems won't normally
run a multiplatform kernel anyway. Also, the patch is really an ugly hack,
which is probably enough reason not to take it. ;-)

The only situation I can think of that is broken without the hotfix is
distribution kernels that were already running multiplatform on Armada XP
(mvebu/orion) and now want to add OMAP support without breaking the
platforms that are already working. Peter Robinson is doing this on for
Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo
people will be in a similar situation, but they can all apply the patch
manually if it doesn't make it into 3.9. It won't be the only patch they
need to get there, it's just the only one for 3.9 we already know about.

	Arnd

[1] https://plus.google.com/117898952501074015902/posts/VgnDhJBxbU4

[PATCH v2] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

A number of ARM platforms were changed in linux-3.9 so they can be enabled
at a single kernel configuration. Unfortunately, the necessary changes for
the EHCI driver were not ready in time and the first attempt to split out
the EHCI bus glues into separate modules had to get reverted before the
merge window.

This means we are still stuck with a situation where enabling any
combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
platforms at the same time leaves us with an EHCI driver that does
not work properly and spits out this build warning:

ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
In file included from ehci-hcd.c:1256:0:
ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used [-Wunused-variable]
In file included from ehci-hcd.c:1276:0:
ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition

This is the simplest patch I could come up with that will restore some
sanity in multiplatform configuration and allow us to build an ARM
allyesconfig kernel. Disallowing the broken configuration in Kconfig
would actually end up in a larger patch and more regression potential
than this one.

We had a similar situation in 3.8 with a conflict between Orion and MXC,
and Alan Stern objected to the simple hack back then and instead provided
a better full conversion of the MXC backend in patch dba63b2f7. A proper
patch for OMAP was submitted in January but also did not make it into 3.9,
see https://patchwork.kernel.org/patch/2055131.

I expect that for 3.10 we will be able to do this correctly and
turn all ARM bus glues into separate modules, ripping out the
code that this patch changes.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Andrew Lunn <andrew@lunn.ch>
CC: Jason Cooper <jason@lakedaemon.net>
---
changes since RFC v1:

* fix ORION_PLATFORM_DRIVER registration
* rebase on top of usb-linus branch

  drivers/usb/host/ehci-hcd.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 416a6dc..f98f2a2 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1253,7 +1253,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_USB_EHCI_HCD_OMAP
 #include "ehci-omap.c"
-#define        PLATFORM_DRIVER         ehci_hcd_omap_driver
+#define	OMAP_PLATFORM_DRIVER	ehci_hcd_omap_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1273,7 +1273,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_ORION
 #include "ehci-orion.c"
-#define	PLATFORM_DRIVER		ehci_orion_driver
+#define	ORION_PLATFORM_DRIVER	ehci_orion_driver
 #endif
 
 #ifdef CONFIG_USB_W90X900_EHCI
@@ -1385,6 +1385,12 @@ static int __init ehci_hcd_init(void)
 		goto clean0;
 #endif
 
+#ifdef ORION_PLATFORM_DRIVER
+	retval = platform_driver_register(&ORION_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto clean1;
+#endif
+
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	retval = ps3_ehci_driver_register(&PS3_SYSTEM_BUS_DRIVER);
 	if (retval < 0)
@@ -1402,10 +1408,20 @@ static int __init ehci_hcd_init(void)
 	if (retval < 0)
 		goto clean4;
 #endif
+
+#ifdef OMAP_PLATFORM_DRIVER
+	retval = platform_driver_register(&OMAP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto clean5;
+#endif
 	return retval;
 
+#ifdef OMAP_PLATFORM_DRIVER
+	/* platform_driver_unregister(&OMAP_PLATFORM_DRIVER); */
+clean5:
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
-	/* platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER); */
+	platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 clean4:
 #endif
 #ifdef OF_PLATFORM_DRIVER
@@ -1416,6 +1432,10 @@ clean3:
 	ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 clean2:
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 clean0:
@@ -1432,12 +1452,18 @@ module_init(ehci_hcd_init);
 
 static void __exit ehci_hcd_cleanup(void)
 {
+#ifdef OMAP_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP_PLATFORM_DRIVER);
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
 	platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 #endif
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> > Instead of adding these tests for non-NULL pdata all over the place, 
> > you could define a static structure with default settings and store a 
> > pointer to it if pdata wasn't set initially.
> 
> Yes, good idea. Here is a new version. Maybe Alexey or Tony can verify if
> that works for them on wm8850. That should be independent of the decision
> into which kernel to merge this patch.

On the whole this looks good (and a lot nicer than the first version).  
However there is one bug...

> +static struct usb_ehci_pdata ehci_platform_defaults;
> +
>  static int ehci_platform_probe(struct platform_device *dev)
>  {
>  	struct usb_hcd *hcd;
>  	struct resource *res_mem;
> -	struct usb_ehci_pdata *pdata = dev->dev.platform_data;
> +	struct usb_ehci_pdata *pdata;
>  	int irq;
>  	int err = -ENOMEM;
>  
> -	if (!pdata) {
> -		WARN_ON(1);
> -		return -ENODEV;
> -	}
> -
>  	if (usb_disabled())
>  		return -ENODEV;
>  
> +	if (!dev->dev.platform_data) {
> +		dev->dev.platform_data = &ehci_platform_defaults;

If the ehci-platform module is unloaded and then reloaded at a
different address, the stale pointer will cause an invalid memory
reference.  ehci_platform_remove() needs to set dev->dev.platform_data
back to NULL if it is equal to &ehci_platform_defaults.

Once that is fixed, you can add

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnaud Patard (Rtp)]

Arnd Bergmann <arnd@arndb.de> writes:

Hi,

> On Saturday 16 March 2013, Greg Kroah-Hartman wrote:
>> On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote:
>> > On Friday 15 March 2013, Greg Kroah-Hartman wrote:
>> > > > Unless something is changed, this patch won't get into 3.9-final.  
>> > > > Do you want Greg to move it to his usb-linus branch?
>> > > 
>> > > It's a bit too "big" for 3.9-final, sorry.
>> > 
>> > Would you consider the hot fix at the start of this thread for 3.9
>> > then? I can resubmit it as a patch for inclusion with the missing
>> > hunk added in if there are no objections.
>> 
>> Feel free to resend, but remember, I am very leery of pushing this
>> type of patch in at the moment, given my past history with it...
>
> Sure, it's your decision. I just don't want to be accused of abandoning the
> issue that I caused. It's not strictly a regression because no configuration
> that was working in 3.8 is broken in 3.9, and embedded systems won't normally
> run a multiplatform kernel anyway. Also, the patch is really an ugly hack,
> which is probably enough reason not to take it. ;-)

Given that the omap patch has been accepted and that the patch is an
"ugly hack", how hard it would be to provide a working patch for mvebu
(well, orion usb driver) ?

>
> The only situation I can think of that is broken without the hotfix is
> distribution kernels that were already running multiplatform on Armada XP
> (mvebu/orion) and now want to add OMAP support without breaking the

well, for omap, this patch may be needed too
http://marc.info/?l=linux-usb&m=136248269928419&w=2 imho (I've not
checked if it's merged now).

> platforms that are already working. Peter Robinson is doing this on for
> Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo
> people will be in a similar situation, but they can all apply the
> patch

fwiw, I've mentionned this usb issue few days ago when talking about
multiplatform on the debian-arm ml.

> manually if it doesn't make it into 3.9. It won't be the only patch they

it can applied in the debian kernel, as long as the patch is merged
upstream.

Arnaud

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Monday 18 March 2013, Arnaud Patard wrote:
> Arnd Bergmann <arnd@arndb.de> writes:

> > Sure, it's your decision. I just don't want to be accused of abandoning the
> > issue that I caused. It's not strictly a regression because no configuration
> > that was working in 3.8 is broken in 3.9, and embedded systems won't normally
> > run a multiplatform kernel anyway. Also, the patch is really an ugly hack,
> > which is probably enough reason not to take it. ;-)
> 
> Given that the omap patch has been accepted and that the patch is an
> "ugly hack", how hard it would be to provide a working patch for mvebu
> (well, orion usb driver) ?

The OMAP patch was accepted for 3.10, and I'm sure we will have good
patches for the other bus glues as well, but the bug is also present on
3.9, and the proper patches are too invasive now to get merged there.

> > platforms that are already working. Peter Robinson is doing this on for
> > Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo
> > people will be in a similar situation, but they can all apply the
> > patch
> 
> fwiw, I've mentionned this usb issue few days ago when talking about
> multiplatform on the debian-arm ml.

Yes, we've known about it for a long time, but failed to get the proper
patches out in time :(

> > manually if it doesn't make it into 3.9. It won't be the only patch they
> 
> it can applied in the debian kernel, as long as the patch is merged
> upstream.

It won't be merged in 3.10, but in that case Debian can backport the proper
patches from 3.10.

	Arnd