[PATCH v4] Move DWC2 driver out of staging

[Paul Zimmerman]

> From: Andre Heider [mailto:a.heider at gmail.com]
> Sent: Friday, January 31, 2014 11:04 AM
> 
> On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > > Hi,
> > >
> > > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > > > The DWC2 driver should now be in good enough shape to move out of
> > > > staging. I have stress tested it overnight on RPI running mass
> > > > storage and Ethernet transfers in parallel, and for several days
> > > > on our proprietary PCI-based platform.
> > > >
> > > > Signed-off-by: Paul Zimmerman <paulz at synopsys.com>
> > > > ---
> > > > v4: Also change directory path in MAINTAINERS
> > >
> > > this looks just fine, but for whatever reason it breaks sdhci on my rpi.
> > > With today's Linus' master the dwc2 controller seems to initialize fine,
> > > but I get this upon boot:
> > >
> > > [    1.783316] sdhci-bcm2835 20300000.sdhci: sdhci_pltfm_init failed -12
> > > [    1.794820] sdhci-bcm2835: probe of 20300000.sdhci failed with error -12
> > >
> > > That is:
> > >
> > > 		struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> > > 							const struct sdhci_pltfm_data *pdata,
> > > 							size_t priv_size)
> > > 		{
> > > 			...
> > >
> > > 			iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > 			if (!iomem) {
> > > 				ret = -ENOMEM;
> > > 				goto err;
> > > 			}
> > >
> > > 			...
> > >
> > > So far it's 100% reproducible. No further infos since my root device
> > > went away.  Same behavior with bcm2835_defconfig.
> > >
> > > Bisecting points to this commit, and if I move this driver back to
> > > staging (revert 197ba5f406cc) usb and sdhci are both working properly.
> > >
> > > Without the revert, this patch on top...
> > >
> > > diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> > > index d01d0d3..eaba547 100644
> > > --- a/drivers/usb/dwc2/platform.c
> > > +++ b/drivers/usb/dwc2/platform.c
> > > @@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
> > >  	int retval;
> > >  	int irq;
> > >
> > > +	if (usb_disabled())
> > > +		return -ENODEV;
> > > +
> > >  	match = of_match_device(dwc2_of_match_table, &dev->dev);
> > >  	if (match && match->data) {
> > >  		params = match->data;
> > >
> > > ...and "nousb" in the cmdline (with crashes without the patch), sdhci works
> > > again. I don't see any obvious clues, any idea what's going on?
> >
> > wait, what ? How can a driver rename cause sdhci to die ? Your error is
> > because you don't have that resource as part of your platform_device.
> >
> > -ECONFUSED. Have you really bisected it down to Paul's patch ?
> 
> This silly move doesn't trigger the sdhci ENOMEM:
> 
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> index b021c96..f739b80 100644
> --- a/arch/arm/boot/dts/bcm2835.dtsi
> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> @@ -100,6 +100,12 @@
>  			status = "disabled";
>  		};
> 
> +		usb {
> +			compatible = "brcm,bcm2835-usb";
> +			reg = <0x7e980000 0x10000>;
> +			interrupts = <1 9>;
> +		};
> +
>  		sdhci: sdhci {
>  			compatible = "brcm,bcm2835-sdhci";
>  			reg = <0x7e300000 0x100>;
> @@ -107,12 +113,6 @@
>  			clocks = <&clk_mmc>;
>  			status = "disabled";
>  		};
> -
> -		usb {
> -			compatible = "brcm,bcm2835-usb";
> -			reg = <0x7e980000 0x10000>;
> -			interrupts = <1 9>;
> -		};
>  	};
> 
>  	clocks {
> 
> Maybe there's some kind of race, or something even messing at the .dtb
> at runtime?

Hi Greg, Steve,

Would moving a USB driver from drivers/staging/ to drivers/usb/ perhaps
cause the initialization order to change? If so, maybe that has exposed
some pre-existing interference between sdhci and dwc2?

Could moving the resource in the .dts file as Andre has done also cause
the initialization order to change?

I didn't test on the RPI platform after the driver move, only on our
proprietary PCIe-based platform. I don't have my RPI with me today, so
I won't be able to debug this until the weekend.

-- 
Paul