On Mon, 8 Sep 2014, Oliver Neukum wrote: > 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. Yes, okay, I suppose that might happen. > > 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 the port is powered, then: If the device is runtime-suspended, it will be resumed. The reset will occur normally. Perhaps the device will be runtime suspended again. What's the problem? > > 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. I don't understand what you mean. Neither suspend nor port power-off is meant for handling errors. We use resets for that purpose. Alan Stern -- 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
