On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@xxxxxxxxx> wrote: > > On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote: > > > This patches causes a regression on a imx51-babbage running 4.18-rc1: > > I get a kernel hang. > > > > If I revert it on top of 4.18-rc1, then it boots fine and USB host is > > functional. > > > > I understand this patch fixes a kernel hang for you, so which commit > > is responsible for the hang you observe? > > I never assumed it was a regression and that USB worked on RDU1 board before, so I never tried to see if this was a regression. I can only tell you that it hangs as soon as any PORTSC registers are accessed. > > It seems this commit fixes a hang for you and causes another hang for me :-) > > > > Any ideas? > RDU1 design is based heavily on Babbage board, moreso USB1/ULPI portion of it is an exact copy (it does use different GPIO for PHY reset, but that's irrelevant), so I am surprised that it breaks in your case. However looking at imx51-babbage.dts, I am suspicious of it's USB1 setup. There we have usbh1phy node that references <&gpio2 5 GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg, is not being used anywhere. Cold that be that the problem you are seeing is due to USB PHY not being properly reset? > I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag: > Yeah, IMHO if you are dropping that flag, you may as well revert the whole patch :-). The path that make the kernel hang in my case would be taken if that flag is dropped. Thanks, Andrey Smirnov -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
