Re: [PATCH] usb: dwc3: avoid probe deferral when USB power supply is not available

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Wed, May 06, 2026, Elson Serrao wrote:
> 
> 
> On 5/1/2026 5:55 PM, Thinh Nguyen wrote:
> > On Tue, Apr 07, 2026, Elson Serrao wrote:
> >> The dwc3 driver currently defers probe if the USB power supply is not yet
> >> registered. On some platforms, even though charging and power supply
> >> functionality is available during normal operation, there may exist
> >> minimal booting modes (such as recovery or diagnostic environments) where
> >> the relevant USB power supply device is not registered. In such cases,
> >> probe deferral prevents USB gadget operation entirely.
> >>
> >> USB data functionality for basic operation does not inherently depend on
> >> the power supply framework, which is only required for enforcing VBUS
> >> current control. The configured VBUS current limit is typically enforced
> >> through the charger or PMIC power path. When charging functionality is
> >> unavailable, applying a current limit has no practical effect, reducing
> >> the benefit of strict probe-time enforcement in these environments.
> >>
> >> Instead of deferring probe, register a power supply notifier when the
> >> USB power supply is not yet available. Cache the requested VBUS current
> >> limit and apply it once the matching power supply becomes available, as
> >> notified through the registered callback.
> >>
> > 
> > This gets a bit cumbersome now that we need to consider some corner
> > cases around the notifier callback.
> > 
> >> Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
> >> ---
> >>  drivers/usb/dwc3/core.c   | 82 ++++++++++++++++++++++++++++++++-------
> >>  drivers/usb/dwc3/core.h   |  4 ++
> >>  drivers/usb/dwc3/gadget.c | 10 ++++-
> >>  3 files changed, 80 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> >> index 161a4d58b2ce..20df0b287623 100644
> >> --- a/drivers/usb/dwc3/core.c
> >> +++ b/drivers/usb/dwc3/core.c
> >> @@ -2167,24 +2167,72 @@ static void dwc3_vbus_draw_work(struct work_struct *work)
> >>  	if (ret < 0)
> >>  		dev_dbg(dwc->dev, "Error (%d) setting vbus draw (%d mA)\n",
> >>  			ret, dwc->current_limit);
> >> +
> >> +	/* Unregister the psy notifier now that we have the power_supply reference */
> >> +	if (dwc->psy_nb.notifier_call) {
> > 
> > Is it possible for dwc3_core_remove() to happen here? If so, should we
> > do something about it?
> > 
> 
> Hi Thinh
> 
> Thanks for the review.
> 
> Yes dwc3_core_remove() could race with this path.
> 
> To simplify things, I’m planning to unregister the notifier only
> from dwc3_core_remove(), so we don’t need to handle this case here
> and the notifier lifetime remains tied to the device lifecycle.
> 
> Let me know if you’d prefer a different approach.
> 

That's fine to me. Just make sure to return early if the power supply is
registered.

<snip>

> >> +
> >> +	dwc->usb_psy = power_supply_get_by_name(dwc->usb_psy_name);
> >> +	if (!dwc->usb_psy) {
> > 
> > Is it possible for the power supply to register here?
> > 
> 
> The power_supply framework introduces a ~10 ms delay [1]
> before invoking notifiers after registration. So for the race described
> above to occur, our probe would need to stall for more than that
> duration between the initial power_supply_get_by_name() call
> and notifier registration, which seems highly unlikely under normal
> conditions.
> 
> That said, there is still a theoretical window where the power
> supply could register in that gap. If you think it's worth being
> defensive here, we could re-check power_supply_get_by_name() after
> registering the notifier and handle the case accordingly.
> 
> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/power_supply_core.c?h=v7.1-rc2*n40__;Iw!!A4F2R9G_pg!dUiPW6mibrvsk4uGO4MnGVg3R1zR3EmxxIROrw4N-ytHZq7N9q-V6irNAWrBrolUR2HABsAGSQoMPzGnEGQsvWdhzWzcVHOU$ 
> 

For my own sanity, can we have that extra check? Otherwise, every time I
scan through this I would need to recall why it wasn't needed.

Thanks,
Thinh