[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1403130905130.18573@ionos.tec.linutronix.de>
Date: Thu, 13 Mar 2014 09:12:48 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: joeyli <jlee@...e.com>
cc: "H. Peter Anvin" <hpa@...or.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Julian Wollrath <jwollrath@....de>, x86@...nel.org,
LKML <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
John Stultz <john.stultz@...aro.org>, Ted Ts'o <tytso@....edu>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
On Thu, 13 Mar 2014, joeyli wrote:
> 於 三,2014-03-12 於 20:59 -0700,H. Peter Anvin 提到:
> > On 03/12/2014 08:55 PM, joeyli wrote:
> > >
> > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> > >
> >
> > Why would we use *both*!? How would that possibly make sense?
> >
> > -hpa
> >
>
> Yes, it does not make sense for using both.
>
> I switched the code in get_rtc_time() set_rtc_time() to TAD when it
> present, just make sure I'm on the right path.
No, you're not. get/set_rtc_time() is a complete trainwreck and as I
said before it should move into the rtc subsystem.
There is no reason at all to keep that stuff in the arch specific
code. It's there for historical reasons and that does not justify to
add more mess to it.
So the right thing to do is:
1) Add eventually missing functionality to the RTC subsystem
2) Move the arch specific cmos stuff to the rtc subsystem as proper
drivers
3) Add TAD there after #2 has been completed.
Any attempt to add TAD to arch/x86 is NACKed unconditionally.
Thanks,
tglx
Powered by blists - more mailing lists