From: Carolina Jubran <cjubran@nvidia.com>
To: Arthur Kiyanovski <akiyano@amazon.com>, netdev@vger.kernel.org
Cc: Richard Cochran <richardcochran@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Miroslav Lichvar <mlichvar@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Wen Gu <guwen@linux.alibaba.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
David Woodhouse <dwmw@amazon.com>,
Yonatan Sarna <ysarna@amazon.com>,
Zorik Machulsky <zorik@amazon.com>,
Alexander Matushevsky <matua@amazon.com>,
Saeed Bshara <saeedb@amazon.com>, Matt Wilson <msw@amazon.com>,
Anthony Liguori <aliguori@amazon.com>,
Nafea Bshara <nafea@amazon.com>,
Evgeny Schmeilin <evgenys@amazon.com>,
Netanel Belgazal <netanel@amazon.com>,
Ali Saidi <alisaidi@amazon.com>,
Benjamin Herrenschmidt <benh@amazon.com>,
Noam Dagan <ndagan@amazon.com>,
David Arinzon <darinzon@amazon.com>,
Evgeny Ostrovsky <evostrov@amazon.com>,
Ofir Tabachnik <ofirt@amazon.com>,
Amit Bernstein <amitbern@amazon.com>,
linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
shuah@kernel.org, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Simon Horman <horms@kernel.org>,
vadim.fedorenko@linux.dev, Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes
Date: Tue, 28 Jul 2026 10:52:52 +0300 [thread overview]
Message-ID: <58700765-8c3c-45a2-ae12-1f8ff46f4725@nvidia.com> (raw)
In-Reply-To: <20260714020340.25014-2-akiyano@amazon.com>
On 14/07/2026 5:03, Arthur Kiyanovski wrote:
>
> +/*
> + * Clock status values for struct ptp_clock_attrs.status
> + */
> +enum ptp_clock_status {
> + /* Clock synchronization status cannot be reliably determined */
> + PTP_CLOCK_STATUS_UNKNOWN = 0,
> +
> + /* Clock is acquiring synchronization */
> + PTP_CLOCK_STATUS_INITIALIZING = 1,
> +
> + /* Clock is synchronized and maintained accurately by the device */
> + PTP_CLOCK_STATUS_SYNCED = 2,
> +
> + /* Clock is drifting but remains within acceptable error bounds */
> + PTP_CLOCK_STATUS_HOLDOVER = 3,
> +
> + /* Clock is drifting without adjustments or synchronization */
> + PTP_CLOCK_STATUS_FREE_RUNNING = 4,
> +
> + /* Clock is unreliable, the error_bound value cannot be trusted */
> + PTP_CLOCK_STATUS_UNRELIABLE = 5
> +};
Could you clarify the intended distinction between FREE_RUNNING and
UNRELIABLE? What does UNRELIABLE represent beyond FREE_RUNNING?
Also, how is userspace expected to relate clock_status to error_bound?
Are there defined thresholds for transitions between the states or are
these entirely device-specific?
> +
> +/*
> + * Clock timescale values for struct ptp_clock_attrs.timescale.
> + *
> + * These definitions describe the mathematical properties and reference
> + * epochs of the timescale provided by the PHC.
> + *
> + * Discipline: Describes the frequency/phase steering behavior.
> + * Continuity: Describes whether the timeline is uninterrupted.
> + */
> +enum ptp_clock_timescale {
> + /* Unknown or unspecified timescale */
> + PTP_TIMESCALE_UNKNOWN = 0,
> +
> + /********************* Absolute Atomic Timescales *********************
> + * These timescales are continuous, monotonic standards based on atomic
> + * physics. They do not experience phase jumps.
> + **********************************************************************/
> +
> + /**
> + * International Atomic Time (TAI)
> + * Epoch: 1958-01-01 00:00:00.
> + * Continuity: Strictly monotonic and continuous; no leap seconds.
> + * Discipline: Primary atomic reference; no phase jumps.
> + */
> + PTP_TIMESCALE_TAI = 1,
> +
> + /**
> + * Terrestrial Time (TT)
> + * Epoch: 1958-01-01 00:00:00.
> + * Continuity: Strictly monotonic and continuous; no leap seconds.
> + * Discipline: Defined as TAI + 32.184s constant offset.
> + */
> + PTP_TIMESCALE_TT = 2,
> +
> + /**
> + * Global Positioning System (GPS) Time
> + * Epoch: 1980-01-06 00:00:00.
> + * Continuity: Strictly monotonic and continuous; no leap seconds.
> + * Discipline: Defined by the GPS constellation; fixed offset from TAI.
> + */
> + PTP_TIMESCALE_GPS = 3,
> +
> + /****************** UTC-Based Timescales (Civil Time) *****************
> + * These timescales are derived from TAI but adjusted to align with
> + * the Earth's rotation, primarily through leap seconds.
> + **********************************************************************/
> +
> + /**
> + * Coordinated Universal Time (UTC) - Wall-clock (CLOCK_REALTIME)
> + * Epoch: 1970-01-01 00:00:00 (Unix epoch).
> + * Continuity: Discontinuous; subject to 1-second leap second
> + * phase jumps.
> + * Discipline: Frequency steered; incorporates leap second corrections.
> + *
> + * Note: Leap-smeared UTC MUST NOT be advertised as PTP_TIMESCALE_UTC.
> + * Smear algorithms are not standardized and the resulting timescale
> + * is ambiguous. Implementations using smeared UTC MUST advertise
> + * PTP_TIMESCALE_UNKNOWN or PTP_TIMESCALE_PROPRIETARY instead.
> + */
> + PTP_TIMESCALE_UTC = 4,
> +
> + /**
> + * POSIX Time (Unix Time)
> + * Epoch: 1970-01-01 00:00:00.
> + * Continuity: Discontinuous; leap seconds handled by
> + * repeating/skipping values.
> + * Discipline: Follows UTC frequency steering and phase jumps.
> + */
> + PTP_TIMESCALE_POSIX = 5,
> +
> + /****************** System-Relative Monotonic Clocks ******************
> + * These timescales are relative to a system event (like boot)
> + * and are not synchronized to an external atomic standard.
> + **********************************************************************/
> +
> + /**
> + * Monotonic System Clock (CLOCK_MONOTONIC)
> + * Epoch: Arbitrary (System boot time).
> + * Continuity: Strictly monotonic; no leap seconds.
> + * Discipline: Frequency steered to match system reference;
> + * does not advance during suspend.
> + */
> + PTP_TIMESCALE_MONOTONIC = 6,
> +
> + /**
> + * Raw Monotonic System Clock (CLOCK_MONOTONIC_RAW)
> + * Epoch: Arbitrary (System boot time).
> + * Continuity: Strictly monotonic; no leap seconds.
> + * Discipline: Raw hardware oscillator; no frequency steering
> + * or discipline.
> + */
> + PTP_TIMESCALE_MONOTONIC_RAW = 7,
> +
> + /**
> + * Boot Time System Clock (CLOCK_BOOTTIME)
> + * Epoch: Arbitrary (System boot time).
> + * Continuity: Strictly monotonic and continuous; no leap seconds.
> + * Discipline: Frequency steered to match system reference;
> + * advances during suspend.
> + */
> + PTP_TIMESCALE_BOOTTIME = 8,
> +
> + /********************** Vendor-Specific Timescale *********************/
> +
> + /* A proprietary or vendor-specific timescale with custom rules. */
> + PTP_TIMESCALE_PROPRIETARY = 9,
> +};
> +
> /*
> * struct ptp_clock_time - represents a time value
> *
> @@ -94,6 +225,119 @@ struct ptp_clock_time {
> __u32 reserved;
> };
>
> +/*
> + * Hardware counter identifiers for struct ptp_sys_time.sys_counter_id
> + */
> +enum ptp_counter_id {
> + /* Counter value not available or type not specified */
> + PTP_COUNTER_UNKNOWN = 0,
> +
> + /* x86 Time Stamp Counter (TSC) */
> + PTP_COUNTER_X86_TSC = 1,
> +
> + /* ARM Generic Timer virtual counter */
> + PTP_COUNTER_ARM_ARCH = 2,
> +};
> +
> +/* Valid flags for struct ptp_clock_attrs.valid */
> +#define PTP_ATTRS_VALID_ERROR_BOUND (1 << 0)
> +#define PTP_ATTRS_VALID_TIMESCALE (1 << 1)
> +#define PTP_ATTRS_VALID_STATUS (1 << 2)
> +
> +/**
> + * struct ptp_clock_attrs - quality attributes for a PHC timestamp
> + *
> + * @valid: Bitmask of PTP_ATTRS_VALID_* indicating which fields
> + * are populated. Zero means no attributes available.
> + * @error_bound: Maximum error in nanoseconds. Valid only when
> + * PTP_ATTRS_VALID_ERROR_BOUND is set.
> + * @timescale: Clock timescale (enum ptp_clock_timescale). Valid only
> + * when PTP_ATTRS_VALID_TIMESCALE is set.
> + * @status: Synchronization status (enum ptp_clock_status). Valid
> + * only when PTP_ATTRS_VALID_STATUS is set.
> + * @rsv: Reserved for future use, must be zero.
> + */
> +struct ptp_clock_attrs {
> + __u32 valid;
> + __u32 error_bound;
Error relative to what? The advertised timescale's true time, or the
device's sync source? And is this a hard bound or an estimate?
> + __u32 timescale;
> + __u32 status;
> + __u32 rsv[4];
> +};
> +
>
next prev parent reply other threads:[~2026-07-28 7:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 2:03 [PATCH v4 net-next 0/7] ptp: Add PHC timestamp quality attributes Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with " Arthur Kiyanovski
2026-07-15 0:45 ` Jacob Keller
2026-07-16 8:09 ` Arthur Kiyanovski
2026-07-16 18:14 ` Jacob Keller
2026-07-28 8:10 ` Carolina Jubran
2026-07-29 0:26 ` Arthur Kiyanovski
2026-07-16 11:22 ` saeed bishara
2026-07-17 7:18 ` Arthur Kiyanovski
2026-07-28 7:52 ` Carolina Jubran [this message]
2026-07-29 0:25 ` Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 2/7] selftests/ptp: Extract print_system_timestamp helper in testptp Arthur Kiyanovski
2026-07-16 11:34 ` saeed bishara
2026-07-17 7:19 ` Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 3/7] selftests/ptp: Add testptp support for attributes ioctls Arthur Kiyanovski
2026-07-16 13:00 ` saeed bishara
2026-07-17 7:20 ` Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 4/7] ptp: ptp_vmclock: Implement " Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 5/7] net: ena: Update PHC admin interface for error bound support Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 6/7] net: ena: Add error bound to PHC communication layer Arthur Kiyanovski
2026-07-14 2:03 ` [PATCH v4 net-next 7/7] net: ena: Implement gettimexattrs64 callback for PTP attributes Arthur Kiyanovski
2026-07-15 0:47 ` Jacob Keller
2026-07-16 8:11 ` Arthur Kiyanovski
2026-07-16 18:07 ` Jacob Keller
2026-07-27 1:41 ` [PATCH v4 net-next 0/7] ptp: Add PHC timestamp quality attributes Richard Cochran
2026-07-27 9:40 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58700765-8c3c-45a2-ae12-1f8ff46f4725@nvidia.com \
--to=cjubran@nvidia.com \
--cc=akiyano@amazon.com \
--cc=aliguori@amazon.com \
--cc=alisaidi@amazon.com \
--cc=amitbern@amazon.com \
--cc=andrew+netdev@lunn.ch \
--cc=benh@amazon.com \
--cc=corbet@lwn.net \
--cc=darinzon@amazon.com \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.com \
--cc=edumazet@google.com \
--cc=evgenys@amazon.com \
--cc=evostrov@amazon.com \
--cc=guwen@linux.alibaba.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=matua@amazon.com \
--cc=mlichvar@redhat.com \
--cc=msw@amazon.com \
--cc=nafea@amazon.com \
--cc=ndagan@amazon.com \
--cc=netanel@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=ofirt@amazon.com \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=saeedb@amazon.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@linutronix.de \
--cc=vadim.fedorenko@linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
--cc=ysarna@amazon.com \
--cc=zorik@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox