quoted

ktime_to_cycles uses hwtstamp as key for the cache lookup. As long as
the PHC is monotonic, the key is unique. If the time of the PHC is set, then
the cache would be invalidated. I'm afraid that setting the PHC could lead to
wrong or missing timestamps. Setting the PHC in hardware, timestamp
generation in hardware, and cache invalidation in software would need to
be synchronized somehow.

You can avoid errors even with a time jump:

Make a variant (union) of skb_shared_hwtstamps to allow driver to
provide an address or cookie instead of ktime_t.  Set a flag in the
skbuff to signal this.

Let the Rx path check the flag and fetch the time stamp by callback
with the address/cookie.

quoted

For TX it is known which timestamp is required. So I would have to find a way
to detect which timestamp shall be filled into hwtstamp.

How about tx_flags in struct skb_shared_info ?

I will try to make an implementation!

Shall I use tx_flags in struct skb_shared_info for both, TX and RX? Or should
I use flags in struct skb_shared_info for address/cookie signalisation?

3 of 8 flags are unused in tx_flags. It may be possible to use the same flag for
TX and RX. Is it worth it trying to save flags?

For TX it signals "fill cycle based timestamp" and could be called
SKBTX_HW_CSTAMP.

For RX it signals "hwtstamp is an address/cookie" and could be called
SKBFL_TSTAMP_COOKIE.

Thank you!
Gerhard