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

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

On Mon, Jun 01, 2026, Elson Serrao wrote:
> 
> 
> On 5/27/2026 4:23 PM, Thinh Nguyen wrote:
> > On Tue, May 26, 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.
> >>
> 
> [...]
> 


> 
> >> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> >> index 3d4ca68e584c..303598048e9a 100644
> >> --- a/drivers/usb/dwc3/gadget.c
> >> +++ b/drivers/usb/dwc3/gadget.c
> >> @@ -3124,15 +3124,21 @@ static void dwc3_gadget_set_ssp_rate(struct usb_gadget *g,
> >>  static int dwc3_gadget_vbus_draw(struct usb_gadget *g, unsigned int mA)
> >>  {
> >>  	struct dwc3		*dwc = gadget_to_dwc(g);
> >> +	unsigned long		flags;
> >>  
> >>  	if (dwc->usb2_phy)
> >>  		return usb_phy_set_power(dwc->usb2_phy, mA);
> >>  
> >> -	if (!dwc->usb_psy)
> >> +	spin_lock_irqsave(&dwc->lock, flags);
> >> +	dwc->current_limit = mA;
> >> +	if (!dwc->usb_psy) {
> >> +		spin_unlock_irqrestore(&dwc->lock, flags);
> >> +		dev_dbg(dwc->dev, "Stored VBUS draw: %u mA (power supply not ready)\n", mA);
> > 
> > Can we use the check if dwc->psy_nb.notifier_block is set to determine
> > if we expect to have a power_supply? Then we can print the message above
> > when it's really not ready, and only return -EOPNOTSUPP if we really
> > don't have a power_supply.
> > 
> Hi Thinh,
> 
> Just to clarify, in the case where dwc->psy_nb.notifier_call is set
> (i.e., we expect the power_supply but it is not available yet), should we
> return 0 and treat it as success since the current limit is cached and
> will be applied later?

Yes, just return 0.

> 
> Or would you prefer returning an error (e.g., -ENODEV) to indicate to
> composite/upper layers that the current limit was not applied immediately
> (in case they need to observe this state)?
> 
> Currently, we update gadget->mA only if this gadget op returns success.
> Returning 0 in this case would update gadget->mA even though the limit
> has not yet been applied.
> 

The dwc->current_limit is updated unconditionally when
usb_gadget_vbus_draw() is called. The gadget->mA should also be updated
and be in sync with the cached value dwc->current_limit. Otherwise, the
gadget->mA will be stale when the notifier update the power supply
after.

BR,
Thinh