On Fri, 2014-09-05 at 10:15 -0400, Alan Stern wrote: > On Fri, 5 Sep 2014, Oliver Neukum wrote: > > > Hi, > > > > looking at your patch for resetting HID devices > > it occurred to me that there's a race between > > a queued reset and a port power switch. Switching > > a port's power state implies to a reset for for > > all interfaces of the device connected to that port. > > > > As a reset is quite disruptive it seems to me that > > no calling off a queued reset is a bug. > > What do you think? > > There shouldn't be a race. We never power-off a port unless the > attached device is already runtime suspended. A runtime-suspended > device shouldn't have any pending resets. Well, it shouldn't, yet I see no way we are enforcing that rule. Actually your patch for usbhid make me think about what happens if the device is closed. AFAICT the reset is not cancelled. But closing will drop the pm count. > And even if there is a pending reset, all that will happen is the reset > will cause the port to power up again, and then the reset will occur. If and only if the port is still unpowered. > If you think it would help, the runtime suspend code could be changed > to prevent suspends if any queued resets are pending. If error handling requires a reset, there's no special likelihood that suspend will clear up the issue. It is specific to port power off. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
