On 05/26, Fabien Lahoudere wrote: > Hello > > I modify ci_hrdc_imx_probe to bypass "data->phy = devm_usb_get_phy_by_phandle(&pdev->dev, > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = ulpi_register_interface(ci->dev, > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is called which is the > original function that make our system to hang. > > Our phy is not initialised before calling ulpi_register_interface so I don't understand how the phy > can reply if it is not out of reset state. I haven't see any problem in hw_phymode_configure(). What's the value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If you phy needs to be taken out of reset to reply to the ulpi reads of the vendor/product ids, then it sounds like you have a similar situation to what I had. I needed to turn on some regulators to get those reads to work, otherwise they would fail, but knowing what needed to be turned on basically meant I needed to probe the ulpi driver so probing the ids wasn't going to be useful. So on my device the reads for the ids go through, but they get all zeroes back, which is actually ok because there aren't any bits set on my devices anyway. After the reads see 0, we fallback to DT matching, which avoids the "bring it out of reset/power it on" sorts of problems entirely. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
