On Wed, Jan 23, 2013 at 5:38 PM, Peter Chen <peter.chen@xxxxxxxxxxxxx> wrote:
> Hi Ming,
>
> As I can't apply your patch directly, I just try below code.
> It works, no "hub 1-0:1.0: hub_suspend" is called.
>
>> init2:
>> + if (type == HUB_RESUME) {
>> + /* root hub is sending resume signal, so wait for its completion */
>> + if (!hdev->parent && usb_hcd_get_rh_ports_resuming(hdev)) {
>> + dev_dbg(&hdev->dev, "wait for ports resuming over\n");
>> + msleep(30);
>> + usb_hcd_set_rh_ports_resuming(hdev, 0);
>> + dev_dbg(&hdev->dev, "ports resuming over\n");
>> + }
>> + }
>>
>
> Do you know the reason why hub_suspend is called if there is a
> 30ms delay at hub_resume? Below is the log with and without 30ms
hub_suspend is called inside runtime suspend path, because no port changes
can be retrieved during root hub ports resuming after remote wakeup
event, then no new child device is found. The added 30ms will cause hcd
to know that it is safe to return the actual port change, so hub_event() will
know the port change and handle it.
In fact, hub_suspend log can still be seen immeaditely if you connect one
hub device into your host controller, but you will find that the port change
event is retrieved and no 'suspend failed because a port is resuming' shows
in the dmesg log.
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
