andrew wrote:
 > On Sun, 19 Dec 2010 19:08:28 +0000 (GMT)
 > Daniel Drake <[email protected]> wrote:
 > 
 > > From: Paul Fox <[email protected]>
 > > 
 > > rtc-cmos was setting suspend/resume hooks at the device_driver level.
 > > However, the platform bus code (drivers/base/platform.c) only looks
 > > for resume hooks at the dev_pm_ops level, or within the platform_driver.
 > > 
 > > Switch rtc_cmos to use dev_pm_ops so that suspend/resume code is
 > > executed again.
 > > 
 > > Signed-off-by: Paul Fox <[email protected]>
 > > Signed-off-by: Daniel Drake <[email protected]>
 > > ---
 > >  drivers/rtc/rtc-cmos.c |   16 +++++++++-------
 > >  1 files changed, 9 insertions(+), 7 deletions(-)
 > > 
 > > v2: incorporate feedback from Rafael J. Wysocki, fix tabs, make a bit more
 > > consistent with typical SIMPLE_DEV_PM_OPS users.
 > > 
 > > v3: remove const keyword already set by macro, thanks to Rafael
 > 
 > It's unclear what the user-visible effects of this bug were.  Machine
 > fails to suspend?  RTC loses its brains on resume?  Something else?

the user visible symptom in our (XO laptop) case was that rtcwake
would fail to wake the laptop.  the RTC alarm would expire, but the
wakeup wasn't unmasked.

as for severity, the impact may have been reduced because if i recall
correctly, the bug only affected platforms with CONFIG_PNP disabled.

paul

 > 
 > That's really important information for a bugfix's changelog.  Please
 > never omit it.
 > 
 > 
 > 
 > I'm going to assume that whatever-the-behaviour-is is fairly serious,
 > and that we want this patch in 2.6.37.  So I tagged it for backporting
 > into 2.6.37.1, as we're getting pretty close to 2.6.37.
 > 
 > The patch also applies to 2.6.36.  Is it needed there?  And in earlier
 > kernels?

=---------------------
 paul fox, [email protected]

_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

Reply via email to