On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx> wrote:
Hello,
my opinion on this kind of stuff is that I want to avoid the layering
of implementations under the rtc subsystem. I'd rather prefer that each
rtc device had its own driver.
I've made error in the past, by accepting such kind of drivers, and
would like to avoid that it happens again.
So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
not all at once :)
I'd start writing a working driver and then see how we should eventually
adapt the rtc subsystem to cope with your needs.
What about ppc_md.get_boot_time() [ppc]?
Please note that the functions above may also be used for very early clock
setting (e.g. time_init()) and in read_persistent_clock().
How should we handle these?
read_persistent_clock is something that should be reconsidered
as well along with all the ntp stuff.
Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c
(e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c
through the inline function __get_rtc_time() in include/asm-generic/rtc.h
(clever, hardware-specific stuff in asm-generic ;-)
yep, I know :( that hardcoded rtc stuff seems to be everywhere!
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
