> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of Jacob > Keller > Sent: Wednesday, April 8, 2026 11:47 AM > To: Nguyen, Anthony L <[email protected]>; Intel Wired LAN > <[email protected]>; [email protected] > Cc: Loktionov, Aleksandr <[email protected]>; Keller, Jacob E > <[email protected]>; Miskell, Timothy <[email protected]> > Subject: [Intel-wired-lan] [PATCH iwl-net 1/4] ice: fix timestamp interrupt > configuration for E825C > > From: Grzegorz Nitka <[email protected]> > > The E825C ice_phy_cfg_intr_eth56g() function is responsible for programming > the PHY interrupt for a given port. This function writes to the > PHY_REG_TS_INT_CONFIG register of the port. The register is responsible for > configuring whether the port interrupt logic is enabled, as well as > programming the threshold of waiting timestamps that will trigger an > interrupt from this port. > > This threshold value must not be programmed to zero while the interrupt is > enabled. Doing so puts the port in a misconfigured state where the PHY > timestamp interrupt for the quad of connected ports will become stuck. > > This occurs, because a threshold of zero results in the timestamp interrupt > status for the port becoming stuck high. The four ports in the connected > quad have their timestamp status indicators muxed together. A new interrupt > cannot be generated until the timestamp status indicators return low for > all four ports. > > Normally, the timestamp status for a port will clear once there are fewer > timestamps in that ports timestamp memory bank than the threshold. A > threshold of zero makes this impossible, so the timestamp status for the > port does not clear. > > The ice driver never intentionally programs the threshold to zero, indeed > the driver always programs it to a value of 1, intending to get an > interrupt immediately as soon as even a single packet is waiting for a > timestamp. > > However, there is a subtle flaw in the programming logic in the > ice_phy_cfg_intr_eth56g() function. Due to the way that the hardware > handles enabling the PHY interrupt. If the threshold value is modified at > the same time as the interrupt is enabled, the HW PHY state machine might > enable the interrupt before the new threshold value is actually updated. > This leaves a potential race condition caused by the hardware logic where > a PHY timestamp interrupt might be triggered before the non-zero threshold > is written, resulting in the PHY timestamp logic becoming stuck. > > Once the PHY timestamp status is stuck high, it will remain stuck even > after attempting to reprogram the PHY block by changing its threshold or > disabling the interrupt. Even a typical PF or CORE reset will not reset the > particular block of the PHY that becomes stuck. Even a warm power cycle is > not guaranteed to cause the PHY block to reset, and a cold power cycle is > required. > > Prevent this by always writing the PHY_REG_TS_INT_CONFIG in two stages. > First write the threshold value with the interrupt disabled, and only write > the enable bit after the threshold has been programmed. When disabling the > interrupt, leave the threshold unchanged. Additionally, re-read the > register after writing it to guarantee that the write to the PHY has been > flushed upon exit of the function. > > While we're modifying this function implementation, explicitly reject > programming a threshold of 0 when enabling the interrupt. No caller does > this today, but the consequences of doing so are significant. An explicit > rejection in the code makes this clear. > > Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") > Signed-off-by: Grzegorz Nitka <[email protected]> > Signed-off-by: Jacob Keller <[email protected]> > Reviewed-by: Aleksandr Loktionov <[email protected]> > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 36 > +++++++++++++++++++++++++---- > 1 file changed, 32 insertions(+), 4 deletions(-)
Tested-by: Sunitha Mekala <[email protected]> (A Contingent worker at Intel)
