From: David Brownell <david-b@pacbell.net>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] provide rtc_cmos platform device
Date: Thu, 22 May 2008 12:56:14 -0700 [thread overview]
Message-ID: <200805221256.14346.david-b@pacbell.net> (raw)
In-Reply-To: <4835C3DE.8070209@aknet.ru>
On Thursday 22 May 2008, Stas Sergeev wrote:
> David Brownell wrote:
> > Well, "regression" is the wrong phrase. You've switched
> > drivers (from the legacy RTC to the new one), so this is
> > not the thing which worked for you before.
> >
> I am not sure how could that happen.
> I am always just taking an old kernel
> config and never change the options
> that are not supposed to be changed.
> Was the old RTC driver removed by any
> chance?
The Kconfig was changed to prevent anyone from using
a particular broken configuration: using legacy RTC
drivers along with the new RTC framework.
Presumably your old config was broken in that way.
So I can see why it'd feel like a regression.
> >> This may also help running the
> >> PNP-enabled kernel on an older PCs.
> >
> > As in, pre-PNP. That's pretty darn old!
>
> But... I think they should still be
> supported, unless it is too difficult.
Sure. Having working hardware to test with is the
usual trouble here. Do you have such hardware?
(I didn't object to fixing that, at all; I was just
pointing out that hardware where this matters is not
particularly available any more, and hasn't been so
for quite a few years now.)
> > (1) On an ARM build (with no PNP configured):
>
> OK, but unfortunately I can't help
> with that. I won't touch any non-x86
> arch code, so I'll simply go for
> the #ifdef here, or someone else
> should make the patch instead. :)
Sure you can help; that's why I sent the compiler
messages telling what went wrong. You were
referencing symbols that are not defined on
non-pnp systems. All you have to do is provide
enough definitions to compile. For test builds
you can even #undef the CONFIG_PNP* symbols at
the top of the rtc-cmos code.
I understand Russell King has been sitting on a
similar patch (for the generic bits, not the x86
specific parts) for some time. Maybe you can get
his patch, which will surely work on ARM.
- Dave
> > You shouldn't define those symbols; the right values are already
> > defined in <asm/mc146818rtc.h>. RTC_PORT(0) and RTC_PORT(1) are
> > the symbolss to use; RTC_IRQ is already defined. All this stuff
> > is used in the <asm-generic/rtc.h> code ...
>
> OK, thanks.
> I'll update the patch, in todo for
> the week-end.
>
next prev parent reply other threads:[~2008-05-22 19:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 18:25 [patch] provide rtc_cmos platform device Stas Sergeev
2008-05-21 22:32 ` Andrew Morton
2008-05-22 19:05 ` Stas Sergeev
2008-05-22 19:56 ` David Brownell [this message]
2008-05-23 5:12 ` Stas Sergeev
2008-05-21 23:05 ` David Brownell
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=200805221256.14346.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stsp@aknet.ru \
/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.