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

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

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

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

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

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

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