On Wed, 27 Sep 2006 08:58:53 -0700
Tom Rini [off-list ref] wrote:

On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:

quoted

On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:

[snip]

quoted

quoted

diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/ 

powerpc/platforms/83xx/mpc834x_itx.c
index 969fbb6..8c676d7 100644

--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c

@@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
 	return 1;
 }

+#ifdef CONFIG_RTC_CLASS
+late_initcall(rtc_class_hookup);
+#endif

Any reason we can't just do this in setup_arch?

I think because of rtc-over-i2c and similar where we need the whole rest
of the system 'up' before we can try and use the RTC (which might not be
the case for this specific board, but for consistency it looks like a
good thing to always do it like this).

this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine.  In the early assignment case, the kernel oopses early in rtc_class_open().

During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions.  Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:

http://lkml.org/lkml/2005/12/20/220

so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).

So we should just configure RTC_CLASS and the specific chip and we're done. :)

Kim