From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Mark A. Greer" <mgreer@mvista.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
Date: Fri, 21 Jan 2005 11:01:12 +1100 [thread overview]
Message-ID: <1106265672.5387.14.camel@gaston> (raw)
In-Reply-To: <41F0449C.5020603@mvista.com>
On Thu, 2005-01-20 at 16:54 -0700, Mark A. Greer wrote:
> 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"?
Because it makes things like CONFIG_PPC_MULTIPLATFORM impossible, which
means you end up with a CONFIG_* mess.
I consider that more important than re-using code.
In any case, as I wrote, the proper solution is to update genrtc to
define rtc_ops so that you get both a) and b), it shouldn't be hard to
update the archs using it.
Ben.
next prev parent reply other threads:[~2005-01-21 0:02 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
2005-01-21 0:01 ` Benjamin Herrenschmidt [this message]
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=1106265672.5387.14.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mgreer@mvista.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.