From nobody Mon Nov 25 10:36:16 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94DDF1DFDB1; Mon, 28 Oct 2024 20:52:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730148771; cv=none; b=TLi3RzCizK9veq8f5WlMtZReAPFXKwjbcgtmPA8HWoikEym76ro2tM4Tz6StlZWEGdP5ocjO9Ym4RqyVAN+R3hWuChbYPzR+koevo4J6+Km3AkZWeolH3gRbOLS8q2F/n8Xc1kM7E9sUbRCAsGH91RkXsqdgJ8z9m8PxtkbsEnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730148771; c=relaxed/simple; bh=ACTtGG9ESVEf5pMl5YWggma0jKgPuXn6xPZk7LoMq2s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=cPqRSGqJ2mLS/Kgp74Yh24cU900mzQbgJAL8sFyKSxw3CWeTI8AW65kB9SfJKfGKTg7A3o4OYmbtbxMVPsf9aqZCN0TV6OshhYyxrFqPQMTF14fh0KKPgMOnfVZG24XxHex4MP7Cu1yH+KN9o86nnd1/8GIbqxeInfPLf/AfHs8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Vh5Dzu6B; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Vh5Dzu6B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730148769; x=1761684769; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ACTtGG9ESVEf5pMl5YWggma0jKgPuXn6xPZk7LoMq2s=; b=Vh5Dzu6Bd3X7bb/iYO/CXuKuMEVovR7bB7XxsQ7bFHtnS+Tbo3MJcJAN Og+rWIwQWXey+hxc7w5m8voKVC4tBAysb5wVfwaUoPu/6Y1Zizls4sIi8 5+HPshhFulPh9iei4GSOtRNUywUZ1DKyAdiW1uIl6Gu6iv16mTHFwgTZF 1q1GicYhMbd1YGFcWE1RZE6XQ4RmziyO2S40OuVi7k9dze6VxxI6NoQ7g +b1p0YRoJZ7fI2NdJVZnLYEr6SwfMVsBMK+PIGK6OPDDoxZzmFteJ3x56 2At9ZOEBgnCNoHaRdCwgvl0tJoIp6dR22A2E5GkcuKWbT2rqX7KViIS+h A==; X-CSE-ConnectionGUID: tJBTipZ2SMC7llv1o1LcnQ== X-CSE-MsgGUID: PwOUIIQmTtqrbDIim3rOOg== X-IronPort-AV: E=McAfee;i="6700,10204,11239"; a="40343542" X-IronPort-AV: E=Sophos;i="6.11,240,1725346800"; d="scan'208";a="40343542" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2024 13:52:48 -0700 X-CSE-ConnectionGUID: 4nJnpUkTQkiP8BN042VRig== X-CSE-MsgGUID: j7yCPt7jRdKnKWNoq5OjJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,240,1725346800"; d="scan'208";a="81358558" Received: from amlin-018-114.igk.intel.com ([10.102.18.114]) by fmviesa007.fm.intel.com with ESMTP; 28 Oct 2024 13:52:45 -0700 From: Arkadiusz Kubalewski To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org Cc: anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, richardcochran@gmail.com, Arkadiusz Kubalewski , Aleksandr Loktionov Subject: [PATCH net-next v2 1/2] ptp: add control over HW timestamp latch point Date: Mon, 28 Oct 2024 21:47:54 +0100 Message-Id: <20241028204755.1514189-2-arkadiusz.kubalewski@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20241028204755.1514189-1-arkadiusz.kubalewski@intel.com> References: <20241028204755.1514189-1-arkadiusz.kubalewski@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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/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/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/ts_point ** Configure timestamp latch point after the SFD: $ echo 1 > /sys/class/ptp/ptp/ts_point [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf Reviewed-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski --- 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/testin= g/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/ts_point +Date: October 2024 +Contact: Arkadiusz Kubalewski +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); =20 +static ssize_t ts_point_show(struct device *dev, struct device_attribute *= attr, + char *page) +{ + struct ptp_clock *ptp =3D dev_get_drvdata(dev); + enum ptp_ts_point point; + int err; + + if (!ptp->info->get_ts_point) + return -EOPNOTSUPP; + err =3D 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 =3D 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 =3D val; + + err =3D 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[] =3D { &dev_attr_pps_enable.attr, &dev_attr_n_vclocks.attr, &dev_attr_max_vclocks.attr, + &dev_attr_ts_point.attr, NULL }; =20 @@ -363,6 +404,9 @@ static umode_t ptp_is_attribute_visible(struct kobject = *kobj, } else if (attr =3D=3D &dev_attr_max_phase_adjustment.attr) { if (!info->adjphase || !info->getmaxphase) mode =3D 0; + } else if (attr =3D=3D &dev_attr_ts_point.attr) { + if (!info->get_ts_point && !info->set_ts_point) + mode =3D 0; } =20 return mode; diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_ker= nel.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; }; =20 +/** + * 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 (>=3D0) 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 st= art + * frame delimiter (SFD), as described in IEEE 802.3cx + * specification. + * + * @get_ts_point: Obtain the timestamp measurement latch point, counterpar= t 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); }; =20 struct ptp_clock; --=20 2.38.1