[patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

This small series enables support for auxiliary clocks on top of the
timekeeping core infrastructure, which has been paritially merged. The
remaining outstanding patches can be found here:

     https://lore.kernel.org/all/20250625182951.587377878@linutronix.de

Auxiliary clocks are required to support TSN use cases in automation,
automotive, audio and other areas. They utilize PTP for synchronizing nodes
in a network accurately, but the underlying master clock is not necessarily
related to clock TAI. They are completely independent and just represent a
common notion of time in a network for an application specific
purpose. This comes with problems obvioulsy:

   1) Applications have no fast access to the time of such independent PTP
      clocks. The only way is to utilize the file descriptor of the PTP
      device with clock_gettime(). That's slow as it has to go all the way
      out to the hardware.

   2) The network stack cannot access PTP time at all because accessing the
      PTP hardware requires preemptible task context in quite some cases.

The timekeeper core changes provide support for this including the ability
to steer these clocks independently from the core timekeeper via
clock_adjtimex(2).

This is obviously incomplete as the user space steering daemon needs to be
able to correlate timestamps from these auxiliary clocks with the
associated PTP device timestamp. The PTP_SYS_OFFSET_EXTENDED IOCTL command
already supports to select clock IDs for pre and post hardware timestamps,
so the first step for correlation is to extend that IOCTL to allow
selecting auxiliary clocks.

Auxiliary clocks do not provide a seperate CLOCK_MONOTONIC_RAW variant as
they are internally utilizing the same clocksource and therefore the
existing CLOCK_MONOTONIC_RAW correlation is valid for them too, if user
space wants to determine the correlation to the underlying clocksource raw
initial conversion factor:

CLOCK_MONOTONIC_RAW:

  The clocksource readout is converted to nanoseconds by a conversion
  factor, which has been determined at setup time. This factor does not
  change over the lifetime of the system.

CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, CLOCK_TAI:

  The clocksource readout is converted to nanoseconds by a conversion
  factor, which starts with the CLOCK_MONOTONIC_RAW conversion factor at
  setup time. This factor can be steered via clock_adjtimex(CLOCK_REALTIME).

  All related clocks use the same conversion factor and internally these
  clocks are built on top of CLOCK_MONOTONIC by adding a clock specific
  offset after the conversion. The CLOCK_REALTIME and CLOCK_TAI offsets can
  be set via clock_settime(2) or clock_adjtimex(2). The CLOCK_BOOTTIME
  offset is modified after a suspend/resume cycle to take the suspend time
  into account.

CLOCK_AUX:

  The clocksource readout is converted to nanoseconds by a conversion
  factor, which starts with the CLOCK_MONOTONIC_RAW conversion factor at
  setup time. This factor can be steered via clock_adjtimex(CLOCK_AUX[n]).

  Each auxiliary clock uses its own conversion factor and offset. The
  offset can be set via clock_settime(2) or clock_adjtimex(2) for each
  clock ID.

The series applies on top of the above mentioned timekeeper core changes
and the PTP character device spring cleaning series, which can be found
here:

  https://lore.kernel.org/all/20250625114404.102196103@linutronix.de

It is also available via git with all prerequisite patches:

  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/driver-auxclock

Miroslav: This branch should enable you to test the actual steering via a
	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.

Thanks,

	tglx
---
 drivers/ptp/ptp_chardev.c        |   21 ++++++++++++++++-----
 include/linux/ptp_clock_kernel.h |   34 ++++------------------------------
 include/linux/timekeeping.h      |    1 +
 kernel/time/timekeeping.c        |   34 ++++++++++++++++++++++++++++++++++
 4 files changed, 55 insertions(+), 35 deletions(-)

[patch 1/3] timekeeping: Provide ktime_get_clock_ts64()

[Thomas Gleixner]

PTP implements an inline switch case for taking timestamps from various
POSIX clock IDs, which already consumes quite some text space. Expanding it
for auxiliary clocks really becomes too big for inlining.

Provide a out of line version. 

The function invalidates the timestamp in case the clock is invalid. The
invalidation allows to implement a validation check without the need to
propagate a return value through deep existing call chains.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/timekeeping.h |    1 +
 kernel/time/timekeeping.c   |   34 ++++++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -44,6 +44,7 @@ extern void ktime_get_ts64(struct timesp
 extern void ktime_get_real_ts64(struct timespec64 *tv);
 extern void ktime_get_coarse_ts64(struct timespec64 *ts);
 extern void ktime_get_coarse_real_ts64(struct timespec64 *ts);
+extern void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts);
 
 /* Multigrain timestamp interfaces */
 extern void ktime_get_coarse_real_ts64_mg(struct timespec64 *ts);
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1636,6 +1636,40 @@ void ktime_get_raw_ts64(struct timespec6
 EXPORT_SYMBOL(ktime_get_raw_ts64);
 
 /**
+ * ktime_get_clock_ts64 - Returns time of a clock in a timespec
+ * @id:		POSIX clock ID of the clock to read
+ * @ts:		Pointer to the timespec64 to be set
+ *
+ * The timestamp is invalidated (@ts->sec is set to -1) if the
+ * clock @id is not available.
+ */
+void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts)
+{
+	/* Invalidate time stamp */
+	ts->tv_sec = -1;
+	ts->tv_nsec = 0;
+
+	switch (id) {
+	case CLOCK_REALTIME:
+		ktime_get_real_ts64(ts);
+		return;
+	case CLOCK_MONOTONIC:
+		ktime_get_ts64(ts);
+		return;
+	case CLOCK_MONOTONIC_RAW:
+		ktime_get_raw_ts64(ts);
+		return;
+	case CLOCK_AUX ... CLOCK_AUX_LAST:
+		if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
+			ktime_get_aux_ts64(id, ts);
+		return;
+	default:
+		WARN_ON_ONCE(1);
+	}
+}
+EXPORT_SYMBOL_GPL(ktime_get_clock_ts64);
+
+/**
  * timekeeping_valid_for_hres - Check if timekeeping is suitable for hres
  */
 int timekeeping_valid_for_hres(void)

Re: [patch 1/3] timekeeping: Provide ktime_get_clock_ts64()

[John Stultz]

On Thu, Jun 26, 2025 at 6:27 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> PTP implements an inline switch case for taking timestamps from various
> POSIX clock IDs, which already consumes quite some text space. Expanding it
> for auxiliary clocks really becomes too big for inlining.
>
> Provide a out of line version.
>
> The function invalidates the timestamp in case the clock is invalid. The
> invalidation allows to implement a validation check without the need to
> propagate a return value through deep existing call chains.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  include/linux/timekeeping.h |    1 +
>  kernel/time/timekeeping.c   |   34 ++++++++++++++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
>
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -44,6 +44,7 @@ extern void ktime_get_ts64(struct timesp
>  extern void ktime_get_real_ts64(struct timespec64 *tv);
>  extern void ktime_get_coarse_ts64(struct timespec64 *ts);
>  extern void ktime_get_coarse_real_ts64(struct timespec64 *ts);
> +extern void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts);
>
>  /* Multigrain timestamp interfaces */
>  extern void ktime_get_coarse_real_ts64_mg(struct timespec64 *ts);
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1636,6 +1636,40 @@ void ktime_get_raw_ts64(struct timespec6
>  EXPORT_SYMBOL(ktime_get_raw_ts64);
>
>  /**
> + * ktime_get_clock_ts64 - Returns time of a clock in a timespec
> + * @id:                POSIX clock ID of the clock to read
> + * @ts:                Pointer to the timespec64 to be set
> + *
> + * The timestamp is invalidated (@ts->sec is set to -1) if the
> + * clock @id is not available.
> + */
> +void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts)
> +{
> +       /* Invalidate time stamp */
> +       ts->tv_sec = -1;
> +       ts->tv_nsec = 0;
> +
> +       switch (id) {
> +       case CLOCK_REALTIME:
> +               ktime_get_real_ts64(ts);
> +               return;
> +       case CLOCK_MONOTONIC:
> +               ktime_get_ts64(ts);
> +               return;
> +       case CLOCK_MONOTONIC_RAW:
> +               ktime_get_raw_ts64(ts);
> +               return;
> +       case CLOCK_AUX ... CLOCK_AUX_LAST:
> +               if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
> +                       ktime_get_aux_ts64(id, ts);
> +               return;
> +       default:
> +               WARN_ON_ONCE(1);
> +       }
> +}
> +EXPORT_SYMBOL_GPL(ktime_get_clock_ts64);

While I recognize this is mainly focused on the ptp use case, as the
interface looks generic from headers point of view, should we add the
other clockids for completeness?

Other than that,
Acked-by: John Stultz <jstultz@google.com>

thanks
-john

Re: [patch 1/3] timekeeping: Provide ktime_get_clock_ts64()

[Vadim Fedorenko]

On 26/06/2025 14:27, Thomas Gleixner wrote:
> PTP implements an inline switch case for taking timestamps from various
> POSIX clock IDs, which already consumes quite some text space. Expanding it
> for auxiliary clocks really becomes too big for inlining.
> 
> Provide a out of line version.
> 
> The function invalidates the timestamp in case the clock is invalid. The
> invalidation allows to implement a validation check without the need to
> propagate a return value through deep existing call chains.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>   include/linux/timekeeping.h |    1 +
>   kernel/time/timekeeping.c   |   34 ++++++++++++++++++++++++++++++++++
>   2 files changed, 35 insertions(+)
> 
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -44,6 +44,7 @@ extern void ktime_get_ts64(struct timesp
>   extern void ktime_get_real_ts64(struct timespec64 *tv);
>   extern void ktime_get_coarse_ts64(struct timespec64 *ts);
>   extern void ktime_get_coarse_real_ts64(struct timespec64 *ts);
> +extern void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts);
>   
>   /* Multigrain timestamp interfaces */
>   extern void ktime_get_coarse_real_ts64_mg(struct timespec64 *ts);
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1636,6 +1636,40 @@ void ktime_get_raw_ts64(struct timespec6
>   EXPORT_SYMBOL(ktime_get_raw_ts64);
>   
>   /**
> + * ktime_get_clock_ts64 - Returns time of a clock in a timespec
> + * @id:		POSIX clock ID of the clock to read
> + * @ts:		Pointer to the timespec64 to be set
> + *
> + * The timestamp is invalidated (@ts->sec is set to -1) if the
> + * clock @id is not available.
> + */
> +void ktime_get_clock_ts64(clockid_t id, struct timespec64 *ts)
> +{
> +	/* Invalidate time stamp */
> +	ts->tv_sec = -1;
> +	ts->tv_nsec = 0;
> +
> +	switch (id) {
> +	case CLOCK_REALTIME:
> +		ktime_get_real_ts64(ts);
> +		return;
> +	case CLOCK_MONOTONIC:
> +		ktime_get_ts64(ts);
> +		return;
> +	case CLOCK_MONOTONIC_RAW:
> +		ktime_get_raw_ts64(ts);
> +		return;
> +	case CLOCK_AUX ... CLOCK_AUX_LAST:
> +		if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
> +			ktime_get_aux_ts64(id, ts);
> +		return;
> +	default:
> +		WARN_ON_ONCE(1);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(ktime_get_clock_ts64);
> +
> +/**
>    * timekeeping_valid_for_hres - Check if timekeeping is suitable for hres
>    */
>   int timekeeping_valid_for_hres(void)
> 

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

[patch 2/3] ptp: Use ktime_get_clock_ts64() for timestamping

[Thomas Gleixner]

The inlined ptp_read_system_[pre|post]ts() switch cases expand to a copious
amount of text in drivers, e.g. ~500 bytes in e1000e. Adding auxiliary
clock support to the inlines would increase it further.

Replace the inline switch case with a call to ktime_get_clock_ts64(), which
reduces the code size in drivers and allows to access auxiliary clocks once
they are enabled in the IOCTL parameter filter.

No functional change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/ptp_clock_kernel.h |   34 ++++------------------------------
 1 file changed, 4 insertions(+), 30 deletions(-)

--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -477,40 +477,14 @@ static inline ktime_t ptp_convert_timest
 
 static inline void ptp_read_system_prets(struct ptp_system_timestamp *sts)
 {
-	if (sts) {
-		switch (sts->clockid) {
-		case CLOCK_REALTIME:
-			ktime_get_real_ts64(&sts->pre_ts);
-			break;
-		case CLOCK_MONOTONIC:
-			ktime_get_ts64(&sts->pre_ts);
-			break;
-		case CLOCK_MONOTONIC_RAW:
-			ktime_get_raw_ts64(&sts->pre_ts);
-			break;
-		default:
-			break;
-		}
-	}
+	if (sts)
+		ktime_get_clock_ts64(sts->clockid, &sts->pre_ts);
 }
 
 static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
 {
-	if (sts) {
-		switch (sts->clockid) {
-		case CLOCK_REALTIME:
-			ktime_get_real_ts64(&sts->post_ts);
-			break;
-		case CLOCK_MONOTONIC:
-			ktime_get_ts64(&sts->post_ts);
-			break;
-		case CLOCK_MONOTONIC_RAW:
-			ktime_get_raw_ts64(&sts->post_ts);
-			break;
-		default:
-			break;
-		}
-	}
+	if (sts)
+		ktime_get_clock_ts64(sts->clockid, &sts->post_ts);
 }
 
 #endif

Re: [patch 2/3] ptp: Use ktime_get_clock_ts64() for timestamping

[John Stultz]

On Thu, Jun 26, 2025 at 6:27 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The inlined ptp_read_system_[pre|post]ts() switch cases expand to a copious
> amount of text in drivers, e.g. ~500 bytes in e1000e. Adding auxiliary
> clock support to the inlines would increase it further.
>
> Replace the inline switch case with a call to ktime_get_clock_ts64(), which
> reduces the code size in drivers and allows to access auxiliary clocks once
> they are enabled in the IOCTL parameter filter.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Acked-by: John Stultz <jstultz@google.com>

Re: [patch 2/3] ptp: Use ktime_get_clock_ts64() for timestamping

[Vadim Fedorenko]

On 26/06/2025 14:27, Thomas Gleixner wrote:
> The inlined ptp_read_system_[pre|post]ts() switch cases expand to a copious
> amount of text in drivers, e.g. ~500 bytes in e1000e. Adding auxiliary
> clock support to the inlines would increase it further.
> 
> Replace the inline switch case with a call to ktime_get_clock_ts64(), which
> reduces the code size in drivers and allows to access auxiliary clocks once
> they are enabled in the IOCTL parameter filter.
> 
> No functional change.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>   include/linux/ptp_clock_kernel.h |   34 ++++------------------------------
>   1 file changed, 4 insertions(+), 30 deletions(-)
> 
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -477,40 +477,14 @@ static inline ktime_t ptp_convert_timest
>   
>   static inline void ptp_read_system_prets(struct ptp_system_timestamp *sts)
>   {
> -	if (sts) {
> -		switch (sts->clockid) {
> -		case CLOCK_REALTIME:
> -			ktime_get_real_ts64(&sts->pre_ts);
> -			break;
> -		case CLOCK_MONOTONIC:
> -			ktime_get_ts64(&sts->pre_ts);
> -			break;
> -		case CLOCK_MONOTONIC_RAW:
> -			ktime_get_raw_ts64(&sts->pre_ts);
> -			break;
> -		default:
> -			break;
> -		}
> -	}
> +	if (sts)
> +		ktime_get_clock_ts64(sts->clockid, &sts->pre_ts);
>   }
>   
>   static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
>   {
> -	if (sts) {
> -		switch (sts->clockid) {
> -		case CLOCK_REALTIME:
> -			ktime_get_real_ts64(&sts->post_ts);
> -			break;
> -		case CLOCK_MONOTONIC:
> -			ktime_get_ts64(&sts->post_ts);
> -			break;
> -		case CLOCK_MONOTONIC_RAW:
> -			ktime_get_raw_ts64(&sts->post_ts);
> -			break;
> -		default:
> -			break;
> -		}
> -	}
> +	if (sts)
> +		ktime_get_clock_ts64(sts->clockid, &sts->post_ts);
>   }
>   
>   #endif
> 
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

[patch 3/3] ptp: Enable auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

Allow ioctl(PTP_SYS_OFFSET_EXTENDED*) to select CLOCK_AUX clock ids for
generating the pre and post hardware readout timestamps.

Aside of adding these clocks to the clock ID validation, this also requires
to check the timestamp to be valid, i.e. the seconds value being greater
than or equal zero. This is necessary because AUX clocks can be
asynchronously enabled or disabled, so there is no way to validate the
availability upfront.

The same could have been achieved by handing the return value of
ktime_get_aux_ts64() all the way down to the IOCTL call site, but that'd
require to modify all existing ptp::gettimex64() callbacks and their inner
call chains. The timestamp check achieves the same with less churn and less
complicated code all over the place.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/ptp/ptp_chardev.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -325,13 +325,19 @@ static long ptp_sys_offset_extended(stru
 	if (IS_ERR(extoff))
 		return PTR_ERR(extoff);
 
-	if (extoff->n_samples > PTP_MAX_SAMPLES ||
-	    extoff->rsv[0] || extoff->rsv[1] ||
-	    (extoff->clockid != CLOCK_REALTIME &&
-	     extoff->clockid != CLOCK_MONOTONIC &&
-	     extoff->clockid != CLOCK_MONOTONIC_RAW))
+	if (extoff->n_samples > PTP_MAX_SAMPLES || extoff->rsv[0] || extoff->rsv[1])
 		return -EINVAL;
 
+	switch (extoff->clockid) {
+	case CLOCK_REALTIME:
+	case CLOCK_MONOTONIC:
+	case CLOCK_MONOTONIC_RAW:
+	case CLOCK_AUX ... CLOCK_AUX_LAST:
+		break;
+	default:
+		return -EINVAL;
+	}
+
 	sts.clockid = extoff->clockid;
 	for (unsigned int i = 0; i < extoff->n_samples; i++) {
 		struct timespec64 ts;
@@ -340,6 +346,11 @@ static long ptp_sys_offset_extended(stru
 		err = ptp->info->gettimex64(ptp->info, &ts, &sts);
 		if (err)
 			return err;
+
+		/* Filter out disabled or unavailable clocks */
+		if (sts.pre_ts.tv_sec < 0 || sts.post_ts.tv_sec < 0)
+			return -EINVAL;
+
 		extoff->ts[i][0].sec = sts.pre_ts.tv_sec;
 		extoff->ts[i][0].nsec = sts.pre_ts.tv_nsec;
 		extoff->ts[i][1].sec = ts.tv_sec;

Re: [patch 3/3] ptp: Enable auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Vadim Fedorenko]

On 26/06/2025 14:27, Thomas Gleixner wrote:
> Allow ioctl(PTP_SYS_OFFSET_EXTENDED*) to select CLOCK_AUX clock ids for
> generating the pre and post hardware readout timestamps.
> 
> Aside of adding these clocks to the clock ID validation, this also requires
> to check the timestamp to be valid, i.e. the seconds value being greater
> than or equal zero. This is necessary because AUX clocks can be
> asynchronously enabled or disabled, so there is no way to validate the
> availability upfront.
> 
> The same could have been achieved by handing the return value of
> ktime_get_aux_ts64() all the way down to the IOCTL call site, but that'd
> require to modify all existing ptp::gettimex64() callbacks and their inner
> call chains. The timestamp check achieves the same with less churn and less
> complicated code all over the place.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>   drivers/ptp/ptp_chardev.c |   21 ++++++++++++++++-----
>   1 file changed, 16 insertions(+), 5 deletions(-)
> 
> --- a/drivers/ptp/ptp_chardev.c
> +++ b/drivers/ptp/ptp_chardev.c
> @@ -325,13 +325,19 @@ static long ptp_sys_offset_extended(stru
>   	if (IS_ERR(extoff))
>   		return PTR_ERR(extoff);
>   
> -	if (extoff->n_samples > PTP_MAX_SAMPLES ||
> -	    extoff->rsv[0] || extoff->rsv[1] ||
> -	    (extoff->clockid != CLOCK_REALTIME &&
> -	     extoff->clockid != CLOCK_MONOTONIC &&
> -	     extoff->clockid != CLOCK_MONOTONIC_RAW))
> +	if (extoff->n_samples > PTP_MAX_SAMPLES || extoff->rsv[0] || extoff->rsv[1])
>   		return -EINVAL;
>   
> +	switch (extoff->clockid) {
> +	case CLOCK_REALTIME:
> +	case CLOCK_MONOTONIC:
> +	case CLOCK_MONOTONIC_RAW:
> +	case CLOCK_AUX ... CLOCK_AUX_LAST:
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
>   	sts.clockid = extoff->clockid;
>   	for (unsigned int i = 0; i < extoff->n_samples; i++) {
>   		struct timespec64 ts;
> @@ -340,6 +346,11 @@ static long ptp_sys_offset_extended(stru
>   		err = ptp->info->gettimex64(ptp->info, &ts, &sts);
>   		if (err)
>   			return err;
> +
> +		/* Filter out disabled or unavailable clocks */
> +		if (sts.pre_ts.tv_sec < 0 || sts.post_ts.tv_sec < 0)
> +			return -EINVAL;
> +
>   		extoff->ts[i][0].sec = sts.pre_ts.tv_sec;
>   		extoff->ts[i][0].nsec = sts.pre_ts.tv_nsec;
>   		extoff->ts[i][1].sec = ts.tv_sec;
> 
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [patch 3/3] ptp: Enable auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

On Thu, Jun 26 2025 at 15:27, Thomas Gleixner wrote:
> +	switch (extoff->clockid) {
> +	case CLOCK_REALTIME:
> +	case CLOCK_MONOTONIC:
> +	case CLOCK_MONOTONIC_RAW:
> +	case CLOCK_AUX ... CLOCK_AUX_LAST:
> +		break;

While trying to solve the merge logistics problem I noticed that this
should be:

	switch (extoff->clockid) {
	case CLOCK_REALTIME:
	case CLOCK_MONOTONIC:
	case CLOCK_MONOTONIC_RAW:
        	break;
	case CLOCK_AUX ... CLOCK_AUX_LAST:
        	if (IS_ENABLED(CONFIG_POSIX_AUX_CLOCKS))
			break;
		fallthrough;

obviously as there is no point in going all the way down into the time
stamping code to figure out that this is disabled.

I blame it all on the heat wave of course :)

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Miroslav Lichvar]

On Thu, Jun 26, 2025 at 03:27:28PM +0200, Thomas Gleixner wrote:
> This is obviously incomplete as the user space steering daemon needs to be
> able to correlate timestamps from these auxiliary clocks with the
> associated PTP device timestamp. The PTP_SYS_OFFSET_EXTENDED IOCTL command
> already supports to select clock IDs for pre and post hardware timestamps,
> so the first step for correlation is to extend that IOCTL to allow
> selecting auxiliary clocks.

> Miroslav: This branch should enable you to test the actual steering via a
> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.

Nice! I ran few quick tests and it seems to be working great. The
observed delay and stability with an AUX clock synchronized to a PHC
seems to be the same as with CLOCK_REALTIME.

Are there any plans to enable software timestamping of packets by
AUX clocks? That would allow an NTP/PTP instance using SW timestamps
to be fully isolated from the adjustments of the CLOCK_REALTIME clock,
e.g. to run an independent NTP/PTP server in a container. This might
be tricky as the skb would likely need to contain the MONOTONIC_RAW
timestamp to be converted later when it gets to a socket, so some
history of adjustments of each clock would need to be saved and
reapplied to the raw timestamp.

-- 
Miroslav Lichvar

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

On Thu, Jun 26 2025 at 16:53, Miroslav Lichvar wrote:
> On Thu, Jun 26, 2025 at 03:27:28PM +0200, Thomas Gleixner wrote:
>> This is obviously incomplete as the user space steering daemon needs to be
>> able to correlate timestamps from these auxiliary clocks with the
>> associated PTP device timestamp. The PTP_SYS_OFFSET_EXTENDED IOCTL command
>> already supports to select clock IDs for pre and post hardware timestamps,
>> so the first step for correlation is to extend that IOCTL to allow
>> selecting auxiliary clocks.
>
>> Miroslav: This branch should enable you to test the actual steering via a
>> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.
>
> Nice! I ran few quick tests and it seems to be working great. The
> observed delay and stability with an AUX clock synchronized to a PHC
> seems to be the same as with CLOCK_REALTIME.

Thank you for taking the time!

> Are there any plans to enable software timestamping of packets by
> AUX clocks?

I'm not aware of any plans or efforts so far, but obviously that'd be
the next logical step.

> That would allow an NTP/PTP instance using SW timestamps
> to be fully isolated from the adjustments of the CLOCK_REALTIME clock,
> e.g. to run an independent NTP/PTP server in a container. This might
> be tricky as the skb would likely need to contain the MONOTONIC_RAW
> timestamp to be converted later when it gets to a socket, so some
> history of adjustments of each clock would need to be saved and
> reapplied to the raw timestamp.

Either that or you could go and implement some BPF magic to take a
timestamp with a particular clock ID based on the packet type. But what
do I know? That's something the network wizards needs to figure out.

Thanks,

        tglx

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Paolo Abeni]

On 6/26/25 3:27 PM, Thomas Gleixner wrote:
> This small series enables support for auxiliary clocks on top of the
> timekeeping core infrastructure, which has been paritially merged. The
> remaining outstanding patches can be found here:
> 
>      https://lore.kernel.org/all/20250625182951.587377878@linutronix.de
> 
> Auxiliary clocks are required to support TSN use cases in automation,
> automotive, audio and other areas. They utilize PTP for synchronizing nodes
> in a network accurately, but the underlying master clock is not necessarily
> related to clock TAI. They are completely independent and just represent a
> common notion of time in a network for an application specific
> purpose. This comes with problems obvioulsy:
> 
>    1) Applications have no fast access to the time of such independent PTP
>       clocks. The only way is to utilize the file descriptor of the PTP
>       device with clock_gettime(). That's slow as it has to go all the way
>       out to the hardware.
> 
>    2) The network stack cannot access PTP time at all because accessing the
>       PTP hardware requires preemptible task context in quite some cases.
> 
> The timekeeper core changes provide support for this including the ability
> to steer these clocks independently from the core timekeeper via
> clock_adjtimex(2).
> 
> This is obviously incomplete as the user space steering daemon needs to be
> able to correlate timestamps from these auxiliary clocks with the
> associated PTP device timestamp. The PTP_SYS_OFFSET_EXTENDED IOCTL command
> already supports to select clock IDs for pre and post hardware timestamps,
> so the first step for correlation is to extend that IOCTL to allow
> selecting auxiliary clocks.
> 
> Auxiliary clocks do not provide a seperate CLOCK_MONOTONIC_RAW variant as
> they are internally utilizing the same clocksource and therefore the
> existing CLOCK_MONOTONIC_RAW correlation is valid for them too, if user
> space wants to determine the correlation to the underlying clocksource raw
> initial conversion factor:
> 
> CLOCK_MONOTONIC_RAW:
> 
>   The clocksource readout is converted to nanoseconds by a conversion
>   factor, which has been determined at setup time. This factor does not
>   change over the lifetime of the system.
> 
> CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, CLOCK_TAI:
> 
>   The clocksource readout is converted to nanoseconds by a conversion
>   factor, which starts with the CLOCK_MONOTONIC_RAW conversion factor at
>   setup time. This factor can be steered via clock_adjtimex(CLOCK_REALTIME).
> 
>   All related clocks use the same conversion factor and internally these
>   clocks are built on top of CLOCK_MONOTONIC by adding a clock specific
>   offset after the conversion. The CLOCK_REALTIME and CLOCK_TAI offsets can
>   be set via clock_settime(2) or clock_adjtimex(2). The CLOCK_BOOTTIME
>   offset is modified after a suspend/resume cycle to take the suspend time
>   into account.
> 
> CLOCK_AUX:
> 
>   The clocksource readout is converted to nanoseconds by a conversion
>   factor, which starts with the CLOCK_MONOTONIC_RAW conversion factor at
>   setup time. This factor can be steered via clock_adjtimex(CLOCK_AUX[n]).
> 
>   Each auxiliary clock uses its own conversion factor and offset. The
>   offset can be set via clock_settime(2) or clock_adjtimex(2) for each
>   clock ID.
> 
> The series applies on top of the above mentioned timekeeper core changes
> and the PTP character device spring cleaning series, which can be found
> here:
> 
>   https://lore.kernel.org/all/20250625114404.102196103@linutronix.de
> 
> It is also available via git with all prerequisite patches:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/driver-auxclock
> 
> Miroslav: This branch should enable you to test the actual steering via a
> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.

I have some dumb issues merging this on net-next.

It looks like we should pull from the above URL, but it looks like the
prereq series there has different hashes WRT the tip tree. Pulling from
there will cause good bunch of duplicate commits - the pre-req series vs
the tip tree and the ptp cleanup series vs already merge commits on
net-next.

I guess we want to avoid such duplicates, but I don't see how to avoid
all of them. A stable branch on top of current net-next will avoid the
ptp cleanup series duplicates, but will not avoid duplicates for
prereqs. Am I missing something obvious?

Thanks,

Paolo

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

On Tue, Jul 01 2025 at 12:16, Paolo Abeni wrote:
> On 6/26/25 3:27 PM, Thomas Gleixner wrote:
>> It is also available via git with all prerequisite patches:
>> 
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/driver-auxclock
>> 
>> Miroslav: This branch should enable you to test the actual steering via a
>> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.
>
> I have some dumb issues merging this on net-next.
>
> It looks like we should pull from the above URL, but it looks like the
> prereq series there has different hashes WRT the tip tree. Pulling from
> there will cause good bunch of duplicate commits - the pre-req series vs
> the tip tree and the ptp cleanup series vs already merge commits on
> net-next.
>
> I guess we want to avoid such duplicates, but I don't see how to avoid
> all of them. A stable branch on top of current net-next will avoid the
> ptp cleanup series duplicates, but will not avoid duplicates for
> prereqs. Am I missing something obvious?

No. I messed that up by not telling that the PTP series should be
applied as a seperate branch, which is merged into net-next. That way I
could have merged that branch back into tip and apply this pile on top.

Let me think about an elegant way to make this work without creating an
utter mess in either of the trees (or both).

Thanks,

        tglx

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Jakub Kicinski]

On Tue, 01 Jul 2025 14:23:39 +0200 Thomas Gleixner wrote:
> On Tue, Jul 01 2025 at 12:16, Paolo Abeni wrote:
> > On 6/26/25 3:27 PM, Thomas Gleixner wrote:  
> >> It is also available via git with all prerequisite patches:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timers/ptp/driver-auxclock
> >> 
> >> Miroslav: This branch should enable you to test the actual steering via a
> >> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.  
> >
> > I have some dumb issues merging this on net-next.
> >
> > It looks like we should pull from the above URL, but it looks like the
> > prereq series there has different hashes WRT the tip tree. Pulling from
> > there will cause good bunch of duplicate commits - the pre-req series vs
> > the tip tree and the ptp cleanup series vs already merge commits on
> > net-next.
> >
> > I guess we want to avoid such duplicates, but I don't see how to avoid
> > all of them. A stable branch on top of current net-next will avoid the
> > ptp cleanup series duplicates, but will not avoid duplicates for
> > prereqs. Am I missing something obvious?  
> 
> No. I messed that up by not telling that the PTP series should be
> applied as a seperate branch, which is merged into net-next. That way I
> could have merged that branch back into tip and apply this pile on top.
> 
> Let me think about an elegant way to make this work without creating an
> utter mess in either of the trees (or both).

Sorry about that, I read the previous cover letter as the branch being
provided for convenience, not that I _should_ pull from it. I should
have asked..

Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Thomas Gleixner]

On Tue, Jul 01 2025 at 16:56, Jakub Kicinski wrote:
> On Tue, 01 Jul 2025 14:23:39 +0200 Thomas Gleixner wrote:
>> > I guess we want to avoid such duplicates, but I don't see how to avoid
>> > all of them. A stable branch on top of current net-next will avoid the
>> > ptp cleanup series duplicates, but will not avoid duplicates for
>> > prereqs. Am I missing something obvious?  
>> 
>> No. I messed that up by not telling that the PTP series should be
>> applied as a seperate branch, which is merged into net-next. That way I
>> could have merged that branch back into tip and apply this pile on top.
>> 
>> Let me think about an elegant way to make this work without creating an
>> utter mess in either of the trees (or both).
>
> Sorry about that, I read the previous cover letter as the branch being
> provided for convenience, not that I _should_ pull from it. I should
> have asked..

I should have made it entirely clear. Next time :)