On Wed, Mar 6, 2013 at 8:04 PM, Bjørn Mork [off-list ref] wrote:

Ming Lei [off-list ref] writes:

quoted

If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.

Cc: Bjørn Mork <redacted>
Signed-off-by: Ming Lei <redacted>
---
 drivers/net/usb/cdc_mbim.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 248d2dc..ec58c2c 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c

@@ -338,7 +338,7 @@ static int cdc_mbim_suspend(struct usb_interface *intf, pm_message_t message)

      if (intf == ctx->control && info->subdriver && info->subdriver->suspend)
              ret = info->subdriver->suspend(intf, message);
-     if (ret < 0)
+     if (ret < 0 && PMSG_IS_AUTO(message))
              usbnet_resume(intf);

 error:

This condition will never happen because the subdriver callback always
return 0 if !PMSG_IS_AUTO(message), so adding anything here is purely
for documentation purposes.  That is OK for me.  But I do not see any
point adding incomplete or wrong documentation.

The above is incomplete because it ignores the failure and still return
an error. And it is wrong because we ignore an error we cannot possibly
handle in resume.  Only the subdriver can do that, which is why we must
delegate this to the subdriver.

I believe the correct here is to document the fact that we require the
subdriver->suspend() callback to always return 0 if !PMSG_IS_AUTO(message).
That is best done with a comment. No need to add any redundant code.

Considered that the subdriver might change its return value in future, how about
just add the below comment?

        /* TODO: resume() might need to handle suspend failure from subdriver */


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html