On Tue, Apr 29, 2014 at 12:25 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 29 Apr 2014, Dan Williams wrote:
>
>> > However, either way we still have bad interactions between
>> > hub_{quiesce|activate}() and usb_port_runtime_{suspend|resume}().
>> > Consider, for example, what happens to the ports' power states when the
>> > hub is reset.
>> >
>>
>> You mean in terms of pm_runtime state getting out of sync with the
>> hardware state? We do have (admittedly ugly in my opinion) a check of
>> the power state in hub_power_on() so if port power was runtime removed
>> hub_activate() will honor that and not restore power. And a new
>> pm_runtime_get_sync in usb_disconnect() will handle the hub_quiesce()
>> interfaction. Am I missing something?
>
> What happens if a thread tries to resume or suspend a port while the
> hub is being reset? With nothing to prevent it, the request sent to
> the hub will fail and the port may end up in a runtime PM error state.
>
I'm expected to be protected by:
/* Prevent autosuspend during the reset */
usb_autoresume_device(udev);
...in usb_reset_device() and usb_reset_and_verify_device()'s
requirement that the device in question not be suspended. The hub
should pin it's parent port active during the reset.
--
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
