[rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

Richard Zidlicky rz at linux-m68k.org
Sat Feb 28 05:55:14 EST 2009


On Wed, Feb 25, 2009 at 11:18:36AM +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven at sonycom.com> wrote:
> 
> > I didn't know NTP was broken with RTC class drivers?
> > 
> > So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
> > now? ;-)
> 
>  broken here means that the kernel won't save the time to the hardware
>  rtc every 11 minutes as it used to do. normal NTP operations are unaffected.

seems like so far ppc is the only architecture attempting to implement it
correctly, all others either have it unimplemented or use the broken
by design set_rtc_mmss method. 
Also note that in most cases hwclock has much better possibilities
to do a good job.

Regarding genrtc vs rtc-ppc/rtc-generic it is worth noting that genrtc
provides RTC_UIE emulation which is of some use for exotic programs like 
"chrony".
Afaics this is also the only situation without a good userspace workaround 
and chrony never worked well for me so I have nothing against junking the 
code.

Regarding a possible reorganisation from the generic to all separate drivers
I agree that the habit of putting rtc-chip specific code in asm-generic is 
confusing at best. 
In many cases such code might be better placed in drivers/rtc or 
include/linux/rtc/chipname.

Imho this does not preclude the possibility to use a generic framework. While
there certainly are valid reasons to have separate drivers in some cases 
I do not see much value in rewriting everything as separate drivers where 
the generic framework works well.

Richard



More information about the Linuxppc-dev mailing list