Hi,
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.
Or there is a reason to use irqsave() version?
see above :-)