Hi, Nicolas Saenz Julienne <[email protected]> writes: > __dwc3_gadget_wakeup() is called while holding a spinlock, then depends on > jiffies in order to timeout while polling the USB core for a link state > update. In the case the wakeup failed, the timeout will never happen and > will also cause the cpu to stall until rcu_preempt kicks in. > > This switches to a "decrement variable and wait" timeout scheme. > > Signed-off-by: Nicolas Saenz Julienne <[email protected]> > --- > drivers/usb/dwc3/gadget.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 8f8c215..d0c711f 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -1433,7 +1433,7 @@ static int dwc3_gadget_get_frame(struct usb_gadget *g) > > static int __dwc3_gadget_wakeup(struct dwc3 *dwc) > { > - unsigned long timeout; > + int retries; > > int ret; > u32 reg; > @@ -1484,14 +1484,16 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc) > } > > /* poll until Link State changes to ON */ > - timeout = jiffies + msecs_to_jiffies(100); > + retries = 20000; > > - while (!time_after(jiffies, timeout)) { > + while (retries--) { > reg = dwc3_readl(dwc->regs, DWC3_DSTS); > > /* in HS, means ON */ > if (DWC3_DSTS_USBLNKST(reg) == DWC3_LINK_STATE_U0) > break; > + > + udelay(5);
let's just drop this udelay() here. It's very likely this will switch the link state much quicker than 100ms anyway. Other than that, nice catch :-) -- balbi
signature.asc
Description: PGP signature
