Received-SPF: pass (google.com: domain of linux-kernel+bounces-17234-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu,  4 Jan 2024 13:24:31 -0800
Precedence: bulk
Mime-Version: 1.0
Message-ID: <20240104212431.3275688-1-maheshb@google.com>
Subject: [PATCHv3 net-next 0/3] add ptp_gettimex64any() API
From: Mahesh Bandewar <maheshb@google.com>
To: Netdev <netdev@vger.kernel.org>, Linux <linux-kernel@vger.kernel.org>, 
	David Miller <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, 
	Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>, John Stultz <jstultz@google.com>, Don Hatchett <hatch@google.com>, 
	Yuliang Li <yuliangli@google.com>, Mahesh Bandewar <mahesh@bandewar.net>, 
	Mahesh Bandewar <maheshb@google.com>, Richard Cochran <richardcochran@gmail.com>, 
	Willem de Bruijn <willemb@google.com>
Content-Type: text/plain; charset="UTF-8"

Applications that are very sensitive to time precision
always measure the latency of the PHC (hardware clock) read.
The best suited API for this is getcrosststamp(), however,
not all platforms can architecturally support it, hence
sandwich-ts APIs become more important for these categories
of applications.  The purpose of the sandwich API is to
measure the width of the PHC-read syscall. The current API
that reads PHC supports only one timebase for it (CLOCK_REALTIME).
CLOCK_REALTIME is disciplined by NTP or NTP-like service,
and hence the value is subject to change. This makes some
applications want the sandwich TS to be delivered in other
timebases.

Ideally, there should be only one API that delivers the
PHC-read with the sandwich-TS of the timebase given by the
user, but modifying the existing API (gettimex64) would
break compatibility.

This series implements an API similar to gettimex64() with
a parameter that allows the user to choose the timebase
needed for these sandwich timestamps.

About the name: This is a superset of the current gettimex64().
Since the timebase for gettimex64 is fixed and is only
sys-time (CLOCK_REALTIME), I'm appending 'any' to add the
choice factor. So gettimex64any() would give you eXtended
time with sandwich TS of a timebase of your choice. If there
is a better name, I won't mind changing.

The timebase options are:
   CLOCK_REALTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_RAW

The CLOCK_REALTIME option is equivalent to using the current
gettimex64() method.

The first patch adds this new PTP method, while the second
patch adds the ioctl support for this PTP method. The last
patch in the series updates the selftest to exercise this
new API.

Mahesh Bandewar (3):
  ptp: add new method ptp_gettimex64any()
  ptp: add ioctl interface for ptp_gettimex64any()
  selftest/ptp: extend test to include ptp_gettimex64any()

 drivers/ptp/ptp_chardev.c             | 37 +++++++++++
 include/linux/ptp_clock_kernel.h      | 50 +++++++++++++-
 include/uapi/linux/ptp_clock.h        | 14 ++++
 tools/testing/selftests/ptp/testptp.c | 96 ++++++++++++++++++++++++++-
 4 files changed, 193 insertions(+), 4 deletions(-)

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
CC: Richard Cochran <richardcochran@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: John Stultz <jstultz@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: "Willem de Bruijn" <willemb@google.com>
CC: netdev@vger.kernel.org
-- 
2.43.0.195.gebba966016-goog