lkml.org 
[lkml]   [2021]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] usb: dwc3: gadget: Disable gadget IRQ during pullup disable
From
Date


On 6/10/2021 4:09 AM, Felipe Balbi wrote:
> Wesley Cheng <wcheng@codeaurora.org> 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@codeaurora.org>
>> ---
>> 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

\
 
 \ /
  Last update: 2021-06-10 20:23    [W:0.090 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site