[PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Krishna Kurapati]

On SC7180 devices, it is observed that dwc3 probing is deferred
because device_links_check_suppliers() finds that '88e3000.phy'
isn't ready yet.

As a part of its probe call, dwc3-qcom driver checks if dwc3 core
is wakeup capable or not. If the dwc3 core is wakeup capable, driver
configures dwc-qcom's power domain to be always ON. Also it configures
dp/dm interrupts accordingly to support wakeup from system suspend.

More info regarding the same can be found at:
commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")

In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
probe, driver ends up reading the wakeup capability of dwc3 core as false
leading to instability in suspend/resume path.

To avoid this scenario, ensure dwc3_probe is successful by checking
if appropriate driver is assigned to it or not after the of_platform_populate
call. If it isn't then defer dwc3-qcom probe as well.

Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
---
 drivers/usb/dwc3/dwc3-qcom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 7703655..096d1414 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
 		dev_err(dev, "failed to get dwc3 platform device\n");
 	}
 
+	if (!qcom->dwc3->dev.driver)
+		return -EPROBE_DEFER;
+
 node_put:
 	of_node_put(dwc3_np);
 
-- 
2.7.4

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Greg Kroah-Hartman]

On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> On SC7180 devices, it is observed that dwc3 probing is deferred
> because device_links_check_suppliers() finds that '88e3000.phy'
> isn't ready yet.
> 
> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> configures dwc-qcom's power domain to be always ON. Also it configures
> dp/dm interrupts accordingly to support wakeup from system suspend.
> 
> More info regarding the same can be found at:
> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> 
> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> probe, driver ends up reading the wakeup capability of dwc3 core as false
> leading to instability in suspend/resume path.
> 
> To avoid this scenario, ensure dwc3_probe is successful by checking
> if appropriate driver is assigned to it or not after the of_platform_populate
> call. If it isn't then defer dwc3-qcom probe as well.
> 
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>  1 file changed, 3 insertions(+)

I got 2 different copies of this change, what's the difference?

confused,

greg k-h

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Krishna Kurapati PSSNV]

On 7/14/2022 8:31 PM, Greg Kroah-Hartman wrote:
> On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
>> On SC7180 devices, it is observed that dwc3 probing is deferred
>> because device_links_check_suppliers() finds that '88e3000.phy'
>> isn't ready yet.
>>
>> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
>> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
>> configures dwc-qcom's power domain to be always ON. Also it configures
>> dp/dm interrupts accordingly to support wakeup from system suspend.
>>
>> More info regarding the same can be found at:
>> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
>> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
>>
>> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
>> probe, driver ends up reading the wakeup capability of dwc3 core as false
>> leading to instability in suspend/resume path.
>>
>> To avoid this scenario, ensure dwc3_probe is successful by checking
>> if appropriate driver is assigned to it or not after the of_platform_populate
>> call. If it isn't then defer dwc3-qcom probe as well.
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> ---
>>   drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>>   1 file changed, 3 insertions(+)
> I got 2 different copies of this change, what's the difference?
>
> confused,
>
> greg k-h
Sorry Greg, My bad, I thought the mail sending failed the first time. So 
I sent the same patch second time. Sorry for the confusion.
Regards,
Krishna,

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Greg Kroah-Hartman]

On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> On SC7180 devices, it is observed that dwc3 probing is deferred
> because device_links_check_suppliers() finds that '88e3000.phy'
> isn't ready yet.
> 
> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> configures dwc-qcom's power domain to be always ON. Also it configures
> dp/dm interrupts accordingly to support wakeup from system suspend.
> 
> More info regarding the same can be found at:
> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> 
> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> probe, driver ends up reading the wakeup capability of dwc3 core as false
> leading to instability in suspend/resume path.
> 
> To avoid this scenario, ensure dwc3_probe is successful by checking
> if appropriate driver is assigned to it or not after the of_platform_populate
> call. If it isn't then defer dwc3-qcom probe as well.
> 
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 7703655..096d1414 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
>  		dev_err(dev, "failed to get dwc3 platform device\n");
>  	}
>  
> +	if (!qcom->dwc3->dev.driver)
> +		return -EPROBE_DEFER;
> +

Why not limit this check to a device type like your changelog mentions?

thanks,

greg k-h

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Krishna Kurapati PSSNV]

On 7/14/2022 8:32 PM, Greg Kroah-Hartman wrote:
> On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
>> On SC7180 devices, it is observed that dwc3 probing is deferred
>> because device_links_check_suppliers() finds that '88e3000.phy'
>> isn't ready yet.
>>
>> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
>> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
>> configures dwc-qcom's power domain to be always ON. Also it configures
>> dp/dm interrupts accordingly to support wakeup from system suspend.
>>
>> More info regarding the same can be found at:
>> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
>> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
>>
>> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
>> probe, driver ends up reading the wakeup capability of dwc3 core as false
>> leading to instability in suspend/resume path.
>>
>> To avoid this scenario, ensure dwc3_probe is successful by checking
>> if appropriate driver is assigned to it or not after the of_platform_populate
>> call. If it isn't then defer dwc3-qcom probe as well.
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> ---
>>   drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>> index 7703655..096d1414 100644
>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
>>   		dev_err(dev, "failed to get dwc3 platform device\n");
>>   	}
>>   
>> +	if (!qcom->dwc3->dev.driver)
>> +		return -EPROBE_DEFER;
>> +
> Why not limit this check to a device type like your changelog mentions?
>
> thanks,
>
> greg k-h
Hi Greg,

I wanted to make it common to any device using this driver. Although on 
devices
ike SC7280,this issue is not seen but the code would hold good. Do you 
see any
concerns if we do it this way ?

Thanks,
Krishna,

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Greg Kroah-Hartman]

On Thu, Jul 14, 2022 at 08:39:31PM +0530, Krishna Kurapati PSSNV wrote:
> 
> On 7/14/2022 8:32 PM, Greg Kroah-Hartman wrote:
> > On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> > > On SC7180 devices, it is observed that dwc3 probing is deferred
> > > because device_links_check_suppliers() finds that '88e3000.phy'
> > > isn't ready yet.
> > > 
> > > As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> > > is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> > > configures dwc-qcom's power domain to be always ON. Also it configures
> > > dp/dm interrupts accordingly to support wakeup from system suspend.
> > > 
> > > More info regarding the same can be found at:
> > > commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> > > commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> > > 
> > > In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> > > probe, driver ends up reading the wakeup capability of dwc3 core as false
> > > leading to instability in suspend/resume path.
> > > 
> > > To avoid this scenario, ensure dwc3_probe is successful by checking
> > > if appropriate driver is assigned to it or not after the of_platform_populate
> > > call. If it isn't then defer dwc3-qcom probe as well.
> > > 
> > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> > > ---
> > >   drivers/usb/dwc3/dwc3-qcom.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > > index 7703655..096d1414 100644
> > > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > > @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
> > >   		dev_err(dev, "failed to get dwc3 platform device\n");
> > >   	}
> > > +	if (!qcom->dwc3->dev.driver)
> > > +		return -EPROBE_DEFER;
> > > +
> > Why not limit this check to a device type like your changelog mentions?
> > 
> > thanks,
> > 
> > greg k-h
> Hi Greg,
> 
> I wanted to make it common to any device using this driver. Although on
> devices
> ike SC7280,this issue is not seen but the code would hold good. Do you see
> any
> concerns if we do it this way ?

How many different types of hardware did you test this change on and
what was the results?

thanks,

greg k-h

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Krishna Kurapati PSSNV]

On 7/14/2022 8:58 PM, Greg Kroah-Hartman wrote:
> On Thu, Jul 14, 2022 at 08:39:31PM +0530, Krishna Kurapati PSSNV wrote:
>> On 7/14/2022 8:32 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
>>>> On SC7180 devices, it is observed that dwc3 probing is deferred
>>>> because device_links_check_suppliers() finds that '88e3000.phy'
>>>> isn't ready yet.
>>>>
>>>> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
>>>> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
>>>> configures dwc-qcom's power domain to be always ON. Also it configures
>>>> dp/dm interrupts accordingly to support wakeup from system suspend.
>>>>
>>>> More info regarding the same can be found at:
>>>> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
>>>> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
>>>>
>>>> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
>>>> probe, driver ends up reading the wakeup capability of dwc3 core as false
>>>> leading to instability in suspend/resume path.
>>>>
>>>> To avoid this scenario, ensure dwc3_probe is successful by checking
>>>> if appropriate driver is assigned to it or not after the of_platform_populate
>>>> call. If it isn't then defer dwc3-qcom probe as well.
>>>>
>>>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>>>> ---
>>>>    drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>>>> index 7703655..096d1414 100644
>>>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>>>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>>>> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
>>>>    		dev_err(dev, "failed to get dwc3 platform device\n");
>>>>    	}
>>>> +	if (!qcom->dwc3->dev.driver)
>>>> +		return -EPROBE_DEFER;
>>>> +
>>> Why not limit this check to a device type like your changelog mentions?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Hi Greg,
>>
>> I wanted to make it common to any device using this driver. Although on
>> devices
>> ike SC7280,this issue is not seen but the code would hold good. Do you see
>> any
>> concerns if we do it this way ?
> How many different types of hardware did you test this change on and
> what was the results?
>
> thanks,
>
> greg k-h
Hi Greg,

   I tested only on SC7180 and SC7280 devices. It was working on SC7280, 
(the first run of of_platform_populate made sure dwc3 probe is done).
On SC7180, during the first run of dwc3-qcom probe, we observed dwc3 
probe getting deferred after of_platform_populate.
As you suggested, I can try and check on other devices using this driver 
and confirm if only SC7180 has this issue. 🙂

Thanks,
Krishna,

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Matthias Kaehlcke]

On Thu, Jul 14, 2022 at 05:02:09PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> > On SC7180 devices, it is observed that dwc3 probing is deferred
> > because device_links_check_suppliers() finds that '88e3000.phy'
> > isn't ready yet.
> > 
> > As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> > is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> > configures dwc-qcom's power domain to be always ON. Also it configures
> > dp/dm interrupts accordingly to support wakeup from system suspend.
> > 
> > More info regarding the same can be found at:
> > commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> > commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> > 
> > In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> > probe, driver ends up reading the wakeup capability of dwc3 core as false
> > leading to instability in suspend/resume path.
> > 
> > To avoid this scenario, ensure dwc3_probe is successful by checking
> > if appropriate driver is assigned to it or not after the of_platform_populate
> > call. If it isn't then defer dwc3-qcom probe as well.
> > 
> > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> > ---
> >  drivers/usb/dwc3/dwc3-qcom.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > index 7703655..096d1414 100644
> > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
> >  		dev_err(dev, "failed to get dwc3 platform device\n");
> >  	}
> >  
> > +	if (!qcom->dwc3->dev.driver)
> > +		return -EPROBE_DEFER;
> > +
> 
> Why not limit this check to a device type like your changelog mentions?

It is not an sc7180 specific issue. It can occur on any platform where the
dwc3 core has supplies that aren't ready when the dwc3-qcom driver probes.

It won't blow up right away since it requires 'wakeup-source' to be set for
the dwc3 core, which currently is only the case for 'usb@a600000' of the
sc7280 AFAIK (I set it for sc7180 in my tree for testing, which is when I
found the issue this patch intends to address).

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Greg Kroah-Hartman]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Jul 27, 2022 at 02:56:06PM +0530, Krishna Kurapati PSSNV wrote:
> Hi Greg,
> 
>   As Mathias pointed out in another thread, no issue was seen so far on
> present QC targets as wakeup-source property was added recently and only for
> SC7180 and SC7280. We ran into some issues like wakeup from system suspend
> in host mode wasn't happening although we enabled wakeup-source in SC7180
> that eventually led us to this bug. But i tried to add debug prints to
> follow the code flow and see that the issue is present on SM8350 as well :
> *"supplier 88e9000.phy-wrapper not ready" *and deferring dwc3 probe.**This
> doesn't seem to be specific to SC7180.

I have no context here at all, sorry.

Remember, some of us get thousands of emails a week to handle and
review.  I don't know what other thread you are talking about, nor what
the issue here is at all, nor even what the patch is.

totally confused,

greg k-h

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Greg Kroah-Hartman]

On Wed, Jul 27, 2022 at 03:03:01PM +0530, Pratham Pratap wrote:

<snip>

Please note that html email is not allowed on kernel mailing lists and
the messages are thrown away, so no one can see them :(

Please fix your email client so that you can participate in kernel
development.

thanks,

greg k-h

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Matthias Kaehlcke]

On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> On SC7180 devices, it is observed that dwc3 probing is deferred
> because device_links_check_suppliers() finds that '88e3000.phy'
> isn't ready yet.
> 
> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> configures dwc-qcom's power domain to be always ON. Also it configures
> dp/dm interrupts accordingly to support wakeup from system suspend.
> 
> More info regarding the same can be found at:
> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> 
> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> probe, driver ends up reading the wakeup capability of dwc3 core as false
> leading to instability in suspend/resume path.
> 
> To avoid this scenario, ensure dwc3_probe is successful by checking
> if appropriate driver is assigned to it or not after the of_platform_populate
> call. If it isn't then defer dwc3-qcom probe as well.
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>

Fixes: 649f5c842ba3 ("usb: dwc3: core: Host wake up support from system suspend")

> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 7703655..096d1414 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
>  		dev_err(dev, "failed to get dwc3 platform device\n");
>  	}
>  
> +	if (!qcom->dwc3->dev.driver)
> +		return -EPROBE_DEFER;

change this to:

		ret = -EPROBE_DEFER;

to put 'dwc3_np'

> +
>  node_put:
>  	of_node_put(dwc3_np);
>  
> -- 
> 2.7.4
> 

Re: [PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Pavan Kondeti]

On Thu, Jul 14, 2022 at 08:25:16PM +0530, Krishna Kurapati wrote:
> On SC7180 devices, it is observed that dwc3 probing is deferred
> because device_links_check_suppliers() finds that '88e3000.phy'
> isn't ready yet.
> 
> As a part of its probe call, dwc3-qcom driver checks if dwc3 core
> is wakeup capable or not. If the dwc3 core is wakeup capable, driver
> configures dwc-qcom's power domain to be always ON. Also it configures
> dp/dm interrupts accordingly to support wakeup from system suspend.
> 
> More info regarding the same can be found at:
> commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
> commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> 
> In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
> probe, driver ends up reading the wakeup capability of dwc3 core as false
> leading to instability in suspend/resume path.
> 
> To avoid this scenario, ensure dwc3_probe is successful by checking
> if appropriate driver is assigned to it or not after the of_platform_populate
> call. If it isn't then defer dwc3-qcom probe as well.
> 
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 7703655..096d1414 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
>  		dev_err(dev, "failed to get dwc3 platform device\n");
>  	}
>  
> +	if (!qcom->dwc3->dev.driver)
> +		return -EPROBE_DEFER;
> +

you need to drop the dwc3 node reference, so set ret = -EPROBE_DEFER here
instead of returning.

>  node_put:
>  	of_node_put(dwc3_np);
>  
> -- 
> 2.7.4
> 

Thanks,
Pavan

[PATCH] usb: dwc3: qcom: Defer dwc3-qcom probe if dwc3 isn't probed properly

[Krishna Kurapati]

On SC7180 devices, it is observed that dwc3 probing is deferred
because device_links_check_suppliers() finds that '88e3000.phy'
isn't ready yet.

As a part of its probe call, dwc3-qcom driver checks if dwc3 core
is wakeup capable or not. If the dwc3 core is wakeup capable, driver
configures dwc-qcom's power domain to be always ON. Also it configures
dp/dm interrupts accordingly to support wakeup from system suspend.

More info regarding the same can be found at:
commit d9be8d5c5b03 ("usb: dwc3: qcom: Keep power domain on to retain controller status"
commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")

In the event, dwc3 probe gets deferred and is processed after dwc3-qcom
probe, driver ends up reading the wakeup capability of dwc3 core as false
leading to instability in suspend/resume path.

To avoid this scenario, ensure dwc3_probe is successful by checking
if appropriate driver is assigned to it or not after the of_platform_populate
call. If it isn't then defer dwc3-qcom probe as well.

Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
---
 drivers/usb/dwc3/dwc3-qcom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 7703655..096d1414 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device *pdev)
 		dev_err(dev, "failed to get dwc3 platform device\n");
 	}
 
+	if (!qcom->dwc3->dev.driver)
+		return -EPROBE_DEFER;
+
 node_put:
 	of_node_put(dwc3_np);
 
-- 
2.7.4