On Thu, Apr 02, 2015 at 12:06:56AM +, Keller, Jacob E wrote:
> I don't know how kernel would fix this. Usually macros like PRI64d are used
> but I am not sure those are defined for the kernel builds
Davem fixed it by casting to (long long).
Thanks,
Richard
--
To unsubscribe from this list:
On Thu, Apr 02, 2015 at 12:06:56AM +, Keller, Jacob E wrote:
I don't know how kernel would fix this. Usually macros like PRI64d are used
but I am not sure those are defined for the kernel builds
Davem fixed it by casting to (long long).
Thanks,
Richard
--
To unsubscribe from this list:
> frank...@freescale.com; net...@vger.kernel.org; mc...@broadcom.com;
> Wyborny, Carolyn; prash...@broadcom.com; da...@davemloft.net;
> Kirsher, Jeffrey T; stefan.soren...@spectralink.com; john.stu...@linaro.org
> Subject: Re: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit
> get/set tim
Thomas Gleixner; Tom Lendacky
> Subject: Re: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit
> get/set time methods.
>
> On Sun, Mar 29, 2015 at 11:12:03PM +0200, Richard Cochran wrote:
>
> > @@ -627,11 +628,11 @@ static void igb_ptp_overflow_check(struct
> wor
: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit
get/set time methods.
On Sun, Mar 29, 2015 at 11:12:03PM +0200, Richard Cochran wrote:
@@ -627,11 +628,11 @@ static void igb_ptp_overflow_check(struct
work_struct *work)
{
struct igb_adapter *igb =
container_of
...@broadcom.com;
Wyborny, Carolyn; prash...@broadcom.com; da...@davemloft.net;
Kirsher, Jeffrey T; stefan.soren...@spectralink.com; john.stu...@linaro.org
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 +, Keller
On Sun, Mar 29, 2015 at 11:12:03PM +0200, Richard Cochran wrote:
> @@ -627,11 +628,11 @@ static void igb_ptp_overflow_check(struct work_struct
> *work)
> {
> struct igb_adapter *igb =
> container_of(work, struct igb_adapter, ptp_overflow_work.work);
> - struct timespec
On Tue, Mar 31, 2015 at 09:08:10PM +, 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
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.
On Tue, Mar 31, 2015 at 09:08:10PM +, 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
On Sun, Mar 29, 2015 at 11:12:03PM +0200, Richard Cochran wrote:
@@ -627,11 +628,11 @@ static void igb_ptp_overflow_check(struct work_struct
*work)
{
struct igb_adapter *igb =
container_of(work, struct igb_adapter, ptp_overflow_work.work);
- struct timespec ts;
+
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.
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
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
14 matches
Mail list logo
