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
Attachment:
signature.asc
Description: Digital signature
