On Thu, May 1, 2014 at 12:02 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 1 May 2014, Dan Williams wrote:
>
>> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
>> > == PM_QOS_FLAGS_ALL)
>> > return -EAGAIN;
>> >
>> > + if (hub->in_reset) {
>> > + port_dev->power_is_on = 0;
>> > + return 0;
>> > + }
>>
>> Why lie? Just return -EBUSY and be done.
>
> Good idea; the complete, updated patch is below. (It's against
> 3.15-rc2, without any of your RFC changes.)
>
>> In fact that also has the
>> nice side effect of clearing runtime errors it seems.
>
> Not really, because if there was an earlier runtime PM error then
> dev->power.runtime_error would be set, so rpm_check_suspend_allowed()
> would fail and the suspend callback wouldn't get called in the first
> place.
>
> Alan Stern
>
>
> 8<---------------------------------------------------------------->8
>
> The USB core doesn't properly handle mutual exclusion between
> resetting a hub and changing the power states of the hub's ports. We
> need to avoid sending port-power requests to the hub while it is being
> reset, because such requests cannot succeed.
>
> This patch fixes the problem by keeping track of when a reset is in
> progress. At such times, attempts to suspend (power-off) a port will
> fail immediately with -EBUSY, and calls to usb_port_runtime_resume()
> will update the power_is_on flag and return immediately. When the
> reset is complete, hub_activate() will automatically restore each port
> to the proper power state.
>
> Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx>
I'll throw this at the front of my series when resubmitting.
--
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
