> From: Andre Heider [mailto:a.hei...@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 <pa...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
