add support for TS sandwich of the user preferred timebase. The options
supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
Signed-off-by: Mahesh Bandewar <[email protected]>
CC: Richard Cochran <[email protected]>
CC: "David S. Miller" <[email protected]>
CC: [email protected]
---
include/linux/ptp_clock_kernel.h | 51 ++++++++++++++++++++++++++++++++
include/uapi/linux/ptp_clock.h | 7 +++++
2 files changed, 58 insertions(+)
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index 1ef4e0f9bd2a..fd7be98e7bba 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -102,6 +102,15 @@ struct ptp_system_timestamp {
* reading the lowest bits of the PHC timestamp and the second
* reading immediately follows that.
*
+ * @gettimex64any: Reads the current time from the hardware clock and
+ optionally also any of the MONO, MONO_RAW, or SYS clock.
+ * parameter ts: Holds the PHC timestamp.
+ * parameter sts: If not NULL, it holds a pair of timestamps from
+ * the clock of choice. The first reading is made right before
+ * reading the lowest bits of the PHC timestamp and the second
+ * reading immediately follows that.
+ * parameter type: any one of the TS opt from ptp_timestamp_types.
+ *
* @getcrosststamp: Reads the current time from the hardware clock and
* system clock simultaneously.
* parameter cts: Contains timestamp (device,system) pair,
@@ -180,6 +189,9 @@ struct ptp_clock_info {
int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
struct ptp_system_timestamp *sts);
+ int (*gettimex64any)(struct ptp_clock_info *ptp, struct timespec64 *ts,
+ struct ptp_system_timestamp *sts,
+ enum ptp_ts_types type);
int (*getcrosststamp)(struct ptp_clock_info *ptp,
struct system_device_crosststamp *cts);
int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
@@ -464,4 +476,43 @@ static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
ktime_get_real_ts64(&sts->post_ts);
}
+static inline void ptp_read_any_prets(struct ptp_system_timestamp *sts,
+ enum ptp_ts_types type)
+{
+ if (sts) {
+ switch (type) {
+ case PTP_TS_REAL:
+ ktime_get_real_ts64(&sts->pre_ts);
+ break;
+ case PTP_TS_MONO:
+ ktime_get_ts64(&sts->pre_ts);
+ break;
+ case PTP_TS_RAW:
+ ktime_get_raw_ts64(&sts->pre_ts);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
+static inline void ptp_read_any_postts(struct ptp_system_timestamp *sts,
+ enum ptp_ts_types type)
+{
+ if (sts) {
+ switch (type) {
+ case PTP_TS_REAL:
+ ktime_get_real_ts64(&sts->post_ts);
+ break;
+ case PTP_TS_MONO:
+ ktime_get_ts64(&sts->post_ts);
+ break;
+ case PTP_TS_RAW:
+ ktime_get_raw_ts64(&sts->post_ts);
+ break;
+ default:
+ break;
+ }
+ }
+}
#endif
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 05cc35fc94ac..dc44e34f8146 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -69,6 +69,13 @@
*/
#define PTP_PEROUT_V1_VALID_FLAGS (0)
+enum ptp_ts_types {
+ PTP_TS_REAL = 0,
+ PTP_TS_MONO,
+ PTP_TS_RAW,
+ PTP_TS_MAX,
+};
+
/*
* struct ptp_clock_time - represents a time value
*
--
2.42.0.582.g8ccd20d70d-goog
On Mon, Oct 02, 2023 at 09:17:01PM -0700, Mahesh Bandewar wrote:
> add support for TS sandwich of the user preferred timebase. The options
> supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
>
> Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
>
> Signed-off-by: Mahesh Bandewar <[email protected]>
> CC: Richard Cochran <[email protected]>
> CC: "David S. Miller" <[email protected]>
> CC: [email protected]
> ---
> include/linux/ptp_clock_kernel.h | 51 ++++++++++++++++++++++++++++++++
> include/uapi/linux/ptp_clock.h | 7 +++++
> 2 files changed, 58 insertions(+)
>
> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index 1ef4e0f9bd2a..fd7be98e7bba 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -102,6 +102,15 @@ struct ptp_system_timestamp {
> * reading the lowest bits of the PHC timestamp and the second
> * reading immediately follows that.
> *
> + * @gettimex64any: Reads the current time from the hardware clock and
> + optionally also any of the MONO, MONO_RAW, or SYS clock.
nit: I think a '*' is needed on the line above.
> + * parameter ts: Holds the PHC timestamp.
> + * parameter sts: If not NULL, it holds a pair of timestamps from
> + * the clock of choice. The first reading is made right before
> + * reading the lowest bits of the PHC timestamp and the second
> + * reading immediately follows that.
> + * parameter type: any one of the TS opt from ptp_timestamp_types.
> + *
> * @getcrosststamp: Reads the current time from the hardware clock and
> * system clock simultaneously.
> * parameter cts: Contains timestamp (device,system) pair,
...
On Mon, Oct 02, 2023 at 09:17:01PM -0700, Mahesh Bandewar wrote:
> add support for TS sandwich of the user preferred timebase. The options
> supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
>
> Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
NAK
Don't just ignore feedback and repost.
On Mon, Oct 02, 2023 at 09:17:01PM -0700, Mahesh Bandewar wrote:
> add support for TS sandwich of the user preferred timebase. The options
> supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
>
> Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
This change log is horrible.
Please write a proper explanation, and be sure to cover the following
three points.
1. context
2. problem
3. solution
Every change log must have those three items.
In addition, this series needs a cover letter that clearly justifies
the need for this change.
Thanks,
Richard
On Tue, Oct 3, 2023 at 9:29 PM Richard Cochran <[email protected]> wrote:
>
> On Mon, Oct 02, 2023 at 09:17:01PM -0700, Mahesh Bandewar wrote:
> > add support for TS sandwich of the user preferred timebase. The options
> > supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> > and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
> >
> > Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
>
> NAK
>
> Don't just ignore feedback and repost.
I replied to all your earlier comments, which one do you think I had ignored?
On Tue, Oct 3, 2023 at 9:38 PM Richard Cochran <[email protected]> wrote:
>
> On Mon, Oct 02, 2023 at 09:17:01PM -0700, Mahesh Bandewar wrote:
> > add support for TS sandwich of the user preferred timebase. The options
> > supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> > and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
> >
> > Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
>
> This change log is horrible.
>
> Please write a proper explanation, and be sure to cover the following
> three points.
>
> 1. context
> 2. problem
> 3. solution
>
> Every change log must have those three items.
>
> In addition, this series needs a cover letter that clearly justifies
> the need for this change.
>
Fair point and the series does have a cover letter which you can
access it at https://lore.kernel.org/lkml/[email protected]/
Probably it's fault of my mailer-script which finds the reviewers for
individual patches by running scripts/get_maintainer.pl but then
coverletter is just sent to the mailing-list
> Thanks,
> Richard
>
On Thu, Oct 05, 2023 at 04:12:44PM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> I replied to all your earlier comments, which one do you think I had ignored?
new enums -- go back and read my reply again!
Thanks,
Richard
On Thu, Oct 05, 2023 at 04:12:44PM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> I replied to all your earlier comments
Actually, you didn't.
(no) Thanks,
Richard
On Thu, Oct 05, 2023 at 04:23:27PM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> Probably it's fault of my mailer-script which finds the reviewers for
> individual patches by running scripts/get_maintainer.pl but then
> coverletter is just sent to the mailing-list
No, it is your responsibility to ensure CC list is correct.
Thanks,
Richard
On Mon, Oct 2, 2023 at 9:17 PM Mahesh Bandewar <[email protected]> wrote:
>
> add support for TS sandwich of the user preferred timebase. The options
> supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
>
> Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
>
> Signed-off-by: Mahesh Bandewar <[email protected]>
> CC: Richard Cochran <[email protected]>
> CC: "David S. Miller" <[email protected]>
> CC: [email protected]
> ---
> include/linux/ptp_clock_kernel.h | 51 ++++++++++++++++++++++++++++++++
> include/uapi/linux/ptp_clock.h | 7 +++++
> 2 files changed, 58 insertions(+)
Hey Mahesh,
Thanks for sending this out! I've got a few thoughts below.
> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index 1ef4e0f9bd2a..fd7be98e7bba 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -102,6 +102,15 @@ struct ptp_system_timestamp {
> * reading the lowest bits of the PHC timestamp and the second
> * reading immediately follows that.
> *
> + * @gettimex64any: Reads the current time from the hardware clock and
> + optionally also any of the MONO, MONO_RAW, or SYS clock.
> + * parameter ts: Holds the PHC timestamp.
> + * parameter sts: If not NULL, it holds a pair of timestamps from
> + * the clock of choice. The first reading is made right before
> + * reading the lowest bits of the PHC timestamp and the second
> + * reading immediately follows that.
> + * parameter type: any one of the TS opt from ptp_timestamp_types.
> + *
> * @getcrosststamp: Reads the current time from the hardware clock and
> * system clock simultaneously.
> * parameter cts: Contains timestamp (device,system) pair,
> @@ -180,6 +189,9 @@ struct ptp_clock_info {
> int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
> int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
> struct ptp_system_timestamp *sts);
> + int (*gettimex64any)(struct ptp_clock_info *ptp, struct timespec64 *ts,
> + struct ptp_system_timestamp *sts,
> + enum ptp_ts_types type);
> int (*getcrosststamp)(struct ptp_clock_info *ptp,
> struct system_device_crosststamp *cts);
> int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);
So I don't see anything in this series that wires into this hook. Did
a patch go missing? Or am I maybe looking in the wrong place?
> @@ -464,4 +476,43 @@ static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
> ktime_get_real_ts64(&sts->post_ts);
> }
>
> +static inline void ptp_read_any_prets(struct ptp_system_timestamp *sts,
> + enum ptp_ts_types type)
> +{
> + if (sts) {
> + switch (type) {
> + case PTP_TS_REAL:
> + ktime_get_real_ts64(&sts->pre_ts);
> + break;
> + case PTP_TS_MONO:
> + ktime_get_ts64(&sts->pre_ts);
> + break;
> + case PTP_TS_RAW:
> + ktime_get_raw_ts64(&sts->pre_ts);
> + break;
> + default:
> + break;
> + }
> + }
> +}
> +
> +static inline void ptp_read_any_postts(struct ptp_system_timestamp *sts,
> + enum ptp_ts_types type)
> +{
> + if (sts) {
> + switch (type) {
> + case PTP_TS_REAL:
> + ktime_get_real_ts64(&sts->post_ts);
> + break;
> + case PTP_TS_MONO:
> + ktime_get_ts64(&sts->post_ts);
> + break;
> + case PTP_TS_RAW:
> + ktime_get_raw_ts64(&sts->post_ts);
> + break;
> + default:
> + break;
> + }
> + }
> +}
Similarly, I'm a little confused as to who the users of these two
functions are? I don't see them in this patch series.
Additionally it seems like instead of two functions, you could maybe
have one ptp_read_any_ts(enum ptp_ts_types type, struct timespec64
*ts) function that the caller passes the sts->pre_ts or sts->post_ts
to?
And finally, I'm not sure if it makes sense, but other logic in the
kernel that does similar clockid multiplexing includes
timens_add_monotonic() or timens_add_boottime() (though the latter
doesn't apply here) for namespace offsets.
I was never excited about time namespaces (hard enough to keep one
sense of time :), but there are some good reasons, and I suspect we
might want to avoid cases where clock_gettime() returns potentially
different values compared to this interface.
thanks again!
-john