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

[Elson Serrao <elson.serrao@oss.qualcomm.com>]

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.
>>

[...]


>> +	}
>> +
>> +	dwc->usb_psy = psy;
>> +	if (dwc->current_limit != UINT_MAX)
> 
> Create a macro for these kinds of checks for readability:
> 
> #define DWC3_CURRENT_UNSPECIFIED UINT_MAX
> 
Ack.

[...]

>> 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?

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.

Thanks,
Elson
>>  		return -EOPNOTSUPP;
>> +	}
>>  
>> -	dwc->current_limit = mA;
>>  	schedule_work(&dwc->vbus_draw_work);
>> +	spin_unlock_irqrestore(&dwc->lock, flags);
>>  
>>  	return 0;
>>  }
>> -- 
>> 2.34.1
>>
> 
> The rest looks good to me.
> 
> Thanks,
> Thinh