On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-s3c2410 glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in ohci_hcd_s3c2410_drv_suspend() will ensure
> proper handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away
> without executing further.
> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index 8018bb1..01430f2 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -430,7 +430,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
> struct platform_device *pdev = to_platform_device(dev);
> unsigned long flags;
> int rc = 0;
> + bool do_wakeup = device_may_wakeup(dev);
>
> + rc = ohci_suspend(hcd, do_wakeup);
> + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> + ohci_resume(hcd, false);
> + rc = -EBUSY;
> + }
> + if (rc)
> + return rc;
> /*
> * Root hub was already suspended. Disable irq emission and
> * mark HW unaccessible, bail out if RH has been resumed. Use
The part that follows this patch doesn't make sense any more. I think
we can afford to get rid of the test for ohci->rh_state !=
OHCI_RH_SUSPENDED; the PM core has been quite stable for years and it
won't try to suspend the controller if the root hub is active.
Also, the
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
line isn't needed, because ohci_suspend() does it.
Putting this all together, all that's left is the spin_lock/unlock and
the call to s3c2410_stop_hc(). The comment isn't needed, nor is the
statement label. (In fact, I'm not even sure if the spin_lock/unlock
lines are needed. It depends on the hardware details.)
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
