kernel/drivers/net/ethernet/intel/e1000e/ptp.c, branch linux-6.18.y

e1000e: set fixed clock frequency indication for Nahum 11 and Nahum 13

2025-06-17T17:09:24Z

On some systems with Nahum 11 and Nahum 13 the value of the XTAL clock in the software STRAP is incorrect. This causes the PTP timer to run at the wrong rate and can lead to synchronization issues. The STRAP value is configured by the system firmware, and a firmware update is not always possible. Since the XTAL clock on these systems always runs at 38.4MHz, the driver may ignore the STRAP and just set the correct value. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits Tested-by: Mor Bar-Gabay Reviewed-by: Gil Fine Signed-off-by: Tony Nguyen

e1000e: Replace convert_art_to_tsc()

2024-06-03T09:18:50Z

The core code now provides a mechanism to convert the ART base clock to the corresponding TSC value without requiring an architecture specific function. Replace the direct conversion by filling in the required data. No functional change intended. Signed-off-by: Thomas Gleixner Signed-off-by: Lakshmi Sowjanya D Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240513103813.5666-4-lakshmi.sowjanya.d@intel.com

e1000e: correct maximum frequency adjustment values

2024-01-29T18:01:08Z

The e1000e driver supports hardware with a variety of different clock speeds, and thus a variety of different increment values used for programming its PTP hardware clock. The values currently programmed in e1000e_ptp_init are incorrect. In particular, only two maximum adjustments are used: 24000000 - 1, and 600000000 - 1. These were originally intended to be used with the 96 MHz clock and the 25 MHz clock. Both of these values are actually slightly too high. For the 96 MHz clock, the actual maximum value that can safely be programmed is 23,999,938. For the 25 MHz clock, the maximum value is 599,999,904. Worse, several devices use a 24 MHz clock or a 38.4 MHz clock. These parts are incorrectly assigned one of either the 24million or 600million values. For the 24 MHz clock, this is not a significant issue: its current increment value can support an adjustment up to 7billion in the positive direction. However, the 38.4 KHz clock uses an increment value which can only support up to 230,769,157 before it starts overflowing. To understand where these values come from, consider that frequency adjustments have the form of: new_incval = base_incval + (base_incval * adjustment) / (unit of adjustment) The maximum adjustment is reported in terms of parts per billion: new_incval = base_incval + (base_incval * adjustment) / 1 billion The largest possible adjustment is thus given by the following: max_incval = base_incval + (base_incval * max_adj) / 1 billion Re-arranging to solve for max_adj: max_adj = (max_incval - base_incval) * 1 billion / base_incval We also need to ensure that negative adjustments cannot underflow. This can be achieved simply by ensuring max_adj is always less than 1 billion. Introduce new macros in e1000.h codifying the maximum adjustment in PPB for each frequency given its associated increment values. Also clarify where these values come from by commenting about the above equations. Replace the switch statement in e1000e_ptp_init with one which mirrors the increment value switch statement from e1000e_get_base_timinica. For each device, assign the appropriate maximum adjustment based on its frequency. Some parts can have one of two frequency modes as determined by E1000_TSYNCRXCTL_SYSCFI. Since the new flow directly matches the assignments in e1000e_get_base_timinca, and uses well defined macro names, it is much easier to verify that the resulting maximum adjustments are correct. It also avoids difficult to parse construction such as the "hw->mac.type < e1000_phc_lpt", and the use of fallthrough which was especially confusing when combined with a conditional block. Note that I believe the current increment value configuration used for 24MHz clocks is sub-par, as it leaves at least 3 extra bits available in the INCVALUE register. However, fixing that requires more careful review of the clock rate and associated values. Reported-by: Trey Harrison Fixes: 68fe1d5da548 ("e1000e: Add Support for 38.4MHZ frequency") Fixes: d89777bf0e42 ("e1000e: add support for IEEE-1588 PTP") Signed-off-by: Jacob Keller Tested-by: Naama Meir Signed-off-by: Tony Nguyen

e1000e: Add support for the next LOM generation

2023-08-24T19:55:25Z

Add devices IDs for the next LOM generations that will be available on the next Intel Client platforms. This patch provides the initial support for these devices. Signed-off-by: Sasha Neftin Tested-by: Naama Meir Signed-off-by: Tony Nguyen

e1000e: Add support for the next LOM generation

2022-11-02T18:00:10Z

ptp: introduce helpers to adjust by scaled parts per million

2022-10-31T11:14:16Z

Many drivers implement the .adjfreq or .adjfine PTP op function with the same basic logic: 1. Determine a base frequency value 2. Multiply this by the abs() of the requested adjustment, then divide by the appropriate divisor (1 billion, or 65,536 billion). 3. Add or subtract this difference from the base frequency to calculate a new adjustment. A few drivers need the difference and direction rather than the combined new increment value. I recently converted the Intel drivers to .adjfine and the scaled parts per million (65.536 parts per billion) logic. To avoid overflow with minimal loss of precision, mul_u64_u64_div_u64 was used. The basic logic used by all of these drivers is very similar, and leads to a lot of duplicate code to perform the same task. Rather than keep this duplicate code, introduce diff_by_scaled_ppm and adjust_by_scaled_ppm. These helper functions calculate the difference or adjustment necessary based on the scaled parts per million input. The diff_by_scaled_ppm function returns true if the difference should be subtracted, and false otherwise. Update the Intel drivers to use the new helper functions. Other vendor drivers will be converted to .adjfine and this helper function in the following changes. Signed-off-by: Jacob Keller Acked-by: Richard Cochran Signed-off-by: David S. Miller

e1000e: convert .adjfreq to .adjfine

2022-07-28T17:57:06Z

The PTP implementation for the e1000e driver uses the older .adjfreq method. This method takes an adjustment in parts per billion. The newer .adjfine implementation uses scaled_ppm. The use of scaled_ppm allows for finer grained adjustments and is preferred over using the older implementation. Make use of mul_u64_u64_div_u64 in order to handle possible overflow of the multiplication used to calculate the desired adjustment to the hardware increment value. Signed-off-by: Jacob Keller Tested-by: Naama Meir Signed-off-by: Tony Nguyen

e1000e: remove unnecessary range check in e1000e_phc_adjfreq

2022-07-28T17:55:56Z

The e1000e_phc_adjfreq function validates that the input delta is within the maximum range. This is already handled by the core PTP code and this is a duplicate and thus unnecessary check. It also complicates refactoring to use the newer .adjfine implementation, where the input is no longer specified in parts per billion. Remove the range validation check. Signed-off-by: Jacob Keller Tested-by: Naama Meir Signed-off-by: Tony Nguyen

e1000e: Add support for Lunar Lake

2021-07-20T23:11:36Z

Add devices IDs for the next LOM generations that will be available on the next Intel Client platform (Lunar Lake) This patch provides the initial support for these devices Signed-off-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen

e1000e: Fix prototype warning

2021-03-23T18:34:02Z

Correct report warnings in ich8lan.c, netdev.c phy.c and ptp.c files Signed-off-by: Sasha Neftin Signed-off-by: Tony Nguyen