]> www.infradead.org Git - users/jedix/linux-maple.git/commit
Merge branch 'ptp_vclock-fixes'
authorJakub Kicinski <kuba@kernel.org>
Tue, 17 Jun 2025 23:13:12 +0000 (16:13 -0700)
committerJakub Kicinski <kuba@kernel.org>
Tue, 17 Jun 2025 23:13:13 +0000 (16:13 -0700)
commit4300fd62daf219e712687fff82098490517d6b20
treea3e0d61c93fd63902093444328f022ee387f2746
parent13c90202ddbb5f6e8457dadc797ca88b2d1b0742
parentaa112cbc5f0ac6f3b44d829005bf34005d9fe9bb
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>