On Oct 22 Arnd Bergmann wrote:
On Thursday 22 October 2015 04:05:00 Amitoj Kaur Chawla wrote:
[...]
Reviewed-by: Arnd Bergmann arnd@arndb.de
(adding the y2038 mailing list as well)
Changes in v2: -Replaced timespec with timspec64 -Modified commit message -Used ktime_get_real_ts64() instead of getnstimeofday64()
[...]
--- a/drivers/firewire/nosy.c +++ b/drivers/firewire/nosy.c
[...]
@@ -413,17 +414,18 @@ static void packet_irq_handler(struct pcilynx *lynx)
[...]
- do_gettimeofday(&tv);
- lynx->rcv_buffer[0] = (__force __le32)tv.tv_usec;
- ktime_get_real_ts64(&ts64);
- timestamp = ts64.tv_nsec / NSEC_PER_USEC;
- lynx->rcv_buffer[0] = (__force __le32)timestamp;
Looks fine to me, but I have a question. It was possibly already discussed at patch v1, though that was apparently not posted to an open list.
include/linux/timekeeping.h says: #define ktime_get_real_ts64(ts) getnstimeofday64(ts)
kernel/time/timekeeping.c says: /** * do_gettimeofday - Returns the time of day in a timeval * @tv: pointer to the timeval to be set * * NOTE: Users should be converted to using getnstimeofday() */
So what is the reason for calling ktime_get_real_ts64() instead of getnstimeofday[64]()?
PS, note to self: Independently of this patch, I need to check whether CLOCK_REALTIME was really the right clock here, in contrast to CLOCK_MONOTONIC.