On Thu, 6 Mar 2014, Oliver Neukum wrote:
> > > This is extremely tricky, almost academical a question.
> > > We cannot fall back to reset_resume() in this case without
> > > very bad consequences.
> > > If remote wakeup is needed, reset_resume() must not be used.
> >
> > The only alternative is to logically disconnect the device. But this
> > conflicts with the persist_enabled flag.
>
> In error handling? It seems to me that persist_enabled is a declaration
> of a goal. What the consequences of reaching that
> goal should be is a legitimate question.
>
> > > It seems to me that the bug in this case is the fallback itself.
> > > From a design viewpoint is probably wrong the unbind a device
> > > in the runtime case. We'd better notify the driver in every case.
> > > If you unbind and rebind you just risk getting into a tight loop.
> >
> > In this case, turning off the persist flag might help:
> >
> > echo 0 >/sys/bus/usb/devices/.../power/persist
>
> But in case remote wakeup is not requested the device
> should persist.
Then you're suggesting something like this in finish_port_resume()?
status = usb_get_status(udev, USB_RECIP_DEVICE, 0, &devstatus);
- /* If a normal resume failed, try doing a reset-resume */
- if (status && !udev->reset_resume && udev->persist_enabled) {
+ /*
+ * If a normal resume failed and remote wakeup is disabled,
+ * try doing a reset-resume.
+ */
+ if (status && !udev->reset_resume && !udev->do_remote_wakeup &&
+ udev->persist_enabled) {
dev_dbg(&udev->dev, "retry with reset-resume\n");
udev->reset_resume = 1;
goto retry_reset_resume;
Are there any wakeup-enabled devices that this will mess up?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
