kirkwood devicetree respin

[Jason Cooper]

On Tue, Mar 20, 2012 at 08:32:22PM +0100, Andrew Lunn wrote:
> On Tue, Mar 20, 2012 at 07:15:07PM +0000, Arnd Bergmann wrote:
> > On Tuesday 20 March 2012, Jason Cooper wrote:
> > > diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> > > index 6c6a5a3..0808417 100644
> > > --- a/drivers/usb/host/ehci-orion.c
> > > +++ b/drivers/usb/host/ehci-orion.c
> > > @@ -318,3 +318,5 @@ static struct platform_driver ehci_orion_driver = {
> > >         .shutdown       = usb_hcd_platform_shutdown,
> > >         .driver.name    = "orion-ehci",
> > >  };
> > > +
> > > +module_platform_driver(ehci_orion_driver);
> > > 
> > This actually looks wrong to me, because the ehci driver has an
> > interesting way of pulling in platform specific drivers.
> > 
> > I'm pretty sure that it will break modular builds, which can only
> > have one module_init function in them. It's not clear to me why this
> > patch actually fixes the problem either. Could it be that you have
> > multiple platform driver back-ends for ehci enabled at the same time?
> > 
> > That should not be possible in theory and at least give a warning, but
> > the ehci probing method is a bit fragile so I would not be too surprised.
> 
> Hi Jason
> 
> I fell fowl of something in this area. Do you have CONFIG_USB_EHCI_MV=y?
> Make sure you do not have this. 
> 
> drivers/usb/host/ehci-hcd.c has some unusual code, and if you have
> both CONFIG_USB_EHCI_MV and CONFIG_PLAT_ORION, the CONFIG_USB_EHCI_MV
> is given preference and the Orion driver never gets its probe
> functions called etc.

waddaya know?  The compile warnings went away, and the d*mn thing booted
fine.

Is there a scenario where someone would want to select
CONFIG_USB_EHCI_MV in menuconfig?

thx,

Jason.