On Sun, 4 Sep 2016, Chen Yu wrote:
> Hi Thomas, Rafael,
> On Fri, Sep 02, 2016 at 09:26:51PM +0200, Thomas Gleixner wrote:
> > On Wed, 31 Aug 2016, Rafael J. Wysocki wrote:
> > > On Monday, August 29, 2016 12:40:39 AM Chen Yu wrote:
> > > > +
> > > > + /*
> > > > + * Make rtc-based persistent clock unusable
> > > > + * if pm_trace is enabled, only take effect
> > > > + * for timekeeping_suspend/resume.
> > > > + */
> > > > + if (pm_trace_is_enabled() &&
> > > > + x86_platform.get_wallclock == mach_get_cmos_time) {
> > > > + ts->tv_sec = 0;
> > > > + ts->tv_nsec = 0;
> > > > + }
> > >
> > > I'm not sure about this. Looks hackish.
> >
> > Indeed. Can't you just keep track that pm_trace fiddled with the cmos clock
> > and then discard the value either in the core or in mach_get_cmos_time()
> The previous version is more straightforward, since
> it ignored the bogus rtc in core. Would you please take
> a glance at it too, thanks:
> https://patchwork.kernel.org/patch/9287347/
This is the same hackery just different:
> +bool persistent_clock_is_usable(void)
> +{
> + /* Unusable if pm_trace is enabled. */
> + return !((x86_platform.get_wallclock == mach_get_cmos_time) &&
> + pm_trace_is_enabled());
> +}
I really have no idea why this is burried in x86 land. The pm_trace hackery
issues mc146818_set_time() to fiddle with the RTC. So any implementation of
this is affected.
So that very piece of pmtrace code should keep track of the wreckage it did
to the RTC and provide the fact to the core timekeeping code which can then
skip the update.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html