From: "Mark A. Greer" <mgreer@mvista.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
Date: Thu, 20 Jan 2005 16:21:14 -0700 [thread overview]
Message-ID: <41F03CEA.2030703@mvista.com> (raw)
In-Reply-To: <20050120225321.GB2626@smtp.west.cox.net>
Tom Rini wrote:
>So you're saying that using the hook directly isn't a different hook? I
>suppose we can agree to disagree, since it's not relevant really :)
>
Well, I could have not used genrtc at all and duplicated the code like
others have (e.g., ds1302 and ip27-rtc.c) but I chose to reuse code
that's already there and debugged. Chosing to interface to genrtc
instead of ppc_md.xxx is chosing to have it work on a wider variety of
platforms over flexibility within one particular type of platform. Pros
and cons to each.
>It can't work on PPC/MULTIPLATFORM as that's a kernel with multiple rtc
>chips in one binary (pmac, todc for prep, chrp?).
>
The point I was making is there there is nothing precluding a kernel
that runs on several boards from using it as long as that's the rtc chip
on all the platforms Its already clear that if there are different rtc
chips, it won't work.
>
>Why ask the user for something you know he wants? If they've selected
>GENRTC and are using the board, they'll probably want GENRTC to work.
>It's exactly what you described except the user won't have to know about
>anything going on.
>
If that's the way you want to go then it should depend on having the rtc
"driver" selected and rtc.h should look something like:
#if defined(CONFIG_I2C_<rtc_driver_a>) || defined(CONFIG_<rtc_driver_b> ...
For now, it would only have to be #ifdef CONFIG_xxx_M41T00
That's fine with me.
next prev parent reply other threads:[~2005-01-20 23:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-17 21:10 [RFC] Option to disable mapping genrtc calls to ppc_md calls Mark A. Greer
2005-01-18 9:20 ` Geert Uytterhoeven
2005-01-18 18:40 ` Mark A. Greer
2005-01-18 19:01 ` Eugene Surovegin
2005-01-18 16:15 ` Tom Rini
2005-01-18 16:25 ` Dan Malek
2005-01-18 17:39 ` Tolunay Orkun
2005-01-18 18:33 ` Tom Rini
2005-01-18 18:13 ` Tom Rini
2005-01-18 18:58 ` Mark A. Greer
2005-01-18 19:08 ` Tom Rini
2005-01-18 19:43 ` Mark A. Greer
2005-01-19 18:08 ` Tom Rini
2005-01-20 20:52 ` Mark A. Greer
2005-01-20 22:53 ` Tom Rini
2005-01-20 23:21 ` Mark A. Greer [this message]
2005-01-20 23:47 ` Tom Rini
2005-01-20 23:56 ` Mark A. Greer
2005-01-18 18:54 ` Eugene Surovegin
2005-01-20 22:27 ` Benjamin Herrenschmidt
2005-01-18 18:55 ` Mark A. Greer
2005-01-18 19:05 ` Tom Rini
2005-01-18 19:33 ` Mark A. Greer
2005-01-20 22:25 ` Benjamin Herrenschmidt
2005-01-20 23:54 ` Mark A. Greer
2005-01-21 0:01 ` Benjamin Herrenschmidt
2005-01-21 0:09 ` Mark A. Greer
2005-01-21 0:12 ` Benjamin Herrenschmidt
2005-01-21 9:14 ` Geert Uytterhoeven
2005-01-21 14:39 ` Corey Minyard
2005-01-21 22:01 ` Benjamin Herrenschmidt
2005-01-21 9:44 ` Christoph Hellwig
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=41F03CEA.2030703@mvista.com \
--to=mgreer@mvista.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=trini@kernel.crashing.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;
as well as URLs for NNTP newsgroup(s).