lkml.org 
[lkml]   [2009]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 20 Feb 2009, Alessandro Zummo wrote:
> On Fri, 20 Feb 2009 16:46:44 +0100
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> > Despite it's name, it's platform-independent, as it's build on top of the RTC
> > abstraction used by "genrtc".
> >
> > This patch series
> > - adds a missing module alias to rtc-parisc,
> > - renames rtc-parisc to rtc-generic,
> > - converts the architectures that currently have CONFIG_GEN_RTC enabled in
> > their defconfig (m68k, parisc, powerpc) to rtc-generic,
> > - removes the obsolete rtc-ppc driver,
> > - removes the old genrtc driver.
> >
> > Note that genrtc may be used on other archictectures as well: at least alpha
> > has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow
> > genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa).
> >
> > Furthermore genrtc and rtc-generic are not 100% userspace compatible:
> > - /dev/rtc provided by genrtc uses a misc character device (10:135),
> > - /dev/rtc provided by rtc-generic uses a dynamic character device.
>
> 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?

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?

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 ;-)

> Regarding the user space, the assumption that a device has
> a fixed major:minor number should be dropped as well.

I know. But it's a userland-visible change, so I wanted to explicit point to
it.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-02-23 13:39    [from the cache]
©2003-2011 Jasper Spaans