From: Jakub Kicinski Date: Thu, 23 Apr 2026 04:10:12 +0000 (-0700) Subject: Merge branch 'intel-wired-lan-driver-updates-2026-04-20-ice' X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9d146a5d10685ab19e15bbedc5107c5b94d45ebe;p=thirdparty%2Fkernel%2Fstable.git Merge branch 'intel-wired-lan-driver-updates-2026-04-20-ice' Jacob Keller says: ==================== Intel Wired LAN Driver Updates 2026-04-20 (ice) Since this is a set of related fixes for just the ice driver, Jake provides the following description for the series: We recently ran into a nasty corner case issue with a customer operating E825C cards seeing some strange behavior with missing Tx timestamps. During the course of debugging. This series contains a few fixes found during this debugging process. The primary issue discovered in the investigation is a misconfiguration of the E825C PHY timestamp interrupt register, PHY_REG_TS_INT_CONFIG. This register is responsible for programming the Tx timestamp behavior of a PHY port. The driver programs two values here: a threshold for when to interrupt and whether the interrupt is enabled. The threshold value is used by hardware to determine when to trigger a Tx timestamp interrupt. The interrupt cause for the port is raised when the number of outstanding timestamps in the PHY port timestamp memory meets the threshold. The interrupt cause is not cleared until the number of outstanding timestamps drops *below* the threshold. It is considered a misconfiguration if the threshold is programmed to 0. If the interrupt is enabled while the threshold is zero, hardware will raise the interrupt cause at the next time it checks. Once raised, the interrupt cause for the port will never lower, since you cannot have fewer than zero outstanding timestamps. Worse, the timestamp status for the port will remain high even if the PHY_REG_TS_INT_CONFIG is reprogrammed with a new threshold. The PHY is a separate hardware block from the MAC, and thus the interrupt status for the port will remain high even if you reset the device MAC with a PF reset, CORE reset, or GLOBAL reset. PHY ports are connected together into quads. Each quad muxes the PHY interrupt status for the 4 ports on the quad together before connecting that to the MACs miscellaneous interrupt vector. As a result, if a single PHY port in the quad is stuck, no timestamp interrupts will be generated for any timestamp on any port on that quad. The ice driver never directly writes a value of 0 for the threshold. Indeed, the desired behavior is to set the threshold to 1, so that interrupts are generated as soon as a single timestamp is captured. Unfortunately, it turns out that for the E825C PHY, programming the threshold and enable bit in the same write may cause a race in the PHY timestamp block. The PHY may "see" the interrupt as enabled first before it sees the threshold value. If the previous threshold value is zero (such as when the register is initialized to zero at a cold power on), the hardware may race with programming the threshold and set the PHY interrupt status to high as described above. The first patch in this series corrects that programming order, ensuring that the threshold is always written first in a separate transaction from enabling the interrupt bit. Additionally, an explicit check against writing a 0 is added to make it clear to future readers that writing 0 to the threshold while enabling the interrupt is not safe. The PHY timestamp block does not reset with the MAC, and seems to only reset during cold power on. This makes recovery from the faulty configuration difficult. To address this, perform an explicit reset of the PHY PTP block during initialization. This is achieved by writing the PHY_REG_GLOBAL register. This performs a PHY soft reset, which completely resets the timestamp block. This includes clearing the timestamp memory, the PHY timestamp interrupt status, and the PHY PTP counter. A soft reset of all ports on the device is done as part of ice_ptp_init_phc() during early initialization of the PTP functionality by the PTP clock owner, prior to programming each PHY. The ice_ptp_init_phc() function is called at driver init and during reinitialization after all forms of device reset. This ensures that the driver begins operation at a clean slate, rather than carrying over the stale and potentially buggy configuration of a previous driver. While attempting to root cause the issue with the PHY timestamp interrupt, we also discovered that the driver incorrectly assumes that it is operating on E822 hardware when reading the PHY timestamp memory status registers in a few places. This includes the check at the end of the interrupt handler, as well as the check done inside the PTP auxiliary function. This prevented the driver from detecting waiting timestamps on ports other than the first two. Finally, the ice_ptp_read_tx_hwstamp_status_eth56g() function was discovered to only read the timestamp interrupt status value from the first quad due to mistaking the port index for a PHY quad index. This resulted in reporting the timestamp status for the second quad as identical to the first quad instead of properly reporting its value. This is a minor fix since the function currently is only used for diagnostic purposes and does not impact driver decision logic. ==================== Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-0-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski --- 9d146a5d10685ab19e15bbedc5107c5b94d45ebe