public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	sam@ravnborg.org
Subject: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers
Date: Sun, 22 Jul 2007 06:43:56 +0100	[thread overview]
Message-ID: <20070722054356.GO21668@ftp.linux.org.uk> (raw)
In-Reply-To: <20070721.192251.122832397.davem@davemloft.net>

	We have a problem - there are two rtc drivers for sparc; sbus and
ebus+isa respectively (drivers/sbus/char/rtc.c and drivers/char/rtc.c).  They
can be built into the kernel at the same time just fine; one that doesn't
find the hardware will STFU and bugger off, leaving the other free to register
misc device, etc.   As the matter of fact, that's what sparc64 defconfig
has.

	However, building both as modules runs into fun problems with
kbuild - we get
	drivers/char/rtc.o
	drivers/sbus/char/rtc.o
	drivers/sbus/char/rtc.mod.c
but no
	drivers/char/rtc.mod.c
and anything that depends on exports from the latter will get buggered.
E.g. we get
WARNING: "rtc_control" [sound/core/snd-rtctimer.ko] undefined!
WARNING: "rtc_unregister" [sound/core/snd-rtctimer.ko] undefined!
WARNING: "rtc_register" [sound/core/snd-rtctimer.ko] undefined!
on sparc64 allmodconfig build because of that.

	Aside of kbuild problems, how is userland supposed to deal with
two modules with the same name, anyway?

	There's another interesting question -
config SUN_MOSTEK_RTC
        tristate "Mostek real time clock support"
        help
          The Mostek RTC chip is used on all known Sun computers except
          some JavaStations. For a JavaStation you need to say Y both here
          and to "Enhanced Real Time Clock Support".
seems to imply that CONFIG_RTC has no business whatsoever on sparc64 builds,
let alone in defconfig - JavaStation had never gone sparc64.  OTOH, we
have explicit scanning ISA bus in addition to EBUS in drivers/char/rtc.c
in case of __sparc_v9__, so it looks like help above ought to be changed.
OTTH, the isa-scanning code looks odd - for comparison, FreeBSD has
the same logics for ebus (looks for node called "rtc"), but the isa probe
in the same driver (sys/sparc64/sparc64/rtc.c) is

static struct isa_pnp_id rtc_isa_ids[] = {
        { 0x000bd041, "AT realtime clock" }, /* PNP0B00 */
        { 0 }
};

static int
rtc_isa_probe(device_t dev)
{

        if (ISA_PNP_PROBE(device_get_parent(dev), dev, rtc_isa_ids) == 0) {
                device_set_desc(dev, "Real Time Clock");
                return (0);
        }

        return (ENXIO);
}

and they claim to find that one on Netra X1, where we seemed to get rtc_init:
no PC rtc found, if the boot logs I've been able to google are to be trusted.

Comments?  Sparc64 box I've got is sbus-only, so I've never touched the
drivers/char/rtc.c stuff - it doesn't find anything ebus anyway, since the
damn thing is simply note there...

  reply	other threads:[~2007-07-22  5:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-20 13:24 sparc64: ERROR: "sys_ioctl" [arch/sparc64/solaris/solaris.ko] undefined! Horst H. von Brand
2007-07-20 16:11 ` Christoph Hellwig
2007-07-22  2:22   ` David Miller
2007-07-22  5:43     ` Al Viro [this message]
2007-07-22  5:54       ` [RFC] Kconfig fun with sparc32/sparc64 rtc drivers David Miller
2007-07-22  6:19         ` Al Viro
2007-07-22  6:22           ` David Miller
2007-07-22  6:31             ` Al Viro
2007-07-22  6:35               ` Al Viro
2007-07-22  6:39                 ` David Miller
2007-07-22  7:22                   ` Al Viro
2007-07-22  7:26                     ` [PATCH] sparc32 missing exports Al Viro
2007-07-22  7:38                       ` David Miller
2007-07-22  7:37                     ` [RFC] Kconfig fun with sparc32/sparc64 rtc drivers David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070722054356.GO21668@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox