[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <B8EFE96D1287C24090BAD9D858E15E6175A08F@sisaex02sj>
Date: Tue, 06 Aug 2013 17:14:00 +0000
From: Shuah Khan <shuah.kh@...sung.com>
To: "david-b@...bell.net" <david-b@...bell.net>,
"dbrownell@...rs.sourceforge.net" <dbrownell@...rs.sourceforge.net>,
"rjw@...k.pl" <rjw@...k.pl>, "pavel@....cz" <pavel@....cz>,
"stern@...land.harvard.edu" <stern@...land.harvard.edu>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: sl811h_suspend() and PM_EVENT_PRETHAW state handling
sl811h_suspend() seems to be the odd routine in the way it handles the
PM_EVENT_PRETHAW state. It treats it same as PM_EVENT_SUSPEND and
PM_EVENT_HIBERNATE. All other uses I could find treat it same as
PM_EVENT_FREEZE and PM_EVENT_QUIESCE. Makes sense since PM_EVENT_PRETHAW
is PM_EVENT_QUIESCE.
#define PM_EVENT_PRETHAW PM_EVENT_QUIESCE
Reference: Commit 185849991d592497e43bcd264c6152af1261ffe2 introduced
PM_EVENT_PRETHAW state to sl811h_suspend().
Couple of questions?
- Why does sl811h_suspend() treat PM_EVENT_PRETHAW different from
PM_EVENT_FREEZE?
There is no problem with this code as such, since state is passed in.
However, this usage conflicts with the rest of the usages and the way
pm_op() routine maps PM_EVENT_PRETHAW/PM_EVENT_QUIESCE to freeze() pm_ops.
case PM_EVENT_FREEZE:
case PM_EVENT_QUIESCE:
return ops->freeze;
Assuming the handling PM_EVENT_PRETHAW is correct in this routine, what
would be the right mapping for this legacy handling to dev_pm_ops?
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) shuah.kh@...sung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists