2015-04-02 00:08:19

by Jacob Keller

[permalink] [raw]
Subject: RE: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit get/set time methods.

> -----Original Message-----
> From: Richard Cochran [mailto:[email protected]]
> Sent: Tuesday, March 31, 2015 2:37 PM
> To: Keller, Jacob E
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; Allan, Bruce W; [email protected];
> [email protected]; [email protected]; [email protected]; Vick,
> Matthew; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> Wyborny, Carolyn; [email protected]; [email protected];
> Kirsher, Jeffrey T; [email protected]; [email protected]
> Subject: Re: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit
> get/set time methods.
>
> On Tue, Mar 31, 2015 at 09:08:10PM +0000, Keller, Jacob E wrote:
> > On Sun, 2015-03-29 at 23:12 +0200, Richard Cochran wrote:
> > > For the 82576, the driver's clock is implemented using a timecounter,
> > > and so with this patch that device is ready for the year 2038.
> > >
> > > However, in the case of the i210, the device stores the number of
> > > seconds in a 32 bit register. Therefore, more work is needed on this
> > > driver before the year 2038 comes around.
> > >
> > > Compile tested only.
> >
> > I assume we would want to use a time counter wrapper here to resolve
> > this issue?
>
> I would just keep the seconds in software for settime() and adjtime(),
> but let the nanoseconds field go to the hardware. Then, the gettime()
> result, the periodic outputs, the external time stamps, and the skb
> time stamps will need to be corrected by that many seconds.
>
> Thanks,
> Richard

That seems reasonable.

Regards,
Jake