lkml.org 
[lkml]   [2009]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
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@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


\
 
 \ /
  Last update: 2009-02-27 22:55    [W:0.078 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site