[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1235511327.18632.73.camel@macbook.infradead.org>
Date: Wed, 25 Feb 2009 06:35:27 +0900
From: David Woodhouse <dwmw2@...radead.org>
To: Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
Cc: Alessandro Zummo <alessandro.zummo@...ertech.it>,
rtc-linux@...glegroups.com, Richard Zidlicky <rz@...ux-m68k.org>,
linux-parisc@...r.kernel.org,
Linux Kernel Development <linux-kernel@...r.kernel.org>,
David@...abs.org, Kyle McMartin <kyle@...artin.ca>,
Linux/PPC Development <linuxppc-dev@...abs.org>,
Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> > 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?
That's the ideal... although did we get NTP sync working again yet?
The rtc-ppc driver was intended as a short-term workaround so that we
can enable the generic RTC class (which was required for PA Semi
Electra, iirc), and still have stuff work on other platforms.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists