From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 59C251C860A for ; Sat, 27 Jun 2026 20:54:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782593671; cv=none; b=GOM962jJMsDwwakbLlPNrl3J5K5FigPJrAURdggTLqnzLkjsx7tnLi4lXH79/mDDEGN8DJ9OrjYANJjx/Q81CVXuOX8lDokbO+bl1YphuQHZq3IDia+yr0VGqI0ED9KEQ6MM48a8hxg8n1viSENdCmBBPfYyq9E0Kb0rMY2V/wo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782593671; c=relaxed/simple; bh=EgL22hUUOTGuwWwz52cS80vjpLz7/YJzdAXrpVqToyg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dkw4KN9SKnbGLrBjmn15gsPhedvaBNEPoAms16io6nFEd2tHLR+f4q7V8QZsWR4X/4X7bOSfl6VbFm8S2CapjHHMualigGhjAJEiS5/nXGu7FdDua5yMHQkms64YgCO9v3Zp2u89wgbkvd6HyLN8bLSmmZQowLmGYyCVPaU78KE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=j5mMzkgW; arc=none smtp.client-ip=74.125.82.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="j5mMzkgW" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-30b6dad2382so4171285eec.0 for ; Sat, 27 Jun 2026 13:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782593669; x=1783198469; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=zw544QpkI2c02+lueS+0hTZun4LgVS1tEYDViWrAgVw=; b=j5mMzkgWLVFgwnJ0kBNVcU2QRlLkKQPluI9FT3q2zQAniUB7XjRHij0r2iIIYydk8o XjLgUpKb2G4OqLJ5P8YOhPFzTdo4+06I3jq1mXw3zwUae36n3o55njww6FULyqMF+hvC yg3ww0xUP6/25Wm3jZhm3hDztkSDNRhykru6EpKc2Rx/TCp3n0z3M4dbG19tytXTSiC/ JmdeUsgzSuYVGyHTJiTZzHwQqxWn628C80K8Rk0udvRGByFYNGdxGa0t1x3Xtsb3RqAm nHboQPn5q8n4gzeByovkqtgCbr4KNoA8t6CLM/Wp/co4kmKDsQFfB8UULFj4ZzhoradO EHBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782593669; x=1783198469; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zw544QpkI2c02+lueS+0hTZun4LgVS1tEYDViWrAgVw=; b=Jx6MgGHer8e+Agyo39Th2MvqPkPB3r7Cs9Ea/8zJus7qsjX/UgpCj7pwBvQcFykMel JVGuVou+mUXusXyS2iuah1kjhtv9gRzN5pNPJ2+GjzkwQWQGjjYGXmEgY6dbIsncB3Iw o1m2AupR+P8phLf/XSH1rU2TiONHmmK3dWtgNvxfqtnSexcdRfGp4wXjPkUxNi4Yhf7B s2Fru79p9T8lAy42VNJ0NG6sl7BzL7fHmudqfSZTVA8H0vORsPZJmSAO14ToVxw+eTM5 FF1cLyOPIgIgt32g8pVgQ4fqYwOXYa7bcLtWO6Z/EoT1G8r2N8L/0gsiInJ0KDMQnP7N KTvg== X-Forwarded-Encrypted: i=1; AHgh+RqhbYmLyjCIoiwz2Bl0MHm4/0c/XoSNIQntT6ReMNhjIwPaJnnbPk1Sie3wQfd55EJ+48SzWtRK4DSKofo=@vger.kernel.org X-Gm-Message-State: AOJu0YwYpBcY6ZjfCJ8dC/qGO968XL1fOh0T5iJA/LqXIPxQ/ZfrXfDO 2SaRxwZM+gip8+t9PREXmtM06y/oVCbiSkPr1q0ALbvIsPisfLYBRGTf+U/IsSptKyI= X-Gm-Gg: AfdE7cnW8NicSJ7Mo85wsoq64Z4mOYQldw1fe9PG6YzodeIM7/2Z+/ybK8ywAFHBAQh pI21KmpNFhllD9F/5DKeSdrRfKPjSnmhwHcFmppFXQKovwKBc2JH0JDtQvGjz1f7FHEMUNSuHps 2SrVbSicze0PrE9T25p1RSKlV1tUsmUO0I4RBDtKifoSHYDuOaYwbY77j42Zzl7gLDp9SvUaqE0 K5UNFfyYFTdj6b2ezZd5N96ta4Qcp0LiK6iVpYXYA03WZ28V5qwTUAYPKxFLOi8Fgpleicp0N7d m/bfbE7z5WI9Ox1U5ZcXCq9Az5UBnhYKcvC29uhYTKZNJhITH3U72Kk4cgULEma5i38yw3mECCt Pg0RtCszTwYBchZoTgxKA3DtNKB6HdiNMdyhUh+ZQFivI7KwGi4ve0u6+1OowDSwskBU0L3Q3xW s= X-Received: by 2002:a05:7300:e801:b0:304:2e00:5fb5 with SMTP id 5a478bee46e88-30c84b2cb38mr9517376eec.3.1782593669179; Sat, 27 Jun 2026 13:54:29 -0700 (PDT) Received: from gerik-arch.lan ([2603:8000:d300:219e::c6c]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30c7c52c591sm41400336eec.7.2026.06.27.13.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jun 2026 13:54:28 -0700 (PDT) From: Gerik Kubiak To: giometti@enneenne.com Cc: richardcochran@gmail.com, linux-kernel@vger.kernel.org, Gerik Kubiak Subject: [RFC PATCH 0/3] PPS Set event clock source Date: Sat, 27 Jun 2026 13:50:25 -0700 Message-ID: <20260627205028.105252-1-gerikkub@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello all, This patch series adds support for userspace to specify the clock source used to collect pps events. The current behavior timestamps events in the REALTIME clock and this series adds support for the BOOTTIME and MONOTONIC_RAW clocks via a new ioctl on a pps fd. This is a minimal proof of concept RFC to understand if there is interest in this feature and if the current approach to the userspace API is appropriate. My usecase is using the pps subsystem to synchronize sensor data to an external clock. The sensor data is timestamped by the BOOTTIME clock in the kernel and I would like to use the pps subsystem to correlate these timestamps to an external clock via a pps-gpio device. sensor data, which is timestamped in the BOOTTIME clock to the external The pps subsystem would work well for this if it could return timestamps in the BOOTTIME clock. Otherwise I would need to correlate the clocks in userspace, which is non-trivial and may be constantly changing. This series adds support for this behavior across three patches. 1. Create a new userspace API for setting the requested clock using an ioctl 2. Update the pps_get_ts function to capture the event in the clocks of interest 3. Update the pps subsystem to track the requested clock and return the stored timestamp corresponding the requested clock I have a few outstanding issues with this series that need clarifications before merging 1. The current implementation collects timestamps for all relevant clocks in pps_get_ts. This seems like overkill, but it prevents issues when the clock source changes. A slimmer implementation would collect timestamps with the selected clock and drop events if userspace changes the clock source after an event has been collected. 2. This implements pps sources for REALTIME, MONOTONIC_RAW and BOOTTIME clocks. This was done to keep the single call to ktime_get_snapshot. It would make sense for this API to support MONOTONIC as well, but I believe that will require changes to ktime_get_snapshot to include the MONOTONIC clock in the system_time_snapshot struct. 3. I created a new ioctl on the pps fd to prevent changing the existing pps API calls. Is this the preferred way to implement this new behavior? It seems cleaner to add an additional flag and field to the existing pps_kparams struct, but it wasn't clear to me if this could be done without breaking the existing userspace contract. Thank you, Gerik Gerik Kubiak (3): pps: Add PPS_SETCLOCK ioctl pps: Capture PPS timestamps in multiple clocks pps: Timestamp pps events per PPS_SETCLOCK clock drivers/pps/kapi.c | 27 ++++++++++++++++++++------- drivers/pps/pps.c | 22 ++++++++++++++++++++++ include/linux/pps_kernel.h | 10 ++++------ include/uapi/linux/pps.h | 6 ++++++ 4 files changed, 52 insertions(+), 13 deletions(-) -- 2.54.0