Re: [PATCH] usb: dwc3: gadget: Disable gadget IRQ during pullup disable

[Wesley Cheng]

On 6/10/2021 4:09 AM, Felipe Balbi wrote:
> Wesley Cheng <wcheng@xxxxxxxxxxxxxx> writes:
> 
>> Current sequence utilizes dwc3_gadget_disable_irq() alongside
>> synchronize_irq() to ensure that no further DWC3 events are generated.
>> However, the dwc3_gadget_disable_irq() API only disables device
>> specific events.  Endpoint events can still be generated.  Briefly
>> disable the interrupt line, so that the cleanup code can run to
>> prevent device and endpoint events. (i.e. __dwc3_gadget_stop() and
>> dwc3_stop_active_transfers() respectively)
>>
>> Without doing so, it can lead to both the interrupt handler and the
>> pullup disable routine both writing to the GEVNTCOUNT register, which
>> will cause an incorrect count being read from future interrupts.
>>
>> Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the controller")
>> Signed-off-by: Wesley Cheng <wcheng@xxxxxxxxxxxxxx>
>> ---
>>  drivers/usb/dwc3/gadget.c | 11 +++++------
>>  1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 49ca5da..89aa9ac 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -2260,13 +2260,10 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>>  	}
>>  
>>  	/*
>> -	 * Synchronize any pending event handling before executing the controller
>> -	 * halt routine.
>> +	 * Synchronize and disable any further event handling while controller
>> +	 * is being enabled/disabled.
>>  	 */
>> -	if (!is_on) {
>> -		dwc3_gadget_disable_irq(dwc);
>> -		synchronize_irq(dwc->irq_gadget);
>> -	}
>> +	disable_irq(dwc->irq_gadget);
>>  
>>  	spin_lock_irqsave(&dwc->lock, flags);
> 
> spin_lock_irqsave() is already disabling interrupt, right? Why do we
> need another call to disable_irq()?
> 

Hi Felipe,

Yes, I remember you brought up that point as well before.  So when I
checked the logs (USB and scheduler ftrace) for this issue, I clearly
saw that we were handling a soft disconnect on CPU3 and then an DWC3 IRQ
being scheduled into CPU0.  Last time we discussed, I mentioned that
spin_lock_irqsave() only disables interrupts on that particular CPU the
thread is running on.

Thanks
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project