On Tue, Oct 29, 2024 at 6:26 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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 Hi Alan and Thinh, Apologies for this late answer. Thanks for your valued inputs, I have a better view now on how to implement remote wakeup in a better way. I'll try to find some time to implement it, but it'll probably take some time given high workload. Best regards, Bart Van Severen
