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):
proc_dir_entry 'rtc' already registered
Call Trace:
[df82bd70] [c0006b8c] show_stack+0x3c/0x1b0 (unreliable)
[df82bda0] [c00cda48] proc_register+0xf8/0x1a0
[df82bdd0] [c00cdc44] create_proc_entry+0x64/0xf0
[df82bdf0] [c024a484] rtc_proc_add_device+0x54/0x90
[df82be00] [c0249048] rtc_device_register+0x1d8/0x220
[df82be40] [c046c0bc] cmos_platform_probe+0x13c/0x3c0
[df82be70] [c01cd524] platform_drv_probe+0x24/0x40
[df82be80] [c01cb15c] driver_probe_device+0xbc/0x200
[df82bea0] [c01cb4ac] __driver_attach+0xcc/0x100
[df82bec0] [c01ca0dc] bus_for_each_dev+0x5c/0xa0
[df82bef0] [c01caf44] driver_attach+0x24/0x40
[df82bf00] [c01cad70] bus_add_driver+0x1f0/0x270
[df82bf20] [c01cb778] driver_register+0x48/0x140
[df82bf40] [c01cd948] platform_driver_register+0x98/0xb0
[df82bf50] [c01cd97c] platform_driver_probe+0x1c/0x90
[df82bf60] [c046bf70] cmos_init+0x20/0x30
[df82bf70] [c0450218] kernel_init+0xa8/0x2b0
[df82bff0] [c000e638] kernel_thread+0x44/0x60
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
- k
On Wed, 20 Feb 2008 10:11:23 -0600
Kumar Gala <[email protected]> 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 :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
Alessandro Zummo wrote:
> On Wed, 20 Feb 2008 10:11:23 -0600
> Kumar Gala <[email protected]> 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
On Wed, 20 Feb 2008 15:37:28 -0500
woodys <[email protected]> wrote:
> 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...
Strange that it has been disabled, I used to keep an eye to avoid touching
anything outside of drivers/rtc .
the rtc subsystem creates the device dynamically, you shouldn't count
on having 254,0. I would eventually ack a patch that adds
/dev/rtc at 10,135 as an alias for /dev/rtc0.
however the best solution would be to upgrade hwclock.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On Wed, Feb 20, 2008 at 10:11:23AM -0600, Kumar Gala wrote:
> Is the functionality provided by drivers/char/gen_rtc.c completely handled
> by the rtc subsystem in drivers/rtc?
they were not designed work parallel at the same. Not sure if there is
ever a valid reason to have both comiled into one kernel image - might be
for some architectures - but when the situation is not handled correctly
the easiest fix is to make them mutually exclusive.
Richard
On Wed, 20 Feb 2008 18:03:25 +0100, Alessandro Zummo <[email protected]> wrote:
> On Wed, 20 Feb 2008 10:11:23 -0600
> Kumar Gala <[email protected]> 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.
>
In fact, you have 3 rtc implementations available.
Please, can you take a look at this question also:
http://marc.info/?l=linux-kernel&m=120355254713965&w=2
> The only real open issue is related to the ntp synchronization
> mode and will be solved only when we can get rid of it :)
>
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT