Hi John,
On 6 January 2017 at 03:08, John Youn John.Youn@synopsys.com wrote:
On 12/28/2016 5:29 PM, John Youn wrote:
Janusz Dziedzic janusz.dziedzic@gmail.com writes:
> On some platfroms(like x86 platform), when one core is running the
USB gadget
> irq thread handler by dwc3_thread_interrupt(), meanwhile another
core also can
> respond other interrupts from dwc3 controller and modify the event
buffer by
> dwc3_interrupt() function, that will cause getting the wrong event
count in
> irq thread handler to make the USB function abnormal. > > We should add spin_lock/unlock() in dwc3_check_event_buf() to avoid
this race.
Why not spin_lock_irq ones? This lock seems to be used in both normal and interrupt threads. Or, I missed anything?
this is top half handler. Interrupts are already disabled.
BTW, We don't use spin_lock in top half handler. Maybe we should/can switch all spin_lock_irqsave() to simple spin_lock() in the thread/callbacks?
in theory, yes we've masked all interrupts from this controller for the duration of the thread handler. However this breaks networking gadgets. I can only guess network stack has a hard requirement to run with IRQs disabled.
Hi,
Is this version 3.00a of the core?
That version has a STAR where the interrupts cannot be masked. That results in similar symptoms to what you're seeing here.
Sorry for late reply. The version is 2.80a.
Regards, John
Didn't see any response to this. Just want to make sure this possibility is addressed as there is a workaround for it on mainline.
Thanks for reminding.
See the following commits for details:
d9fa4c63f766 ("usb: dwc3: core: add a event buffer cache") ebbb2d59398f ("usb: dwc3: gadget: use evt->cache for processing events") 65aca3205046 ("usb: dwc3: gadget: clear events in top-half handler") cf40b86b6ef6 ("usb: dwc3: Implement interrupt moderation") 28632b44d129 ("usb: dwc3: Workaround for irq mask issue")