summaryrefslogtreecommitdiff
path: root/net/lapb/lapb_timer.c
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2025-06-17 16:13:12 -0700
committerJakub Kicinski <kuba@kernel.org>2025-06-17 16:13:13 -0700
commit4300fd62daf219e712687fff82098490517d6b20 (patch)
treea3e0d61c93fd63902093444328f022ee387f2746 /net/lapb/lapb_timer.c
parent13c90202ddbb5f6e8457dadc797ca88b2d1b0742 (diff)
parentaa112cbc5f0ac6f3b44d829005bf34005d9fe9bb (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