From: "Mark A. Greer" <mgreer@mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
Date: Thu, 20 Jan 2005 16:54:04 -0700 [thread overview]
Message-ID: <41F0449C.5020603@mvista.com> (raw)
In-Reply-To: <1106259956.18397.10.camel@gaston>
Benjamin Herrenschmidt wrote:
>
>The patch is going backward since it disables the ability to have
>runtime selection of the RTC chip.
>
Its only "backwards" from a narrow PPC point of view. Without a major
rewrite of the rtc infrastructure, these are the choices:
a) Make a ppc-only solution using ppc_md.xxx.
b) Make a generic solution either by writing an entire driver
duplicating code that's in genrtc (e.g., ds1302) or interface to the
bottom of genrtc (e.g., my rtc code). The only limitation is that you
can't select different rtc chips at runtime.
Choosing a) give you more flexibility within PPC but is PPC only;
choosing b) is generic but assumes its the only rtc chip that will be
used by whatever kernel binary its put in.
I chose b) and to reuse the genrtc code. In a sane world, reusing code
is considered a good thing...
Its obvious that you and Tom prefer a). That's fine but if I switch to
a), I know the first comment I'll get when I post the driver to lmkl
will be, "Why would you make this ppc-specific when you could have made
it generic?" Will you and Tom then defend that decision for me?
Also, this is not board-specific as you and Tom have tried to suggest.
Assuming I change the #ifdef in rtc.h to remove the option as I think
Tom and I are agreeing upon, you select the i2c algo/adapter, the
i2c/rtc client and its there. Where are the "gross hacks for every board"?
Mark
next prev parent reply other threads:[~2005-01-20 23:54 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
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 [this message]
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=41F0449C.5020603@mvista.com \
--to=mgreer@mvista.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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).