On Tue, 27 Apr 2010, Sarah Sharp wrote: > > > It seems to me that if the hub suspend failed, due to it not being > > > implemented, it should have been marked as being active or not > > > suspended, and a call to usb_autoresume_device() ought to succeed > > > because the device is not suspended. > > > > This depends on the error code for the failed suspend call. Prior to > > 2.6.34-rc1, or if the error code is -EBUSY or -EAGAIN, then things will > > work as you say. But in 2.6.34, if the code is anything else then the > > device is marked as being in an error state, neither active nor > > suspended. > > > > I guess the simplest answer is to change the -ENOENT error code in > > hcd.c:bus_suspend() to -EBUSY. Does that fix your problem? > > usbdev_open() will fail if usb_autoresume_device() returns any error > code. But if the return code in hcd.c:bus_suspend() was changed to > -EBUSY and usbdev_open() was made to look for that, then the problem > should be solved. What do you mean? usbdev_open() doesn't call bus_suspend(). If bus_suspend() returned -EBUSY instead of -ENOENT, then the autosuspend would fail but the root hub would still be in the active state rather than in an error state. Consequently, when usbdev_open() called usb_autoresume_device(), the call would succeed immediately instead of failing. 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
