[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1511131043450.526@kaball.uk.xensource.com>
Date: Fri, 13 Nov 2015 10:45:13 +0000
From: Stefano Stabellini <stefano.stabellini@...citrix.com>
To: David Vrabel <david.vrabel@...rix.com>
CC: Stefano Stabellini <stefano.stabellini@...citrix.com>,
<xen-devel@...ts.xensource.com>, <Ian.Campbell@...rix.com>,
<linux-kernel@...r.kernel.org>, <boris.ostrovsky@...cle.com>,
<linux-arm-kernel@...ts.infradead.org>,
John Stultz <john.stultz@...aro.org>
Subject: Re: [Xen-devel] [PATCH v4 7/7] xen/x86: support XENPF_settime64
On Fri, 13 Nov 2015, David Vrabel wrote:
> On 12/11/15 17:30, Stefano Stabellini wrote:
> > Try XENPF_settime64 first, if it is not available fall back to
> > XENPF_settime32.
> >
> > No need to call __current_kernel_time() when all the info needed are
> > already passed via the struct timekeeper * argument.
> >
> > Return NOTIFY_BAD in case of errors.
> [...]
> > @@ -123,9 +124,13 @@ static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> > static struct timespec next_sync;
> >
> > struct xen_platform_op op;
> > - struct timespec now;
> > + struct timespec64 now;
> > + struct timekeeper *tk = priv;
> > + static bool settime64_supported = true;
> > + int ret;
> >
> > - now = __current_kernel_time();
> > + now.tv_sec = tk->xtime_sec;
> > + now.tv_nsec = (long)(tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift);
>
> I think you should introduce __current_kernel_time64() or make
> tk_xtime() available.
>
> John, what do you think?
We already had this discussion:
http://marc.info/?l=linux-kernel&m=144717103112014&w=2
http://marc.info/?l=linux-kernel&m=144724877203864&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists