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

[Paolo Abeni <pabeni@redhat.com>]

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