Yet another architecture not coverd by GEN_RTC - sparc64 never
picked it until now and it doesn't have asm/rtc.h to go with it, so
it wouldn't compile anyway (or have these ioctls in the user-visible
headers, for that matter).
FWIW, I'm very tempted to introduce ARCH_HAS_GEN_RTC and have
it set in arch/*/Kconfig for architectures that know what to do with this
stuff - for something supposedly generic the list of architectures where
it doesn't work is getting too long...
Signed-off-by: Al Viro <[email protected]>
----
diff -urN RC13-git5-serial/drivers/char/Kconfig RC13-git5-genrtc/drivers/char/Kconfig
--- RC13-git5-serial/drivers/char/Kconfig 2005-09-05 16:41:18.000000000 -0400
+++ RC13-git5-genrtc/drivers/char/Kconfig 2005-09-05 16:41:19.000000000 -0400
@@ -736,7 +736,7 @@
config GEN_RTC
tristate "Generic /dev/rtc emulation"
- depends on RTC!=y && !IA64 && !ARM && !PPC64 && !M32R && !SPARC32
+ depends on RTC!=y && !IA64 && !ARM && !PPC64 && !M32R && !SPARC32 && !SPARC64
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
From: [email protected]
Date: Tue, 6 Sep 2005 01:56:45 +0100
> Yet another architecture not coverd by GEN_RTC - sparc64 never
> picked it until now and it doesn't have asm/rtc.h to go with it, so
> it wouldn't compile anyway (or have these ioctls in the user-visible
> headers, for that matter).
>
> FWIW, I'm very tempted to introduce ARCH_HAS_GEN_RTC and have
> it set in arch/*/Kconfig for architectures that know what to do with this
> stuff - for something supposedly generic the list of architectures where
> it doesn't work is getting too long...
>
> Signed-off-by: Al Viro <[email protected]>
I'll add this patch to my sparc tree, thanks Al.
Admittedly, the whole RTC situation is quite a mess I have to
agree.
To make the problem worse, we have two sets of RTC ioctls
which userland makes use of on Sparc. The older ones which
the SBUS RTC driver exported and supported, and the normal
ones the rest of the world uses. Because the normal RTC driver
gets used as well, userland actually tries both ioctl sets.
Therefore, it probably would work to completely do away with
the SBUS RTC ioctl support, and only use the normal ones.
This would make using the generic RTC driver much easier, I
would think.
Anyways, I've added this to my sparc64 TODO list at:
http://vger.kernel.org/~davem/sparc64_todo.html
so that I can get to dealing with this at some point.
On Mon, Sep 05, 2005 at 06:51:41PM -0700, David S. Miller wrote:
> Admittedly, the whole RTC situation is quite a mess I have to
> agree.
>
> To make the problem worse, we have two sets of RTC ioctls
> which userland makes use of on Sparc. The older ones which
> the SBUS RTC driver exported and supported, and the normal
> ones the rest of the world uses. Because the normal RTC driver
> gets used as well, userland actually tries both ioctl sets.
> Therefore, it probably would work to completely do away with
> the SBUS RTC ioctl support, and only use the normal ones.
>
> This would make using the generic RTC driver much easier, I
> would think.
Yeah... Note that what you've just called "generic RTC driver" is
*not* GEN_RTC; it's RTC.
>From my reading of that code, GEN_RTC should've been called FAKE_RTC...
AFAICS, more or less clean solution would be to split the damn thing
into frontend (parsing of ioctls, hopefully very few API variants) and
backend (set of methods for talking to real hardware, or, in this case,
fake of a hardware). With at most one backend selectable (i.e. select
in Kconfig) and frontend available if backend is selected. With any
luck we could eventually get frontends down to one; in any case, their
APIs have no place in include/asm-*
Note that e.g. fsckloads of MIPS RTC drivers would simply become backends
in that scheme; lots of duplicated glue would disappear from them...
I'll look into that once the things settle down a bit with handling the
-bird tree; if you get there first with the work you've mentioned above -
even better ;-)
On Tue, 6 Sep 2005 [email protected] wrote:
> >From my reading of that code, GEN_RTC should've been called FAKE_RTC...
Yep, it's an excuse for platform maintainers not to write proper drivers.
> AFAICS, more or less clean solution would be to split the damn thing
> into frontend (parsing of ioctls, hopefully very few API variants) and
> backend (set of methods for talking to real hardware, or, in this case,
> fake of a hardware). With at most one backend selectable (i.e. select
> in Kconfig) and frontend available if backend is selected. With any
> luck we could eventually get frontends down to one; in any case, their
> APIs have no place in include/asm-*
>
> Note that e.g. fsckloads of MIPS RTC drivers would simply become backends
> in that scheme; lots of duplicated glue would disappear from them...
Note that a few of MIPS RTC drivers are actually I2C devices that the
fake code accesses directly bypassing the relevant I2C driver. That may
be a justified fallback for the one-off boot-time system clock setup when
no suitable I2C driver has been built in, but for normal operation that's
rather miserable. As I happen to have a suitable system for testing, I
may have a look at how to interface such drivers to a generic frontend.
I'm not sure whether in this particular system the RTC chip's interrupt is
wired though -- probably not -- so I may only leave this part of code to
be tested by others.
Maciej
On Tue, Sep 06, 2005 at 03:40:47PM +0100, Maciej W. Rozycki wrote:
> On Tue, 6 Sep 2005 [email protected] wrote:
>
> > >From my reading of that code, GEN_RTC should've been called FAKE_RTC...
>
> Yep, it's an excuse for platform maintainers not to write proper drivers.
I talked with Al about this off list a bit, and pointed out it's
different than it appears. GEN_RTC really is a mostly-generic RTC
driver. There's some fakey stuff going on for UIE (all under
GEN_RTC_X), but the real meat of the driver is common export get/set
time and per-arch (which can abstract further, see ppc32) poke the
hardware for the time. There's 2 (afaik) problems, one being a lack of
alarm support, and the other being hardware access isn't (today)
abstracted out far enough for i2c stuff to work.
Russell King has both of these fixed in the ARM-specific but hardware
poking abstracted rtc driver. I'd like to try and merge things at
somepoint...
--
Tom Rini
http://gate.crashing.org/~trini/
On Tue, 6 Sep 2005, Tom Rini wrote:
> > Yep, it's an excuse for platform maintainers not to write proper drivers.
>
> I talked with Al about this off list a bit, and pointed out it's
> different than it appears. GEN_RTC really is a mostly-generic RTC
> driver. There's some fakey stuff going on for UIE (all under
> GEN_RTC_X), but the real meat of the driver is common export get/set
> time and per-arch (which can abstract further, see ppc32) poke the
> hardware for the time. There's 2 (afaik) problems, one being a lack of
> alarm support, and the other being hardware access isn't (today)
> abstracted out far enough for i2c stuff to work.
The generic problem with the generic driver is it only supports the bare
minimum an RTC might support and no way to provide access to what more
sophisticated hardware may implement (e.g. an IRQ). There is simply no
room for that in the API. And I have seen proposals for reducing the
MC146818 to GEN_RTC, too...
It's certainly good enough for simple implementations of RTCs, like a
battery backed-up 32-bit register counting milliseconds since the
beginning of the year (a so-called TOY clock).
Maciej
On Wed, Sep 07, 2005 at 07:06:25PM +0100, Maciej W. Rozycki wrote:
> On Tue, 6 Sep 2005, Tom Rini wrote:
>
> > > Yep, it's an excuse for platform maintainers not to write proper drivers.
> >
> > I talked with Al about this off list a bit, and pointed out it's
> > different than it appears. GEN_RTC really is a mostly-generic RTC
> > driver. There's some fakey stuff going on for UIE (all under
> > GEN_RTC_X), but the real meat of the driver is common export get/set
> > time and per-arch (which can abstract further, see ppc32) poke the
> > hardware for the time. There's 2 (afaik) problems, one being a lack of
> > alarm support, and the other being hardware access isn't (today)
> > abstracted out far enough for i2c stuff to work.
>
> The generic problem with the generic driver is it only supports the bare
> minimum an RTC might support and no way to provide access to what more
> sophisticated hardware may implement (e.g. an IRQ). There is simply no
> room for that in the API. And I have seen proposals for reducing the
> MC146818 to GEN_RTC, too...
Yes, that's in some ways a feature. Personally I tie IRQ support to
alarm, but perhaps that's just my lack of exposure.
--
Tom Rini
http://gate.crashing.org/~trini/