[v2,RESEND] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

[Felipe Balbi <balbi@kernel.org>]

Hi,

Todor Tomov <todor.tomov@linaro.org> writes:
>>>>> After I apply this patch on 4.14 (or receive it with 4.14.70) I see a regression with
>>>>> the Qualcomm QUSB2 phy driver. I'm testing on a Dragonboard 820c.
>>>>> In boot log I get:
>>>>>
>>>>> [    4.525502] phy phy-7412000.phy.6: QUSB2PHY pll lock failed: status reg = 0
>>>>> [    4.529232] phy phy-7412000.phy.6: phy init failed --> -16
>>>>> [    4.536170] dwc3 7600000.dwc3: failed to initialize core
>>>>> [    4.541743] dwc3: probe of 7600000.dwc3 failed with error -16
>>>>> [    4.549979] phy phy-7411000.phy.5: QUSB2PHY pll lock failed: status reg = 0
>>>>> [    4.552843] phy phy-7411000.phy.5: phy init failed --> -16
>>>>> [    4.559606] dwc3 6a00000.dwc3: failed to initialize core
>>>>> [    4.565181] dwc3: probe of 6a00000.dwc3 failed with error -16
>>>>>
>>>>> I can provide a full log if needed.
>>>>
>>>> please do. Also, try mainline and let us know if the problem
>>>
>>> This is the full log on 4.14.69 + this patch: https://paste.ubuntu.com/p/N5WdHw47QC/
>>> I also managed to get a log from 4.20.0-rc2 and I see the same error: https://paste.udwc3_phy_setupbuntu.com/p/jz6fvYyZh6/
>>>
>>>> persists. Why do you get -EBUSY from the PHY driver?
>>>
>>> Maybe I could have proposed a fix if I knew but I don't know.
>> 
>> I have done some debugging but I still cannot understand it completely.
>> 
>> What I see is that if the PHY interface is configured first (dwc3_phy_setup)
>> then the PHY init (qusb2_phy_init called by dwc3_core_soft_reset) fails
>> with "pll lock failed". If we move dwc3_phy_setup after dwc3_core_soft_reset
>> as it was before this patch, it works.
>
> I have found that during dwc3_phy_setup the PHY interface is configured
> to suspend and this is what breaks the QUSB2 PHY initialization.
> It seems that it can be fixed by adding the "snps,dis_u2_susphy_quirk"
> quirk in device tree. If this approach proves correct, I'll send the
> patch upstream.

That's the correct way, yes.

Thanks