On 8/7/2023 3:36 AM, Karol Kolacinski wrote: > The driver calls ice_ptp_cfg_timestamp() during > ice_ptp_prepare_for_reset() to disable timestamping while the device is > resetting. It then attempts to restore timestamp configuration at the > end of ice_rebuild(). However, it currently forcibly calls > ice_ptp_cfg_timestamp() with a value of true when the device is not E810 > and is the clock owner, while calling ice_ptp_cfg_timestamp() with a > value of false for all other devices. > > This incorrectly forcibly disables timestamping on all ports except the > clock owner. > > This was not detected previously due to a quirk of the LinuxPTP ptp4l > application. If ptp4l detects a missing timestamp, it enters a fault > state and performs recovery logic which includes executing SIOCSHWTSTAMP > again, restoring the now accidentally cleared configuration. > > Not every application does this, and for these applications, timestamps > will mysteriously stop after a PF reset, without being restored until an > application restart. > > Fix this by replacing ice_ptp_cfg_timestamp() with two new functions: > > 1) ice_ptp_disable_timestamp_mode() which unconditionally disables the > timestamping logic in ice_ptp_prepare_for_reset() and > ice_ptp_release() > > 2) ice_ptp_restore_timestamp_mode() which calls > ice_ptp_restore_tx_interrupt() to restore Tx timestamping > configuration, calls ice_set_rx_tstamp() to restore Rx timestamping > configuration, and issues an immediate TSYN_TX interrupt to ensure > that timestamps which may have occurred during the device reset get > processed. > > This obsoletes the ice_set_tx_tstamp() function which can now be safely > removed. > > With this change, all devices should now restore Tx and Rx timestamping > functionality correctly after a PF reset without application > intervention. > > Change-type: DefectResolution > HSDES-number: 22018443364 > HSDES-tenant: server_platf_lan.bug > Signed-off-by: Jacob Keller <[email protected]> > --- I'm sending a version of this patch directly to net-next along with the related fix for PFINT_TSYN_MSK, so that may cause a conflict with this series. I think it should be fixable by Tony or myself when we rebase IWL, but it could lead to needing a new version of the series. Thanks, Jake _______________________________________________ Intel-wired-lan mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
