From patchwork Thu Jan 4 21:24:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= X-Patchwork-Id: 13511557 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FC5F2C6A1 for ; Thu, 4 Jan 2024 21:24:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--maheshb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Hqoqay1H" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-5e744f7ca3bso15205197b3.2 for ; Thu, 04 Jan 2024 13:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704403476; x=1705008276; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=onZJJ0p7bA1O18bnzOb7QEzuO2YArUzN5u9fFaWOrIg=; b=Hqoqay1HIT5WOZo2whBFWAyj2Pa3m+0EoqzKCYRx+f21h/P7/EQux97ivA27UeIhWi 0rLU0hmxxCgNffAD7MAj+K3/xmjD4o7ibCn+Dr/eK3FUjxaooojhH/WdBHPzJks0sPu1 7QSSc6or9JXBat2wsk8p+2tOyE+8ux1rp4t27D/SUygwYHo3H2uj83XGp+2ozGij1ZBJ qPTMl64EhXDErdRBdRAD/zf0jUHzZ5T+4/OKPcmSDmhXPmwdc1mQcuO226q61S7Tx6lh lENTohR4ZmDJrUANSyEFYkVnI55/BwJB3nhTAU0po9h1myX0VpCJS/LURoKRzxhzJ5DD qQLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704403476; x=1705008276; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=onZJJ0p7bA1O18bnzOb7QEzuO2YArUzN5u9fFaWOrIg=; b=C2C5rreOaxaNtMk458uO3wVRMJxKLhv8OK30I7gDWmBgCUI9804ztjBcpMfXuw2leJ uXRGWkeIPKpHr8J+peySbkAJhC+edRvndy9Rv3tWe6/9wZGZloN7AzfzK06K2GOZOAdx uFtlVFu1EHmIlvRr5hzPSRQNXypel+qwV1eOHkXcXvsEIpIx7CzhxbDNsNVKWz8DCTBK Omarkhs4ooZ6mW5TFvPtWMXpObSgSi9MOCY7fw3tlTQOfTbJLY8+KSyHiJl6YyUGDQ8x hNT5itUSaxojPmsQhVnuaL5DWYW1dDOOstC1zWd20tIbq6WlaWNGB5NWWYQ8r/5jHy2/ kgMQ== X-Gm-Message-State: AOJu0YxKRvP00RzaJdoZ9hA9llG7MM4iweo7B2OApUWr/ddqTJw0A52/ DDHBO8gJu7TO/HeVEuB2AAMAAqBuMmeh7HimtNCAACAa67g0nN4hPniy04Q/k0sa3v56Je2MokA r2HxD6TpfczdRsm+tqaP5/YGFVEpBvY50k6gm4dZkKdKwcJLD7YSBrZgAzeCNp46WpM2lJJ0= X-Google-Smtp-Source: AGHT+IESqMAgsrfrSy70rvzKsqlSxftHc2rbuuCAnnkSXGk0yOPCxr6StcAQ6Ugfo71RUtIAFPEgeAFMdEJM X-Received: from coldfire.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:2b7a]) (user=maheshb job=sendgmr) by 2002:a05:690c:3692:b0:5e7:1536:f4b3 with SMTP id fu18-20020a05690c369200b005e71536f4b3mr484304ywb.9.1704403475921; Thu, 04 Jan 2024 13:24:35 -0800 (PST) Date: Thu, 4 Jan 2024 13:24:31 -0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.43.0.195.gebba966016-goog Message-ID: <20240104212431.3275688-1-maheshb@google.com> Subject: [PATCHv3 net-next 0/3] add ptp_gettimex64any() API From: Mahesh Bandewar To: Netdev , Linux , David Miller , Jakub Kicinski , Eric Dumazet , Paolo Abeni Cc: Jonathan Corbet , John Stultz , Don Hatchett , Yuliang Li , Mahesh Bandewar , Mahesh Bandewar , Richard Cochran , Willem de Bruijn X-Patchwork-Delegate: kuba@kernel.org 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 CC: Richard Cochran CC: "David S. Miller" CC: John Stultz CC: Jakub Kicinski CC: "Willem de Bruijn" CC: netdev@vger.kernel.org