]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ptp: allow reading of currently dialed frequency to succeed on free-running clocks
authorVladimir Oltean <vladimir.oltean@nxp.com>
Fri, 13 Jun 2025 17:47:49 +0000 (20:47 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 27 Jun 2025 10:07:39 +0000 (11:07 +0100)
commit8e1525098c8abaae791f29987dd760b09d62fdca
tree21a0ac33058356c7f5976d958633910177e7f9a4
parent6488c58462c5a89b5979ae0763dfa193dd7e7214
ptp: allow reading of currently dialed frequency to succeed on free-running clocks

[ Upstream commit aa112cbc5f0ac6f3b44d829005bf34005d9fe9bb ]

There is a bug in ptp_clock_adjtime() which makes it refuse the
operation even if we just want to read the current clock dialed
frequency, not modify anything (tx->modes == 0). That should be possible
even if the clock is free-running. For context, the kernel UAPI is the
same for getting and setting the frequency of a POSIX clock.

For example, ptp4l errors out at clock_create() -> clockadj_get_freq()
-> clock_adjtime() time, when it should logically only have failed on
actual adjustments to the clock, aka if the clock was configured as
slave. But in master mode it should work.

This was discovered when examining the issue described in the previous
commit, where ptp_clock_freerun() returned true despite n_vclocks being
zero.

Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20250613174749.406826-3-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/ptp/ptp_clock.c