On Mon, 23 Feb 2009 13:34:49 +0100 (CET) Geert Uytterhoeven <geert.uytterhoe...@sonycom.com> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
