#9320 NORM Opportu: duplicate create of /devices/platform/rtc_cmos

[Zarro Boogs per Child]

#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