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.
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
