From: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
To: Rabin Vincent <rabin-66gdRtMMWGc@public.gmane.org>
Cc: stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: platform/i2c busses: pm runtime and system sleep
Date: Fri, 17 Dec 2010 01:09:42 +0100 [thread overview]
Message-ID: <201012170109.43137.rjw@sisk.pl> (raw)
In-Reply-To: <AANLkTinyDE3OxKup_aqsN8HJH_r5LcwkP17OtuMRpACx-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday, December 16, 2010, Rabin Vincent wrote:
> Hello,
>
> There seem to be some differences between the generic ops and the i2c
> and platform busses' implementations of the interaction between runtime
> PM and system sleep:
>
> (1) The platform bus does not implement the
> don't-call-pm->suspend()-if pm_runtime_suspended()-returns-true
> functionality implemented by the generic ops and i2c.
>
> (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.
>
> Are these divergences from the generic ops to be considered as bugs?
I think so. I'm not sure about (1), because someone may already depend on
that behavior, but (2) looks like a bug to me.
> Atleast (2) will cause devices which use UNIVERSAL_DEV_PM_OPS to have
> incorrect runtime pm state after a resume from system sleep.
>
> 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.
> This would mean that simple busses could simply use the
> generic ops like below instead of duplicating their behaviour:
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 6b4cc56..46117e0 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -212,7 +212,7 @@ static int i2c_device_pm_resume(struct device *dev)
> int ret;
>
> if (pm)
> - ret = pm->resume ? pm->resume(dev) : 0;
> + ret = pm_generic_resume(dev);
> else
> ret = i2c_legacy_resume(dev);
Thanks,
Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Rabin Vincent <rabin@rab.in>
Cc: stern@rowland.harvard.edu, linux-pm@lists.linux-foundation.org,
linux-i2c@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: platform/i2c busses: pm runtime and system sleep
Date: Fri, 17 Dec 2010 01:09:42 +0100 [thread overview]
Message-ID: <201012170109.43137.rjw@sisk.pl> (raw)
In-Reply-To: <AANLkTinyDE3OxKup_aqsN8HJH_r5LcwkP17OtuMRpACx@mail.gmail.com>
On Thursday, December 16, 2010, Rabin Vincent wrote:
> Hello,
>
> There seem to be some differences between the generic ops and the i2c
> and platform busses' implementations of the interaction between runtime
> PM and system sleep:
>
> (1) The platform bus does not implement the
> don't-call-pm->suspend()-if pm_runtime_suspended()-returns-true
> functionality implemented by the generic ops and i2c.
>
> (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.
>
> Are these divergences from the generic ops to be considered as bugs?
I think so. I'm not sure about (1), because someone may already depend on
that behavior, but (2) looks like a bug to me.
> Atleast (2) will cause devices which use UNIVERSAL_DEV_PM_OPS to have
> incorrect runtime pm state after a resume from system sleep.
>
> 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.
> This would mean that simple busses could simply use the
> generic ops like below instead of duplicating their behaviour:
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 6b4cc56..46117e0 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -212,7 +212,7 @@ static int i2c_device_pm_resume(struct device *dev)
> int ret;
>
> if (pm)
> - ret = pm->resume ? pm->resume(dev) : 0;
> + ret = pm_generic_resume(dev);
> else
> ret = i2c_legacy_resume(dev);
Thanks,
Rafael
next prev parent reply other threads:[~2010-12-17 0:09 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 18:26 platform/i2c busses: pm runtime and system sleep Rabin Vincent
2010-12-16 18:26 ` Rabin Vincent
[not found] ` <AANLkTinyDE3OxKup_aqsN8HJH_r5LcwkP17OtuMRpACx-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-12-17 0:09 ` Rafael J. Wysocki [this message]
2010-12-17 0:09 ` Rafael J. Wysocki
2011-02-17 15:25 ` Rabin Vincent
2011-02-17 15:25 ` Rabin Vincent
2011-02-18 2:48 ` Rabin Vincent
[not found] ` <AANLkTikRUZRh0YnP8nYTKFnFeUiJbK5xKvHHjn_S+gZE-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-02-18 2:48 ` Rabin Vincent
2011-02-18 2:48 ` Rabin Vincent
2011-02-18 2:48 ` Rabin Vincent
2011-02-18 15:05 ` Alan Stern
2011-02-18 15:05 ` Alan Stern
2011-02-18 15:05 ` Alan Stern
2011-02-18 15:05 ` Alan Stern
2011-02-18 18:28 ` Rafael J. Wysocki
[not found] ` <AANLkTinsPqFcodH0w7LQeFEY+amodNH4CneRCRhhbKaz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-02-18 18:28 ` Rafael J. Wysocki
2011-02-18 18:28 ` Rafael J. Wysocki
2011-02-18 18:28 ` Rafael J. Wysocki
[not found] ` <201102181928.05911.rjw-KKrjLPT3xs0@public.gmane.org>
2011-02-18 19:25 ` Rabin Vincent
2011-02-18 19:25 ` Rabin Vincent
2011-02-18 19:25 ` Rabin Vincent
2011-02-18 20:20 ` Rafael J. Wysocki
2011-02-18 20:20 ` Rafael J. Wysocki
2011-02-18 20:27 ` Russell King - ARM Linux
2011-02-18 20:27 ` Russell King - ARM Linux
2011-02-18 22:16 ` Mark Brown
2011-02-19 7:24 ` Rabin Vincent
2011-02-19 7:24 ` Rabin Vincent
2011-02-19 7:24 ` Rabin Vincent
2011-02-19 9:54 ` Linus Walleij
[not found] ` <20110218202744.GA19427-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-02-18 22:16 ` Mark Brown
2011-02-18 22:16 ` Mark Brown
2011-02-18 22:16 ` Mark Brown
2011-02-19 9:54 ` Linus Walleij
2011-02-19 9:54 ` Linus Walleij
2011-02-19 9:54 ` Linus Walleij
2011-02-19 10:00 ` Russell King - ARM Linux
2011-02-19 10:00 ` Russell King - ARM Linux
[not found] ` <20110219100017.GA29493-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-02-19 10:16 ` Linus Walleij
2011-02-19 10:16 ` Linus Walleij
2011-02-19 10:16 ` Linus Walleij
2011-02-19 10:16 ` Linus Walleij
2011-02-19 10:00 ` Russell King - ARM Linux
2011-02-18 20:27 ` Russell King - ARM Linux
2011-02-18 20:20 ` Rafael J. Wysocki
2011-02-18 19:25 ` Rabin Vincent
2011-02-17 15:25 ` Rabin Vincent
2010-12-17 12:54 ` Mark Brown
2010-12-17 12:54 ` Mark Brown
2010-12-17 13:25 ` Rafael J. Wysocki
[not found] ` <20101217125427.GA29640-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2010-12-17 13:25 ` Rafael J. Wysocki
2010-12-17 13:25 ` Rafael J. Wysocki
2010-12-17 13:34 ` Mark Brown
[not found] ` <201012171425.07775.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-17 13:34 ` Mark Brown
2010-12-17 13:34 ` Mark Brown
2010-12-17 13:49 ` Rafael J. Wysocki
[not found] ` <20101217133434.GH31453-HF5t3jzXg/6ND3a5+9QAFujbO/Zr0HzV@public.gmane.org>
2010-12-17 13:49 ` Rafael J. Wysocki
2010-12-17 13:49 ` Rafael J. Wysocki
[not found] ` <201012171449.26082.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-17 14:24 ` Mark Brown
2010-12-17 14:24 ` Mark Brown
2010-12-17 23:01 ` Rafael J. Wysocki
[not found] ` <20101217142402.GA19391-HF5t3jzXg/6ND3a5+9QAFujbO/Zr0HzV@public.gmane.org>
2010-12-17 23:01 ` Rafael J. Wysocki
2010-12-17 23:01 ` Rafael J. Wysocki
[not found] ` <201012180001.25263.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-18 1:04 ` Mark Brown
2010-12-18 1:04 ` Mark Brown
2010-12-18 12:54 ` Rafael J. Wysocki
[not found] ` <201012181354.58077.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-18 13:20 ` Mark Brown
2010-12-18 13:20 ` Mark Brown
2010-12-18 14:59 ` Rafael J. Wysocki
[not found] ` <20101218132029.GA22273-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2010-12-18 14:59 ` Rafael J. Wysocki
2010-12-18 14:59 ` Rafael J. Wysocki
[not found] ` <201012181559.50347.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-20 15:00 ` Mark Brown
2010-12-20 15:00 ` Mark Brown
2010-12-20 21:13 ` Rafael J. Wysocki
[not found] ` <20101220150051.GI26706-HF5t3jzXg/6ND3a5+9QAFujbO/Zr0HzV@public.gmane.org>
2010-12-20 21:13 ` Rafael J. Wysocki
2010-12-20 21:13 ` Rafael J. Wysocki
[not found] ` <201012202213.53902.rjw-KKrjLPT3xs0@public.gmane.org>
2010-12-21 23:51 ` Mark Brown
2010-12-21 23:51 ` Mark Brown
[not found] ` <20101221235127.GC10081-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2010-12-22 0:35 ` Rafael J. Wysocki
2010-12-22 0:35 ` Rafael J. Wysocki
2010-12-22 0:35 ` Rafael J. Wysocki
2010-12-21 23:51 ` Mark Brown
2010-12-20 15:00 ` Mark Brown
2010-12-18 13:20 ` Mark Brown
2010-12-18 12:54 ` Rafael J. Wysocki
2010-12-18 1:04 ` Mark Brown
2010-12-17 14:24 ` Mark Brown
2010-12-17 0:09 ` Rafael J. Wysocki
2010-12-17 12:54 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2010-12-16 18:26 Rabin Vincent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012170109.43137.rjw@sisk.pl \
--to=rjw-kkrjlpt3xs0@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=rabin-66gdRtMMWGc@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.