ice_ptp_extend_32b_ts(9)

✨ ice_ptp_extend_32b_ts ✨

okay so bestie, we're in the Kernel API Manual today and this one is lowkey a little time-machine situation. The function is ice_ptp_extend_32b_ts and it's giving "glow-up for timestamps" energy 💅

---

💖 NAME 💖

ice_ptp_extend_32b_ts — bestie's job is literally just: convert a 32b nanoseconds timestamp to 64b. that's it. that's the whole vibe 🎀

---

🦋 SYNOPSIS 🦋

u64 ice_ptp_extend_32b_ts (u64 cached_phc_time , u32 in_tstamp );

---

🌸 ARGUMENTS 🌸

• cached_phc_time — a recently cached copy of the PHC time. like, a screenshot of the clock taken not too long ago 📸
• in_tstamp — the ingress/egress 32b nanoseconds timestamp value. the lil baby timestamp we're trying to grow up 🍼

---

👑 DESCRIPTION 👑

okay so here's the tea ☕ — the hardware captures timestamps that only hold 32 bits of nominal nanoseconds, which is not what the stack expects. the stack wants the full 64bit glow-up. also note: those captured timestamp values may actually be 40 bits, but the lower 8 bits are sub-nanoseconds and generally get discarded, so they're not really invited to the party 🙈

So we extend the 32bit nanosecond timestamp using this algorithm and these assumptions, in order:

1. have a recently cached copy of the PHC time. non-negotiable, bestie ✨
2. assume that the in_tstamp was captured 2^31 nanoseconds (~2.1 seconds) before or after the PHC time was captured. that's the whole window we're working with ⏳
3. calculate the delta between the cached time and the timestamp. math era 💅
4. if the delta is smaller than 2^31 nanoseconds, then the timestamp was captured after the PHC time. in this case, the full timestamp is just the cached PHC time plus the delta. slay, addition 🎀
5. otherwise, if the delta is larger than 2^31 nanoseconds, then the timestamp was captured *before* the PHC time — i.e. because the PHC cache was updated after the timestamp was captured by hardware. in this case, the full timestamp is the cached time minus the inverse delta. subtraction ate, no cap 🔥

and the iconic part: this algorithm works even if the PHC time was updated after a Tx timestamp was requested, but before the Tx timestamp event was reported from hardware. like it just handles that. main character behavior fr fr 👑

This calculation primarily relies on keeping the cached PHC time up to date. If the timestamp was captured more than 2^31 nanoseconds after the PHC time, it is possible that the lower 32bits of PHC time have overflowed more than once, and we might generate an incorrect timestamp. 😭 so yeah, that's a real "be careful" moment.

ngl this is the part where we don't get sloppy — the safety net here is:

This is prevented by (a) periodically updating the cached PHC time once a second, and (b) discarding any Tx timestamp packet if it has waited for a timestamp for more than one second. two little guardrails, iconic, love that for us 🫶

---

💜 SEE ALSO 💜

Kernel file ./drivers/net/ethernet/intel/ice/ice_ptp.c — that's the source file, go read it if you're feeling brave 🧚

ice_ptp_find_pin_idx(9), ice_ptp_cfg_tx_interrupt(9), ice_set_rx_tstamp(9), ice_ptp_disable_timestamp_mode(9), ice_ptp_restore_timestamp_mode(9), ice_ptp_read_src_clk_reg(9), ice_ptp_extend_40b_ts(9), ice_ptp_is_tx_tracker_up(9), ice_ptp_req_tx_single_tstamp(9), ice_ptp_complete_tx_single_tstamp(9), ice_ptp_process_tx_tstamp(9), ice_ptp_alloc_tx_tracker(9), ice_ptp_flush_tx_tracker(9), ice_ptp_mark_tx_tracker_stale(9), ice_ptp_flush_all_tx_tracker(9), ice_ptp_release_tx_tracker(9), ice_ptp_init_tx_e82x(9), ice_ptp_init_tx(9), ice_ptp_update_cached_phctime(9), ice_ptp_reset_cached_phctime(9), ice_ptp_write_init(9), ice_ptp_write_adj(9), ice_base_incval(9), ice_ptp_check_tx_fifo(9), ice_ptp_wait_for_offsets(9), ice_ptp_port_phy_stop(9), ice_ptp_port_phy_restart(9), ice_ptp_link_change(9), ice_ptp_cfg_phy_interrupt(9), ice_ptp_reset_phy_timestamping(9), ice_ptp_restart_all_phy(9), ice_ptp_adjfine(9), ice_ptp_extts_event(9), ice_ptp_cfg_extts(9), ice_ptp_disable_all_extts(9), ice_ptp_enable_all_extts(9), ice_ptp_write_perout(9), ice_ptp_cfg_perout(9), ice_ptp_disable_all_perout(9), ice_ptp_enable_all_perout(9), ice_verify_pin(9), ice_ptp_gpio_enable(9), ice_ptp_gettimex64(9), ice_ptp_settime64(9), ice_ptp_adjtime_nonatomic(9), ice_ptp_adjtime(9), struct ice_crosststamp_cfg(9), struct ice_crosststamp_ctx(9), ice_capture_crosststamp(9), ice_ptp_getcrosststamp(9), ice_ptp_hwtstamp_get(9), ice_ptp_set_timestamp_mode(9), ice_ptp_hwtstamp_set(9), ice_ptp_get_rx_hwts(9), ice_ptp_setup_pin_cfg(9), ice_ptp_disable_pins(9), ice_ptp_parse_sdp_entries(9), ice_ptp_set_funcs_e82x(9), ice_ptp_set_funcs_e810(9), ice_ptp_set_funcs_e830(9), ice_ptp_set_caps(9), ice_ptp_create_clock(9), ice_ptp_request_ts(9), ice_ptp_ts_irq(9), ice_ptp_maybe_trigger_tx_interrupt(9), ice_ptp_queue_work(9), ice_ptp_prepare_rebuild_sec(9), ice_ptp_prepare_for_reset(9), ice_ptp_rebuild_owner(9), ice_ptp_rebuild(9), ice_ptp_clock_index(9), ice_ptp_init_owner(9), ice_ptp_init_work(9), ice_ptp_init_port(9), ice_ptp_init_tx_interrupt_mode(9), ice_ptp_init(9), ice_ptp_release(9)

yeah that's a lot of friends. they're all in the group chat 💬

---

and that's the whole page, bestie 💜 this one lives at ./drivers/net/ethernet/intel/ice, dated October 2026, and yes the page name is ice_ptp_extend_32b_ts(9) in case you forgot already 😌 go forth and extend those timestamps, you've got this 🫶✨