On Thu, 2014-03-06 at 10:43 -0500, Alan Stern wrote:
> 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?
Potentially HID. Now that I think about this it seems to me that
drivers really need to be told about the error condition. For
btusb the error condition cannot be handled. For HID it may mean
a lost key or click at the worst. The driver should react to such
errors by disabling power management, but that requires that it
become aware of such errors.
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
