[PATCH] Kconfig fix (GEN_RTC dependencies)

[PATCH] Kconfig fix (GEN_RTC dependencies)

[viro]

	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 <viro@zeniv.linux.org.uk>
----
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

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[David S. Miller]

From: viro@ZenIV.linux.org.uk
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 <viro@zeniv.linux.org.uk>

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.

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[viro]

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

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[Maciej W. Rozycki]

On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk 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

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[Tom Rini]

On Tue, Sep 06, 2005 at 03:40:47PM +0100, Maciej W. Rozycki wrote:
> On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk 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/

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[Maciej W. Rozycki]

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

Re: [PATCH] Kconfig fix (GEN_RTC dependencies)

[Tom Rini]

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/