On Tue, Jan 12, 2016 at 11:53:29AM +0100, Arnd Bergmann wrote:
> On Friday 08 January 2016 09:47:39 Alison Schofield wrote:
> > divamnt stores a start_time at module init and uses it to calculate
> > elapsed time. That elapsed time, stored in secs and usecs, is part of
> > the trace data the driver maintains for the DIVA Server ISDN cards.
> > No change to the format of that time data is required.
> > 
> > To avoid overflow on 32-bit systems, change how time data is obtained:
> >         - replace struct timeval with struct timespec64
> >         - replace do_gettimeofday() with ktime_get_ts64()
> >         - use timespec64_sub() to calculate elapsed time
> > 
> > This is a change from real to monotonic time. Since the driver only
> > stores elapsed time, monotonic time is sufficient and more robust
> > against real time clock changes.
> > 
> > These time deltas are stored in unsigned 32 bits. This is safe as we
> > are always storing time deltas.
> > 
> > Remove declaration and init of unused time constants.
> > 
> > Signed-off-by: Alison Schofield <[email protected]>
> > 
> 
> Hi Alison,
> 
> I've finally gotten around to look at the patch, and it all looks correct
> to me in this version, so please post that to the appropriate maintainer
> lists now.
> 
> Reviewed-by: Arnd Bergmann <[email protected]>
> 
> I think there would be an alternative approach, by removing the 'start_time'
> completely and directly returning the time from ktime_get_ts64() here.
> This would make the returned time values slightly different, as they
> start at system boot time rather than driver load time, but it's only
> used for debugging, and the normal monotonic times are more useful for
> that (you can easily compare them to other timestamps).
> 
> If you want to do that instead, that is also fine with me.
> 
>       Arnd
Arnd, The alternative is simplest/cleanest. Gotta do it. Please review v3.
Thanks!
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038

Reply via email to