Message-ID: <20250626124327.667087805@linutronix.de>
Date: Thu, 26 Jun 2025 15:27:28 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: netdev@...r.kernel.org,
 Richard Cochran <richardcochran@...il.com>,
 Christopher Hall <christopher.s.hall@...el.com>,
 John Stultz <jstultz@...gle.com>,
 Frederic Weisbecker <frederic@...nel.org>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>,
 Miroslav Lichvar <mlichvar@...hat.com>,
 Werner Abt <werner.abt@...nberg-usa.com>,
 David Woodhouse <dwmw2@...radead.org>,
 Stephen Boyd <sboyd@...nel.org>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 Kurt Kanzenbach <kurt@...utronix.de>,
 Nam Cao <namcao@...utronix.de>,
 Antoine Tenart <atenart@...nel.org>
Subject: [patch 0/3] ptp: Provide support for auxiliary clocks for
 PTP_SYS_OFFSET_EXTENDED

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

Powered by blists - more mailing lists