From: "Mark A. Greer" <mgreer@mvista.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: avolkov@varma-el.com, "Mark A. Greer" <mgreer@mvista.com>,
LM Sensors <lm-sensors@lm-sensors.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] Added support of ST m41t85 rtc chip
Date: Wed, 16 Nov 2005 14:24:47 -0700 [thread overview]
Message-ID: <20051116212447.GE30014@mag.az.mvista.com> (raw)
In-Reply-To: <6dEExmJ9.1132154398.1580970.khali@localhost>
On Wed, Nov 16, 2005 at 04:19:58PM +0100, Jean Delvare wrote:
<snip>
> This is why you want to move the decision at the run time level rather
> than the compilation time level whenever possible. The clock output
> option can't be a configuration option. I previously suggested a sysfs
> file, because this gives the greatest flexibility. If you don't like
> the idea for whatever reason, you may go for a module parameter instead.
>
> Same reasonment holds for the m41t00 vs. m41t85 choice. You can't decide
> at compilation time. If we go for a common driver, it has to support
> both devices at the same time. Mark suggested to use platform-specific
> data. I'm not familiar with this, but it sounds reasonable.
I don't know the entire history behind platform_data but my
understanding is that it was designed to provide a mechanism for
platform-specific code to pass info to drivers.
I *believe* that this would be a proper use of platform_data but I'm
hoping someone out in lkml-land who knows better than I will confirm that.
> I don't know for sure at this point whether having a single driver is
> the right choice, I'll let you and Mark check it out and decide. But
> the right way to determine this is definitely not through the use of
> #if/#endif preprocessing stuff.
I agree. We can and absolutely should do this at run-time if a merged
driver is feasible. I'll dig thru the datasheets today and start
prototyping some code if it looks like we can merge the code.
Mark
next prev parent reply other threads:[~2005-11-16 21:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-14 13:50 [PATCH 1/1] Added support of ST m41t85 rtc chip Andrey Volkov
2005-11-15 0:41 ` Andrew Morton
2005-11-15 21:24 ` Andrey Volkov
2005-11-15 20:52 ` Jean Delvare
2005-11-15 21:48 ` Andrey Volkov
2005-11-16 3:15 ` Mark A. Greer
2005-11-16 14:50 ` Andrey Volkov
2005-11-16 18:55 ` Andy Isaacson
2005-11-16 22:24 ` Mark A. Greer
2005-11-18 20:35 ` Mark A. Greer
2005-11-21 12:35 ` Andrey Volkov
2005-12-06 21:18 ` Mark A. Greer
2005-11-16 2:57 ` Mark A. Greer
2005-11-16 14:45 ` Andrey Volkov
2005-11-16 15:19 ` Jean Delvare
2005-11-16 16:43 ` Andrey Volkov
2005-11-16 21:36 ` Mark A. Greer
2005-11-17 9:20 ` Jean Delvare
2005-11-16 21:24 ` Mark A. Greer [this message]
2005-12-19 21:03 ` [RFC] i2c: Combined ST m41txx i2c rtc chip driver (was: [PATCH 1/1] Added support of ST m41t85 rtc chip) Mark A. Greer
2005-12-19 21:06 ` Mark A. Greer
2005-12-20 10:05 ` [RFC] i2c: Combined ST m41txx i2c rtc chip driver Andrey Volkov
2005-12-21 21:25 ` Mark A. Greer
[not found] ` <20060111000912.GA11471@mag.az.mvista.com>
[not found] ` <43C4D275.2070505@varma-el.com>
[not found] ` <20060111161954.GB6405@mag.az.mvista.com>
2006-01-11 19:03 ` Andrey Volkov
2006-01-18 22:06 ` Mark A. Greer
2006-01-19 7:25 ` Jean Delvare
2006-01-26 2:01 ` Mark A. Greer
2006-01-26 20:50 ` Mark A. Greer
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=20051116212447.GE30014@mag.az.mvista.com \
--to=mgreer@mvista.com \
--cc=avolkov@varma-el.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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).