On Tue, Oct 29, 2024 at 12:22:10AM +0000, Thinh Nguyen wrote: > On Mon, Oct 28, 2024, Alan Stern wrote: > > And either way, it looks like there is a potential for races. What if > > the host puts the link into U3 just after an hid write occurs but before > > Regarding the potential race condition you mentioned, the f_hid can > track when the ->suspend() and ->resume() callbacks are called to handle > these corner cases. How it should handle that is up to the f_hid. > > > f_hid has had a chance to queue a packet informing the host? Maybe we > > need to add a flag to the usb_request structure, to let the UDC driver > > know that it should issue a wakeup signal if the request is queued while > > the link is suspended. > > > > The host will sync with the gadget via SetFeature(remote_wakeup) control > request before entering U3/L2 to enable remote wakeup, and it should > disable remote wakeup after resume. We have the flag > gadget->wakeup_armed to track that. The dwc3_gadget_wakeup() will not > trigger remote wakeup if wakeup_armed is disabled. > > > This part of the Gadget API has never been tested very much... > > > > Alan Stern > > > > The f_hid just need to properly implement the handling of remote wakeup > as Alan noted. Bart, it sounds like f_hid needs to do two things: Use a private spinlock to protect all the places where a request is submitted, if the request might cause a wakeup to occur. Also take the spinlock within the suspend and resume callbacks, to keep accurate track of whether the function is suspended. When a suspend occurs, check to see if there are any pending requests still queued that should cause a wakeup, and call usb_gadget_wakeup() if there are. And likewise if such a request is submitted while the function is suspended. Alan Stern
