Re: [PATCH] i2c: Factor out runtime suspend checks from PM operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 22, 2010 at 11:37 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>  static int i2c_device_pm_restore(struct device *dev)
> @@ -266,15 +247,16 @@ static int i2c_device_pm_restore(struct device *dev)
>        const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>        int ret;
>
> -       if (pm)
> -               ret = pm->restore ? pm->restore(dev) : 0;
> -       else
> +       if (pm) {
> +               ret = pm_generic_restore(dev);
> +       } else {
>                ret = i2c_legacy_resume(dev);
>
> -       if (!ret) {
> -               pm_runtime_disable(dev);
> -               pm_runtime_set_active(dev);
> -               pm_runtime_enable(dev);
> +               if (!ret) {
> +                       pm_runtime_disable(dev);
> +                       pm_runtime_set_active(dev);
> +                       pm_runtime_enable(dev);
> +               }
>        }

I asked Rafael about the legacy operations earlier on the other thread:

On Fri, Dec 17, 2010 at 5:39 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> On Thursday, December 16, 2010, Rabin Vincent wrote:
>> If so, before I send patches to fix them: can it be assumed that only
>> drivers using dev_pm_ops (and not the legacy ops of these busses) will
>> need the interactions between runtime PM and system sleep as done in the
>> generic ops?
>
> Yes, you can make this assumption safely.  The drivers that don't use
> dev_pm_ops can't support runtime PM at all.

And even if we did want to support runtime PM interaction for legacy
ops, the code for restore() above suffers from the problem of setting
active even when no callback exists, like I mentioned in the same email
for resume():

On Thu, Dec 16, 2010 at 11:56 PM, Rabin Vincent <rabin@xxxxxx> wrote:
>  (2) Both I2C and platform do not set the device as active when a
>      pm->resume callback exists and it succeeds.
>
>      This seems to have been done in i2c until recently, but has been
>      removed by 753419f59e ("i2c: Fix for suspend/resume issue").  It
>      seems to me that this removal is incorrect, and instead the real
>      problem with the implementation was that it set the device as
>      active even if no resume callback existed, whereas it should only
>      do so when it exists and returns zero, like the generic ops.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux