drivers: ethernet: nxp_enet_qos: arm RX timestamping after MAC start - #117411
Open
bperseghetti wants to merge 1 commit into
Open
drivers: ethernet: nxp_enet_qos: arm RX timestamping after MAC start#117411bperseghetti wants to merge 1 commit into
bperseghetti wants to merge 1 commit into
Conversation
The receive timestamp snapshot logic on this MAC only arms when MAC_TIMESTAMP_CONTROL is written while the receiver is enabled. The PTP clock driver programs that register from its own init routine, and PTP_CLOCK_INIT_PRIORITY defaults to ETH_INIT_PRIORITY, so the PTP clock device can initialize before the MAC driver enables the receiver. When that ordering occurs the configuration is retained in the register but received frames are never timestamped: the receive descriptor status stays clear and the DMA writes no timestamp context descriptor, so gPTP never computes neighborPropDelay and never becomes asCapable. Rewrite MAC_TIMESTAMP_CONTROL with its existing value once the transmitter and receiver are running so the snapshot logic latches the configuration. The register is read back and written unchanged, so this does not alter the timestamp bit selection and is safe on every ENET QoS instantiation regardless of init order. This is independent of the receive-path context descriptor wait already present in the driver, which covers the separate race where the receive interrupt arrives before the DMA finishes the descriptor writebacks. That wait cannot help when the snapshot engine was never armed, because no timestamp context descriptor is produced at all. Observed on MCXN947 hardware: rewriting the identical register value with the MAC running immediately restores receive timestamps. Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
zephyrbot
requested review from
ClaCodes,
Holt-Sun,
butok,
dbaluta,
iuliana-prodan,
lmajewski,
maass-hamburg,
mmahadevan108,
pdgendt,
tpambor and
zejiang0jason
August 26, 2026 03:58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The PTP clock driver programs MAC_TIMESTAMP_CONTROL at its own init time, which can run before enet_qos_start() enables the receiver. On cold boots with that ordering the RX timestamp snapshot logic never arms: and received PTP frames carry no hardware timestamps, so gPTP path delay measurement cannot complete and the port never becomes AS capable.
Read back and rewrite MAC_TIMESTAMP_CONTROL after the MAC receiver is enabled. Rewriting the existing value while RX is running is what latches the snapshot configuration, so this is deliberately not a no-op even though it writes back the same register value.
Validated on NXP MCXN947 hardware across repeated cold boots including power-on resets, path delay measurement completes and the port reports AS capable on every boot, where the broken ordering left it permanently incapable.