[PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

HW support of PTP/timesync solutions in network PHY chips can be
achieved with two different approaches, the timestamp maybe latched
either in the beginning or after the Start of Frame Delimiter (SFD) [1].

Allow ptp device drivers to provide user with control over the timestamp
latch point.

[1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf

Arkadiusz Kubalewski (2):
  ptp: add control over HW timestamp latch point
  ice: ptp: add control over HW timestamp latch point

 Documentation/ABI/testing/sysfs-ptp         | 12 +++++
 drivers/net/ethernet/intel/ice/ice_ptp.c    | 44 +++++++++++++++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 59 +++++++++++++++++++++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
 drivers/ptp/ptp_sysfs.c                     | 44 +++++++++++++++
 include/linux/ptp_clock_kernel.h            | 30 +++++++++++
 6 files changed, 191 insertions(+)

-- 
2.38.1

[PATCH net-next v2 1/2] ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

Currently HW support of PTP/timesync solutions in network PHY chips can be
implemented with two different approaches, the timestamp maybe latched
either at the beginning or after the Start of Frame Delimiter (SFD) [1].

Allow ptp device drivers to provide user with control over the HW
timestamp latch point with ptp sysfs ABI. Provide a new file under sysfs
ptp device (/sys/class/ptp/ptp<N>/ts_point). The file is available for the
user, if the device driver implements at least one of newly provided
callbacks. If the file is not provided the user shall find a PHY timestamp
latch point within the HW vendor specification.

The file is designed for root user/group access only, as the read for
regular user could impact performance of the ptp device.

Usage, examples:

** Obtain current state:
$ cat /sys/class/ptp/ptp<N>/ts_point
Command returns enum/integer:
* 0 - timestamp latched by PHY at the beginning of SFD,
* 1 - timestamp latched by PHY after the SFD,
* None - callback returns error to the user.

** Configure timestamp latch point at the beginning of SFD:
$ echo 0 > /sys/class/ptp/ptp<N>/ts_point

** Configure timestamp latch point after the SFD:
$ echo 1 > /sys/class/ptp/ptp<N>/ts_point

[1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
---
v2:
- improve commit message, describe the new sysfs file and add usage
  examples,
- improve alignment in documentation of enum ptp_ts_point,
- use 0660 permission for ts_point file.
---
 Documentation/ABI/testing/sysfs-ptp | 12 ++++++++
 drivers/ptp/ptp_sysfs.c             | 44 +++++++++++++++++++++++++++++
 include/linux/ptp_clock_kernel.h    | 30 ++++++++++++++++++++
 3 files changed, 86 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp
index 9c317ac7c47a..a0d89e0fd72e 100644
--- a/Documentation/ABI/testing/sysfs-ptp
+++ b/Documentation/ABI/testing/sysfs-ptp
@@ -140,3 +140,15 @@ Description:
 		PPS events to the Linux PPS subsystem. To enable PPS
 		events, write a "1" into the file. To disable events,
 		write a "0" into the file.
+
+What:		/sys/class/ptp/ptp<N>/ts_point
+Date:		October 2024
+Contact:	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
+Description:
+		This file provides control over the point in time in
+		which the HW timestamp is latched. As specified in IEEE
+		802.3cx, the latch point can be either at the beginning
+		or after the end of Start of Frame Delimiter (SFD).
+		Value "0" means the timestamp is latched at the
+		beginning of the SFD. Value "1" means that timestamp is
+		latched after the end of SFD.
diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
index 6b1b8f57cd95..76c2fac54be4 100644
--- a/drivers/ptp/ptp_sysfs.c
+++ b/drivers/ptp/ptp_sysfs.c
@@ -28,6 +28,46 @@ static ssize_t max_phase_adjustment_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(max_phase_adjustment);
 
+static ssize_t ts_point_show(struct device *dev, struct device_attribute *attr,
+			     char *page)
+{
+	struct ptp_clock *ptp = dev_get_drvdata(dev);
+	enum ptp_ts_point point;
+	int err;
+
+	if (!ptp->info->get_ts_point)
+		return -EOPNOTSUPP;
+	err = ptp->info->get_ts_point(ptp->info, &point);
+	if (err)
+		return err;
+
+	return sysfs_emit(page, "%d\n", point);
+}
+
+static ssize_t ts_point_store(struct device *dev, struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct ptp_clock *ptp = dev_get_drvdata(dev);
+	enum ptp_ts_point point;
+	int err;
+	u8 val;
+
+	if (!ptp->info->set_ts_point)
+		return -EOPNOTSUPP;
+	if (kstrtou8(buf, 0, &val))
+		return -EINVAL;
+	if (val > PTP_TS_POINT_MAX)
+		return -EINVAL;
+	point = val;
+
+	err = ptp->info->set_ts_point(ptp->info, point);
+	if (err)
+		return err;
+
+	return count;
+}
+static DEVICE_ATTR(ts_point, 0660, ts_point_show, ts_point_store);
+
 #define PTP_SHOW_INT(name, var)						\
 static ssize_t var##_show(struct device *dev,				\
 			   struct device_attribute *attr, char *page)	\
@@ -335,6 +375,7 @@ static struct attribute *ptp_attrs[] = {
 	&dev_attr_pps_enable.attr,
 	&dev_attr_n_vclocks.attr,
 	&dev_attr_max_vclocks.attr,
+	&dev_attr_ts_point.attr,
 	NULL
 };
 
@@ -363,6 +404,9 @@ static umode_t ptp_is_attribute_visible(struct kobject *kobj,
 	} else if (attr == &dev_attr_max_phase_adjustment.attr) {
 		if (!info->adjphase || !info->getmaxphase)
 			mode = 0;
+	} else if (attr == &dev_attr_ts_point.attr) {
+		if (!info->get_ts_point && !info->set_ts_point)
+			mode = 0;
 	}
 
 	return mode;
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index c892d22ce0a7..ea1bcca7f7f6 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -55,6 +55,24 @@ struct ptp_system_timestamp {
 	clockid_t clockid;
 };
 
+/**
+ * enum ptp_ts_point - possible timestamp latch points (IEEE 802.3cx)
+ *
+ * @PTP_TS_POINT_SFD: timestamp latched at the beginning of sending Start
+ *		      of Frame Delimiter (SFD)
+ * @PTP_TS_POINT_POST_SFD: timestamp latched after the end of sending Start
+ *			   of Frame Delimiter (SFD)
+ */
+enum ptp_ts_point {
+	PTP_TS_POINT_SFD,
+	PTP_TS_POINT_POST_SFD,
+
+	/* private: */
+	__PTP_TS_POINT_MAX
+};
+
+#define PTP_TS_POINT_MAX (__PTP_TS_POINT_MAX - 1)
+
 /**
  * struct ptp_clock_info - describes a PTP hardware clock
  *
@@ -159,6 +177,14 @@ struct ptp_system_timestamp {
  *                scheduling time (>=0) or negative value in case further
  *                scheduling is not required.
  *
+ * @set_ts_point: Request change of timestamp latch point, as the timestamp
+ *                could be latched at the beginning or after the end of start
+ *                frame delimiter (SFD), as described in IEEE 802.3cx
+ *                specification.
+ *
+ * @get_ts_point: Obtain the timestamp measurement latch point, counterpart of
+ *                .set_ts_point() for getting currently configured value.
+ *
  * Drivers should embed their ptp_clock_info within a private
  * structure, obtaining a reference to it using container_of().
  *
@@ -195,6 +221,10 @@ struct ptp_clock_info {
 	int (*verify)(struct ptp_clock_info *ptp, unsigned int pin,
 		      enum ptp_pin_function func, unsigned int chan);
 	long (*do_aux_work)(struct ptp_clock_info *ptp);
+	int (*set_ts_point)(struct ptp_clock_info *ptp,
+			    enum ptp_ts_point point);
+	int (*get_ts_point)(struct ptp_clock_info *ptp,
+			    enum ptp_ts_point *point);
 };
 
 struct ptp_clock;
-- 
2.38.1

Re: [PATCH net-next v2 1/2] ptp: add control over HW timestamp latch point

[Przemek Kitszel]

On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
> Currently HW support of PTP/timesync solutions in network PHY chips can be
> implemented with two different approaches, the timestamp maybe latched
> either at the beginning or after the Start of Frame Delimiter (SFD) [1].
> 
> Allow ptp device drivers to provide user with control over the HW
> timestamp latch point with ptp sysfs ABI. Provide a new file under sysfs
> ptp device (/sys/class/ptp/ptp<N>/ts_point). The file is available for the
> user, if the device driver implements at least one of newly provided
> callbacks. If the file is not provided the user shall find a PHY timestamp
> latch point within the HW vendor specification.
> 
> The file is designed for root user/group access only, as the read for
> regular user could impact performance of the ptp device.
> 
> Usage, examples:
> 
> ** Obtain current state:
> $ cat /sys/class/ptp/ptp<N>/ts_point
> Command returns enum/integer:
> * 0 - timestamp latched by PHY at the beginning of SFD,
> * 1 - timestamp latched by PHY after the SFD,
> * None - callback returns error to the user.
> 
> ** Configure timestamp latch point at the beginning of SFD:
> $ echo 0 > /sys/class/ptp/ptp<N>/ts_point
> 
> ** Configure timestamp latch point after the SFD:
> $ echo 1 > /sys/class/ptp/ptp<N>/ts_point
> 
> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
> 
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>

[...]

> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index c892d22ce0a7..ea1bcca7f7f6 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -55,6 +55,24 @@ struct ptp_system_timestamp {
>   	clockid_t clockid;
>   };
>   
> +/**
> + * enum ptp_ts_point - possible timestamp latch points (IEEE 802.3cx)
> + *
> + * @PTP_TS_POINT_SFD: timestamp latched at the beginning of sending Start
> + *		      of Frame Delimiter (SFD)
> + * @PTP_TS_POINT_POST_SFD: timestamp latched after the end of sending Start
> + *			   of Frame Delimiter (SFD)
> + */
> +enum ptp_ts_point {
> +	PTP_TS_POINT_SFD,
> +	PTP_TS_POINT_POST_SFD,
> +
> +	/* private: */
> +	__PTP_TS_POINT_MAX
> +};
> +
> +#define PTP_TS_POINT_MAX (__PTP_TS_POINT_MAX - 1)

I would move PTP_TS_POINT_MAX into the enum

RE: [PATCH net-next v2 1/2] ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
>Sent: Tuesday, October 29, 2024 9:25 AM
>Subject: Re: [PATCH net-next v2 1/2] ptp: add control over HW timestamp
>latch point
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Currently HW support of PTP/timesync solutions in network PHY chips
>> can be implemented with two different approaches, the timestamp maybe
>> latched either at the beginning or after the Start of Frame Delimiter
>>(SFD) [1].
>>
>> Allow ptp device drivers to provide user with control over the HW
>> timestamp latch point with ptp sysfs ABI. Provide a new file under
>> sysfs ptp device (/sys/class/ptp/ptp<N>/ts_point). The file is
>> available for the user, if the device driver implements at least one
>> of newly provided callbacks. If the file is not provided the user
>> shall find a PHY timestamp latch point within the HW vendor
>>specification.
>>
>> The file is designed for root user/group access only, as the read for
>> regular user could impact performance of the ptp device.
>>
>> Usage, examples:
>>
>> ** Obtain current state:
>> $ cat /sys/class/ptp/ptp<N>/ts_point
>> Command returns enum/integer:
>> * 0 - timestamp latched by PHY at the beginning of SFD,
>> * 1 - timestamp latched by PHY after the SFD,
>> * None - callback returns error to the user.
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 0 > /sys/class/ptp/ptp<N>/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 1 > /sys/class/ptp/ptp<N>/ts_point
>>
>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>
>[...]
>
>> diff --git a/include/linux/ptp_clock_kernel.h
>> b/include/linux/ptp_clock_kernel.h
>> index c892d22ce0a7..ea1bcca7f7f6 100644
>> --- a/include/linux/ptp_clock_kernel.h
>> +++ b/include/linux/ptp_clock_kernel.h
>> @@ -55,6 +55,24 @@ struct ptp_system_timestamp {
>>   	clockid_t clockid;
>>   };
>>
>> +/**
>> + * enum ptp_ts_point - possible timestamp latch points (IEEE 802.3cx)
>> + *
>> + * @PTP_TS_POINT_SFD: timestamp latched at the beginning of sending
>Start
>> + *		      of Frame Delimiter (SFD)
>> + * @PTP_TS_POINT_POST_SFD: timestamp latched after the end of sending
>Start
>> + *			   of Frame Delimiter (SFD)
>> + */
>> +enum ptp_ts_point {
>> +	PTP_TS_POINT_SFD,
>> +	PTP_TS_POINT_POST_SFD,
>> +
>> +	/* private: */
>> +	__PTP_TS_POINT_MAX
>> +};
>> +
>> +#define PTP_TS_POINT_MAX (__PTP_TS_POINT_MAX - 1)
>
>I would move PTP_TS_POINT_MAX into the enum
>

Fixed in v3.

Thank you!
Arkadiusz

[PATCH net-next v2 2/2] ice: ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

Allow user to control the latch point of ptp HW timestamps in E825
devices.

Usage, examples:

** Obtain current state:
$ cat /sys/class/net/eth<N>/device/ptp/ts_point
Command returns enum/integer:
* 0 - timestamp latched by PHY at the beginning of SFD,
* 1 - timestamp latched by PHY after the SFD,
* None - callback returns error to the user.

** Configure timestamp latch point at the beginning of SFD:
$ echo 0 > /sys/class/net/eth<N>/device/ptp/ts_point

** Configure timestamp latch point after the SFD:
$ echo 1 > /sys/class/net/eth<N>/device/ptp/ts_point

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
---
v2:
- add kernel doc return description on ice_get_ts_point(..),
- use enum ptp_ts_point directly, instead of additional bool to pass tx
  timestamp latch point from userspace callback up to ptp_hw
  configuration,
- fix bit logic.
---
 drivers/net/ethernet/intel/ice/ice_ptp.c    | 44 +++++++++++++++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 59 +++++++++++++++++++++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
 3 files changed, 105 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index a999fface272..21fc6b5e2d69 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -2509,6 +2509,48 @@ static int ice_ptp_parse_sdp_entries(struct ice_pf *pf, __le16 *entries,
 	return 0;
 }
 
+/**
+ * ice_get_ts_point - get the tx timestamp latch point
+ * @info: the driver's PTP info structure
+ * @point: return the configured tx timestamp latch point
+ *
+ * Return: 0 on success, negative on failure.
+ */
+static int
+ice_get_ts_point(struct ptp_clock_info *info, enum ptp_ts_point *point)
+{
+	struct ice_pf *pf = ptp_info_to_pf(info);
+	struct ice_hw *hw = &pf->hw;
+	int ret;
+
+	ice_ptp_lock(hw);
+	ret = ice_ptp_hw_ts_point_get(hw, point);
+	ice_ptp_unlock(hw);
+
+	return ret;
+}
+
+/**
+ * ice_set_ts_point - set the tx timestamp latch point
+ * @info: the driver's PTP info structure
+ * @point: requested tx timestamp latch point
+ *
+ * Return: 0 on success, negative on failure.
+ */
+static int
+ice_set_ts_point(struct ptp_clock_info *info, enum ptp_ts_point point)
+{
+	struct ice_pf *pf = ptp_info_to_pf(info);
+	struct ice_hw *hw = &pf->hw;
+	int ret;
+
+	ice_ptp_lock(hw);
+	ret = ice_ptp_hw_ts_point_set(hw, point);
+	ice_ptp_unlock(hw);
+
+	return ret;
+}
+
 /**
  * ice_ptp_set_funcs_e82x - Set specialized functions for E82X support
  * @pf: Board private structure
@@ -2529,6 +2571,8 @@ static void ice_ptp_set_funcs_e82x(struct ice_pf *pf)
 	if (ice_is_e825c(&pf->hw)) {
 		pf->ptp.ice_pin_desc = ice_pin_desc_e825c;
 		pf->ptp.info.n_pins = ICE_PIN_DESC_ARR_LEN(ice_pin_desc_e825c);
+		pf->ptp.info.set_ts_point = ice_set_ts_point;
+		pf->ptp.info.get_ts_point = ice_get_ts_point;
 	} else {
 		pf->ptp.ice_pin_desc = ice_pin_desc_e82x;
 		pf->ptp.info.n_pins = ICE_PIN_DESC_ARR_LEN(ice_pin_desc_e82x);
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index da88c6ccfaeb..0d2d3e36341e 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -6303,3 +6303,62 @@ int ice_cgu_get_output_pin_state_caps(struct ice_hw *hw, u8 pin_id,
 
 	return 0;
 }
+
+/**
+ * ice_ptp_hw_ts_point_get - check if tx timestamping is latched on/post SFD
+ * @hw: pointer to the HW struct
+ * @point: return the configured tx timestamp latch point
+ *
+ * Verify if HW timestamping point is configured to measure at the beginning or
+ * post of SFD (Start of Frame Delimiter)
+ *
+ * Return: 0 on success, negative on error
+ */
+int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point *point)
+{
+	u8 port = hw->port_info->lport;
+	u32 val;
+	int err;
+
+	err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
+	if (err)
+		return err;
+	if (val & PHY_MAC_XIF_TS_SFD_ENA_M)
+		*point = PTP_TS_POINT_SFD;
+	else
+		*point = PTP_TS_POINT_POST_SFD;
+
+	return err;
+}
+
+/**
+ * ice_ptp_hw_ts_point_set - configure timestamping on/post SFD
+ * @hw: pointer to the HW struct
+ * @point: requested tx timestamp latch point
+ *
+ * Configure timestamping to measure at the beginning/post SFD (Start of Frame
+ * Delimiter)
+ *
+ * Return: 0 on success, negative on error
+ */
+int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point)
+{
+	u8 port = hw->port_info->lport;
+	int err, val;
+
+	err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
+	if (err)
+		return err;
+	if ((val & PHY_MAC_XIF_TS_SFD_ENA_M && point == PTP_TS_POINT_SFD) ||
+	    (!(val & PHY_MAC_XIF_TS_SFD_ENA_M) &&
+	     point == PTP_TS_POINT_POST_SFD))
+		return -EINVAL;
+	if (point == PTP_TS_POINT_SFD)
+		val |= PHY_MAC_XIF_TS_SFD_ENA_M;
+	else if (point == PTP_TS_POINT_POST_SFD)
+		val &= ~PHY_MAC_XIF_TS_SFD_ENA_M;
+	else
+		return -EINVAL;
+
+	return ice_write_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, val);
+}
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
index 656daff3447e..f8e495b82653 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
@@ -348,6 +348,8 @@ void ice_ptp_init_hw(struct ice_hw *hw);
 int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64 *tstamp_ready);
 int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port,
 			 enum ice_ptp_tmr_cmd configured_cmd);
+int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point *point);
+int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point);
 
 /* E822 family functions */
 int ice_read_quad_reg_e82x(struct ice_hw *hw, u8 quad, u16 offset, u32 *val);
-- 
2.38.1

Re: [PATCH net-next v2 2/2] ice: ptp: add control over HW timestamp latch point

[Przemek Kitszel]

On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
> Allow user to control the latch point of ptp HW timestamps in E825

sometimes you write ptp, sometimes PTP, I would make it consistent
(but subject line is fine as is)

> devices.
> 
> Usage, examples:
> 
> ** Obtain current state:
> $ cat /sys/class/net/eth<N>/device/ptp/ts_point
> Command returns enum/integer:
> * 0 - timestamp latched by PHY at the beginning of SFD,
> * 1 - timestamp latched by PHY after the SFD,

perhaps those values could be exported to uAPI?
(the enum from the prev patch)
+enum ptp_ts_point {
+	PTP_TS_POINT_SFD,
+	PTP_TS_POINT_POST_SFD,

> * None - callback returns error to the user.
> 
> ** Configure timestamp latch point at the beginning of SFD:
> $ echo 0 > /sys/class/net/eth<N>/device/ptp/ts_point
> 
> ** Configure timestamp latch point after the SFD:
> $ echo 1 > /sys/class/net/eth<N>/device/ptp/ts_point
> 
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>

general ask: for future submissions please use --base switch of
git-send-email, this will aid resolving conflicts or applying the patch
locally for review;

this series in particular would likely conflicts with current
Tony's dev-queue (didn't checked, but Karol removes ice_is_e825c(),
called within 3-line context of your changes).

> ---
> v2:
> - add kernel doc return description on ice_get_ts_point(..),
> - use enum ptp_ts_point directly, instead of additional bool to pass tx
>    timestamp latch point from userspace callback up to ptp_hw
>    configuration,
> - fix bit logic.
> ---
>   drivers/net/ethernet/intel/ice/ice_ptp.c    | 44 +++++++++++++++
>   drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 59 +++++++++++++++++++++
>   drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
>   3 files changed, 105 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index a999fface272..21fc6b5e2d69 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -2509,6 +2509,48 @@ static int ice_ptp_parse_sdp_entries(struct ice_pf *pf, __le16 *entries,
>   	return 0;
>   }
>   
> +/**
> + * ice_get_ts_point - get the tx timestamp latch point

Tx, please apply in the whole patch

> + * @info: the driver's PTP info structure
> + * @point: return the configured tx timestamp latch point
> + *
> + * Return: 0 on success, negative on failure.
> + */
> +static int
> +ice_get_ts_point(struct ptp_clock_info *info, enum ptp_ts_point *point)

nit: the current preferred style is to break line after "info,"

> +{
> +	struct ice_pf *pf = ptp_info_to_pf(info);
> +	struct ice_hw *hw = &pf->hw;
> +	int ret;
> +
> +	ice_ptp_lock(hw);
> +	ret = ice_ptp_hw_ts_point_get(hw, point);
> +	ice_ptp_unlock(hw);
> +
> +	return ret;
> +}

[...]

> +/**
> + * ice_ptp_hw_ts_point_set - configure timestamping on/post SFD
> + * @hw: pointer to the HW struct
> + * @point: requested tx timestamp latch point
> + *
> + * Configure timestamping to measure at the beginning/post SFD (Start of Frame
> + * Delimiter)
> + *
> + * Return: 0 on success, negative on error
> + */
> +int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point)
> +{
> +	u8 port = hw->port_info->lport;
> +	int err, val;
> +
> +	err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
> +	if (err)
> +		return err;
> +	if ((val & PHY_MAC_XIF_TS_SFD_ENA_M && point == PTP_TS_POINT_SFD) ||
> +	    (!(val & PHY_MAC_XIF_TS_SFD_ENA_M) &&
> +	     point == PTP_TS_POINT_POST_SFD))

that's the thing that urged me to start commenting on this patch ;)

put braces around (bit & arith) combined with logical && or ||

you could also split into multiple if branches for readability

> +		return -EINVAL;
> +	if (point == PTP_TS_POINT_SFD)
> +		val |= PHY_MAC_XIF_TS_SFD_ENA_M;
> +	else if (point == PTP_TS_POINT_POST_SFD)
> +		val &= ~PHY_MAC_XIF_TS_SFD_ENA_M;
> +	else
> +		return -EINVAL;
> +
> +	return ice_write_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, val);
> +}
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
> index 656daff3447e..f8e495b82653 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
> @@ -348,6 +348,8 @@ void ice_ptp_init_hw(struct ice_hw *hw);
>   int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64 *tstamp_ready);
>   int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port,
>   			 enum ice_ptp_tmr_cmd configured_cmd);
> +int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point *point);
> +int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point);
>   
>   /* E822 family functions */
>   int ice_read_quad_reg_e82x(struct ice_hw *hw, u8 quad, u16 offset, u32 *val);

RE: [PATCH net-next v2 2/2] ice: ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
>Sent: Tuesday, October 29, 2024 9:22 AM
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Allow user to control the latch point of ptp HW timestamps in E825
>
>sometimes you write ptp, sometimes PTP, I would make it consistent
>(but subject line is fine as is)
>
>> devices.
>>
>> Usage, examples:
>>
>> ** Obtain current state:
>> $ cat /sys/class/net/eth<N>/device/ptp/ts_point
>> Command returns enum/integer:
>> * 0 - timestamp latched by PHY at the beginning of SFD,
>> * 1 - timestamp latched by PHY after the SFD,
>
>perhaps those values could be exported to uAPI?
>(the enum from the prev patch)
>+enum ptp_ts_point {
>+	PTP_TS_POINT_SFD,
>+	PTP_TS_POINT_POST_SFD,
>
>> * None - callback returns error to the user.
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 0 > /sys/class/net/eth<N>/device/ptp/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 1 > /sys/class/net/eth<N>/device/ptp/ts_point
>>
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>
>general ask: for future submissions please use --base switch of
>git-send-email, this will aid resolving conflicts or applying the patch
>locally for review;
>
>this series in particular would likely conflicts with current
>Tony's dev-queue (didn't checked, but Karol removes ice_is_e825c(),
>called within 3-line context of your changes).
>
>> ---
>> v2:
>> - add kernel doc return description on ice_get_ts_point(..),
>> - use enum ptp_ts_point directly, instead of additional bool to pass tx
>>    timestamp latch point from userspace callback up to ptp_hw
>>    configuration,
>> - fix bit logic.
>> ---
>>   drivers/net/ethernet/intel/ice/ice_ptp.c    | 44 +++++++++++++++
>>   drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 59 +++++++++++++++++++++
>>   drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
>>   3 files changed, 105 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c
>b/drivers/net/ethernet/intel/ice/ice_ptp.c
>> index a999fface272..21fc6b5e2d69 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
>> @@ -2509,6 +2509,48 @@ static int ice_ptp_parse_sdp_entries(struct ice_pf
>>*pf, __le16 *entries,
>>   	return 0;
>>   }
>>
>> +/**
>> + * ice_get_ts_point - get the tx timestamp latch point
>
>Tx, please apply in the whole patch
>
>> + * @info: the driver's PTP info structure
>> + * @point: return the configured tx timestamp latch point
>> + *
>> + * Return: 0 on success, negative on failure.
>> + */
>> +static int
>> +ice_get_ts_point(struct ptp_clock_info *info, enum ptp_ts_point *point)
>
>nit: the current preferred style is to break line after "info,"
>
>> +{
>> +	struct ice_pf *pf = ptp_info_to_pf(info);
>> +	struct ice_hw *hw = &pf->hw;
>> +	int ret;
>> +
>> +	ice_ptp_lock(hw);
>> +	ret = ice_ptp_hw_ts_point_get(hw, point);
>> +	ice_ptp_unlock(hw);
>> +
>> +	return ret;
>> +}
>
>[...]
>
>> +/**
>> + * ice_ptp_hw_ts_point_set - configure timestamping on/post SFD
>> + * @hw: pointer to the HW struct
>> + * @point: requested tx timestamp latch point
>> + *
>> + * Configure timestamping to measure at the beginning/post SFD (Start of
>> Frame
>> + * Delimiter)
>> + *
>> + * Return: 0 on success, negative on error
>> + */
>> +int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point)
>> +{
>> +	u8 port = hw->port_info->lport;
>> +	int err, val;
>> +
>> +	err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
>> +	if (err)
>> +		return err;
>> +	if ((val & PHY_MAC_XIF_TS_SFD_ENA_M && point == PTP_TS_POINT_SFD) ||
>> +	    (!(val & PHY_MAC_XIF_TS_SFD_ENA_M) &&
>> +	     point == PTP_TS_POINT_POST_SFD))
>
>that's the thing that urged me to start commenting on this patch ;)
>
>put braces around (bit & arith) combined with logical && or ||
>
>you could also split into multiple if branches for readability
>
>> +		return -EINVAL;
>> +	if (point == PTP_TS_POINT_SFD)
>> +		val |= PHY_MAC_XIF_TS_SFD_ENA_M;
>> +	else if (point == PTP_TS_POINT_POST_SFD)
>> +		val &= ~PHY_MAC_XIF_TS_SFD_ENA_M;
>> +	else
>> +		return -EINVAL;
>> +
>> +	return ice_write_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, val);
>> +}
>> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>>b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> index 656daff3447e..f8e495b82653 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> @@ -348,6 +348,8 @@ void ice_ptp_init_hw(struct ice_hw *hw);
>>   int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64
>>*tstamp_ready);
>>   int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port,
>>   			 enum ice_ptp_tmr_cmd configured_cmd);
>> +int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point
>>*point);
>> +int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point);
>>
>>   /* E822 family functions */
>>   int ice_read_quad_reg_e82x(struct ice_hw *hw, u8 quad, u16 offset, u32
>>*val);

Fixed all in v3.

Thank you!
Arkadiusz

Re: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Vadim Fedorenko]

On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
> HW support of PTP/timesync solutions in network PHY chips can be
> achieved with two different approaches, the timestamp maybe latched
> either in the beginning or after the Start of Frame Delimiter (SFD) [1].
> 
> Allow ptp device drivers to provide user with control over the timestamp
> latch point.
> 
> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf

I just wonder should we add ethtool interface to control this feature.
As we are adding it for phy devices, it's good idea to have a way to
control it through eth device too. WDYT?

RE: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>Sent: Tuesday, October 29, 2024 12:30 PM
>
>On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>> HW support of PTP/timesync solutions in network PHY chips can be
>> achieved with two different approaches, the timestamp maybe latched
>> either in the beginning or after the Start of Frame Delimiter (SFD) [1].
>>
>> Allow ptp device drivers to provide user with control over the timestamp
>> latch point.
>>
>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>
>I just wonder should we add ethtool interface to control this feature.
>As we are adding it for phy devices, it's good idea to have a way to
>control it through eth device too. WDYT?

Seems doable, I guess somehow expand the controllability being added right
now with this series:
https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed948f3b6887@bootlin.com/#r
Or some other idea?

Re: [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Vadim Fedorenko]

On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>> From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>> Sent: Tuesday, October 29, 2024 12:30 PM
>>
>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>>> HW support of PTP/timesync solutions in network PHY chips can be
>>> achieved with two different approaches, the timestamp maybe latched
>>> either in the beginning or after the Start of Frame Delimiter (SFD) [1].
>>>
>>> Allow ptp device drivers to provide user with control over the timestamp
>>> latch point.
>>>
>>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>
>> I just wonder should we add ethtool interface to control this feature.
>> As we are adding it for phy devices, it's good idea to have a way to
>> control it through eth device too. WDYT?
> 
> Seems doable, I guess somehow expand the controllability being added right
> now with this series:
> https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed948f3b6887@bootlin.com/#r
> Or some other idea?

Yeah, the series mentioned correlates with your work, that's why I asked 
about it.
It would be great to be sure that the interface you are proposing can be
reused or somehow combined with the series.

RE: [Intel-wired-lan] [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
>Vadim Fedorenko
>Sent: Tuesday, October 29, 2024 5:17 PM
>
>On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>>> From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>>> Sent: Tuesday, October 29, 2024 12:30 PM
>>>
>>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
>>>> HW support of PTP/timesync solutions in network PHY chips can be
>>>> achieved with two different approaches, the timestamp maybe latched
>>>> either in the beginning or after the Start of Frame Delimiter (SFD)
>>>>[1].
>>>>
>>>> Allow ptp device drivers to provide user with control over the
>>>> timestamp latch point.
>>>>
>>>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>>
>>> I just wonder should we add ethtool interface to control this feature.
>>> As we are adding it for phy devices, it's good idea to have a way to
>>> control it through eth device too. WDYT?
>>
>> Seems doable, I guess somehow expand the controllability being added
>> right now with this series:
>> https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed94
>> 8f3b6887@bootlin.com/#r
>> Or some other idea?
>
>Yeah, the series mentioned correlates with your work, that's why I asked
>about it.
>It would be great to be sure that the interface you are proposing can be
>reused or somehow combined with the series.

Sure, I did some modifications to allow this extension in the future, as
this is still being developed.

Thank you!
Arkadiusz