Hi, Janusz Dziedzic <janusz.dzied...@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 :-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
