[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5645BE8C.6050109@citrix.com>
Date: Fri, 13 Nov 2015 10:42:20 +0000
From: David Vrabel <david.vrabel@...rix.com>
To: Stefano Stabellini <stefano.stabellini@...citrix.com>,
<xen-devel@...ts.xensource.com>
CC: <Ian.Campbell@...rix.com>, <linux-kernel@...r.kernel.org>,
<david.vrabel@...rix.com>, <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 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?
David
--
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