diff options
author | Jakub Kicinski <kuba@kernel.org> | 2025-06-17 16:13:12 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2025-06-17 16:13:13 -0700 |
commit | 4300fd62daf219e712687fff82098490517d6b20 (patch) | |
tree | a3e0d61c93fd63902093444328f022ee387f2746 /net/lapb/lapb_timer.c | |
parent | 13c90202ddbb5f6e8457dadc797ca88b2d1b0742 (diff) | |
parent | aa112cbc5f0ac6f3b44d829005bf34005d9fe9bb (diff) |
Merge branch 'ptp_vclock-fixes'
Vladimir Oltean says:
====================
ptp_vclock fixes
While I was intending to test something else related to PTP in net-next
I noticed any time I would run ptp4l on an interface, the kernel would
print "ptp: physical clock is free running" and ptp4l would exit with an
error code.
I then found Jeongjun Park's patch and subsequent explanation provided
to Jakub's question, specifically related to the code which introduced
the breakage I am seeing.
https://lore.kernel.org/netdev/CAO9qdTEjQ5414un7Yw604paECF=6etVKSDSnYmZzZ6Pg3LurXw@mail.gmail.com/
I had to look at the original issue that prompted Jeongjun Park's patch,
and provide an alternative fix for it. Patch 1/2 in this set contains a
logical revert plus the alternative fix, squashed into one.
Patch 2/2 fixes another issue which was confusing during debugging/
characterization, namely: "ok, the kernel clearly thinks that any
physical clock is free-running after this change (despite there being no
vclocks), but why would ptp4l fail to create the clock altogether? Why
not just fail to adjust it?"
By reverting (locally) Jeongjun Park's commit, I could reproduce
the reported lockdep splat using the commands from patch 1/2's commit
message, and this goes away with the reworked implementation.
====================
Link: https://patch.msgid.link/20250613174749.406826-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/lapb/lapb_timer.c')
0 files changed, 0 insertions, 0 deletions