lkml.org 
[lkml]   [2008]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rtc-linux] state of GEN_RTC vs rtc subsystem
Alessandro Zummo wrote:
> On Wed, 20 Feb 2008 10:11:23 -0600
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
>> Is the functionality provided by drivers/char/gen_rtc.c completely
>> handled by the rtc subsystem in drivers/rtc?
>>
>> I ask for two reasons:
>> 1. should we make it mutually exclusive in Kconfig
>> 2. I've enabled both and get (we'll my defconfig did):
>>
>
> They shouldn't be enabled at once. I think a patch
> for Kconfig has been recently submitted to give a warning
> in such a case.
>
> rtc-cmos should be able to handle the vast majority of x86
> rtcs out there.
>
> The only real open issue is related to the ntp synchronization
> mode and will be solved only when we can get rid of it :)
>
>
On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and
the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian).
If I want to use a current (Etch) hwclock binary - I need genrtc with
/dev/rtc at 10,135, however new rtc_cmos creates /dev/rtc0 at 254,0.
As a result on new kernels hwclock claims that it is not able to access
hardware.

However upgrading the util-linux package will (sometime in the
"unstable" future) solve it, so it is not completely broken... Still, at
the moment - genrtc seems to be a better solution...

Just my $.02...

Woody Suwalski






\
 
 \ /
  Last update: 2008-02-20 22:01    [W:0.234 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site