On Thu, Jan 24, 2013 at 2:10 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Not so. It's true that the message can be produced even when the delay > is present, but if the delay is set to 30 ms then you will get no more > than one message every 30 ms. By contrast, Norbert was getting about 8 > messages per ms. IMO, root hub should be kept in active during sending ports resume after remote wakeup, but it might be not good to let autosuspend delay handle the case because: - the delay can be override by user space - the extra delay isn't needed in other cases(from active in other cases to auto-suspend) > >> I have post one patch which may remove the message, see link[2]. > > I don't think sleeping is the right answer. For example, at the same > time as the resume there could be a new device plugged in. The port change of the new device will be found during checking port status just when the delay is expired, or will be reported by later submitted URB. Also the sleeping can avoid the "suspend failed" message completely. > > What we really want to do is prevent the root hub from autosuspending > while the resume signal is active. One possibility is to have the HCD > call pm_runtime_get_noresume. Can you think of anything better? pm_runtime_get_noresume should be better than adjusting autosuspend delay, but the 'suspend failed' message can't be avoided. Or could we schedule a delayed work to handle hub_activate(HUB_RESUME) for the case? Thanks, -- Ming Lei -- 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
