From: Vadim Fedorenko vadim.fedorenko@linux.dev
[ Upstream commit d3ca2ef0c915d219e0d958e0bdcc4be6c02c210b ]
Originally ptp_ocp driver was not strictly checking flags for external timestamper and was always activating rising edge timestamping as it's the only supported mode. Recent changes to ptp made it incompatible with PTP_EXTTS_REQUEST2 ioctl. Adjust ptp_clock_info to provide supported mode and be compatible with new infra.
While at here remove explicit check of periodic output flags from the driver and provide supported flags for ptp core to check.
Signed-off-by: Vadim Fedorenko vadim.fedorenko@linux.dev Link: https://patch.msgid.link/20250918131146.651468-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - `drivers/ptp/ptp_ocp.c:1488` now sets `.supported_extts_flags = PTP_STRICT_FLAGS | PTP_RISING_EDGE`, which lets the core treat the driver as “strict”. Without this, PTP_EXTTS_REQUEST2 always injects the `PTP_STRICT_FLAGS` bit, so the core rejects every extts enable with `-EOPNOTSUPP` (see the check in `drivers/ptp/ptp_chardev.c:230-241`). That regression breaks external timestamping as soon as user space starts using the new ioctl. - The same block advertises `.supported_perout_flags = PTP_PEROUT_DUTY_CYCLE | PTP_PEROUT_PHASE` (`drivers/ptp/ptp_ocp.c:1489`). When the v2 per-out ioctl validates flags against this mask (`drivers/ptp/ptp_chardev.c:247-304`), the old behavior of honoring duty-cycle and phase requests is preserved; without it every flagged request is refused. - The redundant in-driver mask test just above `ptp_ocp_signal_from_perout()` was dropped (`drivers/ptp/ptp_ocp.c:2095-2120`), because the core now rejects unsupported bits before the driver runs. Functionality stays the same, but it avoids double-checks and is required so valid requests survive the new core gatekeepers. - The patch is small, self-contained to the PTP OCP driver, and only supplies capability metadata to match behavior the hardware already implements (rising-edge extts, duty-cycle/phase per-out). No timing logic or register programming changed, so regression risk is very low. - Failing to pick this up leaves the device unusable with the new ioctls introduced this cycle, which is a clear user-visible regression.
drivers/ptp/ptp_ocp.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c index 4e1286ce05c9a..794ec6e71990c 100644 --- a/drivers/ptp/ptp_ocp.c +++ b/drivers/ptp/ptp_ocp.c @@ -1485,6 +1485,8 @@ static const struct ptp_clock_info ptp_ocp_clock_info = { .pps = true, .n_ext_ts = 6, .n_per_out = 5, + .supported_extts_flags = PTP_STRICT_FLAGS | PTP_RISING_EDGE, + .supported_perout_flags = PTP_PEROUT_DUTY_CYCLE | PTP_PEROUT_PHASE, };
static void @@ -2095,10 +2097,6 @@ ptp_ocp_signal_from_perout(struct ptp_ocp *bp, int gen, { struct ptp_ocp_signal s = { };
- if (req->flags & ~(PTP_PEROUT_DUTY_CYCLE | - PTP_PEROUT_PHASE)) - return -EOPNOTSUPP; - s.polarity = bp->signal[gen].polarity; s.period = ktime_set(req->period.sec, req->period.nsec); if (!s.period)