From: Grzegorz Nitka E82X adapters do not have sequential IDs, lane number is PF ID. Add check for ICE_MAC_GENERIC and skip checking port options. Also, adjust logical port number for specific E825 device with external PHY support (PCI device id 0x579F). For this particular device, with 2x25G (PHY0) and 2x10G (PHY1) port configuration, modification of pf_id -> lane_number mapping is required. PF IDs on the 2nd PHY start from 4 in such scenario. Otherwise, the lane number cannot be determined correctly, leading to PTP init errors during PF initialization. Fixes: 258f5f9058159 ("ice: Add correct PHY lane assignment") Co-developed-by: Karol Kolacinski Signed-off-by: Karol Kolacinski Signed-off-by: Grzegorz Nitka Reviewed-by: Przemek Kitszel Reviewed-by: Milena Olech Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_common.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index 2250426ec91b..28d74bf56ffc 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -4382,6 +4382,15 @@ int ice_get_phy_lane_number(struct ice_hw *hw) unsigned int lane; int err; + /* E82X does not have sequential IDs, lane number is PF ID. + * For E825 device, the exception is the variant with external + * PHY (0x579F), in which there is also 1:1 pf_id -> lane_number + * mapping. + */ + if (hw->mac_type == ICE_MAC_GENERIC || + hw->device_id == ICE_DEV_ID_E825C_SGMII) + return hw->pf_id; + options = kcalloc(ICE_AQC_PORT_OPT_MAX, sizeof(*options), GFP_KERNEL); if (!options) return -ENOMEM; -- 2.47.1 From: Grzegorz Nitka On dual complex E825, only complex 0 has functional CGU (Clock Generation Unit), powering all the PHYs. SBQ (Side Band Queue) destination device 'cgu' in current implementation points to CGU on current complex and, in order to access primary CGU from the secondary complex, the driver should use 'cgu_peer' as a destination device in read/write CGU registers operations. Define new 'cgu_peer' (15) as RDA (Remote Device Access) client over SB-IOSF interface and use it as device target when accessing CGU from secondary complex. This problem has been identified when working on recovery clock enablement [1]. In existing implementation for E825 devices, only PF0, which is clock owner, is involved in CGU configuration, thus the problem was not exposed to the user. [1] https://lore.kernel.org/intel-wired-lan/20250905150947.871566-1-grzegorz.nitka@intel.com/ Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_common.c | 26 ++++++++++++++++++-- drivers/net/ethernet/intel/ice/ice_sbq_cmd.h | 1 + 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index 28d74bf56ffc..2532b6f82e97 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -6505,6 +6505,28 @@ u32 ice_get_link_speed(u16 index) return ice_aq_to_link_speed[index]; } +/** + * ice_get_dest_cgu - get destination CGU dev for given HW + * @hw: pointer to the HW struct + * + * Get CGU client id for CGU register read/write operations. + * + * Return: CGU device id to use in SBQ transactions. + */ +static enum ice_sbq_dev_id ice_get_dest_cgu(struct ice_hw *hw) +{ + /* On dual complex E825 only complex 0 has functional CGU powering all + * the PHYs. + * SBQ destination device cgu points to CGU on a current complex and to + * access primary CGU from the secondary complex, the driver should use + * cgu_peer as a destination device. + */ + if (hw->mac_type == ICE_MAC_GENERIC_3K_E825 && ice_is_dual(hw) && + !ice_is_primary(hw)) + return ice_sbq_dev_cgu_peer; + return ice_sbq_dev_cgu; +} + /** * ice_read_cgu_reg - Read a CGU register * @hw: Pointer to the HW struct @@ -6519,8 +6541,8 @@ u32 ice_get_link_speed(u16 index) int ice_read_cgu_reg(struct ice_hw *hw, u32 addr, u32 *val) { struct ice_sbq_msg_input cgu_msg = { + .dest_dev = ice_get_dest_cgu(hw), .opcode = ice_sbq_msg_rd, - .dest_dev = ice_sbq_dev_cgu, .msg_addr_low = addr }; int err; @@ -6551,8 +6573,8 @@ int ice_read_cgu_reg(struct ice_hw *hw, u32 addr, u32 *val) int ice_write_cgu_reg(struct ice_hw *hw, u32 addr, u32 val) { struct ice_sbq_msg_input cgu_msg = { + .dest_dev = ice_get_dest_cgu(hw), .opcode = ice_sbq_msg_wr, - .dest_dev = ice_sbq_dev_cgu, .msg_addr_low = addr, .data = val }; diff --git a/drivers/net/ethernet/intel/ice/ice_sbq_cmd.h b/drivers/net/ethernet/intel/ice/ice_sbq_cmd.h index 183dd5457d6a..21bb861febbf 100644 --- a/drivers/net/ethernet/intel/ice/ice_sbq_cmd.h +++ b/drivers/net/ethernet/intel/ice/ice_sbq_cmd.h @@ -50,6 +50,7 @@ enum ice_sbq_dev_id { ice_sbq_dev_phy_0 = 0x02, ice_sbq_dev_cgu = 0x06, ice_sbq_dev_phy_0_peer = 0x0D, + ice_sbq_dev_cgu_peer = 0x0F, }; enum ice_sbq_msg_opcode { -- 2.47.1 From: Grzegorz Nitka In some devices, the function numbers used are non-contiguous. For example, here is such configuration for E825 device: root@/home/root# lspci -v | grep Eth 0a:00.0 Ethernet controller: Intel Corporation Ethernet Connection E825-C for backplane (rev 04) 0a:00.1 Ethernet controller: Intel Corporation Ethernet Connection E825-C for backplane (rev 04) 0a:00.4 Ethernet controller: Intel Corporation Ethernet Connection E825-C 10GbE (rev 04) 0a:00.5 Ethernet controller: Intel Corporation Ethernet Connection E825-C 10GbE (rev 04) When distributing RSS and FDIR masks, which are global resources across the active devices, it is required to have a contiguous PF id, which can be described as a logical PF id. In the case above, function 0 would have a logical PF id of 0, function 1 would have a logical PF id of 1, and functions 4 and 5 would have a logical PF ids 2 and 3 respectively. Using logical PF id can properly describe which slice of resources can be used by a particular PF. The 'function id' to 'logical id' mapping has been introduced with the commit 015307754a19 ("ice: Support VF queue rate limit and quanta size configuration"). However, the usage of 'logical_pf_id' field was unintentionally skipped for profile mask configuration. Fix it by using 'logical_pf_id' instead of 'pf_id' value when configuring masks. Without that patch, wrong indexes, i.e. out of range for given PF, can be used while configuring resources masks, which might lead to memory corruption and undefined driver behavior. The call trace below is one of the examples of such error: [ +0.000008] WARNING: CPU: 39 PID: 3830 at drivers/base/devres.c:1095 devm_kfree+0x70/0xa0 [ +0.000002] RIP: 0010:devm_kfree+0x70/0xa0 [ +0.000001] Call Trace: [ +0.000002] [ +0.000002] ice_free_hw_tbls+0x183/0x710 [ice] [ +0.000106] ice_deinit_hw+0x67/0x90 [ice] [ +0.000091] ice_deinit+0x20d/0x2f0 [ice] [ +0.000076] ice_remove+0x1fa/0x6a0 [ice] [ +0.000075] pci_device_remove+0xa7/0x1d0 [ +0.000010] device_release_driver_internal+0x365/0x530 [ +0.000006] driver_detach+0xbb/0x170 [ +0.000003] bus_remove_driver+0x117/0x290 [ +0.000007] pci_unregister_driver+0x26/0x250 Fixes: 015307754a19 ("ice: Support VF queue rate limit and quanta size configuration") Suggested-by: Dan Nowlin Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_flex_pipe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_flex_pipe.c b/drivers/net/ethernet/intel/ice/ice_flex_pipe.c index 363ae79a3620..013c93b6605e 100644 --- a/drivers/net/ethernet/intel/ice/ice_flex_pipe.c +++ b/drivers/net/ethernet/intel/ice/ice_flex_pipe.c @@ -1479,7 +1479,7 @@ static void ice_init_prof_masks(struct ice_hw *hw, enum ice_block blk) per_pf = ICE_PROF_MASK_COUNT / hw->dev_caps.num_funcs; hw->blk[blk].masks.count = per_pf; - hw->blk[blk].masks.first = hw->pf_id * per_pf; + hw->blk[blk].masks.first = hw->logical_pf_id * per_pf; memset(hw->blk[blk].masks.masks, 0, sizeof(hw->blk[blk].masks.masks)); -- 2.47.1 From: Kohei Enju The error path of ixgbe_recovery_probe() has two memory bugs. For non-E610 adapters, the function jumps to clean_up_probe without calling devlink_free(), leaking the devlink instance and its embedded adapter structure. For E610 adapters, devlink_free() is called at shutdown_aci, but clean_up_probe then accesses adapter->state, sometimes triggering use-after-free because adapter is embedded in devlink. This UAF is similar to the one recently reported in ixgbe_remove(). (Link) Fix both issues by moving devlink_free() after adapter->state access, aligning with the cleanup order in ixgbe_probe(). Link: https://lore.kernel.org/intel-wired-lan/20250828020558.1450422-1-den@valinux.co.jp/ Fixes: 29cb3b8d95c7 ("ixgbe: add E610 implementation of FW recovery mode") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Reviewed-by: Jedrzej Jagielski Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index ca1ccc630001..3190ce7e44c7 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -11507,10 +11507,10 @@ static int ixgbe_recovery_probe(struct ixgbe_adapter *adapter) shutdown_aci: mutex_destroy(&adapter->hw.aci.lock); ixgbe_release_hw_control(adapter); - devlink_free(adapter->devlink); clean_up_probe: disable_dev = !test_and_set_bit(__IXGBE_DISABLED, &adapter->state); free_netdev(netdev); + devlink_free(adapter->devlink); pci_release_mem_regions(pdev); if (disable_dev) pci_disable_device(pdev); -- 2.47.1 From: Kohei Enju The current implementation of the igc driver doesn't power up the PHY before the link test in igc_ethtool_diag_test(), causing the link test to always report FAIL when admin state is down and the PHY is consequently powered down. To test the link state regardless of admin state, power up the PHY before the link test in the offline test path. After the link test, the original PHY state is restored by igc_reset(), so additional code which explicitly restores the original state is not necessary. Note that this change is applied only for the offline test path. This is because in the online path we shouldn't interrupt normal networking operation and powering up the PHY and restoring the original state would interrupt that. This implementation also uses igc_power_up_phy_copper() without checking the media type, since igc devices are currently only copper devices and the function is called in other places without checking the media type. Furthermore, the powering up is on a best-effort basis, that is, we don't handle failures of powering up (e.g. bus error) and just let the test report FAIL. Tested on Intel Corporation Ethernet Controller I226-V (rev 04) with cable connected and link available. Set device down and do ethtool test. # ip link set dev enp0s5 down Without patch: # ethtool --test enp0s5 The test result is FAIL The test extra info: Register test (offline) 0 Eeprom test (offline) 0 Interrupt test (offline) 0 Loopback test (offline) 0 Link test (on/offline) 1 With patch: # ethtool --test enp0s5 The test result is PASS The test extra info: Register test (offline) 0 Eeprom test (offline) 0 Interrupt test (offline) 0 Loopback test (offline) 0 Link test (on/offline) 0 Fixes: f026d8ca2904 ("igc: add support to eeprom, registers and link self-tests") Signed-off-by: Kohei Enju Reviewed-by: Vitaly Lifshits Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/igc/igc_ethtool.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c index f3e7218ba6f3..ca93629b1d3a 100644 --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c @@ -2094,6 +2094,9 @@ static void igc_ethtool_diag_test(struct net_device *netdev, netdev_info(adapter->netdev, "Offline testing starting"); set_bit(__IGC_TESTING, &adapter->state); + /* power up PHY for link test */ + igc_power_up_phy_copper(&adapter->hw); + /* Link test performed before hardware reset so autoneg doesn't * interfere with test result */ -- 2.47.1 From: Kohei Enju igb_get_sset_count() returns -ENOTSUPP when a given stringset is not supported, causing userland programs to get "Unknown error 524". Since EOPNOTSUPP should be used when error is propagated to userland, return -EOPNOTSUPP instead of -ENOTSUPP. Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c index f8a208c84f15..10e2445e0ded 100644 --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c @@ -2281,7 +2281,7 @@ static int igb_get_sset_count(struct net_device *netdev, int sset) case ETH_SS_PRIV_FLAGS: return IGB_PRIV_FLAGS_STR_LEN; default: - return -ENOTSUPP; + return -EOPNOTSUPP; } } -- 2.47.1 From: Kohei Enju igc_ethtool_get_sset_count() returns -ENOTSUPP when a given stringset is not supported, causing userland programs to get "Unknown error 524". Since EOPNOTSUPP should be used when error is propagated to userland, return -EOPNOTSUPP instead of -ENOTSUPP. Fixes: 36b9fea60961 ("igc: Add support for statistics") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/igc/igc_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c index ca93629b1d3a..bb783042d1af 100644 --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c @@ -810,7 +810,7 @@ static int igc_ethtool_get_sset_count(struct net_device *netdev, int sset) case ETH_SS_PRIV_FLAGS: return IGC_PRIV_FLAGS_STR_LEN; default: - return -ENOTSUPP; + return -EOPNOTSUPP; } } -- 2.47.1 From: Kohei Enju When the requested PTP feature is not supported, ixgbe_ptp_feature_enable() returns -ENOTSUPP, causing userland programs to get "Unknown error 524". Since EOPNOTSUPP should be used when error is propagated to userland, return -EOPNOTSUPP instead of -ENOTSUPP. Fixes: 3a6a4edaa592 ("ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC)") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c index 114dd88fc71c..6885d2343c48 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c @@ -641,7 +641,7 @@ static int ixgbe_ptp_feature_enable(struct ptp_clock_info *ptp, * disabled */ if (rq->type != PTP_CLK_REQ_PPS || !adapter->ptp_setup_sdp) - return -ENOTSUPP; + return -EOPNOTSUPP; if (on) adapter->flags2 |= IXGBE_FLAG2_PTP_PPS_ENABLED; -- 2.47.1