Re: [Intel-wired-lan] [PATCH iwl-next v1] ice: refactor ice_fdir_create_dflt_rules() function
> -Original Message- > From: Intel-wired-lan On Behalf Of > Mateusz Polchlopek > Sent: 17 January 2025 13:37 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Polchlopek, Mateusz > ; Michal Swiatkowski > > Subject: [Intel-wired-lan] [PATCH iwl-next v1] ice: refactor > ice_fdir_create_dflt_rules() function > > The Flow Director function ice_fdir_create_dflt_rules() calls few times > function ice_create_init_fdir_rule() each time with different enum > ice_fltr_ptype parameter. Next step is to return error code if error occurred. > > Change the code to store all necessary default rules in constant array and > call ice_create_init_fdir_rule() in the loop. It makes it easy to extend the > list of default rules in the future, without the need of duplicate code more > and more. > > Reviewed-by: Michal Swiatkowski > Signed-off-by: Mateusz Polchlopek > --- > .../net/ethernet/intel/ice/ice_ethtool_fdir.c | 21 --- > 1 file changed, 9 insertions(+), 12 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix incorrect PHY settings for 100 GB/s
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Przemyslaw Korba
> Sent: 04 December 2024 18:52
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Nguyen, Anthony L ;
> Kitszel, Przemyslaw ; richardcoch...@gmail.com;
> and...@lunn.ch; olte...@gmail.com; Olech, Milena ;
> pmen...@molgen.mpg.de; Korba, Przemyslaw
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix incorrect PHY settings
> for 100 GB/s
>
> ptp4l application reports too high offset when ran on E823 device with a
> 100GB/s link. Those values cannot go under 100ns, like in a working case when
> using 100 GB/s cable.
>
> This is due to incorrect frequency settings on the PHY clocks for
> 100 GB/s speed. Changes are introduced to align with the internal hardware
> documentation, and correctly initialize frequency in PHY clocks with the
> frequency values that are in our HW spec.
>
> To reproduce the issue run ptp4l as a Time Receiver on E823 device, and
> observe the offset, which will never approach values seen in the PTP working
> case.
>
> Reproduction output:
> ptp4l -i enp137s0f3 -m -2 -s -f /etc/ptp4l_8275.conf
> ptp4l[5278.775]: master offset 12470 s2 freq +41288 path delay -3002
> ptp4l[5278.837]: master offset 10525 s2 freq +39202 path delay -3002
> ptp4l[5278.900]: master offset -24840 s2 freq -20130 path delay -3002
> ptp4l[5278.963]: master offset 10597 s2 freq +37908 path delay -3002
> ptp4l[5279.025]: master offset 8883 s2 freq +36031 path delay -3002
> ptp4l[5279.088]: master offset 7267 s2 freq +34151 path delay -3002
> ptp4l[5279.150]: master offset 5771 s2 freq +32316 path delay -3002
> ptp4l[5279.213]: master offset 4388 s2 freq +30526 path delay -3002
> ptp4l[5279.275]: master offset -30434 s2 freq -28485 path delay -3002
> ptp4l[5279.338]: master offset -28041 s2 freq -27412 path delay -3002
> ptp4l[5279.400]: master offset 7870 s2 freq +31118 path delay -3002
>
> Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support")
> Reviewed-by: Milena Olech
> Signed-off-by: Przemyslaw Korba
> ---
> Changelog:
> v2:
> change commit message
> v1:
> https://lore.kernel.org/intel-wired-lan/20241126102311.344972-1-przemyslaw.ko...@intel.com/
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low latency PHY timer updates
> -Original Message- > From: Intel-wired-lan On Behalf Of Anton > Nadezhdin > Sent: 16 December 2024 20:24 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Nguyen, Anthony L ; > Kitszel, Przemyslaw ; richardcoch...@gmail.com; > Keller, Jacob E ; Kolacinski, Karol > ; Olech, Milena ; > Nadezhdin, Anton > Subject: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low latency > PHY timer updates > > From: Jacob Keller > > Programming the PHY registers in preparation for an increment value change or > a timer adjustment on E810 requires issuing Admin Queue commands for each PHY > register. It has been found that the firmware Admin Queue processing > occasionally has delays of tens or rarely up to hundreds of milliseconds. > This delay cascades to failures in the PTP applications which depend on these > updates being low latency. > > Consider a standard PTP profile with a sync rate of 16 times per second. > This means there is ~62 milliseconds between sync messages. A complete cycle > of the PTP algorithm > > 1) Sync message (with Tx timestamp) from source > 2) Follow-up message from source > 3) Delay request (with Tx timestamp) from sink > 4) Delay response (with Rx timestamp of request) from source > 5) measure instantaneous clock offset > 6) request time adjustment via CLOCK_ADJTIME systemcall > > The Tx timestamps have a default maximum timeout of 10 milliseconds. If we > assume that the maximum possible time is used, this leaves us with ~42 > milliseconds of processing time for a complete cycle. > > The CLOCK_ADJTIME system call is synchronous and will block until the driver > completes its timer adjustment or frequency change. > > If the writes to prepare the PHY timers get hit by a latency spike of 50 > milliseconds, then the PTP application will be delayed past the point where > the next cycle should start. Packets from the next cycle may have already > arrived and are waiting on the socket. > > In particular, LinuxPTP ptp4l may start complaining about missing an announce > message from the source, triggering a fault. In addition, the clockcheck > logic it uses may trigger. This clockcheck failure occurs because the > timestamp captured by hardware is compared against a reading of > CLOCK_MONOTONIC. It is assumed that the time when the Rx timestamp is > captured and the read from CLOCK_MONOTONIC are relatively close together. > This is not the case if there is a significant delay to processing the Rx > packet. > > Newer firmware supports programming the PHY registers over a low latency > interface which bypasses the Admin Queue. Instead, software writes to the > REG_LL_PROXY_L and REG_LL_PROXY_H registers. Firmware reads these registers > and then programs the PHY timers. > > Implement functions to use this interface when available to program the PHY > timers instead of using the Admin Queue. This avoids the Admin Queue latency > and ensures that adjustments happen within acceptable latency bounds. > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > Reviewed-by: Milena Olech > Signed-off-by: Anton Nadezhdin > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 105 > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 4 + > 2 files changed, 109 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 2/5] ice: rename TS_LL_READ* macros to REG_LL_PROXY_H_*
> -Original Message- > From: Intel-wired-lan On Behalf Of Anton > Nadezhdin > Sent: 16 December 2024 20:23 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Nguyen, Anthony L ; > Kitszel, Przemyslaw ; richardcoch...@gmail.com; > Keller, Jacob E ; Kolacinski, Karol > ; Olech, Milena ; > Nadezhdin, Anton > Subject: [Intel-wired-lan] [PATCH iwl-next v2 2/5] ice: rename TS_LL_READ* > macros to REG_LL_PROXY_H_* > > From: Jacob Keller > > The TS_LL_READ macros are used as part of the low latency Tx timestamp > interface. A future firmware extension will add support for performing PHY > timer updates over this interface. Using TS_LL_READ as the prefix for these > macros will be confusing once the interface is used for other purposes. > > Rename the macros, using the prefix REG_LL_PROXY_H, to better clarify that > this is for the low latency interface. > Additionally add macroses for PF_SB_ATQBAH and PF_SB_ATQBAL registers to > better clarify content of this registers as PF_SB_ATQBAH contain low part of > Tx timestamp > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > Reviewed-by: Milena Olech > Signed-off-by: Anton Nadezhdin > --- > drivers/net/ethernet/intel/ice/ice_ptp.c| 14 +++--- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 14 +++--- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 13 - > 3 files changed, 22 insertions(+), 19 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v4] ice: add fw and port health reporters
> -Original Message- > From: Intel-wired-lan On Behalf Of > Konrad Knitter > Sent: 11 December 2024 16:34 > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; Kitszel, Przemyslaw > ; net...@vger.kernel.org; k...@kernel.org; > pab...@redhat.com; eduma...@google.com; da...@davemloft.net; > andrew+net...@lunn.ch; brett.cree...@amd.com; marcin.szy...@linux.intel.com; > Knitter, Konrad > Subject: [Intel-wired-lan] [PATCH iwl-next v4] ice: add fw and port health > reporters > > Firmware generates events for global events or port specific events. > > Driver shall subscribe for health status events from firmware on supported FW > versions >= 1.7.6. > Driver shall expose those under specific health reporter, two new reporters > are introduced: > - FW health reporter shall represent global events (problems with the image, > recovery mode); > - Port health reporter shall represent port-specific events (module failure). > > Firmware only reports problems when those are detected, it does not store > active fault list. > Driver will hold only last global and last port-specific event. > Driver will report all events via devlink health report, so in case of > multiple events of the same source they can be reviewed using devlink > autodump feature. > > $ devlink health > > pci/:b1:00.3: > reporter fw > state healthy error 0 recover 0 auto_dump true > reporter port >state error error 1 recover 0 last_dump_date 2024-03-17 > last_dump_time 09:29:29 auto_dump true > > $ devlink health diagnose pci/:b1:00.3 reporter port > > Syndrome: 262 > Description: Module is not present. > Possible Solution: Check that the module is inserted correctly. > Port Number: 0 > > Tested on Intel Corporation Ethernet Controller E810-C for SFP > > Reviewed-by: Marcin Szycik > Co-developed-by: Sharon Haroni > Signed-off-by: Sharon Haroni > Co-developed-by: Nicholas Nunley > Signed-off-by: Nicholas Nunley > Co-developed-by: Brett Creeley > Signed-off-by: Brett Creeley > Signed-off-by: Konrad Knitter > > --- > v4: Extended documentation to ice_is_fw_health_report_supported. > Comparing host byte order event_source. > v3: Changed patch title to add health reporters. Style fixes. > https://lore.kernel.org/intel-wired-lan/20241209093204.173817-1-konrad.knit...@intel.com/T/#u > v2: Removal of __VA_OPS__ usage. Style fixes. > https://lore.kernel.org/intel-wired-lan/20241209111359.ga2...@kernel.org/T/#t > v1: Initial version > https://lore.kernel.org/intel-wired-lan/20241118104810.477794-1-konrad.knit...@intel.com/#t > > Depends-on: > https://lore.kernel.org/netdev/20240930133724.610512-1-przemyslaw.kits...@intel.com/T/ > --- > .../net/ethernet/intel/ice/devlink/health.c | 295 +- > .../net/ethernet/intel/ice/devlink/health.h | 14 +- > .../net/ethernet/intel/ice/ice_adminq_cmd.h | 87 ++ > drivers/net/ethernet/intel/ice/ice_common.c | 38 +++ > drivers/net/ethernet/intel/ice/ice_common.h | 2 + > drivers/net/ethernet/intel/ice/ice_main.c | 3 + > drivers/net/ethernet/intel/ice/ice_type.h | 5 + > 7 files changed, 436 insertions(+), 8 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 3/5] ice: add lock to protect low latency interface
> -Original Message- > From: Intel-wired-lan On Behalf Of Anton > Nadezhdin > Sent: 16 December 2024 20:24 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Nguyen, Anthony L ; > Kitszel, Przemyslaw ; richardcoch...@gmail.com; > Keller, Jacob E ; Olech, Milena > ; Nadezhdin, Anton > Subject: [Intel-wired-lan] [PATCH iwl-next v2 3/5] ice: add lock to protect > low latency interface > > From: Jacob Keller > > Newer firmware for the E810 devices support a 'low latency' interface to > interact with the PHY without using the Admin Queue. This is interacted with > via the REG_LL_PROXY_L and REG_LL_PROXY_H registers. > > Currently, this interface is only used for Tx timestamps. There are two > different mechanisms, including one which uses an interrupt for firmware to > signal completion. However, these two methods are mutually exclusive, so no > synchronization between them was necessary. > > This low latency interface is being extended in future firmware to support > also programming the PHY timers. Use of the interface for PHY timers will > need synchronization to ensure there is no overlap with a Tx timestamp. > > The interrupt-based response complicates the locking somewhat. We can't use a > simple spinlock. This would require being acquired in > ice_ptp_req_tx_single_tstamp, and released in > ice_ptp_complete_tx_single_tstamp. The ice_ptp_req_tx_single_tstamp function > is called from the threaded IRQ, and the ice_ptp_complete_tx_single_stamp is > called from the low latency IRQ, so we would need to acquire the lock with > IRQs disabled. > > To handle this, we'll use a wait queue along with > wait_event_interruptible_locked_irq in the update flows which don't use the > interrupt. > > The interrupt flow will acquire the wait queue lock, set the > ATQBAL_FLAGS_INTR_IN_PROGRESS, and then initiate the firmware low latency > request, and unlock the wait queue lock. > > Upon receipt of the low latency interrupt, the lock will be acquired, the > ATQBAL_FLAGS_INTR_IN_PROGRESS bit will be cleared, and the firmware response > will be captured, and wake_up_locked() will be called on the wait queue. > > The other flows will use wait_event_interruptible_locked_irq() to wait until > the ATQBAL_FLAGS_INTR_IN_PROGRESS is clear. This function checks the > condition under lock, but does not hold the lock while waiting. On return, > the lock is held, and a return of zero indicates we hold the lock and the > in-progress flag is not set. > > This will ensure that threads which need to use the low latency interface > will sleep until they can acquire the lock without any pending low latency > interrupt flow interfering. > > Signed-off-by: Jacob Keller > Reviewed-by: Milena Olech > Signed-off-by: Anton Nadezhdin > --- > drivers/net/ethernet/intel/ice/ice_ptp.c| 42 + > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 18 + > drivers/net/ethernet/intel/ice/ice_type.h | 10 + > 3 files changed, 62 insertions(+), 8 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 4/5] ice: check low latency PHY timer update firmware capability
> -Original Message- > From: Intel-wired-lan On Behalf Of Anton > Nadezhdin > Sent: 16 December 2024 20:24 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Nguyen, Anthony L ; > Kitszel, Przemyslaw ; richardcoch...@gmail.com; > Keller, Jacob E ; Kolacinski, Karol > ; Olech, Milena ; > Nadezhdin, Anton > Subject: [Intel-wired-lan] [PATCH iwl-next v2 4/5] ice: check low latency PHY > timer update firmware capability > > From: Jacob Keller > > Newer versions of firmware support programming the PHY timer via the low > latency interface exposed over REG_LL_PROXY_L and REG_LL_PROXY_H. Add support > for checking the device capabilities for this feature. > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > Reviewed-by: Milena Olech > Signed-off-by: Anton Nadezhdin > --- > drivers/net/ethernet/intel/ice/ice_common.c | 3 +++ > drivers/net/ethernet/intel/ice/ice_type.h | 2 ++ > 2 files changed, 5 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 1/5] ice: use rd32_poll_timeout_atomic in ice_read_phy_tstamp_ll_e810
> -Original Message- > From: Intel-wired-lan On Behalf Of Anton > Nadezhdin > Sent: 16 December 2024 20:23 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Nguyen, Anthony L ; > Kitszel, Przemyslaw ; richardcoch...@gmail.com; > Keller, Jacob E ; Kolacinski, Karol > ; Olech, Milena ; > Nadezhdin, Anton > Subject: [Intel-wired-lan] [PATCH iwl-next v2 1/5] ice: use > rd32_poll_timeout_atomic in ice_read_phy_tstamp_ll_e810 > > From: Jacob Keller > > The ice_read_phy_tstamp_ll_e810 function repeatedly reads the PF_SB_ATQBAL > register until the TS_LL_READ_TS bit is cleared. This is a perfect candidate > for using rd32_poll_timeout. However, the default implementation uses a > sleep-based wait. > > Add a new rd32_poll_timeout_atomic macro which is based on the non-sleeping > read_poll_timeout_atomic implementation. Use this to replace the loop reading > in the ice_read_phy_tstamp_ll_e810 function. > > This will also be used in the future when low latency PHY timer updates are > supported. > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > Reviewed-by: Milena Olech > Signed-off-by: Anton Nadezhdin > --- > drivers/net/ethernet/intel/ice/ice_osdep.h | 3 +++ > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 30 + > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 2 +- > 3 files changed, 17 insertions(+), 18 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v1] ice: remove invalid parameter of equalizer
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Mateusz Polchlopek
> Sent: 31 December 2024 15:21
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Polchlopek, Mateusz
> Subject: [Intel-wired-lan] [PATCH iwl-net v1] ice: remove invalid parameter
> of equalizer
>
> It occurred that in the commit 70838938e89c ("ice: Implement driver
> functionality to dump serdes equalizer values") the invalid DRATE parameter
> for reading has been added. The output of the command:
>
> $ ethtool -d
>
> returns the garbage value in the place where DRATE value should be stored.
>
> Remove mentioned parameter to prevent return of corrupted data to userspace.
>
> Fixes: 70838938e89c ("ice: Implement driver functionality to dump serdes
> equalizer values")
> Signed-off-by: Mateusz Polchlopek
> ---
> drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 -
> drivers/net/ethernet/intel/ice/ice_ethtool.c| 1 -
> drivers/net/ethernet/intel/ice/ice_ethtool.h| 1 -
> 3 files changed, 3 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH] ixgbe: Fix unreachable retry logic in combined and byte I2C write functions
> -Original Message- > From: Intel-wired-lan On Behalf Of Rand > Deeb > Sent: 06 March 2025 15:42 > To: Nguyen, Anthony L ; Kitszel, Przemyslaw > ; Andrew Lunn ; David S. > Miller ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; moderated > list:INTEL ETHERNET DRIVERS ; open > list:NETWORKING DRIVERS ; open list > > Cc: deeb.r...@confident.ru; lvc-proj...@linuxtesting.org; > voskresenski.stanis...@confident.ru; Rand Deeb > Subject: [Intel-wired-lan] [PATCH] ixgbe: Fix unreachable retry logic in > combined and byte I2C write functions > > The current implementation of `ixgbe_write_i2c_combined_generic_int` and > `ixgbe_write_i2c_byte_generic_int` sets `max_retry` to `1`, which makes the > condition `retry < max_retry` always evaluate to `false`. This renders the > retry mechanism ineffective, as the debug message and retry logic are never > executed. > > This patch increases `max_retry` to `3` in both functions, aligning them with > the retry logic in `ixgbe_read_i2c_combined_generic_int`. This ensures that > the retry mechanism functions as intended, improving robustness in case of > I2C write failures. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Signed-off-by: Rand Deeb > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2] i40e: fix MMIO write access to an invalid page in i40e_clear_hw
> -Original Message- > From: Intel-wired-lan On Behalf Of > Kyungwook Boo > Sent: 11 March 2025 10:46 > To: Loktionov, Aleksandr ; Kitszel, Przemyslaw > ; Nguyen, Anthony L Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH iwl-next v2] i40e: fix MMIO write access to > an invalid page in i40e_clear_hw > > When the device sends a specific input, an integer underflow can occur, > leading to MMIO write access to an invalid page. > > Prevent the integer underflow by changing the type of related variables. > > Signed-off-by: Kyungwook Boo > Link: > https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7...@gmail.com/T/ > --- > Changes in v2: > - Formatting properly > - Fix variable shadowing > - Link to v1: > https://lore.kernel.org/netdev/55acc5dc-8d5a-45bc-a59c-9304071e4...@gmail.com/ > --- > drivers/net/ethernet/intel/i40e/i40e_common.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net] ice: ensure periodic output start time is in the future
> -Original Message-
> From: Intel-wired-lan On Behalf Of Jacob
> Keller
> Sent: 20 February 2025 03:43
> To: Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
>
Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Keller, Jacob E
> Subject: [Intel-wired-lan] [PATCH iwl-net] ice: ensure periodic output start
> time is in the future
>
> From: Karol Kolacinski
>
> On E800 series hardware, if the start time for a periodic output signal is
> programmed into GLTSYN_TGT_H and GLTSYN_TGT_L registers, the hardware logic
> locks up and the periodic output signal never starts. Any future attempt to
> reprogram the clock function is futile as the hardware will not reset until a
> power on.
>
> The ice_ptp_cfg_perout function has logic to prevent this, as it checks if
> the requested start time is in the past. If so, a new start time is
> calculated by rounding up.
>
> Since commit d755a7e129a5 ("ice: Cache perout/extts requests and check
> flags"), the rounding is done to the nearest multiple of the clock period,
> rather than to a full second. This is more accurate, since it ensures the
> signal matches the user request precisely.
>
> Unfortunately, there is a race condition with this rounding logic. If the
> current time is close to the multiple of the period, we could calculate a
> target time that is extremely soon. It takes time for the software to program
> the registers, during which time this requested start time could become a
> start time in the past. If that happens, the periodic output signal will lock
> up.
>
> For large enough periods, or for the logic prior to the mentioned commit,
> this is unlikely. However, with the new logic rounding to the period and with
> a small enough period, this becomes inevitable.
>
> For example, attempting to enable a 10MHz signal requires a period of 100
> nanoseconds. This means in the *best* case, we have 99 nanoseconds to program
> the clock output. This is essentially impossible, and thus such a small
> period practically guarantees that the clock output function will lock up.
>
> To fix this, add some slop to the clock time used to check if the start time
> is in the past. Because it is not critical that output signals start
> immediately, but it *is* critical that we do not brick the function, 0.5
> seconds is selected. > This does mean that any requested output will be
> delayed by at least 0.5 seconds.
>
> This slop is applied before rounding, so that we always round up to the
> nearest multiple of the period that is at least 0.5 seconds in the future,
> ensuring a minimum of 0.5 seconds to program the clock output registers.
>
> Finally, to ensure that the hardware registers programming the clock output
> complete in a timely manner, add a write flush to the end of
> ice_ptp_write_perout. This ensures we don't risk any issue with PCIe
> transaction batching.
>
> Strictly speaking, this fixes a race condition all the way back at the
> initial implementation of periodic output programming, as it is theoretically
> possible to trigger this bug even on the old logic when always rounding to a
> full second. However, the window is narrow, and the code has been refactored
> heavily since then, making a direct backport not apply cleanly.
>
> Fixes: d755a7e129a5 ("ice: Cache perout/extts requests and check flags")
> Signed-off-by: Karol Kolacinski
> Signed-off-by: Jacob Keller
> ---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH intel-net v2] ice: fix reservation of resources for RDMA when disabled
> -Original Message-
> From: Intel-wired-lan On Behalf Of Jesse
> Brandeburg
> Sent: 06 March 2025 23:27
> To: intel-wired-...@lists.osuosl.org
> Cc: Brandeburg, Jesse ; net...@vger.kernel.org;
> kernel-t...@cloudflare.com; jbran...@kernel.org; l...@kernel.org; Kitszel,
> Przemyslaw ; Ertman, David M
>
> Subject: [Intel-wired-lan] [PATCH intel-net v2] ice: fix reservation of
> resources for RDMA when disabled
>
> From: Jesse Brandeburg
>
> If the CONFIG_INFINIBAND_IRDMA symbol is not enabled as a module or a
> built-in, then don't let the driver reserve resources for RDMA. The result of
> this change is a large savings in resources for older kernels, and a cleaner
> driver configuration for the IRDMA=n case for old and new kernels.
>
> Implement this by avoiding enabling the RDMA capability when scanning
> hardware capabilities.
>
> Note: Loading the out-of-tree irdma driver in connection to the in-kernel ice
> driver, is not supported, and should not be attempted, especially when
> disabling IRDMA in the kernel config.
>
> Fixes: d25a0fc41c1f ("ice: Initialize RDMA support")
> Signed-off-by: Jesse Brandeburg
> Acked-by: Dave Ertman
> ---
> v2: resend with acks, add note about oot irdma (Leon), reword commit message
> v1:
> https://lore.kernel.org/netdev/20241114000105.703740-1-jbran...@kernel.org/
> ---
> drivers/net/ethernet/intel/ice/ice_common.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v4] ice: use DSN instead of PCI BDF for ice_adapter index
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Przemek Kitszel
> Sent: 14 April 2025 18:43
> To: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
>
> Cc: Jiri Pirko ; Temerkhanov, Sergey
> ; net...@vger.kernel.org; Loktionov, Aleksandr
> ; Kolacinski, Karol
> ; Kubiak, > Michal ;
> Simon Horman ; Kitszel, Przemyslaw
> ; Keller, Jacob E ;
> Jakub Kicinski
> Subject: [Intel-wired-lan] [PATCH iwl-net v4] ice: use DSN instead of PCI BDF
> for ice_adapter index
>
> Use Device Serial Number instead of PCI bus/device/function for the index of
> struct ice_adapter.
>
> Functions on the same physical device should point to the very same
> ice_adapter instance, but with two PFs, when at least one of them is PCI-e
> passed-through to a VM, it is no longer the case - PFs will get seemingly
> random PCI BDF values, and thus indices, what finally leds to each of them
> being on their own instance of ice_adapter. That causes them to don't attempt
> any synchronization of the PTP HW clock usage, or any other future resources.
>
> DSN works nicely in place of the index, as it is "immutable" in terms of
> virtualization.
>
> Fixes: 0e2bddf9e5f9 ("ice: add ice_adapter for shared data across PFs on the
> same NIC")
> Suggested-by: Jacob Keller
> Suggested-by: Jakub Kicinski
> Suggested-by: Jiri Pirko
> Reviewed-by: Aleksandr Loktionov
> Signed-off-by: Przemek Kitszel
> ---
> CC: Karol Kolacinski
> CC: Grzegorz Nitka
> CC: Michal Schmidt
> CC: Sergey Temerkhanov
> CC: Michal Kubiak
> CC: Simon Horman
>
> v4:
> - Add fixes tag for real... (Simon)
> - extend commit message (Simon)
> - pass dsn to ice_adapter_new() to have simpler code
> (I happened to do that as (local) followup) (me)
>
> v3:
> https://lore.kernel.org/intel-wired-lan/20250408134655.4287-1-przemyslaw.kits...@intel.com/
> - Add fixes tag (Michal K)
> - add missing braces (lkp bot), turns out it's hard to purge C++ from your
> mind
> - (no changes in the collision handling on 32bit systems)
>
> v2:
> https://lore.kernel.org/intel-wired-lan/20250407112005.85468-1-przemyslaw.kits...@intel.com/
> - target to -net (Jiri)
> - mix both halves of u64 DSN on 32bit systems (Jiri)
> - (no changes in terms of fallbacks for pre-prod HW)
> - warn when there is DSN collision after reducing to 32bit
>
> v1:
> https://lore.kernel.org/netdev/20250306211159.3697-2-przemyslaw.kits...@intel.com
> ---
> drivers/net/ethernet/intel/ice/ice_adapter.h | 6 ++-
> drivers/net/ethernet/intel/ice/ice_adapter.c | 47
> 2 files changed, 22 insertions(+), 31 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 1/2] ice: add link_down_events statistic
> -Original Message- > From: Intel-wired-lan On Behalf Of > Martyna Szapar-Mudlaw > Sent: 14 April 2025 18:30 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Martyna Szapar-Mudlaw > > Subject: [Intel-wired-lan] [PATCH iwl-next v2 1/2] ice: add link_down_events > statistic > > Introduce a link_down_events counter to the ice driver, incremented each time > the link transitions from up to down. > This counter can help diagnose issues related to link stability, such as port > flapping or unexpected link drops. > > The value is exposed via ethtool's get_link_ext_stats() interface. > > Signed-off-by: Martyna Szapar-Mudlaw > --- > drivers/net/ethernet/intel/ice/ice.h | 1 + > drivers/net/ethernet/intel/ice/ice_ethtool.c | 10 ++ > drivers/net/ethernet/intel/ice/ice_main.c| 3 +++ > 3 files changed, 14 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 1/4] igb: Link IRQs to NAPI instances
> -Original Message-
> From: Intel-wired-lan On Behalf Of Kurt
> Kanzenbach
> Sent: 17 February 2025 17:01
> To: Nguyen, Anthony L ; Kitszel, Przemyslaw
>
> Cc: Andrew Lunn ; David S. Miller
> ; Eric Dumazet ; Jakub Kicinski
> ; Paolo Abeni ; Sebastian Andrzej Siewior
> ; Damato, Joe ; Gerhard Engleder
> ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; Kurt Kanzenbach
> Subject: [Intel-wired-lan] [PATCH iwl-next v2 1/4] igb: Link IRQs to NAPI
> instances
>
> Link IRQs to NAPI instances via netdev-genl API. This allows users to query
> that information via netlink:
>
> |$ ./tools/net/ynl/pyynl/cli.py --spec
> Documentation/netlink/specs/netdev.yaml \
> | --dump napi-get --json='{"ifindex": 2}'
> |[{'defer-hard-irqs': 0,
> | 'gro-flush-timeout': 0,
> | 'id': 8204,
> | 'ifindex': 2,
> | 'irq': 127,
> | 'irq-suspend-timeout': 0},
> | {'defer-hard-irqs': 0,
> | 'gro-flush-timeout': 0,
> | 'id': 8203,
> | 'ifindex': 2,
> | 'irq': 126,
> | 'irq-suspend-timeout': 0},
> | {'defer-hard-irqs': 0,
> | 'gro-flush-timeout': 0,
> | 'id': 8202,
> | 'ifindex': 2,
> | 'irq': 125,
> | 'irq-suspend-timeout': 0},
> | {'defer-hard-irqs': 0,
> | 'gro-flush-timeout': 0,
> | 'id': 8201,
> | 'ifindex': 2,
> | 'irq': 124,
> | 'irq-suspend-timeout': 0}]
> |$ cat /proc/interrupts | grep enp2s0
> |123: 0 1 IR-PCI-MSIX-:02:00.0 0-edge enp2s0
> |124: 0 7 IR-PCI-MSIX-:02:00.0 1-edge
> enp2s0-TxRx-0
> |125: 0 0 IR-PCI-MSIX-:02:00.0 2-edge
> enp2s0-TxRx-1
> |126: 0 5 IR-PCI-MSIX-:02:00.0 3-edge
> enp2s0-TxRx-2
> |127: 0 0 IR-PCI-MSIX-:02:00.0 4-edge
> enp2s0-TxRx-3
>
> Reviewed-by: Joe Damato
> Signed-off-by: Kurt Kanzenbach
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 2/4] igb: Link queues to NAPI instances
> -Original Message-
> From: Intel-wired-lan On Behalf Of Kurt
> Kanzenbach
> Sent: 17 February 2025 17:01
> To: Nguyen, Anthony L ; Kitszel, Przemyslaw
>
> Cc: Andrew Lunn ; David S. Miller
> ; Eric Dumazet ; Jakub Kicinski
> ; Paolo Abeni ; Sebastian Andrzej Siewior
> ; Damato, Joe ; Gerhard Engleder
> ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; Kurt Kanzenbach
> Subject: [Intel-wired-lan] [PATCH iwl-next v2 2/4] igb: Link queues to NAPI
> instances
>
> Link queues to NAPI instances via netdev-genl API. This is required to use
> XDP/ZC busy polling. See commit 5ef44b3cb43b ("xsk: Bring back busy polling
support") for details.
>
> This also allows users to query the info with netlink:
>
> |$ ./tools/net/ynl/pyynl/cli.py --spec
> Documentation/netlink/specs/netdev.yaml \
> | --dump queue-get --json='{"ifindex": 2}'
> |[{'id': 0, 'ifindex': 2, 'napi-id': 8201, 'type': 'rx'},
> | {'id': 1, 'ifindex': 2, 'napi-id': 8202, 'type': 'rx'},
> | {'id': 2, 'ifindex': 2, 'napi-id': 8203, 'type': 'rx'},
> | {'id': 3, 'ifindex': 2, 'napi-id': 8204, 'type': 'rx'},
> | {'id': 0, 'ifindex': 2, 'napi-id': 8201, 'type': 'tx'},
> | {'id': 1, 'ifindex': 2, 'napi-id': 8202, 'type': 'tx'},
> | {'id': 2, 'ifindex': 2, 'napi-id': 8203, 'type': 'tx'},
> | {'id': 3, 'ifindex': 2, 'napi-id': 8204, 'type': 'tx'}]
>
> Add rtnl locking to PCI error handlers, because netif_queue_set_napi()
> requires the lock held.
>
> While at __igb_open() use RCT coding style.
>
> Signed-off-by: Kurt Kanzenbach
> ---
> drivers/net/ethernet/intel/igb/igb.h | 2 ++
> drivers/net/ethernet/intel/igb/igb_main.c | 43
> +++ drivers/net/ethernet/intel/igb/igb_xsk.c |
> 2 ++
> 3 files changed, 42 insertions(+), 5 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 3/4] igb: Add support for persistent NAPI config
> -Original Message- > From: Intel-wired-lan On Behalf Of Kurt > Kanzenbach > Sent: 17 February 2025 17:01 > To: Nguyen, Anthony L ; Kitszel, Przemyslaw > > Cc: Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub Kicinski > ; Paolo Abeni ; Sebastian Andrzej Siewior > ; Damato, Joe ; Gerhard Engleder > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; Kurt Kanzenbach > Subject: [Intel-wired-lan] [PATCH iwl-next v2 3/4] igb: Add support for > persistent NAPI config > > Use netif_napi_add_config() to assign persistent per-NAPI config. > > This is useful for preserving NAPI settings when changing queue counts or for > user space programs using SO_INCOMING_NAPI_ID. > > Signed-off-by: Kurt Kanzenbach > --- > drivers/net/ethernet/intel/igb/igb_main.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v6] ice: Add E830 checksum offload support
> -Original Message- > From: Intel-wired-lan On Behalf Of Paul > Greenwalt > Sent: 18 December 2024 14:42 > To: intel-wired-...@lists.osuosl.org > Cc: k...@kernel.org; net...@vger.kernel.org; Greenwalt, Paul > ; Alice Michael ; Eric > Joyner > Subject: [Intel-wired-lan] [PATCH iwl-next v6] ice: Add E830 checksum offload > support > > E830 supports raw receive and generic transmit checksum offloads. > > Raw receive checksum support is provided by hardware calculating the checksum > over the whole packet, regardless of type. The calculated checksum is > provided to driver in the Rx flex descriptor. Then the driver assigns the > checksum to skb->csum and sets skb->ip_summed to CHECKSUM_COMPLETE. > > Generic transmit checksum support is provided by hardware calculating the > checksum given two offsets: the start offset to begin checksum calculation, > and the offset to insert the calculated checksum in the packet. Support is > advertised to the stack using NETIF_F_HW_CSUM feature. > > E830 has the following limitations when both generic transmit checksum > offload and TCP Segmentation Offload (TSO) are enabled: > > 1. Inner packet header modification is not supported. This restriction > includes the inability to alter TCP flags, such as the push flag. As a > result, this limitation can impact the receiver's ability to coalesce > packets, potentially degrading network throughput. > 2. The Maximum Segment Size (MSS) is limited to 1023 bytes, which prevents > support of Maximum Transmission Unit (MTU) greater than 1063 bytes. > > Therefore NETIF_F_HW_CSUM and NETIF_F_ALL_TSO features are mutually > exclusive. NETIF_F_HW_CSUM hardware feature support is indicated but is not > enabled by default. Instead, IP checksums and NETIF_F_ALL_TSO are > the > defaults. Enforcement of mutual exclusivity of NETIF_F_HW_CSUM and > NETIF_F_ALL_TSO is done in ice_set_features(). Mutual exclusivity of IP > checksums and NETIF_F_HW_CSUM is handled by netdev_fix_features(). > > When NETIF_F_HW_CSUM is requested the provided skb->csum_start and > skb->csum_offset are passed to hardware in the Tx context descriptor > generic checksum (GCS) parameters. Hardware calculates the 1's complement > from skb->csum_start to the end of the packet, and inserts the result in the > packet at skb->csum_offset. > > Co-developed-by: Alice Michael > Signed-off-by: Alice Michael > Co-developed-by: Eric Joyner > Signed-off-by: Eric Joyner > Signed-off-by: Paul Greenwalt > --- > Changelog: > v1->v2 > - Update commit message with additional details. > - Add newlines, and add params around > - Return early from ice_fix_features() to avoid extra indentation and > large if block. > - Move and change some defines. > - replace htons and le16_t_cpu with swap16. > - Use FIELD_PREP where possible. > - Removed checksum valid bit check STATUS1_L2TAG2P_S. This check is not > needed since there is no situation which will return an error. > v2->v3 > - Minor fixes in commit message. > - Removed unused register defines in ice_hw_autogen.h. > - Moved GCS and TSO feature fix to helper function > ice_fix_features_gcs(), and updated logic. > - Update to align naming with related flags. > v3->v4 > - Move a check for GCS and TSO mutual exclusivity from > ice_fix_features() to ice_set_features(). > v4->v5 > - Remove lingering GCS and TSO mutual exclusivity comments and code in > ice_fix_features(). > - Remove unused variable ICE_TX_FLAGS_RING_GCS. > - Remove Tested-by and Signed-off-by tag due to changes to patch. > - Use ICE_TX_GCS_DESC_TYPE_M and ICE_TX_GCS_DESC_CSUM_PSH in > ice_tx_csum() to set the GCS decriptor field type. > v5->v6 > - Fix build error. > --- > drivers/net/ethernet/intel/ice/ice.h | 1 + > .../net/ethernet/intel/ice/ice_lan_tx_rx.h| 9 +-- > drivers/net/ethernet/intel/ice/ice_lib.c | 8 +- > drivers/net/ethernet/intel/ice/ice_main.c | 18 + > drivers/net/ethernet/intel/ice/ice_txrx.c | 27 ++- > drivers/net/ethernet/intel/ice/ice_txrx.h | 2 ++ > drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 26 ++ > 7 files changed, 87 insertions(+), 4 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v1] ice: fix memory leak in aRFS after reset
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Grzegorz Nitka
> Sent: 23 January 2025 13:46
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Michal Swiatkowski
>
> Subject: [Intel-wired-lan] [PATCH iwl-net v1] ice: fix memory leak in aRFS
> after reset
>
> Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding
> a checker to verify if aRFS memory is already allocated while configuring
> VSI. aRFS objects are allocated in two cases:
> - as part of VSI initialization (at probe), and
> - as part of reset handling
>
> However, VSI reconfiguration executed during reset involves memory allocation
> one more time, without prior releasing already allocated resources. This led
> to the memory leak with the following signature:
>
> [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object
> 0xff3c1ca7252e6000 (size 8192):
> comm "kworker/0:0", pid 8, jiffies 4296833052
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace (crc 0):
>[] __kmalloc_cache_noprof+0x275/0x340
>[] ice_init_arfs+0x3a/0xe0 [ice]
>[] ice_vsi_cfg_def+0x607/0x850 [ice]
>[] ice_vsi_setup+0x5b/0x130 [ice]
>[] ice_init+0x1c1/0x460 [ice]
>[] ice_probe+0x2af/0x520 [ice]
> [] local_pci_probe+0x43/0xa0
> [] work_for_cpu_fn+0x13/0x20
> [] process_one_work+0x179/0x390
> [] worker_thread+0x239/0x340
> [] kthread+0xcc/0x100
> [] ret_from_fork+0x2d/0x50
> [] ret_from_fork_asm+0x1a/0x30
> ...
>
> Fixes: 28bf26724fdb ("ice: Implement aRFS")
> Reviewed-by: Michal Swiatkowski
> Signed-off-by: Grzegorz Nitka
> ---
> drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 1/3] ice: rename ice_ptp_init_phc_eth56g function
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 10 February 2025 19:41 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > Nguyen, Anthony L ; ho...@kernel.org; Kitszel, > Przemyslaw > Subject: [Intel-wired-lan] [PATCH iwl-next v2 1/3] ice: rename > ice_ptp_init_phc_eth56g function > > From: Karol Kolacinski > > Refactor the code by changing ice_ptp_init_phc_eth56g function name to > ice_ptp_init_phc_e825, to be consistent with the naming pattern for other > devices. > > Signed-off-by: Karol Kolacinski > Signed-off-by: Grzegorz Nitka > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] ice: E825C PHY register cleanup
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 10 February 2025 19:41 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > Nguyen, Anthony L ; ho...@kernel.org; Kitszel, > Przemyslaw > Subject: [Intel-wired-lan] [PATCH iwl-next v2 3/3] ice: E825C PHY register > cleanup > > From: Karol Kolacinski > > Minor PTP register refactor, including logical grouping E825C 1-step > timestamping registers. Remove unused register definitions > (PHY_REG_GPCS_BITSLIP, PHY_REG_REVISION). > Also, apply preferred GENMASK macro (instead of ICE_M) for register fields > definition affected by this patch. > > Reviewed-by: Simon Horman > Reviewed-by: Przemek Kitszel > Signed-off-by: Karol Kolacinski > Signed-off-by: Grzegorz Nitka > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 31 ++--- > 1 file changed, 14 insertions(+), 17 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 2/3] ice: Refactor E825C PHY registers info struct
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 10 February 2025 19:41 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > Nguyen, Anthony L ; ho...@kernel.org; Kitszel, > Przemyslaw > Subject: [Intel-wired-lan] [PATCH iwl-next v2 2/3] ice: Refactor E825C PHY > registers info struct > > From: Karol Kolacinski > > Simplify ice_phy_reg_info_eth56g struct definition to include base address > for the very first quad. Use base address info and 'step' value to determine address for specific PHY quad. > > Reviewed-by: Przemek Kitszel > Signed-off-by: Karol Kolacinski > Signed-off-by: Grzegorz Nitka > --- > .../net/ethernet/intel/ice/ice_ptp_consts.h | 75 --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 6 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 4 +- > 3 files changed, 20 insertions(+), 65 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH][next][V2] ice: make const read-only array dflt_rules static
> -Original Message- > From: Intel-wired-lan On Behalf Of Colin > Ian King > Sent: 17 March 2025 22:50 > To: Nguyen, Anthony L ; Kitszel, Przemyslaw > ; Andrew Lunn ; David S > . Miller ; Dumazet, Eric ; Jakub > Kicinski ; Paolo Abeni ; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][next][V2] ice: make const read-only array > dflt_rules static > > Don't populate the const read-only array dflt_rules on the stack at run time, > instead make it static. > > Signed-off-by: Colin Ian King > > --- > V2: Remove additional changes not related to this commit. > --- > drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v3 2/3] ice: refactor ice_sbq_msg_dev enum
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 20 March 2025 18:46 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > ho...@kernel.org; Kitszel, Przemyslaw > Subject: [Intel-wired-lan] [PATCH iwl-next v3 2/3] ice: refactor > ice_sbq_msg_dev enum > > From: Karol Kolacinski > > Rename ice_sbq_msg_dev to ice_sbq_dev_id to reflect the meaning of this type > more precisely. This enum type describes RDA (Remote Device Access) client > ids, accessible over SB (Side Band) interface. > Rename enum elements to make a driver namespace more cleaner and consistent > with other definitions within SB Remove unused 'rmn_x' entries, specific to > unsupported E824 device. > Adjust clients '2' and '13' names (phy_0 and phy_0_peer respectively) to be > compliant with EAS doc. According to the specification, regardless of the > complex entity (single or dual), when accessing its own ports, they're > accessed always as 'phy_0' client. And referred as 'phy_0_peer' when handling ports conneced to the other complex. > > Reviewed-by: Simon Horman > Reviewed-by: Przemek Kitszel > Signed-off-by: Karol Kolacinski > Co-developed-by: Grzegorz Nitka > Signed-off-by: Grzegorz Nitka > --- > drivers/net/ethernet/intel/ice/ice_common.c | 2 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 20 ++-- > drivers/net/ethernet/intel/ice/ice_sbq_cmd.h | 11 --- > 3 files changed, 15 insertions(+), 18 deletions(-) Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v3 3/3] ice: enable timesync operation on 2xNAC E825 devices
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 20 March 2025 18:46 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > ho...@kernel.org; Kitszel, Przemyslaw > Subject: [Intel-wired-lan] [PATCH iwl-next v3 3/3] ice: enable timesync > operation on 2xNAC E825 devices > > From: Karol Kolacinski > > According to the E825C specification, SBQ address for ports on a single > complex is device 2 for PHY 0 and device 13 for PHY1. > For accessing ports on a dual complex E825C (so called 2xNAC mode), the > driver should use destination device 2 (referred as phy_0) for the current > complex PHY and device 13 (referred as phy_0_peer) for peer complex PHY. > > Differentiate SBQ destination device by checking if current PF port number is > on the same PHY as target port number. > > Adjust 'ice_get_lane_number' function to provide unique port number for ports > from PHY1 in 'dual' mode config (by adding fixed offset for PHY1 ports). > Cache this value in ice_hw struct. > > Introduce ice_get_primary_hw wrapper to get access to timesync register not > available from second NAC. > > Reviewed-by: Simon Horman > Reviewed-by: Przemek Kitszel > Signed-off-by: Karol Kolacinski > Co-developed-by: Grzegorz Nitka > Signed-off-by: Grzegorz Nitka > --- > drivers/net/ethernet/intel/ice/ice.h| 60 - > drivers/net/ethernet/intel/ice/ice_common.c | 6 ++- > drivers/net/ethernet/intel/ice/ice_ptp.c| 49 - > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 39 +++--- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 5 -- > drivers/net/ethernet/intel/ice/ice_type.h | 1 + > 6 files changed, 134 insertions(+), 26 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v3 1/3] ice: remove SW side band access workaround for E825
> -Original Message- > From: Intel-wired-lan On Behalf Of > Grzegorz Nitka > Sent: 20 March 2025 18:46 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > ho...@kernel.org; Kitszel, Przemyslaw ; Michal > Swiatkowski > Subject: [Intel-wired-lan] [PATCH iwl-next v3 1/3] ice: remove SW side band > access workaround for E825 > > From: Karol Kolacinski > > Due to the bug in FW/NVM autoload mechanism (wrong default SB_REM_DEV_CTL > register settings), the access to peer PHY and CGU clients was disabled by > default. > > As the workaround solution, the register value was overwritten by the driver > at the probe or reset handling. > Remove workaround as it's not needed anymore. The fix in autoload procedure > has been provided with NVM 3.80 version. > > NOTE: at the time the fix was provided in NVM, the E825C product was not > officially available on the market, so it's not expected this change will > cause regression when running with older driver/kernel versions. > > Reviewed-by: Michal Swiatkowski > Reviewed-by: Przemek Kitszel > Signed-off-by: Karol Kolacinski > Signed-off-by: Grzegorz Nitka > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 23 - > 1 file changed, 23 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v3] ice: add E830 Earliest TxTime First Offload support
> -Original Message- > From: Intel-wired-lan On Behalf Of Paul > Greenwalt > Sent: 13 March 2025 19:16 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Greenwalt, Paul ; > Loktionov, Aleksandr > Subject: [Intel-wired-lan] [PATCH iwl-next v3] ice: add E830 Earliest TxTime > First Offload support > > E830 supports Earliest TxTime First (ETF) hardware offload, which is > configured via the ETF Qdisc (see tc-etf(8)). ETF introduces a new Tx flow > mechanism that utilizes a timestamp ring (tstamp_ring) alongside the standard > Tx ring. This timestamp ring is used to indicate when hardware will transmit > a packet. > > The allocation and initialization of the timestamp ring occur when the > feature is enabled via tc-etf. Since the timestamp ring and Tx ring are > tightly coupled, both must be configured simultaneously. > > To support ETF, the following flags are introduced: > > - ICE_F_TXTIME: Device feature flag set for E830 NICs, indicating ETF support. > - ICE_FLAG_TXTIME: PF-level flag indicating whether ETF is enabled on any Tx queue. It is checked during ring allocation to determine if timestamp rings should be allocated and is also referenced when modifying queue count via ethtool -G. > - ICE_TX_FLAGS_TXTIME: Per-ring flag set when ETF is enabled and cleared when disabled for a specific Tx queue. It helps determine ETF status when transmitting timestamped packets and is used by ice_is_txtime_ena() to check if ETF is enabled on any Tx queue. > > Due to a hardware issue that can result in a malicious driver detection > event, additional timestamp descriptors are required when wrapping the > timestamp ring. Up to 64 additional timestamp descriptors are reserved, > reducing the available Tx descriptors. > > To accommodate this, ICE_MAX_NUM_DESC_BY_MAC is introduced, defining: > > - E830: Maximum Tx descriptor length of 8096 (8K - 32 - 64 for timestamp fetch descriptors). > - E810 and E82X: Maximum Tx descriptor length of 8160 (8K - 32) . > > Reviewed-by: Aleksandr Loktionov > Co-developed-by: Alice Michael > Signed-off-by: Alice Michael > Signed-off-by: Paul Greenwalt > --- > Changelog: > v2->v3: > - Fix const compiler warning. > - Fix spelling error in function header. > - Fix Changelog verions number. > v1->v2: > - Resolve patch apply isue. > - Fixes RCT, zero struct initialization, move bailout condition to top of function, removed unnecessary newlines, and added use of str_enable_disable. > v1: > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20250227111333.30675-1-paul.greenw...@intel.com/ > --- > drivers/net/ethernet/intel/ice/ice.h | 9 +- > .../net/ethernet/intel/ice/ice_adminq_cmd.h | 53 + > drivers/net/ethernet/intel/ice/ice_base.c | 212 +++--- > drivers/net/ethernet/intel/ice/ice_base.h | 1 + > drivers/net/ethernet/intel/ice/ice_common.c | 118 ++ > drivers/net/ethernet/intel/ice/ice_common.h | 10 + > drivers/net/ethernet/intel/ice/ice_ethtool.c | 61 - > .../net/ethernet/intel/ice/ice_hw_autogen.h | 3 + > .../net/ethernet/intel/ice/ice_lan_tx_rx.h| 42 > drivers/net/ethernet/intel/ice/ice_lib.c | 45 +++- > drivers/net/ethernet/intel/ice/ice_main.c | 174 +- > drivers/net/ethernet/intel/ice/ice_txrx.c | 129 ++- > drivers/net/ethernet/intel/ice/ice_txrx.h | 4 + > drivers/net/ethernet/intel/ice/ice_txrx_lib.h | 14 ++ > drivers/net/ethernet/intel/ice/ice_virtchnl.c | 2 +- > 15 files changed, 823 insertions(+), 54 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v3 1/8] ice, libie: move generic adminq descriptors to lib
> -Original Message- > From: Intel-wired-lan On Behalf Of > Michal Swiatkowski > Sent: 25 April 2025 11:38 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Lobakin, Aleksander > ; Kitszel, Przemyslaw > ; Kwapulinski, Piotr > ; Loktionov, Aleksandr > ; Jagielski, Jedrzej > ; Zaremba, Larysa ; > Nguyen, Anthony L > Subject: [Intel-wired-lan] [iwl-next v3 1/8] ice, libie: move generic adminq > descriptors to lib > > The descriptor structure is the same in ice, ixgbe and i40e. Move it to common libie header to use it across different driver. > > Leave device specific adminq commands in separate folders. This lead to a change that need to be done in filling/getting descriptor: > - previous: struct specific_desc *cmd; cmd = &desc.params.specific_desc; > - now: struct specific_desc *cmd; cmd = libie_aq_raw(&desc); > > Do this changes across the driver to allow clean build. The casting only have to be done in case of specific descriptors, for generic one union can still be used. > > Changes beside code moving: > - change ICE_ prefix to LIBIE_ prefix (ice_ and libie_ too) > - remove shift variables not otherwise needed (in libie_aq_flags) > - fill/get descriptor data based on desc.params.raw whenever the descriptor isn't defined in libie > - move defines from the libie_aq_sth structure outside > - add libie_aq_raw helper and use it instead of explicit casting > > Reviewed by: Przemek Kitszel > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Michal Swiatkowski > --- > drivers/net/ethernet/intel/ice/ice.h | 2 +- > .../net/ethernet/intel/ice/ice_adminq_cmd.h | 270 +--- > drivers/net/ethernet/intel/ice/ice_common.h | 6 +- > drivers/net/ethernet/intel/ice/ice_controlq.h | 8 +- > include/linux/net/intel/libie/adminq.h| 272 > .../net/ethernet/intel/ice/devlink/health.c | 4 +- > drivers/net/ethernet/intel/ice/ice_common.c | 390 +- > drivers/net/ethernet/intel/ice/ice_controlq.c | 53 +-- > drivers/net/ethernet/intel/ice/ice_dcb.c | 36 +- > drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 2 +- > drivers/net/ethernet/intel/ice/ice_ddp.c | 47 +-- > .../net/ethernet/intel/ice/ice_fw_update.c| 24 +- > drivers/net/ethernet/intel/ice/ice_fwlog.c| 16 +- > drivers/net/ethernet/intel/ice/ice_lag.c | 4 +- > drivers/net/ethernet/intel/ice/ice_lib.c | 6 +- > drivers/net/ethernet/intel/ice/ice_main.c | 34 +- > drivers/net/ethernet/intel/ice/ice_nvm.c | 38 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 20 +- > drivers/net/ethernet/intel/ice/ice_sched.c| 18 +- > drivers/net/ethernet/intel/ice/ice_sriov.c| 4 +- > drivers/net/ethernet/intel/ice/ice_switch.c | 55 +-- > drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 6 +- > drivers/net/ethernet/intel/ice/ice_virtchnl.c | 2 +- > .../net/ethernet/intel/ice/ice_vlan_mode.c| 6 +- > 24 files changed, 673 insertions(+), 650 deletions(-) > create mode 100644 include/linux/net/intel/libie/adminq.h > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v3 6/8] ice: use libie_aq_str
> -Original Message- > From: Intel-wired-lan On Behalf Of > Michal Swiatkowski > Sent: 25 April 2025 11:38 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Lobakin, Aleksander > ; Kitszel, Przemyslaw > ; Kwapulinski, Piotr > ; Loktionov, Aleksandr > ; Jagielski, Jedrzej > ; Zaremba, Larysa ; > Nguyen, Anthony L > Subject: [Intel-wired-lan] [iwl-next v3 6/8] ice: use libie_aq_str > > Simple: > s/ice_aq_str/libie_aq_str > > Add libie_aminq module in ice Kconfig. > > Reviewed-by: Przemek Kitszel > Signed-off-by: Michal Swiatkowski > --- > drivers/net/ethernet/intel/Kconfig| 1 + > drivers/net/ethernet/intel/ice/ice.h | 1 - > .../net/ethernet/intel/ice/devlink/devlink.c | 10 +-- > .../net/ethernet/intel/ice/devlink/health.c | 2 +- > drivers/net/ethernet/intel/ice/ice_dpll.c | 20 +++--- > drivers/net/ethernet/intel/ice/ice_ethtool.c | 12 ++-- > .../net/ethernet/intel/ice/ice_fw_update.c| 20 +++--- > drivers/net/ethernet/intel/ice/ice_lib.c | 4 +- > drivers/net/ethernet/intel/ice/ice_main.c | 69 +++ > drivers/net/ethernet/intel/ice/ice_virtchnl.c | 4 +- > .../net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 24 +++ > 11 files changed, 59 insertions(+), 108 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v3 8/8] i40e: use libie_aq_str
> -Original Message- > From: Intel-wired-lan On Behalf Of > Michal Swiatkowski > Sent: 25 April 2025 11:38 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Lobakin, Aleksander > ; Kitszel, Przemyslaw > ; Kwapulinski, Piotr > ; Loktionov, Aleksandr > ; Jagielski, Jedrzej > ; Zaremba, Larysa ; > Nguyen, Anthony L > Subject: [Intel-wired-lan] [iwl-next v3 8/8] i40e: use libie_aq_str > > There is no need to store the err string in hw->err_str. Simplify it and use > common helper. hw->err_str is still used for other purpouse. > > It should be marked that previously for unknown error the numeric value was > passed as a string. Now the "LIBIE_AQ_RC_UNKNOWN" is used for such cases. > > Add libie_aminq module in i40e Kconfig. > > Reviewed-by: Przemek Kitszel > Reviewed-by: Larysa Zaremba > Signed-off-by: Michal Swiatkowski > --- > drivers/net/ethernet/intel/Kconfig| 1 + > .../net/ethernet/intel/i40e/i40e_prototype.h | 1 - > drivers/net/ethernet/intel/i40e/i40e_client.c | 7 +- > drivers/net/ethernet/intel/i40e/i40e_common.c | 52 - > drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c | 8 +- > .../net/ethernet/intel/i40e/i40e_ethtool.c| 22 +- > drivers/net/ethernet/intel/i40e/i40e_main.c | 209 +++--- > drivers/net/ethernet/intel/i40e/i40e_nvm.c| 2 +- > .../ethernet/intel/i40e/i40e_virtchnl_pf.c| 27 +-- > 9 files changed, 105 insertions(+), 224 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v3 2/8] ixgbe: use libie adminq descriptors
> -Original Message- > From: Intel-wired-lan On Behalf Of > Michal Swiatkowski > Sent: 25 April 2025 11:38 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Lobakin, Aleksander > ; Kitszel, Przemyslaw > ; Kwapulinski, Piotr > ; Loktionov, Aleksandr > ; Jagielski, Jedrzej > ; Zaremba, Larysa ; > Nguyen, Anthony L > Subject: [Intel-wired-lan] [iwl-next v3 2/8] ixgbe: use libie adminq > descriptors > > Use libie_aq_desc instead of ixgbe_aci_desc. Do needed changes to allow clean > build. > > Move additional caps used in ixgbe to libie. > > Reviewed-by: Przemek Kitszel > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Michal Swiatkowski > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.h | 12 +- > .../ethernet/intel/ixgbe/ixgbe_type_e610.h| 226 +-- > include/linux/net/intel/libie/adminq.h| 16 ++ > .../net/ethernet/intel/ixgbe/devlink/region.c | 4 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 272 +- > .../ethernet/intel/ixgbe/ixgbe_fw_update.c| 4 +- > 6 files changed, 167 insertions(+), 367 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v3 3/8] i40e: use libie adminq descriptors
> -Original Message- > From: Intel-wired-lan On Behalf Of > Michal Swiatkowski > Sent: 25 April 2025 11:38 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Lobakin, Aleksander > ; Kitszel, Przemyslaw > ; Kwapulinski, Piotr > ; Loktionov, Aleksandr > ; Jagielski, Jedrzej > ; Zaremba, Larysa ; > Nguyen, Anthony L > Subject: [Intel-wired-lan] [iwl-next v3 3/8] i40e: use libie adminq > descriptors > > Use libie_aq_desc instead of i40e_aq_desc. Do needed changes to allow clean build. > > Get version descriptor is a little less detailed on i40e. To not mess up with shifting or union inside libie desc use get version descriptor from i40e. > > Move additional caps for i40e to libie. > > Fix RCT in declaration that is using libie_aq_desc; > > Use libie_aq_raw() wherever it can be used. > > The libie aq error is extended, cover it in ice driver just to clean build. In next patches the libie code for that will be used in each of intel driver. > > Reviewed-by: Przemek Kitszel > Signed-off-by: Michal Swiatkowski > --- > drivers/net/ethernet/intel/i40e/i40e_adminq.h | 12 +- > .../net/ethernet/intel/i40e/i40e_adminq_cmd.h | 155 +--- > .../net/ethernet/intel/i40e/i40e_prototype.h | 16 +- > drivers/net/ethernet/intel/i40e/i40e_type.h | 6 +- > include/linux/net/intel/libie/adminq.h| 19 + > drivers/net/ethernet/intel/i40e/i40e_adminq.c | 68 +- > drivers/net/ethernet/intel/i40e/i40e_common.c | 754 +- > drivers/net/ethernet/intel/i40e/i40e_dcb.c| 10 +- > .../net/ethernet/intel/i40e/i40e_debugfs.c| 46 +- > .../net/ethernet/intel/i40e/i40e_ethtool.c| 14 +- > drivers/net/ethernet/intel/i40e/i40e_main.c | 31 +- > drivers/net/ethernet/intel/i40e/i40e_nvm.c| 16 +- > drivers/net/ethernet/intel/ice/ice_main.c | 8 + > 13 files changed, 505 insertions(+), 650 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v4 2/2] ixgbe: add link_down_events statistic
> -Original Message- > From: Intel-wired-lan On Behalf Of > Martyna Szapar-Mudlaw > Sent: 15 May 2025 16:20 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; k...@kernel.org; > dawid.osuchow...@linux.intel.com; pmen...@molgen.mpg.de; Martyna > Szapar-Mudlaw ; Kory Maincent > ; Loktionov, Aleksandr > > Subject: [Intel-wired-lan] [PATCH iwl-next v4 2/2] ixgbe: add > link_down_events statistic > > Introduce a link_down_events counter to the ixgbe driver, incremented each > time the link transitions from up to down. > This counter can help diagnose issues related to link stability, such as port > flapping or unexpected link drops. > > The value is exposed via ethtool's get_link_ext_stats() interface. > > Reviewed-by: Kory Maincent > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Martyna Szapar-Mudlaw > --- > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 + > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 10 ++ > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c| 2 ++ > 3 files changed, 13 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next] i40e: add link_down_events statistic
> -Original Message- > From: Intel-wired-lan On Behalf Of Dawid > Osuchowski > Sent: 21 May 2025 19:54 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Dawid Osuchowski > ; Martyna Szapar-Mudlaw > ; Michal Swiatkowski > > Subject: [Intel-wired-lan] [PATCH iwl-next] i40e: add link_down_events > statistic > > Introduce a link_down_events counter to the i40e driver, incremented each > time the link transitions from up to down. > This counter can help diagnose issues related to link stability, such as port > flapping or unexpected link drops. > > The value is exposed via ethtool's get_link_ext_stats() interface. > > Co-developed-by: Martyna Szapar-Mudlaw > Signed-off-by: Martyna Szapar-Mudlaw > Reviewed-by: Michal Swiatkowski > Signed-off-by: Dawid Osuchowski > --- > Based on series [1] from Martyna where this was implemented for ixgbe and ice > drivers. > > [1] > https://lore.kernel.org/netdev/20250515105011.1310692-1-martyna.szapar-mud...@linux.intel.com/ > --- > drivers/net/ethernet/intel/i40e/i40e.h | 1 + > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 10 ++ > drivers/net/ethernet/intel/i40e/i40e_main.c| 3 +++ > 3 files changed, 14 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v5 1/3] ice: redesign dpll sma/u.fl pins control
> -Original Message- > From: Intel-wired-lan On Behalf Of > Arkadiusz Kubalewski > Sent: 22 April 2025 21:32 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz > ; Kitszel, Przemyslaw > > Subject: [Intel-wired-lan] [PATCH iwl-next v5 1/3] ice: redesign dpll > sma/u.fl pins control > > DPLL-enabled E810 NIC driver provides user with list of input and output > pins. Hardware internal design impacts user control over SMA and U.FL pins. > Currently end-user view on those dpll pins doesn't provide any layer of > abstraction. On the hardware level SMA and U.FL pins are tied together due to > existence of direction control logic for each pair: > - SMA1 (bi-directional) and U.FL1 (only output) > - SMA2 (bi-directional) and U.FL2 (only input) The user activity on each pin > of the pair may impact the state of the other. > > Previously all the pins were provided to the user as is, without the control > over SMA pins direction. > > Introduce a software controlled layer of abstraction over external board > pins, instead of providing the user with access to raw pins connected to the > dpll: > - new software controlled SMA and U.FL pins, > - callback operations directing user requests to corresponding hardware pins according to the runtime configuration, > - ability to control SMA pins direction. > > Reviewed-by: Przemek Kitszel > Signed-off-by: Arkadiusz Kubalewski > --- > v5: > - stop pins unregister for not present SW pins @E810-LOM NIC. > --- > drivers/net/ethernet/intel/ice/ice_dpll.c | 927 +++- > drivers/net/ethernet/intel/ice/ice_dpll.h | 23 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 + > 3 files changed, 936 insertions(+), 15 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v5 3/3] ice: add ice driver PTP pin documentation
> -Original Message- > From: Intel-wired-lan On Behalf Of > Arkadiusz Kubalewski > Sent: 22 April 2025 21:32 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > Olech, Milena ; Kubalewski, Arkadiusz > > Subject: [Intel-wired-lan] [PATCH iwl-next v5 3/3] ice: add ice driver PTP > pin documentation > > From: Karol Kolacinski > > Add a description of PTP pins support by the adapters to ice driver > documentation. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > Signed-off-by: Arkadiusz Kubalewski > --- > v5: > - no change. > --- > .../device_drivers/ethernet/intel/ice.rst | 13 + > 1 file changed, 13 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v5 2/3] ice: change SMA pins to SDP in PTP API
> -Original Message- > From: Intel-wired-lan On Behalf Of > Arkadiusz Kubalewski > Sent: 22 April 2025 21:32 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Kolacinski, Karol ; > Olech, Milena ; Kubalewski, Arkadiusz > > Subject: [Intel-wired-lan] [PATCH iwl-next v5 2/3] ice: change SMA pins to > SDP in PTP API > > From: Karol Kolacinski > > This change aligns E810 PTP pin control to all other products. > > Currently, SMA/U.FL port expanders are controlled together with SDP pins > connected to 1588 clock. To align this, separate this control by exposing > only SDP20..23 pins in PTP API on adapters with DPLL. > > Clear error for all E810 on absent NVM pin section or other errors to allow > proper initialization on SMA E810 with NVM section. > > Use ARRAY_SIZE for pin array instead of internal definition. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > Signed-off-by: Arkadiusz Kubalewski > --- > v5: > - no change. > --- > drivers/net/ethernet/intel/ice/ice_ptp.c | 254 --- > drivers/net/ethernet/intel/ice/ice_ptp.h | 3 - > 2 files changed, 39 insertions(+), 218 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 02/15] ice: rename TSPLL and CGU functions and definitions
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 02/15] ice: rename TSPLL and CGU > functions and definitions > > From: Karol Kolacinski > > Rename TSPLL and CGU functions, definitions etc. to match the file name and > have consistent naming scheme. > > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_common.h | 36 +-- > drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 16 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 11 +- > drivers/net/ethernet/intel/ice/ice_tspll.h | 32 +-- > drivers/net/ethernet/intel/ice/ice_type.h | 20 +- > drivers/net/ethernet/intel/ice/ice_common.c | 28 +- > drivers/net/ethernet/intel/ice/ice_ptp.c| 2 +- > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 4 +- > drivers/net/ethernet/intel/ice/ice_tspll.c | 350 > 9 files changed, 244 insertions(+), 255 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 03/15] ice: fix E825-C TSPLL register definitions
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, > Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 03/15] ice: fix E825-C TSPLL register > definitions > > The E825-C hardware has a slightly different register layout for register 19 of the Clock Generation Unit and TSPLL. The fbdiv_intgr value can be 10 bits wide. > > Additionally, most of the fields that were in register 24 are made available > in register 23 instead. The programming logic already has a corrected > definition for register 23, but it incorrectly still used the 8-bit > definition of fbdiv_intgr. This results in truncating some of the values of > fbdiv_intgr, including the value used for the 156.25MHz signal. > > The driver only used register 24 to obtain the enable status, which we should > read from register 23. This results in an incorrect output for the log > messages, but does not change any functionality besides disabled-by-default > dynamic debug messages. > > Fix the register definitions, and adjust the code to properly reflect the > enable/disable status in the log messages. > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/ice/ice_common.h | 17 - > drivers/net/ethernet/intel/ice/ice_tspll.c | 17 +++-- > 2 files changed, 23 insertions(+), 11 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 04/15] ice: remove ice_tspll_params_e825 definitions
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, > Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 04/15] ice: remove ice_tspll_params_e825 > definitions > > From: Karol Kolacinski > > Remove ice_tspll_params_e825 definitions as according to EDS (Electrical > Design Specification) doc, E825 devices support only 156.25 MHz TSPLL > frequency for both TCXO and TIME_REF clock source. > > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.h | 21 +- > drivers/net/ethernet/intel/ice/ice_tspll.c | 107 +++-- > 2 files changed, 11 insertions(+), 117 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 05/15] ice: use designated initializers for TSPLL consts
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 05/15] ice: use designated initializers > for TSPLL consts > > From: Karol Kolacinski > > Instead of multiple comments, use designated initializers for TSPLL consts. > > Adjust ice_tspll_params_e82x fields sizes. > > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.h | 8 +-- > drivers/net/ethernet/intel/ice/ice_tspll.c | 95 ++ > 2 files changed, 34 insertions(+), 69 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 06/15] ice: add TSPLL log config helper
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 06/15] ice: add TSPLL log config helper > > From: Karol Kolacinski > > Add a helper function to print new/current TSPLL config. This helps avoid > unnecessary casts from u8 to enums. > > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 54 +- > 1 file changed, 30 insertions(+), 24 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 07/15] ice: add ICE_READ/WRITE_CGU_REG_OR_DIE helpers
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 07/15] ice: add > ICE_READ/WRITE_CGU_REG_OR_DIE helpers > > From: Karol Kolacinski > > Add ICE_READ_CGU_REG_OR_DIE() and ICE_WRITE_CGU_REG_OR_DIE() helpers to avoid > multiple error checks after calling read/write functions. > > Suggested-by: Przemek Kitszel > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_common.h | 15 +++ > drivers/net/ethernet/intel/ice/ice_tspll.c | 160 ++-- > 2 files changed, 47 insertions(+), 128 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 08/15] ice: clear time_sync_en field for E825-C during reprogramming
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 08/15] ice: clear time_sync_en field for > E825-C during reprogramming > > When programming the Clock Generation Unit for E285-C hardware, we need to > clear the time_sync_en bit of the DWORD 9 before we set the frequency. > > Co-developed-by: Karol Kolacinski > Signed-off-by: Karol Kolacinski > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 6 ++ > 1 file changed, 6 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 09/15] ice: read TSPLL registers again before reporting status
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 09/15] ice: read TSPLL registers again > before reporting status > > After programming the TSPLL, re-read the registers before reporting status. > This ensures the debug log message will show what was actually programmed, > rather than relying on a cached value. > > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 10/15] ice: use bitfields instead of unions for CGU regs
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 10/15] ice: use bitfields instead of > unions for CGU regs > > From: Karol Kolacinski > > Switch from unions with bitfield structs to definitions with bitfield masks. > This is necessary, because some registers have different field definitions or > even use a different register for the same fields based on HW type. > > Remove unused register fields. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_common.h | 212 - > drivers/net/ethernet/intel/ice/ice_tspll.c | 234 ++-- > 2 files changed, 153 insertions(+), 293 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 12/15] ice: wait before enabling TSPLL
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 12/15] ice: wait before enabling TSPLL > > From: Karol Kolacinski > > To ensure proper operation, wait for 10 to 20 microseconds before enabling > TSPLL. > > Adjust wait time after enabling TSPLL from 1-5 ms to 1-2 ms. > > Those values are empirical and tested on multiple HW configurations. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 15/15] ice: default to TIME_REF instead of TXCO on E825-C
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 15/15] ice: default to TIME_REF instead > of TXCO on E825-C > > The driver currently defaults to the internal oscillator as the clock source > for E825-C hardware. While this clock source is labeled TCXO, indicating a > temperature compensated oscillator, this is only true for some board designs. > Many board designs have a less capable oscillator. The E825-C hardware may > also have its clock source set to the TIME_REF pin. > This pin is connected to the DPLL and is often a more stable clock source. > The choice of the internal oscillator is not suitable for all systems, > especially those which want to enable SyncE support. > > There is currently no interface available for users to configure the clock > source. Other variants of the E82x board have the clock source configured in > the NVM, but E825-C lacks this capability, so different board designs cannot > select a different default clock via firmware. > > In most setups, the TIME_REF is a suitable default clock source. > Additionally, we now fall back to the internal oscillator automatically if > the TIME_REF clock source cannot be locked. > > Change the default clock source for E825-C to TIME_REF. Note that the driver > logs a dev_dbg message upon configuring the TSPLL which includes the clock > source and frequency. This can be enabled to confirm which clock source is in > use. > > Longterm a proper interface to dynamically introspect and change the clock > source will be designed (perhaps some extension of the DPLL subsystem?) > > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/ice/ice_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 11/15] ice: add multiple TSPLL helpers
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 11/15] ice: add multiple TSPLL helpers > > From: Karol Kolacinski > > Add helpers for checking TSPLL params, disabling sticky bits, configuring > TSPLL and getting default clock frequency to simplify the code flows. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 156 - > 1 file changed, 108 insertions(+), 48 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 13/15] ice: fall back to TCXO on TSPLL lock fail
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 13/15] ice: fall back to TCXO on TSPLL > lock fail > > From: Karol Kolacinski > > TSPLL can fail when trying to lock to TIME_REF as a clock source, e.g. when the external clock source is not stable or connected to the board. > To continue operation after failure, try to lock again to internal TCXO and > inform user about this. > > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_tspll.c | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 14/15] ice: move TSPLL init calls to ice_ptp.c
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 14/15] ice: move TSPLL init calls to > ice_ptp.c > > From: Karol Kolacinski > > Initialize TSPLL after initializing PHC in ice_ptp.c instead of calling for > each product in PHC init in ice_ptp_hw.c. > > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice_ptp.c| 11 +++ > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 22 +- > drivers/net/ethernet/intel/ice/ice_tspll.c | 5 + > 3 files changed, 17 insertions(+), 21 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v4 01/15] ice: move TSPLL functions to a separate file
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 02 May 2025 04:24 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kubiak, Michal > ; Loktionov, Aleksandr > ; Kolacinski, Karol > ; Kitszel, > Przemyslaw > ; Olech, Milena ; Paul > Menzel > Subject: [Intel-wired-lan] [PATCH v4 01/15] ice: move TSPLL functions to a > separate file > > From: Karol Kolacinski > > Collect TSPLL related functions and definitions and move them to a separate file to have all TSPLL functionality in one place. > > Move CGU related functions and definitions to ice_common.* > > Reviewed-by: Michal Kubiak > Reviewed-by: Milena Olech > Signed-off-by: Karol Kolacinski > --- > drivers/net/ethernet/intel/ice/ice.h| 1 + > drivers/net/ethernet/intel/ice/ice_cgu_regs.h | 181 --- > drivers/net/ethernet/intel/ice/ice_common.h | 176 +++ > drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 161 -- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 43 -- > drivers/net/ethernet/intel/ice/ice_tspll.h | 46 ++ > drivers/net/ethernet/intel/ice/ice_common.c | 61 +++ > drivers/net/ethernet/intel/ice/ice_ptp.c| 1 - > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 542 > drivers/net/ethernet/intel/ice/ice_tspll.c | 646 > drivers/net/ethernet/intel/ice/Makefile | 2 +- > 11 files changed, 931 insertions(+), 929 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next 3/5] igb: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Vladimir Oltean
> Sent: 13 May 2025 15:42
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Keller, Jacob E ;
> Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Gomes, Vinicius ; >
> Vadim Fedorenko ; Richard Cochran
>
> Subject: [Intel-wired-lan] [PATCH iwl-next 3/5] igb: convert to
> ndo_hwtstamp_get() and ndo_hwtstamp_set()
>
> New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs
> for configuring hardware timestamping") from kernel v6.6.
>
> It is time to convert the Intel igb driver to the new API, so that
> timestamping configuration can be removed from the ndo_eth_ioctl() path
> completely.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/ethernet/intel/igb/igb.h | 9 --
> drivers/net/ethernet/intel/igb/igb_main.c | 6 ++--
> drivers/net/ethernet/intel/igb/igb_ptp.c | 37 +++
> 3 files changed, 25 insertions(+), 27 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next 5/5] i40e: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Vladimir Oltean
> Sent: 13 May 2025 15:42
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Keller, Jacob E ;
> Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Gomes, Vinicius ;
> Vadim Fedorenko ; Richard Cochran
>
> Subject: [Intel-wired-lan] [PATCH iwl-next 5/5] i40e: convert to
> ndo_hwtstamp_get() and ndo_hwtstamp_set()
>
> New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs
> for configuring hardware timestamping") from kernel v6.6.
>
> It is time to convert the Intel i40e driver to the new API, so that
> timestamping configuration can be removed from the ndo_eth_ioctl() path
> completely.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/ethernet/intel/i40e/i40e.h | 9 +++--
> drivers/net/ethernet/intel/i40e/i40e_main.c | 24 +---
> drivers/net/ethernet/intel/i40e/i40e_ptp.c | 43 +++--
> 3 files changed, 31 insertions(+), 45 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next 1/5] ice: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Vladimir Oltean
> Sent: 13 May 2025 15:41
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Keller, Jacob E ;
> Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Gomes, Vinicius ;
> Vadim Fedorenko ; Richard Cochran
>
> Subject: [Intel-wired-lan] [PATCH iwl-next 1/5] ice: convert to
> ndo_hwtstamp_get() and ndo_hwtstamp_set()
>
> New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs
> for configuring hardware timestamping") from kernel v6.6.
>
> It is time to convert the Intel ice driver to the new API, so that
> timestamping configuration can be removed from the ndo_eth_ioctl() path
> completely.
>
> Signed-off-by: Vladimir Oltean
> Acked-by: Jacob Keller
> ---
> Previously submitted as
https://patchwork.kernel.org/project/netdevbpf/patch/20250512160036.909434-1-vladimir.olt...@nxp.com/
>
> drivers/net/ethernet/intel/ice/ice_main.c | 24 +---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 45 ---
> drivers/net/ethernet/intel/ice/ice_ptp.h | 17 ++---
> 3 files changed, 37 insertions(+), 49 deletions(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v4] ice/ptp: fix crosstimestamp reporting
> -Original Message-
> From: Intel-wired-lan On Behalf Of Anton
> Nadezhdin
> Sent: 20 May 2025 14:12
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Nguyen, Anthony L ;
> richardcoch...@gmail.com; Nadezhdin, Anton ;
> Loktionov, Aleksandr ; Kubalewski, Arkadiusz
>
> Subject: [Intel-wired-lan] [PATCH iwl-net v4] ice/ptp: fix crosstimestamp
> reporting
>
> Set use_nsecs=true as timestamp is reported in ns. Lack of this result in
> smaller timestamp error window which cause error during phc2sys execution on
> E825 NICs:
> phc2sys[1768.256]: ioctl PTP_SYS_OFFSET_PRECISE: Invalid argument
>
> This problem was introduced in the cited commit which omitted setting
> use_nsecs to true when converting the ice driver to use convert_base_to_cs().
>
> Testing hints (ethX is PF netdev):
> phc2sys -s ethX -c CLOCK_REALTIME -O 37 -m
> phc2sys[1769.256]: CLOCK_REALTIME phc offset -5 s0 freq -0 delay0
>
> Fixes: d4bea547ebb57 ("ice/ptp: Remove convert_art_to_tsc()")
> Signed-off-by: Anton Nadezhdin
> Reviewed-by: Aleksandr Loktionov
> Reviewed-by: Arkadiusz Kubalewski
> ---
> V3 -> V4 Updated commit message
> ---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 1 +
> 1 file changed, 1 insertion(+)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 1/2] net: intel: rename 'hena' to 'hashcfg' for clarity
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 06 May 2025 01:44 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kitszel, Przemyslaw > ; Loktionov, Aleksandr > ; Simon Horman > Subject: [Intel-wired-lan] [PATCH iwl-next v2 1/2] net: intel: rename 'hena' > to 'hashcfg' for clarity > > i40e, ice, and iAVF all use 'hena' as a shorthand for the "hash enable" configuration. This comes originally from the X710 datasheet 'xxQF_HENA' registers. In the context of the registers the meaning is fairly clear. > > However, on its own, hena is a weird name that can be more difficult to > understand. This is especially true in ice. The E810 hardware doesn't even > have registers with HENA in the name. > > Replace the shorthand 'hena' with 'hashcfg'. This makes it clear the > variables deal with the Hash configuration, not just a single boolean on/off > for all hashing. > > Do not update the register names. These come directly from the datasheet for > X710 and X722, and it is more important that the names can be searched. > > Suggested-by: Przemek Kitszel > Reviewed-by: Aleksandr Loktionov > Reviewed-by: Przemek Kitszel > Reviewed-by: Simon Horman > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/i40e/i40e_txrx.h| 8 ++-- > drivers/net/ethernet/intel/iavf/iavf.h | 10 ++--- > drivers/net/ethernet/intel/iavf/iavf_txrx.h| 4 +- > drivers/net/ethernet/intel/ice/ice_flow.h | 4 +- > drivers/net/ethernet/intel/ice/ice_virtchnl.h | 4 +- > include/linux/avf/virtchnl.h | 22 +-- > drivers/net/ethernet/intel/i40e/i40e_main.c| 2 +- > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 46 +++--- > drivers/net/ethernet/intel/iavf/iavf_main.c| 17 > drivers/net/ethernet/intel/iavf/iavf_virtchnl.c| 33 > drivers/net/ethernet/intel/ice/ice_lib.c | 2 +- > drivers/net/ethernet/intel/ice/ice_virtchnl.c | 44 ++--- > .../ethernet/intel/ice/ice_virtchnl_allowlist.c| 2 +- > 13 files changed, 101 insertions(+), 97 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2 2/2] net: intel: move RSS packet classifier types to libie
> -Original Message- > From: Intel-wired-lan On Behalf Of Jacob > Keller > Sent: 06 May 2025 01:44 > To: Intel Wired LAN ; Nguyen, Anthony L > ; netdev > Cc: Keller, Jacob E ; Kitszel, Przemyslaw > ; Simon Horman ; Loktionov, > Aleksandr > Subject: [Intel-wired-lan] [PATCH iwl-next v2 2/2] net: intel: move RSS > packet classifier types to libie > > The Intel i40e, iavf, and ice drivers all include a definition of the packet > classifier filter types used to program RSS hash enable bits. For i40e, these > bits are used for both the PF and VF to configure the PFQF_HENA and VFQF_HENA > registers. > > For ice and iAVF, these bits are used to communicate the desired hash enable > filter over virtchnl via its struct virtchnl_rss_hashena. The virtchnl.h > header makes no mention of where the bit definitions reside. > > Maintaining a separate copy of these bits across three drivers is cumbersome. > Move the definition to libie as a new pctype.h header file. > Each driver can include this, and drop its own definition. > > The ice implementation also defined a ICE_AVF_FLOW_FIELD_INVALID, intending > to use this to indicate when there were no hash enable bits set. This is > confusing, since the enumeration is using bit positions. A value of 0 *should* indicate the first bit. Instead, rewrite the code that uses ICE_AVF_FLOW_FIELD_INVALID to just check if the avf_hash is zero. From context this should be clear that we're checking if none of the bits are set. > > The values are kept as bit positions instead of encoding the BIT_ULL directly > into their value. While most users will simply use BIT_ULL immediately, i40e > uses the macros both with BIT_ULL and test_bit/set_bit calls. > > Reviewed-by: Przemek Kitszel > Reviewed-by: Simon Horman > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Jacob Keller > --- > drivers/net/ethernet/intel/i40e/i40e_txrx.h| 35 +-- > drivers/net/ethernet/intel/i40e/i40e_type.h| 32 -- > drivers/net/ethernet/intel/iavf/iavf_txrx.h| 36 ++-- > drivers/net/ethernet/intel/iavf/iavf_type.h| 32 -- > drivers/net/ethernet/intel/ice/ice_flow.h | 64 ++-- > include/linux/avf/virtchnl.h | 1 + > include/linux/net/intel/libie/pctype.h | 41 + > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 81 +- > drivers/net/ethernet/intel/i40e/i40e_main.c| 23 > drivers/net/ethernet/intel/i40e/i40e_txrx.c| 25 > drivers/net/ethernet/intel/ice/ice_flow.c | 45 +++--- > 11 files changed, 185 insertions(+), 230 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v2 net] net: ice: Perform accurate aRFS flow match
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Krishna Kumar
> Sent: 20 May 2025 22:37
> To: net...@vger.kernel.org
> Cc: da...@davemloft.net; ho...@kernel.org; Nguyen, Anthony L
> ; Kitszel, Przemyslaw
> ; eduma...@google.com;
> intel-wired-...@lists.osuosl.org; andrew+net...@lunn.ch; k...@kernel.org;
> pab...@redhat.com; Samudrala, Sridhar ; Zaki,
> Ahmed ; Kumar, Krishna
> Subject: [Intel-wired-lan] [PATCH v2 net] net: ice: Perform accurate aRFS
> flow match
>
> This patch fixes an issue seen in a large-scale deployment under heavy
> incoming pkts where the aRFS flow wrongly matches a flow and reprograms the
> NIC with wrong settings. That mis-steering causes RX-path latency spikes and
> noisy neighbor effects when many connections collide on the same hash (some
> of our production servers have 20-30K connections).
>
> set_rps_cpu() calls ndo_rx_flow_steer() with flow_id that is calculated by
> hashing the skb sized by the per rx-queue table size. This results in
> multiple connections (even across different rx-queues) getting the same hash
> value. > The driver steer function modifies the wrong flow to use this
> rx-queue, e.g.: Flow#1 is first added:
>Flow#1: , Hash 'h', q#10
>
> Later when a new flow needs to be added:
> Flow#2: , Hash 'h', q#20
>
> The driver finds the hash 'h' from Flow#1 and updates it to use q#20. This
> results in both flows getting un-optimized - packets for Flow#1 goes to q#20,
> and then reprogrammed back to q#10 later and so on; and Flow #2 programming
> is never done as Flow#1 is matched first for all misses. Many flows may
> wrongly share the same hash and reprogram rules of the original flow each
> with their own q#.
>
> Tested on two 144-core servers with 16K netperf sessions for 180s. Netperf
> clients are pinned to cores 0-71 sequentially (so that wrong packets on q#s
72-143 can be measured). IRQs are set 1:1 for queues -> CPUs, enable XPS,
enable aRFS (global value is 144 * rps_flow_cnt).
>
> Test notes about results from ice_rx_flow_steer():
> ---
> 1. "Skip:" counter increments here:
>if (fltr_info->q_index == rxq_idx ||
> arfs_entry->fltr_state != ICE_ARFS_ACTIVE)
> goto out;
> 2. "Add:" counter increments here:
>ret = arfs_entry->fltr_info.fltr_id;
>INIT_HLIST_NODE(&arfs_entry->list_entry);
> 3. "Update:" counter increments here:
>/* update the queue to forward to on an already existing flow */
>
> Runtime comparison: original code vs with the patch for different
> rps_flow_cnt values.
>
> +---+--+--+
> | rps_flow_cnt | 512 |2048 |
> +---+--+--+
> | Ratio of Pkts on Good:Bad q's | 214 vs 822K | 1.1M vs 980K |
> | Avoid wrong aRFS programming | 0 vs 310K| 0 vs 30K |
> | CPU User | 216 vs 183 | 216 vs 206 |
> | CPU System| 1441 vs 1171 | 1447 vs 1320 |
> | CPU Softirq | 1245 vs 920 | 1238 vs 961 |
> | CPU Total | 29 vs 22.7 | 29 vs 24.9 |
> | aRFS Update | 533K vs 59 | 521K vs 32 |
> | aRFS Skip | 82M vs 77M | 7.2M vs 4.5M |
> +---+--+--+
>
> A separate TCP_STREAM and TCP_RR with 1,4,8,16,64,128,256,512 connections
> showed no performance degradation.
>
> Some points on the patch/aRFS behavior:
> 1. Enabling full tuple matching ensures flows are always correctly matched,
> even with smaller hash sizes.
> 2. 5-6% drop in CPU utilization as the packets arrive at the correct CPUs
> and fewer calls to driver for programming on misses.
> 3. Larger hash tables reduces mis-steering due to more unique flow hashes,
> but still has clashes. However, with larger per-device rps_flow_cnt, old
> flows take more time to expire and new aRFS flows cannot be added if h/w
> limits are reached (rps_may_expire_flow() succeeds when 10*rps_flow_cnt
> pkts have been processed by this cpu that are not part of the flow).
>
> Changes since v1:
> - Added "Fixes:" tag and documented return values.
> - Added @ for function parameters.
> - Updated subject line to denote target tree (net)
>
> Fixes: 28bf26724fdb0 ("ice: Implement aRFS")
> Signed-off-by: Krishna Kumar
> ---
> drivers/net/ethernet/intel/ice/ice_arfs.c | 49 +++
> 1 file changed, 49 insertions(+)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix eswitch code memory leak in reset scenario
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Grzegorz Nitka
> Sent: 16 May 2025 18:39
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Nguyen, Anthony L ;
> Kitszel, Przemyslaw
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix eswitch code memory
> leak in reset scenario
>
> Add simple eswitch mode checker in attaching VF procedure and allocate
> required port representor memory structures only in switchdev mode.
> The reset flows triggers VF (if present) detach/attach procedure.
> It might involve VF port representor(s) re-creation if the device is
> configured is switchdev mode (not legacy one).
> The memory was blindly allocated in current implementation, regardless of the
> mode and not freed if in legacy mode.
>
> Kmemeleak trace:
> unreferenced object (percpu) 0x7e3bce5b888458 (size 40):
> comm "bash", pid 1784, jiffies 4295743894
> hex dump (first 32 bytes on cpu 45):
>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace (crc 0):
>pcpu_alloc_noprof+0x4c4/0x7c0
>ice_repr_create+0x66/0x130 [ice]
>ice_repr_create_vf+0x22/0x70 [ice]
>ice_eswitch_attach_vf+0x1b/0xa0 [ice]
>ice_reset_all_vfs+0x1dd/0x2f0 [ice]
>ice_pci_err_resume+0x3b/0xb0 [ice]
>pci_reset_function+0x8f/0x120
>reset_store+0x56/0xa0
>kernfs_fop_write_iter+0x120/0x1b0
>vfs_write+0x31c/0x430
>ksys_write+0x61/0xd0
>do_syscall_64+0x5b/0x180
>entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Testing hints (ethX is PF netdev):
> - create at least one VF
>echo 1 > /sys/class/net/ethX/device/sriov_numvfs
> - trigger the reset
>echo 1 > /sys/class/net/ethX/device/reset
>
> Fixes: 415db8399d06 ("ice: make representor code generic")
> Signed-off-by: Grzegorz Nitka
> Reviewed-by: Przemek Kitszel
> ---
>
> v1->v2: rebase, adding netdev mailing list
>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v1] ice: check correct pointer in fwlog debugfs
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Michal Swiatkowski
> Sent: 24 June 2025 14:57
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kitszel, Przemyslaw
> ; Michal Swiatkowski
>
Subject: [Intel-wired-lan] [PATCH iwl-net v1] ice: check correct pointer in
fwlog debugfs
>
> pf->ice_debugfs_pf_fwlog should be check for an error here.
>
> Fixes: 96a9a9341cda ("ice: configure FW logging")
> Reviewed-by: Przemek Kitszel
> Signed-off-by: Michal Swiatkowski
> ---
> drivers/net/ethernet/intel/ice/ice_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next] ice: convert ice_add_prof() to bitmap
> -Original Message- > From: Intel-wired-lan On Behalf Of > Przemek Kitszel > Sent: 18 June 2025 16:59 > To: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L > > Cc: net...@vger.kernel.org; Kitszel, Przemyslaw > ; Keller, Jacob E ; > Loktionov, Aleksandr ; Brandeburg, Jesse > > Subject: [Intel-wired-lan] [PATCH iwl-next] ice: convert ice_add_prof() to > bitmap > > From: Jesse Brandeburg > > Previously the ice_add_prof() took an array of u8 and looped over it with > for_each_set_bit(), examining each 8 bit value as a bitmap. >This was just hard to understand and unnecessary, and was triggering undefined >behavior sanitizers with unaligned accesses within bitmap fields (on our >internal tools/builds). Since the @ptype being passed in was already declared >as a bitmap, refactor this to use native types with the advantage of >simplifying the code to use a single loop. > > Co-developed-by: Jacob Keller > Signed-off-by: Jacob Keller > Signed-off-by: Jesse Brandeburg > Signed-off-by: Aleksandr Loktionov > CC: Jesse Brandeburg > Signed-off-by: Przemek Kitszel > --- > .../net/ethernet/intel/ice/ice_flex_pipe.h| 7 +- > .../net/ethernet/intel/ice/ice_flex_pipe.c| 78 +++ > drivers/net/ethernet/intel/ice/ice_flow.c | 4 +- > 3 files changed, 34 insertions(+), 55 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v3] ice: add 40G speed to Admin Command GET PORT OPTION
> -Original Message- > From: Intel-wired-lan On Behalf Of > Aleksandr Loktionov > Sent: 16 May 2025 20:12 > To: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L > ; Loktionov, Aleksandr > > Cc: net...@vger.kernel.org; Kitszel, Przemyslaw > ; Simon Horman > Subject: [Intel-wired-lan] [PATCH iwl-next v3] ice: add 40G speed to Admin > Command GET PORT OPTION > > Introduce the ICE_AQC_PORT_OPT_MAX_LANE_40G constant and update the code to > process this new option in both the devlink and the Admin Queue Command GET > PORT OPTION (opcode 0x06EA) message, similar to existing constants like > ICE_AQC_PORT_OPT_MAX_LANE_50G, ICE_AQC_PORT_OPT_MAX_LANE_100G, and so on. > > This feature allows the driver to correctly report configuration options for > 2x40G on ICX-D LCC and other cards in the future via devlink. > > Example command: > devlink port split pci/:01:00.0/0 count 2 > > Example dmesg: > ice :01:00.0: Available port split options and max port speeds (Gbps): > ice :01:00.0: Status Split Quad 0 Quad 1 > ice :01:00.0: count L0 L1 L2 L3 L4 L5 L6 L7 > ice :01:00.0: 2 40 - - - 40 - - - > ice :01:00.0: 2 50 - 50 - - - - - > ice :01:00.0: 4 25 25 25 25 - - - - > ice :01:00.0: 4 25 25 - - 25 25 - - > ice :01:00.0: Active 8 10 10 10 10 10 10 10 10 > ice :01:00.0: 1 100 - - - - - - - > > Signed-off-by: Aleksandr Loktionov > Reviewed-by: Przemek Kitszel > Reviewed-by: Simon Horman > --- > v2->v3 - fix indent > v1->v2 - fix typo in commit message > --- > drivers/net/ethernet/intel/ice/devlink/port.c | 2 ++ > drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 + > drivers/net/ethernet/intel/ice/ice_common.c | 2 +- > drivers/net/ethernet/intel/ice/ice_ethtool.c| 3 ++- > 4 files changed, 6 insertions(+), 2 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next 4/5] ixgbe: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Vladimir Oltean
> Sent: 13 May 2025 15:42
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Keller, Jacob E ;
> Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Gomes, Vinicius ;
> Vadim Fedorenko ; Richard Cochran
>
> Subject: [Intel-wired-lan] [PATCH iwl-next 4/5] ixgbe: convert to
> ndo_hwtstamp_get() and ndo_hwtstamp_set()
>
> New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs
> for configuring hardware timestamping") from kernel v6.6.
>
> It is time to convert the Intel ixgbe driver to the new API, so that
> timestamping configuration can be removed from the ndo_eth_ioctl() path
> completely.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 9 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 42 +--
> 3 files changed, 29 insertions(+), 28 deletions(-)
>
With the ixgbe_from_netdev() change
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: add E835 device IDs
> -Original Message- > From: Intel-wired-lan On Behalf Of Dawid > Osuchowski > Sent: 20 May 2025 15:01 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; Dawid Osuchowski > ; Knitter, Konrad > ; Simon Horman > Subject: [Intel-wired-lan] [PATCH iwl-next v2] ice: add E835 device IDs > > E835 is an enhanced version of the E830. > It continues to use the same set of commands, registers and interfaces as > other devices in the 800 Series. > > Following device IDs are added: > - 0x1248: Intel(R) Ethernet Controller E835-CC for backplane > - 0x1249: Intel(R) Ethernet Controller E835-CC for QSFP > - 0x124A: Intel(R) Ethernet Controller E835-CC for SFP > - 0x1261: Intel(R) Ethernet Controller E835-C for backplane > - 0x1262: Intel(R) Ethernet Controller E835-C for QSFP > - 0x1263: Intel(R) Ethernet Controller E835-C for SFP > - 0x1265: Intel(R) Ethernet Controller E835-L for backplane > - 0x1266: Intel(R) Ethernet Controller E835-L for QSFP > - 0x1267: Intel(R) Ethernet Controller E835-L for SFP > > Reviewed-by: Konrad Knitter > Reviewed-by: Simon Horman > Signed-off-by: Dawid Osuchowski > --- > v2 changes: > - v1: > https://lore.kernel.org/netdev/20250514104632.331559-1-dawid.osuchow...@linux.intel.com/ > - Move device IDs to corresponding spot in the file (Tony) > - Add Reviewed-by tag from Simon > --- > drivers/net/ethernet/intel/ice/ice_common.c | 9 + > drivers/net/ethernet/intel/ice/ice_devids.h | 18 ++ > drivers/net/ethernet/intel/ice/ice_main.c | 9 + > 3 files changed, 36 insertions(+) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH v2] ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Haoxiang Li
> Sent: 03 July 2025 15:23
> To: Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; andrew+net...@lunn.ch; da...@davemloft.net;
> eduma...@google.com; k...@kernel.org; pab...@redhat.com
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Haoxiang Li ;
> sta...@vger.kernel.org; Michal Swiatkowski
> ; Loktionov, Aleksandr
>
> Subject: [Intel-wired-lan] [PATCH v2] ice: Fix a null pointer dereference in
> ice_copy_and_init_pkg()
>
> Add check for the return value of devm_kmemdup() to prevent potential null
> pointer dereference.
>
> Fixes: c76488109616 ("ice: Implement Dynamic Device Personalization (DDP)
> download")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Haoxiang Li
> Reviewed-by: Michal Swiatkowski
> Reviewed-by: Aleksandr Loktionov
> ---
> Changes in v2:
> - modify the Fixes commit number. Thanks, Michal!
> ---
> drivers/net/ethernet/intel/ice/ice_ddp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [iwl-next v2] ixgbe: add the 2.5G and 5G speeds in auto-negotiation for E610
> -Original Message- > From: Intel-wired-lan On Behalf Of Piotr > Kwapulinski > Sent: 04 July 2025 18:36 > To: intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; and...@lunn.ch; pmen...@molgen.mpg.de; > Kwapulinski, Piotr ; Kitszel, Przemyslaw > > Subject: [Intel-wired-lan] [iwl-next v2] ixgbe: add the 2.5G and 5G speeds in > auto-negotiation for E610 > > The auto-negotiation limitation for 2.5G and 5G speeds is no longer true for > X550 successors like E610 adapter. Enable the 2.5G and 5G speeds in > auto-negotiation for E610 at driver load. > > Reviewed-by: Przemek Kitszel > Signed-off-by: Piotr Kwapulinski > --- > v1 -> v2 > More details in commit message > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 35 +++ > 1 file changed, 12 insertions(+), 23 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix Rx page leak on multi-buffer frames
> -Original Message-
> From: Intel-wired-lan On Behalf Of Jacob
> Keller
> Sent: 12 July 2025 05:54
> To: Fijalkowski, Maciej ; Kitszel, Przemyslaw
> ; Intel Wired LAN
> ; Lobakin, Aleksander
>
> Cc: Joe Damato ; Nguyen, Anthony L
> ; net...@vger.kernel.org; Christoph Petrausch
> ; Jaroslav Pulchart
> ; Keller, Jacob E
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix Rx page leak on
> multi-buffer frames
>
> The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each
> buffer in the current frame. This function was introduced as part of handling
> multi-buffer XDP support in the ice driver.
>
> It works by iterating over the buffers from first_desc up to 1 plus the total
> number of fragments in the frame, cached from before the XDP program was
> executed.
>
> If the hardware posts a descriptor with a size of 0, the logic used in
> ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as
> fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment,
> we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call
> ice_put_rx_buf().
>
> Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page
> or free it. This leaves a stale page in the ring, as we don't increment
> next_to_alloc.
>
> The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented
> properly, and that it always points to a buffer with a NULL page. Since this
> function doesn't check, it will happily recycle a page over the top of the
> next_to_alloc buffer, losing track of the old page.
>
> Note that this leak only occurs for multi-buffer frames. The
> ice_put_rx_mbuf() function always handles at least one buffer, so a
> single-buffer frame will always get handled correctly. It is not clear
> precisely why the hardware hands us descriptors with a size of 0 sometimes,
> but it happens somewhat regularly with "jumbo frames" used by 9K MTU.
>
> To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on
> all buffers between first_desc and next_to_clean. Borrow the logic of a
> similar function in i40e used for this same purpose. Use the same logic also
> in ice_get_pgcnts().
>
> Instead of iterating over just the number of fragments, use a loop which
> iterates until the current index reaches to the next_to_clean element just
> past the current frame. Check the current number of fragments (post XDP
> program). For all buffers up 1 more than the number of fragments, > we'll
> update the pagecnt_bias. For any buffers past this, pagecnt_bias is left
> as-is. This ensures that fragments released by the XDP program, as well as
> any buffers with zero-size won't have their pagecnt_bias updated incorrectly.
> Unlike i40e, the ice_put_rx_mbuf() function does call
> ice_put_rx_buf() on the last buffer of the frame indicating end of packet.
>
> The xdp_xmit value only needs to be updated if an XDP program is run, and
> only once per packet. Drop the xdp_xmit pointer argument from
> ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function
> directly. This avoids needing to pass the argument and avoids an extra >
> bit-wise OR for each buffer in the frame.
>
> Move the increment of the ntc local variable to ensure its updated *before*
> all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic
> requires the index of the element just after the current frame.
>
> This has the advantage that we also no longer need to track or cache the
> number of fragments in the rx_ring, which saves a few bytes in the ring.
>
> Cc: Christoph Petrausch
> Reported-by: Jaroslav Pulchart
> Closes:
> https://lore.kernel.org/netdev/cak8ffz4hy6gujnenz3wy9jaylzxgfpr7dnzxzgmyoe44car...@mail.gmail.com/
> Fixes: 743bbd93cf29 ("ice: put Rx buffers after being done with current
> frame")
> Signed-off-by: Jacob Keller
> ---
> I've tested this in a setup with MTU 9000, using a combination of iperf3 and
> wrk generated traffic.
>
> I tested this in a couple of ways. First, I check memory allocations using
> /proc/allocinfo:
>
> awk '/ice_alloc_mapped_page/ { printf("%s %s\n", $1, $2) }' /proc/allocinfo |
> numfmt --to=iec
>
> Second, I ported some stats from i40e written by Joe Damato to track the page
> allocation and busy counts. I consistently saw that the allocate stat
> increased without the busy or waive stats increasing. I also added a stat to
> track directly when we overwrote a page pointer that was non-NULL in
> ice_reuse_rx_page(), and saw it increment consistently.
>
> With this fix, all of these indicators are fixed. I've tested both 1500 byte
> and 9000 byte MTU and no longer see the leak. With the counters I was able to
> immediately see a leak within a few minutes of iperf3, so I am confident that
> I've resolved the leak with this fix.
>
> I've now also tested with xdp-bench and confirm that XDP_TX and XDP_REDIR
> work properly with the fix for updating xdp_xmit.
Re: [Intel-wired-lan] [PATCH iwl-net v2 2/2] ixgbe: prevent from unwanted interface name changes
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Jedrzej Jagielski
> Sent: 07 July 2025 14:29
> To: intel-wired-...@lists.osuosl.org
> Cc: Nguyen, Anthony L ; net...@vger.kernel.org;
> dhowe...@redhat.com; david.kap...@amd.com; j...@resnulli.us; Kitszel,
> Przemyslaw ; Jagielski, Jedrzej
> ; Jakub Kicinski
> Subject: [Intel-wired-lan] [PATCH iwl-net v2 2/2] ixgbe: prevent from
> unwanted interface name changes
>
> Users of the ixgbe driver report that after adding devlink support by the
> commit a0285236ab93 ("ixgbe: add initial devlink support") their configs got
> broken due to unwanted changes of interfaces names.
> It's caused by changing names by devlink port initialization flow.
>
> To prevent from that set skip_phys_port_name_get flag for ixgbe devlink ports.
>
> Reported-by: David Howells
> Closes: https://lkml.org/lkml/2025/4/24/2052
> Reported-by: David Kaplan
> Closes: https://www.spinics.net/lists/netdev/msg1099410.html
> Suggested-by: Jakub Kicinski
> Acked-by: Przemek Kitszel
> Fixes: a0285236ab93 ("ixgbe: add initial devlink support")
> Signed-off-by: Jedrzej Jagielski
> ---
> v2: use new flag instead of creating blank implementation of
>ndo_get_phys_port_name()
> ---
> drivers/net/ethernet/intel/ixgbe/devlink/devlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
Tested-by: Rinitha S (A Contingent worker at Intel)
