On Tue, 9 Sep 2014, Oliver Neukum wrote: > On Mon, 2014-09-08 at 10:56 -0400, Alan Stern wrote: > > On Mon, 8 Sep 2014, Oliver Neukum wrote: > > > > > On Fri, 2014-09-05 at 10:15 -0400, Alan Stern wrote: > > > > > 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? > > We are doing a superfluous reset. When are we doing a superfluous reset? If a reset is queued while the port is powered down? > Resets are not good. > The normal operation of the device is interrupted. > Any unnecessary reset should be avoided. If the port is powered down then the device isn't operating, normally or otherwise. Besides, if the communication with the device is messed up badly enough for a reset to be needed, I don't see how two resets can make things worse then they already are. > > > > 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. > > That was the intention. Yet if a power cycle doesn't do the job, > a reset won't do it either. We don't power-cycle the device; we only power-cycle the port. Sure, if the device is bus-powered then it will lose power when the port does. But so what? Recovery from port power-off always involves a reset. Adding a redundant reset is unlikely to make any difference. 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
