#9320 NORM Opportu: duplicate create of /devices/platform/rtc_cmos
Zarro Boogs per Child
bugtracker at laptop.org
Thu Apr 22 17:11:58 EDT 2010
#9320: duplicate create of /devices/platform/rtc_cmos
--------------------------------+-------------------------------------------
Reporter: pgf | Owner: pgf
Type: defect | Status: new
Priority: normal | Milestone: Opportunity
Component: kernel | Version: not specified
Resolution: | Keywords:
Next_action: diagnose | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
--------------------------------+-------------------------------------------
Changes (by pgf):
* owner: dsaxena => pgf
* component: not assigned => kernel
Comment:
i'm attaching my work-in-progress patch. it seems that somewhere between
2.6.25 and 2.6.30, the rtc_cmos driver was re-worked to contain a hard-
coded fallback driver in the case where acpi PNP driver isn't found. it's
this hard-coded platform driver config that conflicts with ours.
ifdefing arch/x86/kernel/rtc.c gets rid of the duplicate device create.
then, however, our rtc_wake_on()/off() calls are never invoked across
suspend/resume, because the cmos_suspend()/cmos_resume() routines in
drivers/rtc/rtc-cmos.c are never called. i don't understand why not. the
symptom is that although the rtc alarm expires, the wakeup was never
unmasked. the rtc alarm status bit is being set correctly, as evidenced
by "rtc wakeup" being reported by /sys/power/wakeup-source when the system
is woken by other means. (this symptom is observed in #10090.)
if our rtc_wake_on()/rtc_wake_off() routines are called directly during
suspend/resume in olpc-pm.c (as in the patch), then rtc wakeups happen
correctly.
--
Ticket URL: <http://dev.laptop.org/ticket/9320#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list