RE: 2.6.21-rc2 : Oops in rtc_cmos...

["Paul Rolland" <rol@as2917.net>]

Hello,

> > Yes, it does, so it's a Good One (tm),
> 
> And points out that $SUBJECT is misleading; the root cause of
> the oops isn't rtc_cmos.  Workaround, don't enable the legacy
> driver for this hardware.

Well, sorry for that, but my point was that without enabling
CONFIG_DRV_RTC_CMOS and only using CONFIG_RTC, my dmesg says :

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

Having seem that, I got thru all the options, trying to find what I
could have forgot as an option, and added the RTC_CMOS one, that resulted
in an Oops... 

> One of the good things about getting rtc-cmos merged:  it
> exposes this new RTC framework to new mistakes, which helps
> fix some of the remaining rough spots.  

Good ;)
 
> > pnp: Device 00:03 does not support disabling.
> 
> Blame the PNP stack for that particular useless message.
> I'l send a fix for that one too.
OK, ready to test ! 

> > drivers/rtc/hctosys.c: unable to open rtc device (rtc0) 
> Because probing 00:03 failed, was never fully usable.
> So then rtc0 couldn't be found.  You'd get the same
> message if, say, the RTC was loaded as a module.

It seems to me that the DRV_RTC_CMOS and the "standard" CONFIG_RTC
shouldn't be used at the same time... Am I correct on that ? 
Wouldn't it be better to have this dependancy enforced ?

Regards,
Paul