[PATCH net-next v2 0/9] ptp .adjphase cleanups

[PATCH net-next v2 0/9] ptp .adjphase cleanups

[Rahul Rameshbabu]

The goal of this patch series is to improve documentation of .adjphase, add
a new callback .getmaxphase to enable advertising the max phase offset a
device PHC can support, and support invoking .adjphase from the testptp
kselftest.

Changes:
  v2->v1:
    * Removes arbitrary rule that the PHC servo must restore the frequency
      to the value used in the last .adjfine call if any other PHC
      operation is used after a .adjphase operation.
    * Removes a macro introduced in v1 for adding PTP sysfs device
      attribute nodes using a callback for populating the data.

Link: https://lore.kernel.org/netdev/20230120160609.19160723@kernel.org/
Link: https://lore.kernel.org/netdev/20230510205306.136766-1-rrameshbabu@nvidia.com/
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>

Rahul Rameshbabu (9):
  ptp: Clarify ptp_clock_info .adjphase expects an internal servo to be
    used
  docs: ptp.rst: Add information about NVIDIA Mellanox devices
  testptp: Remove magic numbers related to nanosecond to second
    conversion
  testptp: Add support for testing ptp_clock_info .adjphase callback
  ptp: Add .getmaxphase callback to ptp_clock_info
  net/mlx5: Add .getmaxphase ptp_clock_info callback
  ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback
  ptp: idt82p33: Add .getmaxphase ptp_clock_info callback
  ptp: ocp: Add .getmaxphase ptp_clock_info callback

 Documentation/driver-api/ptp.rst              | 29 +++++++++++++++
 .../ethernet/mellanox/mlx5/core/lib/clock.c   | 31 ++++++++--------
 drivers/ptp/ptp_chardev.c                     |  5 ++-
 drivers/ptp/ptp_clock.c                       |  4 +++
 drivers/ptp/ptp_clockmatrix.c                 | 36 +++++++++----------
 drivers/ptp/ptp_clockmatrix.h                 |  2 +-
 drivers/ptp/ptp_idt82p33.c                    | 18 +++++-----
 drivers/ptp/ptp_idt82p33.h                    |  4 +--
 drivers/ptp/ptp_ocp.c                         |  7 ++++
 drivers/ptp/ptp_sysfs.c                       | 12 +++++++
 include/linux/ptp_clock_kernel.h              | 11 ++++--
 include/uapi/linux/ptp_clock.h                |  3 +-
 tools/testing/selftests/ptp/testptp.c         | 29 ++++++++++++---
 13 files changed, 135 insertions(+), 56 deletions(-)

-- 
2.38.4

[PATCH net-next v2 1/9] ptp: Clarify ptp_clock_info .adjphase expects an internal servo to be used

[Rahul Rameshbabu]

.adjphase expects a PHC to use an internal servo algorithm to correct the
provided phase offset target in the callback. Implementation of the
internal servo algorithm are defined by the individual devices.

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
---

Notes:
    Changes:
    
      v2->v1:
        * Removes arbitrary rule that the PHC servo must restore the frequency
          to the value used in the last .adjfine call if any other PHC operation
          is used after a .adjphase operation.

 Documentation/driver-api/ptp.rst | 16 ++++++++++++++++
 include/linux/ptp_clock_kernel.h |  6 ++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/ptp.rst b/Documentation/driver-api/ptp.rst
index 664838ae7776..4552a1f20488 100644
--- a/Documentation/driver-api/ptp.rst
+++ b/Documentation/driver-api/ptp.rst
@@ -73,6 +73,22 @@ Writing clock drivers
    class driver, since the lock may also be needed by the clock
    driver's interrupt service routine.
 
+PTP hardware clock requirements for '.adjphase'
+-----------------------------------------------
+
+   The 'struct ptp_clock_info' interface has a '.adjphase' function.
+   This function has a set of requirements from the PHC in order to be
+   implemented.
+
+     * The PHC implements a servo algorithm internally that is used to
+       correct the offset passed in the '.adjphase' call.
+     * When other PTP adjustment functions are called, the PHC servo
+       algorithm is disabled.
+
+   **NOTE:** '.adjphase' is not a simple time adjustment functionality
+   that 'jumps' the PHC clock time based on the provided offset. It
+   should correct the offset provided using an internal algorithm.
+
 Supported hardware
 ==================
 
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index fdffa6a98d79..f8e8443a8b35 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -77,8 +77,10 @@ struct ptp_system_timestamp {
  *            nominal frequency in parts per million, but with a
  *            16 bit binary fractional field.
  *
- * @adjphase:  Adjusts the phase offset of the hardware clock.
- *             parameter delta: Desired change in nanoseconds.
+ * @adjphase:  Indicates that the PHC should use an internal servo
+ *             algorithm to correct the provided phase offset.
+ *             parameter delta: PHC servo phase adjustment target
+ *                              in nanoseconds.
  *
  * @adjtime:  Shifts the time of the hardware clock.
  *            parameter delta: Desired change in nanoseconds.
-- 
2.38.4

[PATCH net-next v2 2/9] docs: ptp.rst: Add information about NVIDIA Mellanox devices

[Rahul Rameshbabu]

The mlx5_core driver has implemented ptp clock driver functionality but
lacked documentation about the PTP devices. This patch adds information
about the Mellanox device family.

Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
 Documentation/driver-api/ptp.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/driver-api/ptp.rst b/Documentation/driver-api/ptp.rst
index 4552a1f20488..5e033c3b11b3 100644
--- a/Documentation/driver-api/ptp.rst
+++ b/Documentation/driver-api/ptp.rst
@@ -122,3 +122,16 @@ Supported hardware
           - LPF settings (bandwidth, phase limiting, automatic holdover, physical layer assist (per ITU-T G.8273.2))
           - Programmable output PTP clocks, any frequency up to 1GHz (to other PHY/MAC time stampers, refclk to ASSPs/SoCs/FPGAs)
           - Lock to GNSS input, automatic switching between GNSS and user-space PHC control (optional)
+
+   * NVIDIA Mellanox
+
+     - GPIO
+          - Certain variants of ConnectX-6 Dx and later products support one
+            GPIO which can time stamp external triggers and one GPIO to produce
+            periodic signals.
+          - Certain variants of ConnectX-5 and older products support one GPIO,
+            configured to either time stamp external triggers or produce
+            periodic signals.
+     - PHC instances
+          - All ConnectX devices have a free-running counter
+          - ConnectX-6 Dx and later devices have a UTC format counter
-- 
2.38.4

[PATCH net-next v2 3/9] testptp: Remove magic numbers related to nanosecond to second conversion

[Rahul Rameshbabu]

Use existing NSEC_PER_SEC declaration in place of hardcoded magic numbers.

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Maciek Machnikowski <maciek@machnikowski.net>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
 tools/testing/selftests/ptp/testptp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/ptp/testptp.c b/tools/testing/selftests/ptp/testptp.c
index 198ad5f32187..ca2b03d57aef 100644
--- a/tools/testing/selftests/ptp/testptp.c
+++ b/tools/testing/selftests/ptp/testptp.c
@@ -110,7 +110,7 @@ static long ppb_to_scaled_ppm(int ppb)
 
 static int64_t pctns(struct ptp_clock_time *t)
 {
-	return t->sec * 1000000000LL + t->nsec;
+	return t->sec * NSEC_PER_SEC + t->nsec;
 }
 
 static void usage(char *progname)
@@ -317,7 +317,7 @@ int main(int argc, char *argv[])
 		tx.time.tv_usec = adjns;
 		while (tx.time.tv_usec < 0) {
 			tx.time.tv_sec  -= 1;
-			tx.time.tv_usec += 1000000000;
+			tx.time.tv_usec += NSEC_PER_SEC;
 		}
 
 		if (clock_adjtime(clkid, &tx) < 0) {
-- 
2.38.4

[PATCH net-next v2 4/9] testptp: Add support for testing ptp_clock_info .adjphase callback

[Rahul Rameshbabu]

Invoke clock_adjtime syscall with tx.modes set with ADJ_OFFSET when testptp
is invoked with a phase adjustment offset value. Support seconds and
nanoseconds for the offset value.

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Maciek Machnikowski <maciek@machnikowski.net>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
 tools/testing/selftests/ptp/testptp.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/ptp/testptp.c b/tools/testing/selftests/ptp/testptp.c
index ca2b03d57aef..ae23ef51f198 100644
--- a/tools/testing/selftests/ptp/testptp.c
+++ b/tools/testing/selftests/ptp/testptp.c
@@ -134,6 +134,7 @@ static void usage(char *progname)
 		"            1 - external time stamp\n"
 		"            2 - periodic output\n"
 		" -n val     shift the ptp clock time by 'val' nanoseconds\n"
+		" -o val     phase offset (in nanoseconds) to be provided to the PHC servo\n"
 		" -p val     enable output with a period of 'val' nanoseconds\n"
 		" -H val     set output phase to 'val' nanoseconds (requires -p)\n"
 		" -w val     set output pulse width to 'val' nanoseconds (requires -p)\n"
@@ -167,6 +168,7 @@ int main(int argc, char *argv[])
 	int adjfreq = 0x7fffffff;
 	int adjtime = 0;
 	int adjns = 0;
+	int adjphase = 0;
 	int capabilities = 0;
 	int extts = 0;
 	int flagtest = 0;
@@ -188,7 +190,7 @@ int main(int argc, char *argv[])
 
 	progname = strrchr(argv[0], '/');
 	progname = progname ? 1+progname : argv[0];
-	while (EOF != (c = getopt(argc, argv, "cd:e:f:ghH:i:k:lL:n:p:P:sSt:T:w:z"))) {
+	while (EOF != (c = getopt(argc, argv, "cd:e:f:ghH:i:k:lL:n:o:p:P:sSt:T:w:z"))) {
 		switch (c) {
 		case 'c':
 			capabilities = 1;
@@ -228,6 +230,9 @@ int main(int argc, char *argv[])
 		case 'n':
 			adjns = atoi(optarg);
 			break;
+		case 'o':
+			adjphase = atoi(optarg);
+			break;
 		case 'p':
 			perout = atoll(optarg);
 			break;
@@ -327,6 +332,18 @@ int main(int argc, char *argv[])
 		}
 	}
 
+	if (adjphase) {
+		memset(&tx, 0, sizeof(tx));
+		tx.modes = ADJ_OFFSET | ADJ_NANO;
+		tx.offset = adjphase;
+
+		if (clock_adjtime(clkid, &tx) < 0) {
+			perror("clock_adjtime");
+		} else {
+			puts("phase adjustment okay");
+		}
+	}
+
 	if (gettime) {
 		if (clock_gettime(clkid, &ts)) {
 			perror("clock_gettime");
-- 
2.38.4

[PATCH net-next v2 5/9] ptp: Add .getmaxphase callback to ptp_clock_info

[Rahul Rameshbabu]

Enables advertisement of the maximum offset supported by the phase control
functionality of PHCs. The callback is used to return an error if an offset
not supported by the PHC is used in ADJ_OFFSET. The ioctls
PTP_CLOCK_GETCAPS and PTP_CLOCK_GETCAPS2 now advertise the maximum offset a
PHC's phase control functionality is capable of supporting. Introduce new
sysfs node, max_phase_adjustment.

Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Maciek Machnikowski <maciek@machnikowski.net>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
---

Notes:
    Changes:
    
      v2->v1:
        * Removes a macro introduced in v1 for adding PTP sysfs device
          attribute nodes using a callback for populating the data.

 drivers/ptp/ptp_chardev.c             |  5 ++++-
 drivers/ptp/ptp_clock.c               |  4 ++++
 drivers/ptp/ptp_sysfs.c               | 12 ++++++++++++
 include/linux/ptp_clock_kernel.h      |  5 +++++
 include/uapi/linux/ptp_clock.h        |  3 ++-
 tools/testing/selftests/ptp/testptp.c |  6 ++++--
 6 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index af3bc65c4595..362bf756e6b7 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -136,7 +136,10 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
 		caps.pps = ptp->info->pps;
 		caps.n_pins = ptp->info->n_pins;
 		caps.cross_timestamping = ptp->info->getcrosststamp != NULL;
-		caps.adjust_phase = ptp->info->adjphase != NULL;
+		caps.adjust_phase = ptp->info->adjphase != NULL &&
+				    ptp->info->getmaxphase != NULL;
+		if (caps.adjust_phase)
+			caps.max_phase_adj = ptp->info->getmaxphase(ptp->info);
 		if (copy_to_user((void __user *)arg, &caps, sizeof(caps)))
 			err = -EFAULT;
 		break;
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index 790f9250b381..80f74e38c2da 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -135,11 +135,15 @@ static int ptp_clock_adjtime(struct posix_clock *pc, struct __kernel_timex *tx)
 		ptp->dialed_frequency = tx->freq;
 	} else if (tx->modes & ADJ_OFFSET) {
 		if (ops->adjphase) {
+			s32 max_phase_adj = ops->getmaxphase(ops);
 			s32 offset = tx->offset;
 
 			if (!(tx->modes & ADJ_NANO))
 				offset *= NSEC_PER_USEC;
 
+			if (offset > max_phase_adj || offset < -max_phase_adj)
+				return -ERANGE;
+
 			err = ops->adjphase(ops, offset);
 		}
 	} else if (tx->modes == 0) {
diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
index f30b0a439470..77219cdcd683 100644
--- a/drivers/ptp/ptp_sysfs.c
+++ b/drivers/ptp/ptp_sysfs.c
@@ -18,6 +18,17 @@ static ssize_t clock_name_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(clock_name);
 
+static ssize_t max_phase_adjustment_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *page)
+{
+	struct ptp_clock *ptp = dev_get_drvdata(dev);
+
+	return snprintf(page, PAGE_SIZE - 1, "%d\n",
+			ptp->info->getmaxphase(ptp->info));
+}
+static DEVICE_ATTR_RO(max_phase_adjustment);
+
 #define PTP_SHOW_INT(name, var)						\
 static ssize_t var##_show(struct device *dev,				\
 			   struct device_attribute *attr, char *page)	\
@@ -309,6 +320,7 @@ static struct attribute *ptp_attrs[] = {
 	&dev_attr_clock_name.attr,
 
 	&dev_attr_max_adjustment.attr,
+	&dev_attr_max_phase_adjustment.attr,
 	&dev_attr_n_alarms.attr,
 	&dev_attr_n_external_timestamps.attr,
 	&dev_attr_n_periodic_outputs.attr,
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index f8e8443a8b35..1ef4e0f9bd2a 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -82,6 +82,10 @@ struct ptp_system_timestamp {
  *             parameter delta: PHC servo phase adjustment target
  *                              in nanoseconds.
  *
+ * @getmaxphase:  Advertises maximum offset that can be provided
+ *                to the hardware clock's phase control functionality
+ *                through adjphase.
+ *
  * @adjtime:  Shifts the time of the hardware clock.
  *            parameter delta: Desired change in nanoseconds.
  *
@@ -171,6 +175,7 @@ struct ptp_clock_info {
 	struct ptp_pin_desc *pin_config;
 	int (*adjfine)(struct ptp_clock_info *ptp, long scaled_ppm);
 	int (*adjphase)(struct ptp_clock_info *ptp, s32 phase);
+	s32 (*getmaxphase)(struct ptp_clock_info *ptp);
 	int (*adjtime)(struct ptp_clock_info *ptp, s64 delta);
 	int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
 	int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 1d108d597f66..05cc35fc94ac 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -95,7 +95,8 @@ struct ptp_clock_caps {
 	int cross_timestamping;
 	/* Whether the clock supports adjust phase */
 	int adjust_phase;
-	int rsv[12];   /* Reserved for future use. */
+	int max_phase_adj; /* Maximum phase adjustment in nanoseconds. */
+	int rsv[11];       /* Reserved for future use. */
 };
 
 struct ptp_extts_request {
diff --git a/tools/testing/selftests/ptp/testptp.c b/tools/testing/selftests/ptp/testptp.c
index ae23ef51f198..a162a3e15c29 100644
--- a/tools/testing/selftests/ptp/testptp.c
+++ b/tools/testing/selftests/ptp/testptp.c
@@ -292,7 +292,8 @@ int main(int argc, char *argv[])
 			       "  %d pulse per second\n"
 			       "  %d programmable pins\n"
 			       "  %d cross timestamping\n"
-			       "  %d adjust_phase\n",
+			       "  %d adjust_phase\n"
+			       "  %d maximum phase adjustment (ns)\n",
 			       caps.max_adj,
 			       caps.n_alarm,
 			       caps.n_ext_ts,
@@ -300,7 +301,8 @@ int main(int argc, char *argv[])
 			       caps.pps,
 			       caps.n_pins,
 			       caps.cross_timestamping,
-			       caps.adjust_phase);
+			       caps.adjust_phase,
+			       caps.max_phase_adj);
 		}
 	}
 
-- 
2.38.4

[PATCH net-next v2 6/9] net/mlx5: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

Implement .getmaxphase callback of ptp_clock_info in mlx5 driver. No longer
do a range check in .adjphase callback implementation. Handled by the ptp
stack.

Cc: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
 .../ethernet/mellanox/mlx5/core/lib/clock.c   | 31 +++++++++----------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index 932fbc843c69..973babfaff25 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
@@ -93,17 +93,23 @@ static bool mlx5_modify_mtutc_allowed(struct mlx5_core_dev *mdev)
 	return MLX5_CAP_MCAM_FEATURE(mdev, ptpcyc2realtime_modify);
 }
 
-static bool mlx5_is_mtutc_time_adj_cap(struct mlx5_core_dev *mdev, s64 delta)
+static s32 mlx5_ptp_getmaxphase(struct ptp_clock_info *ptp)
 {
-	s64 min = MLX5_MTUTC_OPERATION_ADJUST_TIME_MIN;
-	s64 max = MLX5_MTUTC_OPERATION_ADJUST_TIME_MAX;
+	struct mlx5_clock *clock = container_of(ptp, struct mlx5_clock, ptp_info);
+	struct mlx5_core_dev *mdev;
 
-	if (MLX5_CAP_MCAM_FEATURE(mdev, mtutc_time_adjustment_extended_range)) {
-		min = MLX5_MTUTC_OPERATION_ADJUST_TIME_EXTENDED_MIN;
-		max = MLX5_MTUTC_OPERATION_ADJUST_TIME_EXTENDED_MAX;
-	}
+	mdev = container_of(clock, struct mlx5_core_dev, clock);
+
+	return MLX5_CAP_MCAM_FEATURE(mdev, mtutc_time_adjustment_extended_range) ?
+		       MLX5_MTUTC_OPERATION_ADJUST_TIME_EXTENDED_MAX :
+			     MLX5_MTUTC_OPERATION_ADJUST_TIME_MAX;
+}
+
+static bool mlx5_is_mtutc_time_adj_cap(struct mlx5_core_dev *mdev, s64 delta)
+{
+	s64 max = mlx5_ptp_getmaxphase(&mdev->clock.ptp_info);
 
-	if (delta < min || delta > max)
+	if (delta < -max || delta > max)
 		return false;
 
 	return true;
@@ -351,14 +357,6 @@ static int mlx5_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
 
 static int mlx5_ptp_adjphase(struct ptp_clock_info *ptp, s32 delta)
 {
-	struct mlx5_clock *clock = container_of(ptp, struct mlx5_clock, ptp_info);
-	struct mlx5_core_dev *mdev;
-
-	mdev = container_of(clock, struct mlx5_core_dev, clock);
-
-	if (!mlx5_is_mtutc_time_adj_cap(mdev, delta))
-		return -ERANGE;
-
 	return mlx5_ptp_adjtime(ptp, delta);
 }
 
@@ -734,6 +732,7 @@ static const struct ptp_clock_info mlx5_ptp_clock_info = {
 	.pps		= 0,
 	.adjfine	= mlx5_ptp_adjfine,
 	.adjphase	= mlx5_ptp_adjphase,
+	.getmaxphase    = mlx5_ptp_getmaxphase,
 	.adjtime	= mlx5_ptp_adjtime,
 	.gettimex64	= mlx5_ptp_gettimex,
 	.settime64	= mlx5_ptp_settime,
-- 
2.38.4

[PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

Advertise the maximum offset the .adjphase callback is capable of
supporting in nanoseconds for IDT ClockMatrix devices.

Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Vincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
---
 drivers/ptp/ptp_clockmatrix.c | 36 +++++++++++++++++------------------
 drivers/ptp/ptp_clockmatrix.h |  2 +-
 2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index c9d451bf89e2..f6f9d4adce04 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c
@@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
 /* PTP Hardware Clock interface */
 
 /*
- * Maximum absolute value for write phase offset in picoseconds
- *
- * @channel:  channel
- * @delta_ns: delta in nanoseconds
+ * Maximum absolute value for write phase offset in nanoseconds
  *
  * Destination signed register is 32-bit register in resolution of 50ps
  *
- * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
+ * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
+ * Represent 107374182350 ps as 107374182 ns
+ */
+static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
+{
+	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
+}
+
+/*
+ * Internal function for implementing support for write phase offset
+ *
+ * @channel:  channel
+ * @delta_ns: delta in nanoseconds
  */
 static int _idtcm_adjphase(struct idtcm_channel *channel, s32 delta_ns)
 {
@@ -1708,7 +1717,6 @@ static int _idtcm_adjphase(struct idtcm_channel *channel, s32 delta_ns)
 	u8 i;
 	u8 buf[4] = {0};
 	s32 phase_50ps;
-	s64 offset_ps;
 
 	if (channel->mode != PTP_PLL_MODE_WRITE_PHASE) {
 		err = channel->configure_write_phase(channel);
@@ -1716,19 +1724,7 @@ static int _idtcm_adjphase(struct idtcm_channel *channel, s32 delta_ns)
 			return err;
 	}
 
-	offset_ps = (s64)delta_ns * 1000;
-
-	/*
-	 * Check for 32-bit signed max * 50:
-	 *
-	 * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
-	 */
-	if (offset_ps > MAX_ABS_WRITE_PHASE_PICOSECONDS)
-		offset_ps = MAX_ABS_WRITE_PHASE_PICOSECONDS;
-	else if (offset_ps < -MAX_ABS_WRITE_PHASE_PICOSECONDS)
-		offset_ps = -MAX_ABS_WRITE_PHASE_PICOSECONDS;
-
-	phase_50ps = div_s64(offset_ps, 50);
+	phase_50ps = div_s64((s64)delta_ns * 1000, 50);
 
 	for (i = 0; i < 4; i++) {
 		buf[i] = phase_50ps & 0xff;
@@ -2048,6 +2044,7 @@ static const struct ptp_clock_info idtcm_caps = {
 	.n_ext_ts	= MAX_TOD,
 	.n_pins		= MAX_REF_CLK,
 	.adjphase	= &idtcm_adjphase,
+	.getmaxphase	= &idtcm_getmaxphase,
 	.adjfine	= &idtcm_adjfine,
 	.adjtime	= &idtcm_adjtime,
 	.gettime64	= &idtcm_gettime,
@@ -2064,6 +2061,7 @@ static const struct ptp_clock_info idtcm_caps_deprecated = {
 	.n_ext_ts	= MAX_TOD,
 	.n_pins		= MAX_REF_CLK,
 	.adjphase	= &idtcm_adjphase,
+	.getmaxphase    = &idtcm_getmaxphase,
 	.adjfine	= &idtcm_adjfine,
 	.adjtime	= &idtcm_adjtime_deprecated,
 	.gettime64	= &idtcm_gettime,
diff --git a/drivers/ptp/ptp_clockmatrix.h b/drivers/ptp/ptp_clockmatrix.h
index bf1e49409844..7c17c4f7f573 100644
--- a/drivers/ptp/ptp_clockmatrix.h
+++ b/drivers/ptp/ptp_clockmatrix.h
@@ -18,7 +18,7 @@
 #define MAX_PLL		(8)
 #define MAX_REF_CLK	(16)
 
-#define MAX_ABS_WRITE_PHASE_PICOSECONDS (107374182350LL)
+#define MAX_ABS_WRITE_PHASE_NANOSECONDS (107374182L)
 
 #define TOD_MASK_ADDR		(0xFFA5)
 #define DEFAULT_TOD_MASK	(0x04)
-- 
2.38.4

[PATCH net-next v2 8/9] ptp: idt82p33: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

Advertise the maximum offset the .adjphase callback is capable of
supporting in nanoseconds for IDT devices.

This change refactors the negation of the offset stored in the register to
be after the boundary check of the offset value rather than before.
Boundary checking is done based on the intended value rather than its
device-specific representation.

Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Min Li <min.li.xe@renesas.com>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
---
 drivers/ptp/ptp_idt82p33.c | 18 +++++++++---------
 drivers/ptp/ptp_idt82p33.h |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/ptp/ptp_idt82p33.c b/drivers/ptp/ptp_idt82p33.c
index afc76c22271a..057190b9cd3d 100644
--- a/drivers/ptp/ptp_idt82p33.c
+++ b/drivers/ptp/ptp_idt82p33.c
@@ -978,24 +978,23 @@ static int idt82p33_enable(struct ptp_clock_info *ptp,
 	return err;
 }
 
+static s32 idt82p33_getmaxphase(__always_unused struct ptp_clock_info *ptp)
+{
+	return WRITE_PHASE_OFFSET_LIMIT;
+}
+
 static int idt82p33_adjwritephase(struct ptp_clock_info *ptp, s32 offset_ns)
 {
 	struct idt82p33_channel *channel =
 		container_of(ptp, struct idt82p33_channel, caps);
 	struct idt82p33 *idt82p33 = channel->idt82p33;
-	s64 offset_regval, offset_fs;
+	s64 offset_regval;
 	u8 val[4] = {0};
 	int err;
 
-	offset_fs = (s64)(-offset_ns) * 1000000;
-
-	if (offset_fs > WRITE_PHASE_OFFSET_LIMIT)
-		offset_fs = WRITE_PHASE_OFFSET_LIMIT;
-	else if (offset_fs < -WRITE_PHASE_OFFSET_LIMIT)
-		offset_fs = -WRITE_PHASE_OFFSET_LIMIT;
-
 	/* Convert from phaseoffset_fs to register value */
-	offset_regval = div_s64(offset_fs * 1000, IDT_T0DPLL_PHASE_RESOL);
+	offset_regval = div_s64((s64)(-offset_ns) * 1000000000ll,
+				IDT_T0DPLL_PHASE_RESOL);
 
 	val[0] = offset_regval & 0xFF;
 	val[1] = (offset_regval >> 8) & 0xFF;
@@ -1175,6 +1174,7 @@ static void idt82p33_caps_init(u32 index, struct ptp_clock_info *caps,
 	caps->n_ext_ts = MAX_PHC_PLL,
 	caps->n_pins = max_pins,
 	caps->adjphase = idt82p33_adjwritephase,
+	caps->getmaxphase = idt82p33_getmaxphase,
 	caps->adjfine = idt82p33_adjfine;
 	caps->adjtime = idt82p33_adjtime;
 	caps->gettime64 = idt82p33_gettime;
diff --git a/drivers/ptp/ptp_idt82p33.h b/drivers/ptp/ptp_idt82p33.h
index 8fcb0b17d207..6a63c14b6966 100644
--- a/drivers/ptp/ptp_idt82p33.h
+++ b/drivers/ptp/ptp_idt82p33.h
@@ -43,9 +43,9 @@
 #define DEFAULT_OUTPUT_MASK_PLL1	DEFAULT_OUTPUT_MASK_PLL0
 
 /**
- * @brief Maximum absolute value for write phase offset in femtoseconds
+ * @brief Maximum absolute value for write phase offset in nanoseconds
  */
-#define WRITE_PHASE_OFFSET_LIMIT (20000052084ll)
+#define WRITE_PHASE_OFFSET_LIMIT (20000l)
 
 /** @brief Phase offset resolution
  *
-- 
2.38.4

[PATCH net-next v2 9/9] ptp: ocp: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

Add a function that advertises a maximum offset of zero supported by
ptp_clock_info .adjphase in the OCP null ptp implementation.

Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
---
 drivers/ptp/ptp_ocp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
index ab8cab4d1560..20a974ced8d6 100644
--- a/drivers/ptp/ptp_ocp.c
+++ b/drivers/ptp/ptp_ocp.c
@@ -1124,6 +1124,12 @@ ptp_ocp_null_adjfine(struct ptp_clock_info *ptp_info, long scaled_ppm)
 	return -EOPNOTSUPP;
 }
 
+static s32
+ptp_ocp_null_getmaxphase(struct ptp_clock_info *ptp_info)
+{
+	return 0;
+}
+
 static int
 ptp_ocp_null_adjphase(struct ptp_clock_info *ptp_info, s32 phase_ns)
 {
@@ -1239,6 +1245,7 @@ static const struct ptp_clock_info ptp_ocp_clock_info = {
 	.adjtime	= ptp_ocp_adjtime,
 	.adjfine	= ptp_ocp_null_adjfine,
 	.adjphase	= ptp_ocp_null_adjphase,
+	.getmaxphase	= ptp_ocp_null_getmaxphase,
 	.enable		= ptp_ocp_enable,
 	.verify		= ptp_ocp_verify,
 	.pps		= true,
-- 
2.38.4

Re: [PATCH net-next v2 1/9] ptp: Clarify ptp_clock_info .adjphase expects an internal servo to be used

[Richard Cochran]

On Tue, May 23, 2023 at 01:54:32PM -0700, Rahul Rameshbabu wrote:
> .adjphase expects a PHC to use an internal servo algorithm to correct the
> provided phase offset target in the callback. Implementation of the
> internal servo algorithm are defined by the individual devices.
> 
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>

Acked-by: Richard Cochran <richardcochran@gmail.com>

Re: [PATCH net-next v2 5/9] ptp: Add .getmaxphase callback to ptp_clock_info

[Richard Cochran]

On Tue, May 23, 2023 at 01:54:36PM -0700, Rahul Rameshbabu wrote:
> Enables advertisement of the maximum offset supported by the phase control
> functionality of PHCs. The callback is used to return an error if an offset
> not supported by the PHC is used in ADJ_OFFSET. The ioctls
> PTP_CLOCK_GETCAPS and PTP_CLOCK_GETCAPS2 now advertise the maximum offset a
> PHC's phase control functionality is capable of supporting. Introduce new
> sysfs node, max_phase_adjustment.
> 
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Maciek Machnikowski <maciek@machnikowski.net>
> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>

Acked-by: Richard Cochran <richardcochran@gmail.com>

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Paolo Abeni]

On Tue, 2023-05-23 at 13:54 -0700, Rahul Rameshbabu wrote:
> Advertise the maximum offset the .adjphase callback is capable of
> supporting in nanoseconds for IDT ClockMatrix devices.
> 
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Vincent Cheng <vincent.cheng.xh@renesas.com>
> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
> ---
>  drivers/ptp/ptp_clockmatrix.c | 36 +++++++++++++++++------------------
>  drivers/ptp/ptp_clockmatrix.h |  2 +-
>  2 files changed, 18 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
> index c9d451bf89e2..f6f9d4adce04 100644
> --- a/drivers/ptp/ptp_clockmatrix.c
> +++ b/drivers/ptp/ptp_clockmatrix.c
> @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
>  /* PTP Hardware Clock interface */
>  
>  /*
> - * Maximum absolute value for write phase offset in picoseconds
> - *
> - * @channel:  channel
> - * @delta_ns: delta in nanoseconds
> + * Maximum absolute value for write phase offset in nanoseconds
>   *
>   * Destination signed register is 32-bit register in resolution of 50ps
>   *
> - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
> + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
> + * Represent 107374182350 ps as 107374182 ns
> + */
> +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
> +{
> +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
> +}

This introduces a functional change WRT the current code. Prior to this
patch ClockMatrix tries to adjust phase delta even above
MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
After this patch it will error out.

Perhaps a more conservative approach would be keeping the existing
logic in _idtcm_adjphase and let idtcm_getmaxphase return  
S32_MAX?

Note that even that will error out for delta == S32_MIN so perhaps an
API change to allow the driver specify unlimited delta would be useful
(possibly regardless of the above).

Cheers,

Paolo

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Paolo Abeni]

On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
> On Tue, 2023-05-23 at 13:54 -0700, Rahul Rameshbabu wrote:
> > Advertise the maximum offset the .adjphase callback is capable of
> > supporting in nanoseconds for IDT ClockMatrix devices.
> > 
> > Cc: Richard Cochran <richardcochran@gmail.com>
> > Cc: Vincent Cheng <vincent.cheng.xh@renesas.com>
> > Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
> > ---
> >  drivers/ptp/ptp_clockmatrix.c | 36 +++++++++++++++++------------------
> >  drivers/ptp/ptp_clockmatrix.h |  2 +-
> >  2 files changed, 18 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
> > index c9d451bf89e2..f6f9d4adce04 100644
> > --- a/drivers/ptp/ptp_clockmatrix.c
> > +++ b/drivers/ptp/ptp_clockmatrix.c
> > @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
> >  /* PTP Hardware Clock interface */
> >  
> >  /*
> > - * Maximum absolute value for write phase offset in picoseconds
> > - *
> > - * @channel:  channel
> > - * @delta_ns: delta in nanoseconds
> > + * Maximum absolute value for write phase offset in nanoseconds
> >   *
> >   * Destination signed register is 32-bit register in resolution of 50ps
> >   *
> > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
> > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
> > + * Represent 107374182350 ps as 107374182 ns
> > + */
> > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
> > +{
> > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
> > +}
> 
> This introduces a functional change WRT the current code. Prior to this
> patch ClockMatrix tries to adjust phase delta even above
> MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
> After this patch it will error out.
> 
> Perhaps a more conservative approach would be keeping the existing
> logic in _idtcm_adjphase and let idtcm_getmaxphase return  
> S32_MAX?
> 
> Note that even that will error out for delta == S32_MIN so perhaps an
> API change to allow the driver specify unlimited delta would be useful
> (possibly regardless of the above).

What about allowing drivers with no getmaxphase() callback, meaning
such drivers allow adjusting unlimited phase delta? 

Thanks!

Paolo

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
>> On Tue, 2023-05-23 at 13:54 -0700, Rahul Rameshbabu wrote:
>> > Advertise the maximum offset the .adjphase callback is capable of
>> > supporting in nanoseconds for IDT ClockMatrix devices.
>> > 
>> > Cc: Richard Cochran <richardcochran@gmail.com>
>> > Cc: Vincent Cheng <vincent.cheng.xh@renesas.com>
>> > Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
>> > ---
>> >  drivers/ptp/ptp_clockmatrix.c | 36 +++++++++++++++++------------------
>> >  drivers/ptp/ptp_clockmatrix.h |  2 +-
>> >  2 files changed, 18 insertions(+), 20 deletions(-)
>> > 
>> > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
>> > index c9d451bf89e2..f6f9d4adce04 100644
>> > --- a/drivers/ptp/ptp_clockmatrix.c
>> > +++ b/drivers/ptp/ptp_clockmatrix.c
>> > @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
>> >  /* PTP Hardware Clock interface */
>> >  
>> >  /*
>> > - * Maximum absolute value for write phase offset in picoseconds
>> > - *
>> > - * @channel:  channel
>> > - * @delta_ns: delta in nanoseconds
>> > + * Maximum absolute value for write phase offset in nanoseconds
>> >   *
>> >   * Destination signed register is 32-bit register in resolution of 50ps
>> >   *
>> > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
>> > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
>> > + * Represent 107374182350 ps as 107374182 ns
>> > + */
>> > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
>> > +{
>> > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
>> > +}
>> 
>> This introduces a functional change WRT the current code. Prior to this
>> patch ClockMatrix tries to adjust phase delta even above
>> MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
>> After this patch it will error out.

My understanding is the syscall for adjphase, clock_adjtime, cannot
represent an offset granularity smaller than nanoseconds using the
struct timex offset member. To me, it seems that adjusting a delta above
MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
units by the device), while supported by the device driver, would not be
a capability utilized by any interface that would invoke the .adjphase
callback implemented by ClockMatrix. The parameter doc comments even
describe the delta provided is in nanoseconds, which is why the
parameter was named delta_ns. Therefore, the increased precision in ps
is lost either way.

>> 
>> Perhaps a more conservative approach would be keeping the existing
>> logic in _idtcm_adjphase and let idtcm_getmaxphase return  
>> S32_MAX?

I personally do not like the idea of a device driver circumventing the
PTP core stack for the check and implementing its own check. I can
understand this choice potentially if the precision supported that is
greater than nanosecond representation was utilized. I think this will
depend on the outcome of the discussion of the previous point.

>> 
>> Note that even that will error out for delta == S32_MIN so perhaps an
>> API change to allow the driver specify unlimited delta would be useful
>> (possibly regardless of the above).
>
> What about allowing drivers with no getmaxphase() callback, meaning
> such drivers allow adjusting unlimited phase delta? 

I think this relates to the idea that even with "unlimited" adjustment
support, the driver is still bound by the parameter value range for the
.adjphase interface. Therefore, there really is not a way to support
"unlimited" delta per-say. I understand the argument that the interface
+ check in the ptp core stack will limit the adjustment range to be
[S32_MIN + 1, S32_MAX - 1] at most rather than [S32_MIN, S32_MAX].
However, I feel that if such large offset adjustments are needed, a
difference of one nanosecond in either extreme is not a large loss.

The reason I wanted to enforce device drivers to implement .getmaxphase
was to discourage/avoid drivers from implementing their own range checks
in .adjphase since there is a core check in the ptp_clock_adjtime
function invoked when userspace calls the clock_adjtime syscall for the
ADJ_OFFSET operation. Maybe this is just something to be discussed
during each code review instead when implementers publish support to the
mailing list?

>
> Thanks!
>
> Paolo

Thanks for the feedback,

Rahul Rameshbabu

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

Hi Paolo,

Any comments on this follow-up?

On Thu, 25 May, 2023 11:09:17 -0700 Rahul Rameshbabu <rrameshbabu@nvidia.com> wrote:
> On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
>> On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
>>> On Tue, 2023-05-23 at 13:54 -0700, Rahul Rameshbabu wrote:
>>> > Advertise the maximum offset the .adjphase callback is capable of
>>> > supporting in nanoseconds for IDT ClockMatrix devices.
>>> > 
>>> > Cc: Richard Cochran <richardcochran@gmail.com>
>>> > Cc: Vincent Cheng <vincent.cheng.xh@renesas.com>
>>> > Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
>>> > ---
>>> >  drivers/ptp/ptp_clockmatrix.c | 36 +++++++++++++++++------------------
>>> >  drivers/ptp/ptp_clockmatrix.h |  2 +-
>>> >  2 files changed, 18 insertions(+), 20 deletions(-)
>>> > 
>>> > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
>>> > index c9d451bf89e2..f6f9d4adce04 100644
>>> > --- a/drivers/ptp/ptp_clockmatrix.c
>>> > +++ b/drivers/ptp/ptp_clockmatrix.c
>>> > @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
>>> >  /* PTP Hardware Clock interface */
>>> >  
>>> >  /*
>>> > - * Maximum absolute value for write phase offset in picoseconds
>>> > - *
>>> > - * @channel:  channel
>>> > - * @delta_ns: delta in nanoseconds
>>> > + * Maximum absolute value for write phase offset in nanoseconds
>>> >   *
>>> >   * Destination signed register is 32-bit register in resolution of 50ps
>>> >   *
>>> > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
>>> > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
>>> > + * Represent 107374182350 ps as 107374182 ns
>>> > + */
>>> > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
>>> > +{
>>> > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
>>> > +}
>>> 
>>> This introduces a functional change WRT the current code. Prior to this
>>> patch ClockMatrix tries to adjust phase delta even above
>>> MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
>>> After this patch it will error out.
>
> My understanding is the syscall for adjphase, clock_adjtime, cannot
> represent an offset granularity smaller than nanoseconds using the
> struct timex offset member. To me, it seems that adjusting a delta above
> MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
> units by the device), while supported by the device driver, would not be
> a capability utilized by any interface that would invoke the .adjphase
> callback implemented by ClockMatrix. The parameter doc comments even
> describe the delta provided is in nanoseconds, which is why the
> parameter was named delta_ns. Therefore, the increased precision in ps
> is lost either way.
>
>>> 
>>> Perhaps a more conservative approach would be keeping the existing
>>> logic in _idtcm_adjphase and let idtcm_getmaxphase return  
>>> S32_MAX?
>
> I personally do not like the idea of a device driver circumventing the
> PTP core stack for the check and implementing its own check. I can
> understand this choice potentially if the precision supported that is
> greater than nanosecond representation was utilized. I think this will
> depend on the outcome of the discussion of the previous point.
>
>>> 
>>> Note that even that will error out for delta == S32_MIN so perhaps an
>>> API change to allow the driver specify unlimited delta would be useful
>>> (possibly regardless of the above).
>>
>> What about allowing drivers with no getmaxphase() callback, meaning
>> such drivers allow adjusting unlimited phase delta? 
>
> I think this relates to the idea that even with "unlimited" adjustment
> support, the driver is still bound by the parameter value range for the
> .adjphase interface. Therefore, there really is not a way to support
> "unlimited" delta per-say. I understand the argument that the interface
> + check in the ptp core stack will limit the adjustment range to be
> [S32_MIN + 1, S32_MAX - 1] at most rather than [S32_MIN, S32_MAX].
> However, I feel that if such large offset adjustments are needed, a
> difference of one nanosecond in either extreme is not a large loss.
>
> The reason I wanted to enforce device drivers to implement .getmaxphase
> was to discourage/avoid drivers from implementing their own range checks
> in .adjphase since there is a core check in the ptp_clock_adjtime
> function invoked when userspace calls the clock_adjtime syscall for the
> ADJ_OFFSET operation. Maybe this is just something to be discussed
> during each code review instead when implementers publish support to the
> mailing list?
>

I am pretty open to revising this, but I wanted to know if your opinion
is still the same based on this response I provided.

>>
>> Thanks!
>>
>> Paolo
>
> Thanks for the feedback,
>
> Rahul Rameshbabu

Thanks,

-- Rahul Rameshbabu

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Paolo Abeni]

Hi,

I'm sorry for the late reply. This fell under my radar.

On Thu, 2023-05-25 at 11:09 -0700, Rahul Rameshbabu wrote:
> On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> > On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
> > > > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
> > > > index c9d451bf89e2..f6f9d4adce04 100644
> > > > --- a/drivers/ptp/ptp_clockmatrix.c
> > > > +++ b/drivers/ptp/ptp_clockmatrix.c
> > > > @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
> > > >  /* PTP Hardware Clock interface */
> > > >  
> > > >  /*
> > > > - * Maximum absolute value for write phase offset in picoseconds
> > > > - *
> > > > - * @channel:  channel
> > > > - * @delta_ns: delta in nanoseconds
> > > > + * Maximum absolute value for write phase offset in nanoseconds
> > > >   *
> > > >   * Destination signed register is 32-bit register in resolution of 50ps
> > > >   *
> > > > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
> > > > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
> > > > + * Represent 107374182350 ps as 107374182 ns
> > > > + */
> > > > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
> > > > +{
> > > > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
> > > > +}
> > > 
> > > This introduces a functional change WRT the current code. Prior to this
> > > patch ClockMatrix tries to adjust phase delta even above
> > > MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
> > > After this patch it will error out.
> 
> My understanding is the syscall for adjphase, clock_adjtime, cannot
> represent an offset granularity smaller than nanoseconds using the
> struct timex offset member. 

Ok.

> To me, it seems that adjusting a delta above
> MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
> units by the device), while supported by the device driver, would not be
> a capability utilized by any interface that would invoke the .adjphase
> callback implemented by ClockMatrix.

Here I don't follow. I must admit I know the ptp subsystem very little,
but AFAICS, we could have e.g.

clock_adjtime() // offset > 200 secs (200000000 usec)
 -> do_clock_adjtime
    -> kc->clock_adj
       -> clock_posix_dynamic
          -> pc_clock_adjtime
             -> ptp_clock_adjtime
                -> _idtcm_adjphase // delta land unmodified up here

I guess the user-space could pass such large delta (e.g. at boot
time?!?). If so, with this patch we change an user-space observable
behavior, and I think we should avoid that.

Thanks

Paolo

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

On Fri, 09 Jun, 2023 08:38:11 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> Hi,
>
> I'm sorry for the late reply. This fell under my radar.
>
> On Thu, 2023-05-25 at 11:09 -0700, Rahul Rameshbabu wrote:
>> On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
>> > On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
>> > > > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
>> > > > index c9d451bf89e2..f6f9d4adce04 100644
>> > > > --- a/drivers/ptp/ptp_clockmatrix.c
>> > > > +++ b/drivers/ptp/ptp_clockmatrix.c
>> > > > @@ -1692,14 +1692,23 @@ static int initialize_dco_operating_mode(struct idtcm_channel *channel)
>> > > >  /* PTP Hardware Clock interface */
>> > > >  
>> > > >  /*
>> > > > - * Maximum absolute value for write phase offset in picoseconds
>> > > > - *
>> > > > - * @channel:  channel
>> > > > - * @delta_ns: delta in nanoseconds
>> > > > + * Maximum absolute value for write phase offset in nanoseconds
>> > > >   *
>> > > >   * Destination signed register is 32-bit register in resolution of 50ps
>> > > >   *
>> > > > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
>> > > > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
>> > > > + * Represent 107374182350 ps as 107374182 ns
>> > > > + */
>> > > > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
>> > > > +{
>> > > > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
>> > > > +}
>> > > 
>> > > This introduces a functional change WRT the current code. Prior to this
>> > > patch ClockMatrix tries to adjust phase delta even above
>> > > MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
>> > > After this patch it will error out.
>> 
>> My understanding is the syscall for adjphase, clock_adjtime, cannot
>> represent an offset granularity smaller than nanoseconds using the
>> struct timex offset member. 
>
> Ok.
>
>> To me, it seems that adjusting a delta above
>> MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
>> units by the device), while supported by the device driver, would not be
>> a capability utilized by any interface that would invoke the .adjphase
>> callback implemented by ClockMatrix.

I see I caused some confusion in terms of what I was focused on with
this response. My main concern here was still about supporting precision
units higher than nanoseconds. For example if a device was capable of
supporting 107374182350 picoseconds for ADJ_OFFSET, it doesn't matter
whether the driver advertises 107374182 nanoseconds as the maximum
adjustment capability versus 107374182350 picoseconds even though
107374182 nanoseconds < 107374182350 picoseconds because the granularity
of the parameter for the adjphase callback is in nanoseconds. I think we
have converged on this topic but not the other point you brought up.

>
> Here I don't follow. I must admit I know the ptp subsystem very little,
> but AFAICS, we could have e.g.
>
> clock_adjtime() // offset > 200 secs (200000000 usec)
>  -> do_clock_adjtime
>     -> kc->clock_adj
>        -> clock_posix_dynamic
>           -> pc_clock_adjtime
>              -> ptp_clock_adjtime
>                 -> _idtcm_adjphase // delta land unmodified up here
>
> I guess the user-space could pass such large delta (e.g. at boot
> time?!?). If so, with this patch we change an user-space observable
> behavior, and I think we should avoid that.

The point that you bring up here is about clamping (which is done by
idtcm_adjphase previously) versus throwing an error when out of range
(what is now done in ptp_clock_adjtime in this patch series). This was
something I was struggling with deciding on a unified behavior across
all drivers. For example, the mlx5_core driver chooses to return -ERANGE
when the delta landed on it is out of the range supported by the PHC of
the device. We chose to return an error because there was no mechanism
previously for the userspace to know what was the supported offset when
using ADJ_OFFSET with different PHC devices. If a user provides an
offset and no error is returned, the user would assume that offset had
been applied (there was no way to know that it was clamped from the
userspace). This patch series now adds the query for maximum supported
offset in the PTP_CLOCK_GETCAPS ioctl. In my opinion, I think we will
see an userspace observable behavior change either way unfortunately due
to the inconsistency among device drivers, which was one of the main
issues this patch submission targets. I am ok with making the common
behavior in ptp_clock_adjtime clamp the provided offset value instead of
throwing an error when out of range. In both cases, userspace programs
can handle the out-of-range case explicitly with a check against the
maximum offset value now advertised in PTP_CLOCK_GETCAPS. My personal
opinion is that since we have this inconsistency among device drivers
for handling out of range offsets that are currently provided as-is to
the driver-specific callback implementations, it makes sense to converge
to a version that returns an error when the userspace provides
out-of-range values rather than silently clamping these values. However,
I am open to either version as long as we have consistency and do not
leave this up to individual device-drivers to dictate since this adds
further complexity in the userspace when working with this syscall.

>
> Thanks
>
> Paolo

Thanks,

Rahul Rameshbabu

RE: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Keller, Jacob E]

> -----Original Message-----
> From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
> Sent: Friday, June 9, 2023 12:48 PM
> To: Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; David S. Miller <davem@davemloft.net>; Keller,
> Jacob E <jacob.e.keller@intel.com>; Gal Pressman <gal@nvidia.com>; Tariq
> Toukan <tariqt@nvidia.com>; Saeed Mahameed <saeed@kernel.org>; Richard
> Cochran <richardcochran@gmail.com>; Vincent Cheng
> <vincent.cheng.xh@renesas.com>
> Subject: Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase
> ptp_clock_info callback
> 
> On Fri, 09 Jun, 2023 08:38:11 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> > Hi,
> >
> > I'm sorry for the late reply. This fell under my radar.
> >
> > On Thu, 2023-05-25 at 11:09 -0700, Rahul Rameshbabu wrote:
> >> On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com>
> wrote:
> >> > On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
> >> > > > diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
> >> > > > index c9d451bf89e2..f6f9d4adce04 100644
> >> > > > --- a/drivers/ptp/ptp_clockmatrix.c
> >> > > > +++ b/drivers/ptp/ptp_clockmatrix.c
> >> > > > @@ -1692,14 +1692,23 @@ static int
> initialize_dco_operating_mode(struct idtcm_channel *channel)
> >> > > >  /* PTP Hardware Clock interface */
> >> > > >
> >> > > >  /*
> >> > > > - * Maximum absolute value for write phase offset in picoseconds
> >> > > > - *
> >> > > > - * @channel:  channel
> >> > > > - * @delta_ns: delta in nanoseconds
> >> > > > + * Maximum absolute value for write phase offset in nanoseconds
> >> > > >   *
> >> > > >   * Destination signed register is 32-bit register in resolution of 50ps
> >> > > >   *
> >> > > > - * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
> >> > > > + * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
> >> > > > + * Represent 107374182350 ps as 107374182 ns
> >> > > > + */
> >> > > > +static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp
> __always_unused)
> >> > > > +{
> >> > > > +	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
> >> > > > +}
> >> > >
> >> > > This introduces a functional change WRT the current code. Prior to this
> >> > > patch ClockMatrix tries to adjust phase delta even above
> >> > > MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
> >> > > After this patch it will error out.
> >>
> >> My understanding is the syscall for adjphase, clock_adjtime, cannot
> >> represent an offset granularity smaller than nanoseconds using the
> >> struct timex offset member.
> >
> > Ok.
> >
> >> To me, it seems that adjusting a delta above
> >> MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
> >> units by the device), while supported by the device driver, would not be
> >> a capability utilized by any interface that would invoke the .adjphase
> >> callback implemented by ClockMatrix.
> 
> I see I caused some confusion in terms of what I was focused on with
> this response. My main concern here was still about supporting precision
> units higher than nanoseconds. For example if a device was capable of
> supporting 107374182350 picoseconds for ADJ_OFFSET, it doesn't matter
> whether the driver advertises 107374182 nanoseconds as the maximum
> adjustment capability versus 107374182350 picoseconds even though
> 107374182 nanoseconds < 107374182350 picoseconds because the granularity
> of the parameter for the adjphase callback is in nanoseconds. I think we
> have converged on this topic but not the other point you brought up.
> 
> >
> > Here I don't follow. I must admit I know the ptp subsystem very little,
> > but AFAICS, we could have e.g.
> >
> > clock_adjtime() // offset > 200 secs (200000000 usec)
> >  -> do_clock_adjtime
> >     -> kc->clock_adj
> >        -> clock_posix_dynamic
> >           -> pc_clock_adjtime
> >              -> ptp_clock_adjtime
> >                 -> _idtcm_adjphase // delta land unmodified up here
> >
> > I guess the user-space could pass such large delta (e.g. at boot
> > time?!?). If so, with this patch we change an user-space observable
> > behavior, and I think we should avoid that.
> 
> The point that you bring up here is about clamping (which is done by
> idtcm_adjphase previously) versus throwing an error when out of range
> (what is now done in ptp_clock_adjtime in this patch series). This was
> something I was struggling with deciding on a unified behavior across
> all drivers. For example, the mlx5_core driver chooses to return -ERANGE
> when the delta landed on it is out of the range supported by the PHC of
> the device. We chose to return an error because there was no mechanism
> previously for the userspace to know what was the supported offset when
> using ADJ_OFFSET with different PHC devices. If a user provides an
> offset and no error is returned, the user would assume that offset had
> been applied (there was no way to know that it was clamped from the
> userspace). This patch series now adds the query for maximum supported
> offset in the PTP_CLOCK_GETCAPS ioctl. In my opinion, I think we will
> see an userspace observable behavior change either way unfortunately due
> to the inconsistency among device drivers, which was one of the main
> issues this patch submission targets. I am ok with making the common
> behavior in ptp_clock_adjtime clamp the provided offset value instead of
> throwing an error when out of range. In both cases, userspace programs
> can handle the out-of-range case explicitly with a check against the
> maximum offset value now advertised in PTP_CLOCK_GETCAPS. My personal
> opinion is that since we have this inconsistency among device drivers
> for handling out of range offsets that are currently provided as-is to
> the driver-specific callback implementations, it makes sense to converge
> to a version that returns an error when the userspace provides
> out-of-range values rather than silently clamping these values. However,
> I am open to either version as long as we have consistency and do not
> leave this up to individual device-drivers to dictate since this adds
> further complexity in the userspace when working with this syscall.
> 

I'm in favor of throwing an error, since userspace that *doesn't* check for the max value and assumes it will apply without a clamp may be surprised when it starts clamping. Userspace which previously supplied a large value and it clamps now gets an error, which might be concerning, but they got driver defined behavior before, where it might error or it might clamp, so I think we're in a no-win scenario there.

I don't really see the value in clamping because that makes it hard to tell if an update was fully applied or not. Now software has to know to check the range in advance. I wouldn't view a partially applied update as a successful behavior in a timing application. Thus, on the principle of least surprise I would avoid clamping. I'm open to other opinions, and I think standardizing is much better than letting it be driver behavior.


> >
> > Thanks
> >
> > Paolo
> 
> Thanks,
> 
> Rahul Rameshbabu

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Paolo Abeni]

On Mon, 2023-06-12 at 05:16 +0000, Keller, Jacob E wrote:
> > -----Original Message-----
> > From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
> > Sent: Friday, June 9, 2023 12:48 PM
> > To: Paolo Abeni <pabeni@redhat.com>
> > Cc: netdev@vger.kernel.org; David S. Miller <davem@davemloft.net>; Keller,
> > Jacob E <jacob.e.keller@intel.com>; Gal Pressman <gal@nvidia.com>; Tariq
> > Toukan <tariqt@nvidia.com>; Saeed Mahameed <saeed@kernel.org>; Richard
> > Cochran <richardcochran@gmail.com>; Vincent Cheng
> > <vincent.cheng.xh@renesas.com>
> > Subject: Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase
> > ptp_clock_info callback
> > 
> > On Fri, 09 Jun, 2023 08:38:11 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> > > On Thu, 2023-05-25 at 11:09 -0700, Rahul Rameshbabu wrote:
> > > > On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> > > > 
> > > 
> > > I guess the user-space could pass such large delta (e.g. at boot
> > > time?!?). If so, with this patch we change an user-space observable
> > > behavior, and I think we should avoid that.
> > 
> > The point that you bring up here is about clamping (which is done by
> > idtcm_adjphase previously) versus throwing an error when out of range
> > (what is now done in ptp_clock_adjtime in this patch series). This was
> > something I was struggling with deciding on a unified behavior across
> > all drivers. For example, the mlx5_core driver chooses to return -ERANGE
> > when the delta landed on it is out of the range supported by the PHC of
> > the device. We chose to return an error because there was no mechanism
> > previously for the userspace to know what was the supported offset when
> > using ADJ_OFFSET with different PHC devices. If a user provides an
> > offset and no error is returned, the user would assume that offset had
> > been applied (there was no way to know that it was clamped from the
> > userspace). This patch series now adds the query for maximum supported
> > offset in the PTP_CLOCK_GETCAPS ioctl. In my opinion, I think we will
> > see an userspace observable behavior change either way unfortunately due
> > to the inconsistency among device drivers, which was one of the main
> > issues this patch submission targets. I am ok with making the common
> > behavior in ptp_clock_adjtime clamp the provided offset value instead of
> > throwing an error when out of range. In both cases, userspace programs
> > can handle the out-of-range case explicitly with a check against the
> > maximum offset value now advertised in PTP_CLOCK_GETCAPS. My personal
> > opinion is that since we have this inconsistency among device drivers
> > for handling out of range offsets that are currently provided as-is to
> > the driver-specific callback implementations, it makes sense to converge
> > to a version that returns an error when the userspace provides
> > out-of-range values rather than silently clamping these values. However,
> > I am open to either version as long as we have consistency and do not
> > leave this up to individual device-drivers to dictate since this adds
> > further complexity in the userspace when working with this syscall.
> 
> I'm in favor of throwing an error, since userspace that *doesn't*
> check for the max value and assumes it will apply without a clamp may
> be surprised when it starts clamping. Userspace which previously
> supplied a large value and it clamps now gets an error, which might
> be concerning, but they got driver defined behavior before, where it
> might error or it might clamp, so I think we're in a no-win scenario
> there.
> 
> I don't really see the value in clamping because that makes it hard
> to tell if an update was fully applied or not. Now software has to
> know to check the range in advance. I wouldn't view a partially
> applied update as a successful behavior in a timing application.
> Thus, on the principle of least surprise I would avoid clamping. I'm
> open to other opinions, and I think standardizing is much better than
> letting it be driver behavior.

Given that this is general agreement on throwing an error, I'll be ok
with that. Perhaps mention the behaviour change in the commit message?

Thanks!

Paolo

Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase ptp_clock_info callback

[Rahul Rameshbabu]

On Mon, 12 Jun, 2023 16:15:29 +0200 Paolo Abeni <pabeni@redhat.com> wrote:
> Given that this is general agreement on throwing an error, I'll be ok
> with that. Perhaps mention the behaviour change in the commit message?
>
> Thanks!
>
> Paolo

Mentioned the behavior change in the following patches.

Link: https://lore.kernel.org/netdev/20230612211500.309075-8-rrameshbabu@nvidia.com/
Link: https://lore.kernel.org/netdev/20230612211500.309075-9-rrameshbabu@nvidia.com/

Thanks,

-- Rahul Rameshbabu