[lkml]   [2013]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: usb_wwan_write() called while device still being resumed
On 02/15/2013 08:05 PM, Bjørn Mork wrote:
> Maybe something like the completely untested:
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 3148b10..38e19ba 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -512,6 +512,9 @@ static int rpm_resume(struct device *dev, int rpmflags)
> else if (dev->power.disable_depth == 1 && dev->power.is_suspended
> && dev->power.runtime_status == RPM_ACTIVE)
> retval = 1;
> + else if (rpmflags & RPM_ASYNC && dev->power.request_pending &&
> + dev->power.request == RPM_REQ_RESUME)
> + retval = -EINPROGRESS;
> else if (dev->power.disable_depth > 0)
> retval = -EACCES;
> if (retval)

Second thought: not sure this will work since power.request_pending and
power.request are set to these values later in the same rpm_resume()
function. However, the three lines before yours caught my attention.
They are not in my 3.1 source tree and the conditions are very close
from the ones I am seeing when the issue happens: disable_depth == 1,
is_suspended == 1. Only runtime_status is not equal to RPM_ACTIVE.

Nonetheless, I have looked at the patch that introduced these
( ) and it details a problem that is very
similar to mine. It also mentions a workaround to be implemented in the
driver by saving the suspend status into a variable that is checked when
pm_runtime_get() return -EACCES. This variable already exists in
usb_wwan, actually it is the very variable that is checked a bit later
in that other chunk of code you mentioned:

spin_lock_irqsave(&intfdata->susp_lock, flags);
if (intfdata->suspended) {
usb_anchor_urb(this_urb, &portdata->delayed);
spin_unlock_irqrestore(&intfdata->susp_lock, flags);
} else {

So it looks like this code is here for exactly that purpose. However in
my current condition I do not see how this block could be run since
runtime PM is disabled when intfdata->suspended is set to true.

I will try implementing the workaround suggested (checking if
intfdata->suspended is set when -EACCES is returned and go on if it is
the case) and see if it works (and I bet it will). In the upstream
kernel the issue seems to have been addressed already, so this might
just be a source-out-of-date issue.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-02-18 04:41    [W:0.038 / U:2.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site