Re: [PATCH v2] firewire: Replace timeval with timespec64

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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.
-- 
Stefan Richter
-=====-===== =-=- =-==-
http://arcgraph.de/sr/