On Thu, May 22, 2014 at 07:14:40PM +0100, Alan Stern wrote: > On Thu, 22 May 2014, Will Deacon wrote: > > > > Anyway, there are two possible ways of handling this. One is to avoid > > > changing the error code to -EBUSY when the device in question is a root > > > hub. Just let it go into a runtime-PM error state; it won't matter > > > since the controller doesn't support runtime PM anyway. You can test > > > this by changing the "if (status != 0)" line in usb_runtime_suspend to > > > > > > if (status != 0 && udev->parent) > > > > I'd tried something like this already, but I prefer your patch below. Plus, > > this hack results in a failure being logged to dmesg on the initial suspend > > attempt. > > > > > The other approach is to disable runtime PM for the root hub when the > > > host controller driver doesn't have a bus_suspend or bus_resume method. > > > This seems like a cleaner approach; the patch below implements it. > > > > Thanks for this! I can confirm that your patch below fixes the issue for me, > > so: > > > > Reported-by: Will Deacon <will.deacon@xxxxxxx> > > Tested-by: Will Deacon <will.deacon@xxxxxxx> > > You know, I think it might be best to make both changes. Even though > runtime PM will be disabled by default, the user can always override > this setting. If that happens, the suspend should fail with the proper > error code instead of going into a loop. > > Do you mind if I add the change to usb_runtime_suspend() in the patch? That sounds sensible -- if runtime PM is being forced on, then errors are worth reporting. Will -- 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
