[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 richardcoch...@gmail.com --- drivers/ptp/ptp_pch.c |8 1 file changed, 4 insertions

[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 richardcoch...@gmail.com --- drivers/ptp/ptp_ixp46x.c |8 1 file changed, 4 insertions(+), 4 deletions

[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 richardcoch...@gmail.com --- drivers/net/ethernet/sfc/ptp.c | 22

[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 richardcoch...@gmail.com --- drivers/ptp/ptp_chardev.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b

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

the 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 richardcoch...@gmail.com --- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++-- 1 file changed, 7 insertions

[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 richardcoch...@gmail.com --- drivers/ptp/ptp_clock.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git

[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 richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpts.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

[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 richardcoch...@gmail.com --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8 1 file

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

comes around. Compile tested only. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- 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

[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 richardcoch...@gmail.com --- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++- 1 file changed, 6 insertions

Re: [PATCH 2/4] ptp/clcok:Introduce the setktime/getktime interfaces with ktime_t type

On Fri, Mar 20, 2015 at 02:43:42PM +0100, Arnd Bergmann wrote: Doing gettime separately from settime would be rather silly here, so trying to avoid the conditional would mean doing a single large patch across all drivers. There is really no need for any dancing around here. There are

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Wed, Mar 11, 2015 at 11:20:59AM +, Stathis Voukelatos wrote: Our feeling is that we will have to test and verify that a move to gPTP will fit with the use cases that we have to support and that will require a fair amount of effort and rewrite of application software. If the driver is

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

BTW I am getting doubles of your messages, both addressed to the mailings lists, but only one also addressed to me. You should just send one copy, with everyone on CC. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Fri, Mar 06, 2015 at 10:50:08AM +, Stathis Voukelatos wrote: Although the PTP way appears to be the best from an architectural point of view, we have some questions as whether it is suitable for the audio use cases that this module is mainly intended for. To use the PTP terminology in a

[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 richardcoch...@gmail.com --- drivers/net/ethernet/adi/bfin_mac.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[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 richardcoch...@gmail.com --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |7 ++- 1 file changed, 2 insertions

[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 richardcoch...@gmail.com --- drivers/net/ethernet/freescale/gianfar_ptp.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff

[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 richardcoch...@gmail.com --- drivers/net/ethernet/intel/e1000e/ptp.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[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 richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpts.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions

[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 richardcoch...@gmail.com --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

[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 richardcoch...@gmail.com --- drivers/net/ethernet/mellanox/mlx4/en_clock.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[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 richardcoch...@gmail.com --- drivers/net/ethernet/freescale/fec_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5

[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 richardcoch...@gmail.com --- drivers/net/ethernet/intel/igb/igb_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5

[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 richardcoch...@gmail.com --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c |7 ++- 1 file changed, 2 insertions(+), 5

[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 richardcoch...@gmail.com --- drivers/net/ethernet/broadcom/tg3.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers

[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

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

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 e1000_adapter

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. However, in the case of the i210

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); - struct timespec ts

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8 1 file

[PATCH net-next V3 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 richardcoch...@gmail.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpts.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

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

. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- 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

[PATCH net-next V3 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 richardcoch...@gmail.com --- include/linux/ptp_clock_kernel.h | 12

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

. Thanks, Richard * ChangeLog ** V3 - dp83640: use timespec64 throughout per Arnd's suggestion - tilegx: use timespec64 throughout per Chris' suggestion - add Jeff's acked-bys ** V2 - use the new methods in the posix clock code right away (patch #3) Richard Cochran (23): ptp: introduce

[PATCH net-next V3 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, and the stored value is unsigned. Therefore this driver and device are ready for the year 2038. However, more work will be needed prior to 2106. Compile tested only. Signed-off-by: Richard Cochran richardcoch...@gmail.com

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/ptp/ptp_pch.c |8 1 file changed, 4 insertions

[PATCH net-next V3 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 richardcoch...@gmail.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- drivers/net/ethernet/intel/fm10k

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

compile tested. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- arch/tile/gxio/mpipe.c |4 ++-- arch/tile/include/gxio/mpipe.h |4 ++-- drivers/net/ethernet/tile/tilegx.c |9 + 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/tile

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/ptp/ptp_ixp46x.c |8 1 file changed, 4 insertions(+), 4 deletions

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 11 ++- 1 file changed, 6 insertions

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/sfc/ptp.c | 22

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 13 +++-- 1 file changed, 7 insertions

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/freescale/gianfar_ptp.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/ptp/ptp_chardev.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/broadcom/tg3.c | 10 +- 1 file changed, 5 insertions

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/ptp/ptp_clock.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git

[PATCH net-next V3 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 richardcoch...@gmail.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- drivers/net/ethernet/intel/e1000e/ptp.c

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 1 file changed, 4 insertions

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/freescale/fec_ptp.c |8 1 file changed, 4 insertions(+), 4

[PATCH net-next V3 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 richardcoch...@gmail.com --- drivers/net/ethernet/adi/bfin_mac.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net

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

comes around. Compile tested only. Signed-off-by: Richard Cochran richardcoch...@gmail.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- drivers/net/ethernet/intel/igb/igb_ptp.c | 41 +++--- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers

[PATCH net-next V3 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 richardcoch...@gmail.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com --- drivers/net/ethernet/intel/i40e

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Fri, Feb 27, 2015 at 05:09:24PM +, Stathis Voukelatos wrote: To summarize (and confirm my understanding) your suggestion is for the sniffer to be configured to match PTP packets and (similarly to the dp83640) return the Message Type and Sequence Id fields that will allow them to be

Re: [RFC][PATCH 00/19] Add timekeeping tests to kernel selftest

On Wed, Feb 25, 2015 at 02:32:05PM -0800, John Stultz wrote: Thoughts or comments here would be greatly appreciated! I only browsed through just to get an idea of the various tests, and the series looks good to me. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

On Wed, Feb 25, 2015 at 10:53:11AM +, Stathis Voukelatos wrote: On 25/02/15 09:50, Richard Cochran wrote: The Linux kernel already fully supports this kind of application via the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly don't need another another interface just

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Tue, Feb 24, 2015 at 04:48:08PM +, Stathis Voukelatos wrote: This patch adds support for the Ethernet Packet Sniffer H/W module developed by Linn Products Ltd and found in the IMG Pistachio SoC. The module allows Ethernet packets to be parsed, matched against a user-defined pattern and

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote: Let me suggest another approach that stays in line with the existing frame work. Based on the device's limitations and your own example, it seems clear that the intended use case is synchronization for AVB applications using

Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Wed, Feb 25, 2015 at 05:12:08PM +, Stathis Voukelatos wrote: Regarding this last point, the actual counter that generates the timestamps is not part of the sniffer H/W module. Timestamps are provided to the sniffer externally in H/W by a different module. Apart of that there is not eg.

Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

On Mon, Feb 23, 2015 at 09:37:24AM +, Stathis Voukelatos wrote: Hi Richard, On 18/02/15 21:08, Richard Cochran wrote: On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote: The command string for packet matching is stored in module RAM and consists of a sequence of 16-bit

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

On Mon, Mar 23, 2015 at 12:02:03PM -0400, Chris Metcalf wrote: This driver is 64-bit only. Would it make more sense to just change the accessors from gettime/settime to gettime/settime64 and nothing else, i.e. rely on the current behavior that timespec and timespec64 are the same type, and

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

On Mon, Mar 23, 2015 at 01:26:22PM -0400, Chris Metcalf wrote: As far as I know, the tilegx driver is the only client of those gxio routines. ... I guess that brings us back to changing the gxio_xxx APIs. Ok, I'll do that for the next round. Thanks, Richard -- To unsubscribe from this list:

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 it

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:

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

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

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 13, 2015 at 04:37:59PM +0200, Richard Cochran wrote: On Wed, May 13, 2015 at 02:19:53PM +0200, Arnd Bergmann wrote: Ah, very good. Extending this one function should be fairly straightforward, just discuss with the PTP maintainer how to best do it. Sorry, I deleted the original

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 13, 2015 at 02:19:53PM +0200, Arnd Bergmann wrote: Ah, very good. Extending this one function should be fairly straightforward, just discuss with the PTP maintainer how to best do it. Sorry, I deleted the original post, and I have zero clue what is is all about. Can you give me a

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 13, 2015 at 12:50:02PM -0700, Jonathan Richardson wrote: ptp_clock_adjtime() casts it to an unsigned and returns an error: if ((unsigned long) ts.tv_nsec = NSEC_PER_SEC) return -EINVAL; The value of a timeval is the sum of its fields, but the field tv_usec must always

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 13, 2015 at 04:25:49PM -0700, Jonathan Richardson wrote: On 15-05-13 01:27 PM, Richard Cochran wrote: If the ISR is delivering batches of time stamps, then the interrupt rate aught to be the highest rate that the system can support. It to nanosecond precision so it can

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Fri, May 01, 2015 at 12:01:07PM -0700, Jonathan Richardson wrote: The DTE creates timestamps of hardware based events such as GPIO, I2S signals for audio, etc. It was also intended to provide 802.1AS / PTP timestamps for network packets. The h/w has up to 32 clients -- the hardware inputs

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Fri, May 08, 2015 at 01:02:17PM -0700, Jonathan Richardson wrote: For the clock functions I think we can use the existing framework unchanged with one exception: ptp_clock_adjtime() doesn't allow negative time adjustments and we would like to allow this. ??? /** * struct ptp_clock_info -

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 13, 2015 at 12:38:22PM -0700, Jonathan Richardson wrote: The input events may occur at a rate greater than we want to generate timestamps at. Maybe we need a better term than divider. The h/w sees x input signals over x period of time and then samples the input signal at a divided

Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus

On Wed, May 20, 2015 at 04:38:02PM -0700, Jonathan Richardson wrote: Richard, this design isn't going to work. We need to have both kernel and user space consumers. But you did not implement even a single kernel consumer. We don't want all GPIO's in a common timestamp buffer either, as it

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

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 would

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

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

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: [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 suspect this isn't extremely

Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

I have three nits to pick... On Thu, Jul 02, 2015 at 06:14:48PM -0700, Christopher Hall wrote: diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h index b8b7306..344f129 100644 --- a/include/linux/ptp_clock_kernel.h +++ b/include/linux/ptp_clock_kernel.h @@

Re: [PATCH v2 0/1] Add PTP cross-timestamp to the PTP driver interface

On Thu, Jul 02, 2015 at 06:14:47PM -0700, Christopher Hall wrote: This patch adds an additional callback getsynctime64(). Which will be called when the driver is able to perform a more accurate, implementation specific cross-timestamping. For example, future network devices that implement

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Sat, Aug 22, 2015 at 10:33:48PM +0200, Thomas Gleixner wrote: @@ -196,19 +197,31 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg) break; } pct = sysoff-ts[0]; - for (i = 0; i sysoff-n_samples; i++)

Re: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

On Sun, Aug 23, 2015 at 10:15:00AM +0200, Thomas Gleixner wrote: So why can't you take N samples from the synced hardware? It does not make any sense to me to switch to the imprecise mode if nsamples 1. Ok, then I prefer to leave this imprecise method in place and ... You can also provide a

Re: [PATCH 1/5] Add functions producing system time given a backing counter value

On Wed, Jul 29, 2015 at 12:49:44PM +0200, Peter Zijlstra wrote: This is still fuzzy, right? The hardware ART timestamp could be from _before_ the NTP adjust; or the NTP adjust could happen while we do this conversion and we'll take the retry loop. In the original series, yes. In both cases,

Re: [PATCH 1/5] Add functions producing system time given a backing counter value

On Wed, Jul 29, 2015 at 12:23:27PM +0200, Thomas Gleixner wrote: Something like the below untested patch should be all we need for PTP to be as precise as possible. Yes, that is as good as it can be. The code protects against concurrent NTP adjustments, and the PTP driver will have to block

Re: [PATCH v2 4/4] Added getsynctime64() callback

On Thu, Aug 13, 2015 at 09:10:36PM +, Hall, Christopher S wrote: + if (!cpu_has_art) + return -EOPNOTSUPP; Perform this check before registration, setting .getsynctime64 accordingly. The problem here is that ART initialization doesn't happen until we install TSC as a

Re: [PATCH v2 4/4] Added getsynctime64() callback

On Fri, Aug 07, 2015 at 04:01:35PM -0700, Christopher Hall wrote: --- a/drivers/net/ethernet/intel/e1000e/defines.h +++ b/drivers/net/ethernet/intel/e1000e/defines.h @@ -527,6 +527,13 @@ #define E1000_RXCW_C 0x2000/* Receive config */ #define E1000_RXCW_SYNCH

Re: [PATCH v2 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

() callback provided by the driver. The cross-timestamp is best effort where the latency between the capture of system time (getnstimeofday()) and the device time (driver callback) may be significant. Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 04:22:03PM +0200, Thomas Gleixner wrote: > It's not only the DSP. There is a bunch of usre space software > involved as well. Care to think about the full picture and not just > about some randomly chosen single problem out of the full problem > space. I would surely like

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Wed, Oct 14, 2015 at 09:21:42AM +0200, Thomas Gleixner wrote: > The firmware gives you an ART/audio timestamp pair. The firmware does > neither know about system time nor about PTP time. > > So we have to do correlation in software. Ok, so give me the ART/audio and two recent ART/ptp times*

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > If we're only tracking 4ms of history, how does this solution > measurably improve the error over using the timestamps to generate > MONOTONIC_RAW clock deltas (which doesn't require keeping any history) > and using

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 12:48:03PM +0200, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Richard Cochran wrote: > > > On Mon, Oct 19, 2015 at 05:36:56PM -0700, John Stultz wrote: > > > If we're only tracking 4ms of history, how does this solution > > > measurabl

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 09:11:21PM +0200, Thomas Gleixner wrote: > Darn, we don't want to have that kind of sampling in every driver > which has this kind of problem even if it looks like the simpler > choice for this particular use case. This is going to be something > which next generation chips

Re: [PATCH v4 1/4] Produce system time from correlated clocksource

On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote: > You can, in fact, achieve "proper" correlation by sampling. As John > said, the question is whether the method in the patch set "measurably > improves the error" over using another, simpler method. H

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