[RFC net-next 14/22] ptp: mlx4: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)

[RFC net-next 02/22] ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl.

This patch changes the code to use the new method whenever implemented by the PHC driver. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_chardev.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c

[RFC net-next 19/22] ptp: dp83640: convert to the 64 bit get/set time methods.

This device stores the number of seconds in a 32 bit register. So more work is needed on this driver before the year 2038 comes around. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/phy/dp83640.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff

[RFC net-next 22/22] ptp: remove 32 bit get/set methods.

. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_chardev.c|8 +--- drivers/ptp/ptp_clock.c | 12 ++-- include/linux/ptp_clock_kernel.h |8 3 files changed, 11 insertions(+), 17 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp

[RFC net-next 20/22] ptp: ixp46x: convert to the 64 bit get/set time methods.

The device has a 64 bit clock register, where each clock tick is 16 nanoseconds, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_ixp46x.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/ptp

[RFC net-next 17/22] ptp: cpts: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/ti/cpts.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --

[RFC net-next 18/22] ptp: tilegx: convert to the 64 bit get/set time methods.

This driver calls code (via gxio_mpipe_get/set_timestamp) that makes the assumption that the tv_sec field is 64 bits wide. So apparently this driver is 64 bit only. So maybe this driver and device are ready for 2038, but maybe not. Not even compile tested. Signed-off-by: Richard Cochran

[RFC net-next 13/22] ptp: ixgbe: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++--- 1 file changed, 7 insertions(+), 7 dele

[RFC net-next 16/22] ptp: stmmac: convert to the 64 bit get/set time methods.

This device stores the number of seconds in a 32 bit register. So more work is needed on this driver before the year 2038 comes around. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8 1 file changed, 4 insertions(+), 4

[RFC net-next 11/22] ptp: i40e: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +- 1 file changed, 13 insertions

[RFC net-next 03/22] ptp: blackfin: convert to the 64 bit get/set time methods.

The device uses 64 bit nanoseconds register, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/net/ethernet/adi/bfin_mac.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/adi/bfin_mac.c b

[RFC net-next 08/22] ptp: gianfar: convert to the 64 bit get/set time methods.

The device features a 64 bit nanoseconds register, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net

[RFC net-next 10/22] ptp: fm10k: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

[RFC net-next 05/22] ptp: bnx2x: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 1 file changed, 4 insertions(+), 4 deletions(-)

[RFC net-next 04/22] ptp: xgbe: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)

[RFC net-next 06/22] ptp: tg3: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/tg3.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[RFC net-next 01/22] ptp: introduce get/set time methods with explicit 64 bit seconds.

Converting the PHC drivers over to the new methods is one step along the way to making them ready for 2038. Once all the drivers are up to date, then the old methods will be removed. Signed-off-by: Richard Cochran --- include/linux/ptp_clock_kernel.h | 12 ++-- 1 file changed, 10

Re: [RFC net-next 22/22] ptp: remove 32 bit get/set methods.

On Sat, Mar 21, 2015 at 09:59:52PM +0100, Richard Cochran wrote: > diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c > index 296b0ec..2665360 100644 > --- a/drivers/ptp/ptp_clock.c > +++ b/drivers/ptp/ptp_clock.c > @@ -107,13 +107,21 @@ static int ptp_clock_getres(str

[PATCH net-next V2 04/23] ptp: blackfin: convert to the 64 bit get/set time methods.

The device uses 64 bit nanoseconds register, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/net/ethernet/adi/bfin_mac.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/adi/bfin_mac.c b

[PATCH net-next V2 01/23] ptp: introduce get/set time methods with explicit 64 bit seconds.

Converting the PHC drivers over to the new methods is one step along the way to making them ready for 2038. Once all the drivers are up to date, then the old methods will be removed. Signed-off-by: Richard Cochran --- include/linux/ptp_clock_kernel.h | 12 ++-- 1 file changed, 10

[PATCH net-next V2 07/23] ptp: tg3: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/tg3.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH net-next V2 12/23] ptp: i40e: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/i40e/i40e_ptp.c | 26 +- 1 file changed, 13 insertions

[PATCH net-next V2 19/23] ptp: tilegx: convert to the 64 bit get/set time methods.

This driver calls code (via gxio_mpipe_get/set_timestamp) that makes the assumption that the tv_sec field is 64 bits wide. So apparently this driver is 64 bit only. So maybe this driver and device are ready for 2038, but maybe not. Not even compile tested. Signed-off-by: Richard Cochran

[PATCH net-next V2 23/23] ptp: remove 32 bit get/set methods.

. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_chardev.c|8 +--- drivers/ptp/ptp_clock.c | 15 --- include/linux/ptp_clock_kernel.h |8 3 files changed, 5 insertions(+), 26 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp

[PATCH net-next V2 11/23] ptp: fm10k: convert to the 64 bit get/set time methods.

The device appears to use a 64 bit nanoseconds register, and so with this patch the driver should be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/fm10k/fm10k_ptp.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

[PATCH net-next V2 14/23] ptp: ixgbe: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++--- 1 file changed, 7 insertions(+), 7 dele

[PATCH net-next V2 20/23] ptp: dp83640: convert to the 64 bit get/set time methods.

This device stores the number of seconds in a 32 bit register. So more work is needed on this driver before the year 2038 comes around. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/phy/dp83640.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff

[PATCH net-next V2 22/23] ptp: pch: convert to the 64 bit get/set time methods.

The device has a 64 bit clock register, where each clock tick is 32 nanoseconds, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_pch.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff

[PATCH net-next V2 21/23] ptp: ixp46x: convert to the 64 bit get/set time methods.

The device has a 64 bit clock register, where each clock tick is 16 nanoseconds, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_ixp46x.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/ptp

[PATCH net-next V2 16/23] ptp: sfc: convert to the 64 bit get/set time methods.

This patch changes the driver to use the newer API. Depending on how the hardware represents a time value, this driver may or may not yet be ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/sfc/ptp.c | 22 +++--- 1 file

[PATCH net-next V2 18/23] ptp: cpts: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/ti/cpts.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --

[PATCH net-next V2 17/23] ptp: stmmac: convert to the 64 bit get/set time methods.

This device stores the number of seconds in a 32 bit register. So more work is needed on this driver before the year 2038 comes around. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8 1 file changed, 4 insertions(+), 4

[PATCH net-next V2 13/23] ptp: igb: convert to the 64 bit get/set time methods.

2038 comes around. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++--- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/inte

[PATCH net-next V2 15/23] ptp: mlx4: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)

[PATCH net-next V2 09/23] ptp: gianfar: convert to the 64 bit get/set time methods.

The device features a 64 bit nanoseconds register, and so with this patch the driver is ready for the year 2038. Signed-off-by: Richard Cochran --- drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net

[PATCH net-next V2 10/23] ptp: e1000e: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/e1000e/ptp.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)

[PATCH net-next V2 06/23] ptp: bnx2x: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 1 file changed, 4 insertions(+), 4 deletions(-)

[PATCH net-next V2 08/23] ptp: fec: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/freescale/fec_ptp.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --

[PATCH net-next V2 00/23] ptp: get ready for 2038

maintainers for a review. Thanks, Richard * ChangeLog ** V2 - use the new methods in the posix clock code right away (patch #3) Richard Cochran (23): ptp: introduce get/set time methods with explicit 64 bit seconds. ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl. ptp: use

[PATCH net-next V2 05/23] ptp: xgbe: convert to the 64 bit get/set time methods.

This driver's clock is implemented using a timecounter, and so with this patch the driver is ready for the year 2038. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)

[PATCH net-next V2 03/23] ptp: use the 64 bit get/set time methods for the posix clock.

This patch changes the posix clock code to prefer the new methods whenever they are implemented by the PHC drivers. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_clock.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/ptp/ptp_clock.c b

[PATCH net-next V2 02/23] ptp: use the 64 bit gettime method for the SYS_OFFSET ioctl.

This patch changes the code to use the new method whenever implemented by the PHC driver. Signed-off-by: Richard Cochran --- drivers/ptp/ptp_chardev.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c

Re: [PATCH net-next V2 04/23] ptp: blackfin: convert to the 64 bit get/set time methods.

On Sun, Mar 22, 2015 at 03:28:46AM +0100, Arnd Bergmann wrote: > I think it would be good to replace the open-coded > > ns = ts->tv_sec * 10ULL; > ns += ts->tv_nsec; > > here with a call to ns_to_timespec64(), here and in other drivers that you > are already touching. Ye

Re: [PATCH net-next V2 20/23] ptp: dp83640: convert to the 64 bit get/set time methods.

On Sun, Mar 22, 2015 at 03:36:31AM +0100, Arnd Bergmann wrote: > On Saturday 21 March 2015, Richard Cochran wrote: > > mutex_lock(&clock->extreg_lock); > > > > - err = tdr_write(1, phydev, ts, PTP_LOAD_CLK); > > + err = tdr_

Re: [PATCH net-next V2 20/23] ptp: dp83640: convert to the 64 bit get/set time methods.

On Sun, Mar 22, 2015 at 06:48:02PM +0100, Arnd Bergmann wrote: > Ok, got it. The code looks correct then, though I'd like to see the use > of 'timespec' pushed out as far as possible. How about changing the > type for tdr_write() as well here? > > tdr_write() itself should be fine until 2106, as i

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

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: s

Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

On Wed, Apr 22, 2015 at 10:45:23AM +0200, Thomas Gleixner wrote: > So we could save one translation step if we implement new syscalls > which have a scalar nsec interface instead of the timespec/timeval > cruft and let user space do the translation to whatever it wants. +1 > I personally would we

Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote: > time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, > getitimer, setitimer: > all deprecated => wontfix If adjtimex is deprecated, what will replace it? It is really important for ntp. Thanks, Richard -- To unsubscribe

[PATCH net-next 02/11] ptp: bnx2x: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff

[PATCH net-next 05/11] ptp: gianfar: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Signed-off-by: Richard Cochran --- drivers/net/ethernet/freescale/gianfar_ptp.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net

[PATCH net-next 01/11] ptp: blackfin: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Signed-off-by: Richard Cochran --- drivers/net/ethernet/adi/bfin_mac.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/adi

[PATCH net-next 06/11] ptp: e1000e: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/e1000e/ptp.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel

[PATCH net-next 11/11] ptp: cpts: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/ti/cpts.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net

[PATCH net-next 10/11] ptp: stmmac: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet

[PATCH net-next 09/11] ptp: mlx4: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/mellanox/mlx4/en_clock.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet

[PATCH net-next 07/11] ptp: igb: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/igb/igb_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a

[PATCH net-next 04/11] ptp: fec: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/freescale/fec_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a

[PATCH net-next 08/11] ptp: ixgbe: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() and timespec64_to_ns() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH net-next 03/11] ptp: tg3: use helpers for converting ns to timespec.

This patch changes the driver to use ns_to_timespec64() instead of open coding the same logic. Compile tested only. Signed-off-by: Richard Cochran --- drivers/net/ethernet/broadcom/tg3.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/broadcom/tg3

[PATCH net-next 00/11] remove open coded ns_to_timespec64 and reverse

Richard Cochran (11): ptp: blackfin: use helpers for converting ns to timespec. ptp: bnx2x: use helpers for converting ns to timespec. ptp: tg3: use helpers for converting ns to timespec. ptp: fec: use helpers for converting ns to timespec. ptp: gianfar: use helpers for converting ns to

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, 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. > > &

Re: [PATCH net-next 00/11] remove open coded ns_to_timespec64 and reverse

On Tue, Mar 31, 2015 at 09:11:30PM +, Keller, Jacob E wrote: > For all the Intel drivers, this looks fine. I'm surprised I never > noticed before. I think the helpers appeared only after the first PHC drivers. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-

Re: [PATCH net-next V3 10/23] ptp: e1000e: convert to the 64 bit get/set time methods.

On Sun, Mar 29, 2015 at 11:12:00PM +0200, Richard Cochran wrote: > @@ -171,11 +171,11 @@ static void e1000e_systim_overflow_work(struct > work_struct *work) > struct e1000_adapter *adapter = container_of(work, struct e100

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 work_struct > *work) > { > struct igb_adapter *igb = > container_of(work, struct igb_adapter, ptp_overflow_work.work); > -

Re: [PATCH 11/11] k_clock:Remove the 32bit methods with timespec type

On Mon, Apr 20, 2015 at 01:57:39PM +0800, Baolin Wang wrote: > @@ -911,18 +907,14 @@ retry: > return -EINVAL; > > kc = clockid_to_kclock(timr->it_clock); > - if (WARN_ON_ONCE(!kc || (!kc->timer_set && !kc->timer_set64))) { > + if (WARN_ON_ONCE(!kc || !kc->timer_set64)

Re: [GIT PULL] kdbus for 4.1-rc1

On Mon, Apr 20, 2015 at 11:46:51PM +0200, Greg Kroah-Hartman wrote: > As was pointed out, even the tiny IoT devices running Linux are now > using D-Bus, it's everywhere :) I would like to take issue with that assertion. Some people are putting dbus and systemd into embedded devices, but not into

Re: [PATCH 4/5] ntp: Do leapsecond adjustment in adjtimex read path

John, The description is just awful. On Thu, Jun 11, 2015 at 03:54:56PM -0700, John Stultz wrote: > Since the leapsecond is applied at tick-time, this > means there is a small window of time at the start > of a leap-second where we cross into the next second > before applying the leap. First you

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On Thu, Jun 04, 2015 at 10:31:45AM +0200, Michal Suchanek wrote: > You might want to try to run the bus at 60MHz or 80MHz and then the > values would probably again be different. > > The first two values are set in DT so the logical place for setting > the third is also in DT. > > Otherwise you w

Re: [PATCH] Doc: networking: txtimestamp: fix printf format warning

On Wed, Jun 03, 2015 at 09:38:39PM +0200, Frans Klaver wrote: > Documentation/networking/timestamping/txtimestamp.c: In function > ‘__print_timestamp’: > Documentation/networking/timestamping/txtimestamp.c:99:3: warning: format > ‘%ld’ expects argument of type ‘long int’, but argument 3 has type

Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths

On Fri, Jun 05, 2015 at 09:29:13AM +0200, Peter Zijlstra wrote: > That leaves the question; for who is this exact second edge important? Distributed applications using the UTC time scale. Many control applications are done with a 1 millisecond period. Having the time wrong by a second for 10 or 1

Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths

On Fri, Jun 05, 2015 at 11:10:08AM +0200, Peter Zijlstra wrote: > Firstly I would strongly suggest such applications not use UTC because > of this, I think TAI was invented for just this reason. So I wonder whether the bug in the original post affects TAI timers as well... > Secondly, how would J

Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths

On Fri, Jun 05, 2015 at 09:29:13AM +0200, Peter Zijlstra wrote: > That leaves the question; for who is this exact second edge important? Another one: data loggers for scientific applications using UTC time stamps. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-

Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths

On Fri, May 29, 2015 at 01:24:28PM -0700, John Stultz wrote: > Apologies to Richard Cochran, who pushed for such a change > years ago, which I resisted due to the concerns about the > performance overhead. For the record, I got the idea from Michel Hack of IBM. > While I suspec

Re: PTP clock driver for FSL DPAA

On Tue, May 22, 2018 at 10:07:20AM +, Y.b. Lu wrote: > I'm going to make a PTP clock driver patch for FSL DPAA ethernet controller. > (drivers/net/ethernet/freescale/dpaa/) > Actually the 1588 timer module on FSL DPAA is same with the one on FSL eTSEC > in hardware.(whose PTP clock driver is

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Thu, Mar 29, 2018 at 09:37:15AM -0500, Andy Gross wrote: > > If you aren't actually testing/validating this specific board, how can you > make > a statement like this? Unless you have tested these specifically on this > board, > I'd appreciate not getting false information about what is or i

Re: [PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

On Thu, Mar 29, 2018 at 09:37:15AM -0500, Andy Gross wrote: > > Feel free to send your own contributions where you are adding the things that > are important to you. You can count on it. I am really happy that ipq4019 at least boots mainline. BTW is there any hope of getting a working mainline

Re: [PATCH] ptp_pch: use helpers function for converting between ns and timespec

On Fri, Apr 27, 2018 at 03:36:18PM +0800, YueHaibing wrote: > use ns_to_timespec64() and timespec64_to_ns() instead of open coding Acked-by: Richard Cochran

Re: [PATCH 1/5] ptp: rework gianfar_ptp as QorIQ common PTP driver

es. > > Signed-off-by: Yangbo Lu For the series: Acked-by: Richard Cochran

Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping

On Mon, Jun 04, 2018 at 03:08:36PM +0800, Yangbo Lu wrote: > +if FSL_DPAA_ETH > +config FSL_DPAA_ETH_TS > + bool "DPAA hardware timestamping support" > + select PTP_1588_CLOCK_QORIQ > + default n > + help > + Enable DPAA hardware timestamping support. > + This option is

Re: [BUG] igb: reconnecting of cable not always detected

On Tue, Apr 24, 2018 at 11:09:02AM -0700, Alexander Duyck wrote: > On Tue, Apr 24, 2018 at 8:14 AM, Holger Schurig > wrote: > > Sometimes, plugging the cable back in is detected ... > > > > [ 43.736922] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps > > Full Duplex, Flow Control: RX

Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping

On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote: > +/* PTP nominal frequency 1GHz */ > +#define DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS 1 Nit: Frequency is the inverse of the period. It can be one or the other, not both. Why not call it simply DPAA2_PTP_CLK_PERIOD_NS? You haven't implemente

Re: [PATCH net-next 1/2] ptp: ptp_clockmatrix: Add wait_for_sys_apll_dpll_lock.

_adj[MAX_OUTPUT][4]; > }; Looks like this removal is unrelated to the patch subject, and so it deserves its own small patch. Acked-by: Richard Cochran

Re: [PATCH net-next 2/2] ptp: ptp_clockmatrix: Add alignment of 1 PPS to idtcm_perout_enable.

On Thu, Feb 11, 2021 at 11:38:45PM -0500, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > When enabling output using PTP_CLK_REQ_PEROUT, need to align the output > clock to the internal 1 PPS clock. > > Signed-off-by: Vincent Cheng Acked-by: Richard Cochran

Re: [PATCH 1/1] net: fec: ptp: avoid register access when ipg clock is disabled

On Tue, Feb 23, 2021 at 09:00:32AM +0100, Heiko Thiery wrote: > HI Jakub, > > Am Di., 23. Feb. 2021 um 04:00 Uhr schrieb Jakub Kicinski : > > Why is the PTP interface registered when it can't be accessed? > > > > Perhaps the driver should unregister the PTP clock when it's brought > > down? I don

Re: [PATCH 1/1] net: fec: ptp: avoid register access when ipg clock is disabled

On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote: > It is not only the PHC clock that stops. Rather, it is the entire > ethernet building block in the SOC that is disabled, including the > PHC. Sure, but why does the driver do that? Thanks, Richard

Re: [PATCH 1/1] net: fec: ptp: avoid register access when ipg clock is disabled

On Thu, Feb 25, 2021 at 03:05:32PM +0100, Heiko Thiery wrote: > But the explanation why it is currently disabled that way can be found > in the commit 91c0d987a9788dcc5fe26baafd73bf9242b68900. Okay, without re-factoring the entire driver, I agree that the gettime lock up aught to be fixed in a si

Re: [PATCH v2 1/1] net: fec: ptp: avoid register access when ipg clock is disabled

gt; - add mutex (thanks to Richard) > > v3: > I did a mistake and did not test properly > - add parenteses > - fix the used variable Acked-by: Richard Cochran

Re: [PATCH net] ptp: ptp_clockmatrix: update to support 4.8.7 firmware

Other minor changes includes: > adding more debug logs, increasing snap accuracy for pre 4.8.7 firmware > and supporting new tcs2bin format. > > Signed-off-by: Min Li Acked-by: Richard Cochran

Re: [PATCH v3 1/1] can: dev: add software tx timestamps

On Sun, Jan 10, 2021 at 09:49:03PM +0900, Vincent Mailhol wrote: > * The hardware rx timestamp of a local loopback message is the > hardware tx timestamp. This means that there are no needs to > implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets. I can't agree with that statement. T

Re: [PATCH v3 1/1] can: dev: add software tx timestamps

On Tue, Jan 12, 2021 at 09:00:33AM +0900, Vincent MAILHOL wrote: > Out of curiosity, which programs do you use? I guess wireshark > but please let me know if you use any other programs (I just use > to write a small C program to do the stuff). I was thinking of PTP over DeviceNET (which, in turn,

Re: [PATCH net] net: ethernet: ti: cpts: fix ethtool output when no ptp_clock registered

ialization/deinitialization") > Signed-off-by: Grygorii Strashko Acked-by: Richard Cochran

Re: GTE - The hardware timestamping engine

On Tue, Mar 23, 2021 at 10:03:18AM +0100, Thierry Reding wrote: > I agree. My understanding is the the TSC is basically an SoC-wide clock > that can be (and is) used by several hardware blocks. There's an > interface for software to read out the value, but it's part of a block > called TKE (time-ke

Re: GTE - The hardware timestamping engine

On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote: > Adding Richard Cochran as well, for drivers/ptp/, he may be able to > identify whether this should be integrated into that framework in some > form. I'm not familiar with the GTE, but it sounds like it is a (free r

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On Mon, Mar 29, 2021 at 11:56:31AM +0200, Daphne Preston-Kendal wrote: > > The other is that the kernel updates the offset when a leap > > second is inserted/deleted even if the original offset is zero, so > > checking for zero (in the kernel or an application) works only until > > the first leap s

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote: > On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote: > > Using ntpd on Debian, the service will set the offset, but only after > > synchronization with the upstream server has been established, and >

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote: > There are at least two issues with handling a zero offset as a special > value. One is that zero could potentially be a valid value in distant > future. I not losing sleep over that, but > The other is that the kernel updates the

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On Mon, Mar 29, 2021 at 04:57:55PM +0200, Thomas Gleixner wrote: > I think adjtimex is the right place and not yet another random file > somewhere. Something like the below. Perfect. Acked-by: Richard Cochran > --- > include/uapi/linux/timex.h |7 +-- > ke

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On Fri, Mar 26, 2021 at 12:13:43PM +0100, Thomas Gleixner wrote: > On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote: > > Unfortunately, although the majority of distributions ship with a leap > > second file from the zoneinfo database, many or most of them (I have > > Arch here) do not configure

Re: [PATCH] time: Fix overwrite err unexpected in clock_adjtime32

On Mon, Apr 12, 2021 at 12:45:51PM +, Chen Jun wrote: > the correct error is covered by put_old_timex32. Well, the non-negative return code (TIME_OK, TIME_INS, etc) is clobbered by put_old_timex32(). > Fixes: f1f1d5ebd10f ("posix-timers: Introduce a syscall for clock tuning.") This is not th

Re: [PATCH] time: Fix overwrite err unexpected in clock_adjtime32

On Mon, Apr 12, 2021 at 02:52:11PM +, chenjun (AM) wrote: > 在 2021/4/12 22:20, Richard Cochran 写道: > > On Mon, Apr 12, 2021 at 12:45:51PM +, Chen Jun wrote: > >> the correct error is covered by put_old_timex32. > > > > Well, the non-negative return co

<    1   2   3   4   5   6   7   8   9   10   >