Re: [Intel-wired-lan] [PATCH bpf-next v12 0/5] xsk: TX metadata Launch Time support
Hello: This series was applied to bpf/bpf-next.git (net) by Martin KaFai Lau : On Sun, 16 Feb 2025 17:34:25 +0800 you wrote: > This series expands the XDP TX metadata framework to allow user > applications to pass per packet 64-bit launch time directly to the kernel > driver, requesting launch time hardware offload support. The XDP TX > metadata framework will not perform any clock conversion or packet > reordering. > > Please note that the role of Tx metadata is just to pass the launch time, > not to enable the offload feature. Users will need to enable the launch > time hardware offload feature of the device by using the respective > command, such as the tc-etf command. > > [...] Here is the summary with links: - [bpf-next,v12,1/5] xsk: Add launch time hardware offload support to XDP Tx metadata https://git.kernel.org/bpf/bpf-next/c/ca4419f15abd - [bpf-next,v12,2/5] selftests/bpf: Add launch time request to xdp_hw_metadata https://git.kernel.org/bpf/bpf-next/c/6164847e5403 - [bpf-next,v12,3/5] net: stmmac: Add launch time support to XDP ZC https://git.kernel.org/bpf/bpf-next/c/04f64dea1364 - [bpf-next,v12,4/5] igc: Refactor empty frame insertion for launch time support https://git.kernel.org/bpf/bpf-next/c/f9b53bb13923 - [bpf-next,v12,5/5] igc: Add launch time support to XDP ZC https://git.kernel.org/bpf/bpf-next/c/d7c3a7ff7502 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [Intel-wired-lan] [RFC net-next v2 1/2] devlink: add whole device devlink instance
On Wed, 19 Feb 2025 17:32:54 +0100 Przemek Kitszel wrote: > Add a support for whole device devlink instance. Intented as a entity > over all PF devices on given physical device. > > In case of ice driver we have multiple PF devices (with their devlink > dev representation), that have separate drivers loaded. However those > still do share lots of resources due to being the on same HW. Examples > include PTP clock and RSS LUT. Historically such stuff was assigned to > PF0, but that was both not clear and not working well. Now such stuff > is moved to be covered into struct ice_adapter, there is just one instance > of such per HW. > > This patch adds a devlink instance that corresponds to that ice_adapter, > to allow arbitrage over resources (as RSS LUT) via it (further in the > series (RFC NOTE: stripped out so far)). > > Thanks to Wojciech Drewek for very nice naming of the devlink instance: > PF0: pci/:00:18.0 > whole-dev:pci/:00:18 > But I made this a param for now (driver is free to pass just "whole-dev"). Which only works nicely if you're talking about functions not full separate links :) When I was thinking about it a while back my intuition was that we should have a single instance, just accessible under multiple names. But I'm not married to that direction if there are problems with it. > $ devlink dev # (Interesting part of output only) > pci/:af:00: > nested_devlink: > pci/:af:00.0 > pci/:af:00.1 > pci/:af:00.2 > pci/:af:00.3 > pci/:af:00.4 > pci/:af:00.5 > pci/:af:00.6 > pci/:af:00.7 Could you go into more details on what stays on the "nested" instances and what moves to the "whole-dev"? Jiri recently pointed out to y'all cases where stuff that should be a port attribute was an instance attribute.
Re: [Intel-wired-lan] [PATCH iwl-next v5 1/9] net: ethtool: mm: extract stmmac verification logic into common library
On Wed, Feb 19, 2025 at 09:53:41PM -0500, Faizal Rahim wrote: > +/** > + * ethtool_mmsv_stop() - Stop MAC Merge Software Verification > + * @mmsv: MAC Merge Software Verification state > + * > + * Drivers should call this method in a state where the hardware is > + * about to lose state, like ndo_stop() or suspend(), and turning off > + * MAC Merge features would be superfluous. Otherwise, prefer > + * ethtool_mmsv_link_state_handle() with up=false. > + */ > +void ethtool_mmsv_stop(struct ethtool_mmsv *mmsv); > + > +/** > + * ethtool_mmsv_link_state_handle() - Inform MAC Merge Software Verification > + * of link state changes > + * @mmsv: MAC Merge Software Verification state > + * @up: True if device carrier is up and able to pass verification packets > + * > + * Calling context is expected to be from a thread, interrupts enabled. s/thread/task/, I think it's a more conventional way of referring to process context. > + */ > +void ethtool_mmsv_link_state_handle(struct ethtool_mmsv *mmsv, bool up); > + > +/** > + * ethtool_mmsv_event_handle() - Inform MAC Merge Software Verification > + *of interrupt-based events > + * @mmsv: MAC Merge Software Verification state > + * @event: Event which took place (packet transmission or reception) > + * > + * Calling context expects to have interrupts disabled. > + */ > +void ethtool_mmsv_event_handle(struct ethtool_mmsv *mmsv, > +enum ethtool_mmsv_event event); > + > +/** > + * ethtool_mmsv_get_mm() - get_mm() hook for MAC Merge Software Verification > + * @mmsv: MAC Merge Software Verification state > + * @state: see struct ethtool_mm_state > + * > + * Drivers are expected to call this from their ethtool_ops :: get_mm() > + * method. > + */ > +void ethtool_mmsv_get_mm(struct ethtool_mmsv *mmsv, > + struct ethtool_mm_state *state); > + > +/** > + * ethtool_mmsv_set_mm() - set_mm() hook for MAC Merge Software Verification > + * @mmsv: MAC Merge Software Verification state > + * @cfg: see struct ethtool_mm_cfg > + * > + * Drivers are expected to call this from their ethtool_ops :: set_mm() > + * method. > + */ > +void ethtool_mmsv_set_mm(struct ethtool_mmsv *mmsv, struct ethtool_mm_cfg > *cfg); > + > +/** > + * ethtool_mmsv_init() - Initialize MAC Merge Software Verification state > + * @mmsv: MAC Merge Software Verification state > + * @dev: Pointer to network interface > + * @ops: Methods for implementing the generic functionality > + * > + * The MAC Merge Software Verification is a timer- and event-based state > + * machine intended for network interfaces which lack a hardware-based > + * TX verification process (as per IEEE 802.3 clause 99.4.3). The timer > + * is managed by the core code, whereas events are supplied by the > + * driver explicitly calling one of the other API functions. > + */ > +void ethtool_mmsv_init(struct ethtool_mmsv *mmsv, struct net_device *dev, > +const struct ethtool_mmsv_ops *ops); The kernel-doc comments are fine, but I think the convention is to put them near the function definitions (in net/ethtool/mm.c) rather than near the function prototypes, for the very simple reason that in the C language, you can have multiple function declarations but a single definition. The kernel-doc for the structures is fine where it is.
Re: [Intel-wired-lan] [PATCH iwl-next v5 0/9] igc: Add support for Frame Preemption feature in IGC
On Wed, Feb 19, 2025 at 09:53:40PM -0500, Faizal Rahim wrote: > Introduces support for the FPE feature in the IGC driver. > > The patches aligns with the upstream FPE API: > https://patchwork.kernel.org/project/netdevbpf/cover/20230220122343.1156614-1-vladimir.olt...@nxp.com/ > https://patchwork.kernel.org/project/netdevbpf/cover/20230119122705.73054-1-vladimir.olt...@nxp.com/ > > It builds upon earlier work: > https://patchwork.kernel.org/project/netdevbpf/cover/20220520011538.109-1-vinicius.go...@intel.com/ > > The patch series adds the following functionalities to the IGC driver: > a) Configure FPE using `ethtool --set-mm`. > b) Display FPE settings via `ethtool --show-mm`. > c) View FPE statistics using `ethtool --include-statistics --show-mm'. > e) Block setting preemptible tc in taprio since it is not supported yet. >Existing code already blocks it in mqprio. Thanks for the work, the patch set looks ok to me apart from the minor things I highlighted. It would be good to know that you've tested: - a netdev down/up cycle - a suspend/resume cycle - with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_DMA_API_DEBUG, CONFIG_KASAN all enabled - the kselftest again just so we have more confidence we are not missing some non-obvious issues. @Furong, the set looks close to final state to me, would you mind leaving a Tested-by: tag on patch 1/9?
Re: [Intel-wired-lan] [PATCH iwl-net v2] iavf: fix circular lock dependency with netdev_lock
> -Original Message- > From: Intel-wired-lan On Behalf Of Jakub > Kicinski > Sent: Friday, February 14, 2025 8:40 PM > To: Keller, Jacob E > Cc: Intel Wired LAN ; netdev > ; Nguyen, Anthony L ; > Kitszel, Przemyslaw > Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] iavf: fix circular lock > dependency > with netdev_lock > > On Thu, 13 Feb 2025 16:30:59 -0800 Jacob Keller wrote: > > Analyzing the places where we take crit_lock in the driver there are > > two > > sources: > > > > a) several of the work queue tasks including adminq_task, > > watchdog_task, reset_task, and the finish_config task. > > > > b) various callbacks which ultimately stem back to .ndo operations or > > ethtool operations. > > > > The latter cannot be triggered until after the netdevice registration > > is completed successfully. > > > > The iAVF driver uses alloc_ordered_workqueue, which is an unbound > > workqueue that has a max limit of 1, and thus guarantees that only a > > single work item on the queue is executing at any given time, so none > > of the other work threads could be executing due to the ordered workqueue > guarantees. > > > > The iavf_finish_config() function also does not do anything else after > > register_netdevice, unless it fails. It seems unlikely that the driver > > private crit_lock is protecting anything that register_netdevice() > > itself touches. > > > > Thus, to fix this ABBA lock violation, lets simply release the > > adapter->crit_lock as well as netdev_lock prior to calling > > register_netdevice(). We do still keep holding the RTNL lock as > > required by the function. If we do fail to register the netdevice, > > then we re-acquire the adapter critical lock to finish the transition > > back to __IAVF_INIT_CONFIG_ADAPTER. > > > > This ensures every call where both netdev_lock and the > > adapter->crit_lock are acquired under the same ordering. > > Thanks a lot for figuring this out, much appreciated! > > Reviewed-by: Jakub Kicinski Tested-by: Rafal Romanowski
[Intel-wired-lan] [PATCH iwl-net v2] ice: fix Get Tx Topology AQ command error on E830
From: Paul Greenwalt
The Get Tx Topology AQ command (opcode 0x0418) has different read flag
requriements depending on the hardware/firmware. For E810, E822, and E823
firmware the read flag must be set, and for newer hardware (E825 and E830)
it must not be set.
This results in failure to configure Tx topology and the following warning
message during probe:
DDP package does not support Tx scheduling layers switching feature -
please update to the latest DDP package and try again
The current implementation only handles E825-C but not E830. It is
confusing as we first check ice_is_e825c() and then set the flag in the set
case. Finally, we check ice_is_e825c() again and set the flag for all other
hardware in both the set and get case.
Instead, notice that we always need the read flag for set, but only need
the read flag for get on E810, E822, and E823 firmware. Fix the logic to
check the MAC type and set the read flag in get only on the older devices
which require it.
Fixes: ba1124f58afd ("ice: Add E830 device IDs, MAC type and registers")
Signed-off-by: Paul Greenwalt
Signed-off-by: Jacob Keller
---
Changes in v2:
- Update commit message to include the warning users see
- Rework code to set the flag for E810 and E822 instead of to *not* set it
for E825-C and E830. We anticipate that future hardware and firmware
versions will behave like E830.
- Link to v1:
https://lore.kernel.org/r/20250218-jk-e830-ddp-loading-fix-v1-1-47dc8e8d4...@intel.com
---
drivers/net/ethernet/intel/ice/ice_ddp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c
b/drivers/net/ethernet/intel/ice/ice_ddp.c
index
03988be03729b76e96188864896527060c8c4d5b..59323c019544fc1f75dcb8a5d31e0b0c82932fe1
100644
--- a/drivers/net/ethernet/intel/ice/ice_ddp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
@@ -2345,15 +2345,15 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf, u16
buf_size,
cmd->set_flags |= ICE_AQC_TX_TOPO_FLAGS_SRC_RAM |
ICE_AQC_TX_TOPO_FLAGS_LOAD_NEW;
- if (ice_is_e825c(hw))
- desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
+ desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
} else {
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_get_tx_topo);
cmd->get_flags = ICE_AQC_TX_TOPO_GET_RAM;
- }
- if (!ice_is_e825c(hw))
- desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
+ if (hw->mac_type == ICE_MAC_E810 ||
+ hw->mac_type == ICE_MAC_GENERIC)
+ desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
+ }
status = ice_aq_send_cmd(hw, &desc, buf, buf_size, cd);
if (status)
---
base-commit: 992ee3ed6e9fdd0be83a7daa5ff738e3cf86047f
change-id: 20250218-jk-e830-ddp-loading-fix-9efdbdfc270a
Best regards,
--
Jacob Keller
Re: [Intel-wired-lan] [PATCH iwl-net] ice: fix Get Tx Topology AQ command error on E830
On 2/19/2025 1:37 AM, Michal Swiatkowski wrote:
> On Tue, Feb 18, 2025 at 04:46:34PM -0800, Jacob Keller wrote:
>> From: Paul Greenwalt
>>
>> With E830 Get Tx Topology AQ command (opcode 0x0418) returns an error when
>> setting the AQ command read flag, and since the get command is a direct
>> command there is no need to set the read flag.
>>
>> Fix this by only setting read flag on set command.
>
> Why it isn't true for other hw? I mean, why not:
> if (set)
> RD_FLAG
> else
> NOT_RD_FLAG
> Other hw needs RD flag in case of get too?
>
>From what I understand, we didn't anticipate this flow changing. E810
and E822 hardware require FLAG_RD for both get and set, while E825-C and
E830 expect FLAG_RD only for set, but not for get.
>>
>
> Don't you need fixes tag?
You're correct. I'll add it in v2
>> Signed-off-by: Paul Greenwalt
>> Signed-off-by: Jacob Keller
>> ---
>> drivers/net/ethernet/intel/ice/ice_ddp.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c
>> b/drivers/net/ethernet/intel/ice/ice_ddp.c
>> index
>> 03988be03729b76e96188864896527060c8c4d5b..49bd49ab3ccf36c990144894e887341459377a2d
>> 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_ddp.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
>> @@ -2345,15 +2345,15 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf, u16
>> buf_size,
>> cmd->set_flags |= ICE_AQC_TX_TOPO_FLAGS_SRC_RAM |
>>ICE_AQC_TX_TOPO_FLAGS_LOAD_NEW;
>>
>> -if (ice_is_e825c(hw))
>> -desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
>> +desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
>> } else {
>> ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_get_tx_topo);
>> cmd->get_flags = ICE_AQC_TX_TOPO_GET_RAM;
>> -}
>>
>> -if (!ice_is_e825c(hw))
>> -desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
>> +if (hw->mac_type != ICE_MAC_GENERIC_3K_E825 &&
>> +hw->mac_type != ICE_MAC_E830)
>> +desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
>> +}
>>
>> status = ice_aq_send_cmd(hw, &desc, buf, buf_size, cd);
>> if (status)
>>
>
> In general looks fine, only one question.
>
> Thanks,
> Michal
Thanks for the review, I'll send a v2 with this cleaned up and include a
fixes tag.
>
>> ---
>> base-commit: f5da7c45188eea71394bf445655cae2df88a7788
>> change-id: 20250218-jk-e830-ddp-loading-fix-9efdbdfc270a
>>
>> Best regards,
>> --
>> Jacob Keller
Re: [Intel-wired-lan] [PATCH iwl-next] igc: Change Tx mode for MQPRIO offloading
On 17/2/2025 7:45 pm, Kurt Kanzenbach wrote: The current MQPRIO offload implementation uses the legacy TSN Tx mode. In this mode the hardware uses four packet buffers and considers queue priorities. In order to harmonize the TAPRIO implementation with MQPRIO switch to the Missed "," ? In order to harmonize the TAPRIO implementation with MQPRIO, switch to the diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index 1e44374ca1ffbb86e9893266c590f318984ef574..6e4582de9602db2c6667f1736cc2acaa4d4b5201 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -47,7 +47,7 @@ static unsigned int igc_tsn_new_flags(struct igc_adapter *adapter) new_flags |= IGC_FLAG_TSN_QAV_ENABLED; if (adapter->strict_priority_enable) - new_flags |= IGC_FLAG_TSN_LEGACY_ENABLED; + new_flags |= IGC_FLAG_TSN_QBV_ENABLED; return new_flags; } IGC_FLAG_TSN_QBV_ENABLED is set multiple times in different lines: if (adapter->taprio_offload_enable) new_flags |= IGC_FLAG_TSN_QBV_ENABLED; if (is_any_launchtime(adapter)) new_flags |= IGC_FLAG_TSN_QBV_ENABLED; if (is_cbs_enabled(adapter)) new_flags |= IGC_FLAG_TSN_QAV_ENABLED; if (adapter->strict_priority_enable) new_flags |= IGC_FLAG_TSN_QBV_ENABLED; return new_flags; } We can combine the conditions to simplify: if (adapter->taprio_offload_enable || is_any_launchtime(adapter) || adapter->strict_priority_enable) new_flags |= IGC_FLAG_TSN_QBV_ENABLED;
Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix Get Tx Topology AQ command error on E830
On Thu, Feb 20, 2025 at 03:15:24PM -0800, Jacob Keller wrote:
> From: Paul Greenwalt
>
> The Get Tx Topology AQ command (opcode 0x0418) has different read flag
> requriements depending on the hardware/firmware. For E810, E822, and E823
> firmware the read flag must be set, and for newer hardware (E825 and E830)
> it must not be set.
>
> This results in failure to configure Tx topology and the following warning
> message during probe:
>
> DDP package does not support Tx scheduling layers switching feature -
> please update to the latest DDP package and try again
>
> The current implementation only handles E825-C but not E830. It is
> confusing as we first check ice_is_e825c() and then set the flag in the set
> case. Finally, we check ice_is_e825c() again and set the flag for all other
> hardware in both the set and get case.
>
> Instead, notice that we always need the read flag for set, but only need
> the read flag for get on E810, E822, and E823 firmware. Fix the logic to
> check the MAC type and set the read flag in get only on the older devices
> which require it.
>
> Fixes: ba1124f58afd ("ice: Add E830 device IDs, MAC type and registers")
> Signed-off-by: Paul Greenwalt
> Signed-off-by: Jacob Keller
> ---
> Changes in v2:
> - Update commit message to include the warning users see
> - Rework code to set the flag for E810 and E822 instead of to *not* set it
> for E825-C and E830. We anticipate that future hardware and firmware
> versions will behave like E830.
> - Link to v1:
> https://lore.kernel.org/r/20250218-jk-e830-ddp-loading-fix-v1-1-47dc8e8d4...@intel.com
> ---
> drivers/net/ethernet/intel/ice/ice_ddp.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c
> b/drivers/net/ethernet/intel/ice/ice_ddp.c
> index
> 03988be03729b76e96188864896527060c8c4d5b..59323c019544fc1f75dcb8a5d31e0b0c82932fe1
> 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ddp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
> @@ -2345,15 +2345,15 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf, u16
> buf_size,
> cmd->set_flags |= ICE_AQC_TX_TOPO_FLAGS_SRC_RAM |
> ICE_AQC_TX_TOPO_FLAGS_LOAD_NEW;
>
> - if (ice_is_e825c(hw))
> - desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> + desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> } else {
> ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_get_tx_topo);
> cmd->get_flags = ICE_AQC_TX_TOPO_GET_RAM;
> - }
>
> - if (!ice_is_e825c(hw))
> - desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> + if (hw->mac_type == ICE_MAC_E810 ||
> + hw->mac_type == ICE_MAC_GENERIC)
> + desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> + }
>
> status = ice_aq_send_cmd(hw, &desc, buf, buf_size, cd);
> if (status)
>
Thanks for fixing
Reviewed-by: Michal Swiatkowski
> ---
> base-commit: 992ee3ed6e9fdd0be83a7daa5ff738e3cf86047f
> change-id: 20250218-jk-e830-ddp-loading-fix-9efdbdfc270a
>
> Best regards,
> --
> Jacob Keller
>
[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS 76e04786735e2864bec8666e116cb1ba7bc4f578
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue branch HEAD: 76e04786735e2864bec8666e116cb1ba7bc4f578 ice: add ice driver PTP pin documentation elapsed time: 1454m configs tested: 74 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc randconfig-001-20250220gcc-13.2.0 arc randconfig-002-20250220gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allyesconfiggcc-14.2.0 arm randconfig-001-20250220gcc-14.2.0 arm randconfig-002-20250220gcc-14.2.0 arm randconfig-003-20250220gcc-14.2.0 arm randconfig-004-20250220gcc-14.2.0 arm64 allmodconfigclang-18 arm64randconfig-001-20250220gcc-14.2.0 arm64randconfig-002-20250220gcc-14.2.0 arm64randconfig-003-20250220clang-21 arm64randconfig-004-20250220gcc-14.2.0 csky randconfig-001-20250220gcc-14.2.0 csky randconfig-002-20250220gcc-14.2.0 hexagon allmodconfigclang-21 hexagon allyesconfigclang-18 hexagon randconfig-001-20250220clang-21 hexagon randconfig-002-20250220clang-21 i386allmodconfiggcc-12 i386 allnoconfiggcc-12 i386allyesconfiggcc-12 i386 buildonly-randconfig-001-20250220gcc-12 i386 buildonly-randconfig-002-20250220gcc-12 i386 buildonly-randconfig-003-20250220gcc-12 i386 buildonly-randconfig-004-20250220clang-19 i386 buildonly-randconfig-005-20250220clang-19 i386 buildonly-randconfig-006-20250220clang-19 i386 defconfigclang-19 loongarchrandconfig-001-20250220gcc-14.2.0 loongarchrandconfig-002-20250220gcc-14.2.0 nios2randconfig-001-20250220gcc-14.2.0 nios2randconfig-002-20250220gcc-14.2.0 parisc randconfig-001-20250220gcc-14.2.0 parisc randconfig-002-20250220gcc-14.2.0 powerpc randconfig-001-20250220gcc-14.2.0 powerpc randconfig-002-20250220clang-16 powerpc randconfig-003-20250220clang-21 powerpc64randconfig-001-20250220clang-16 powerpc64randconfig-002-20250220clang-18 powerpc64randconfig-003-20250220gcc-14.2.0 riscvrandconfig-001-20250220gcc-14.2.0 riscvrandconfig-002-20250220clang-21 s390allmodconfigclang-19 s390allyesconfiggcc-14.2.0 s390 randconfig-001-20250220clang-19 s390 randconfig-002-20250220gcc-14.2.0 sh allmodconfiggcc-14.2.0 sh allyesconfiggcc-14.2.0 sh randconfig-001-20250220gcc-14.2.0 sh randconfig-002-20250220gcc-14.2.0 sparc allmodconfiggcc-14.2.0 sparcrandconfig-001-20250220gcc-14.2.0 sparcrandconfig-002-20250220gcc-14.2.0 sparc64 randconfig-001-20250220gcc-14.2.0 sparc64 randconfig-002-20250220gcc-14.2.0 um allmodconfigclang-21 um allyesconfiggcc-12 um randconfig-001-20250220gcc-12 um randconfig-002-20250220gcc-12 x86_64 allnoconfigclang-19 x86_64 allyesconfigclang-19 x86_64 buildonly-randconfig-001-20250220gcc-12 x86_64 buildonly-randconfig-002-20250220gcc-12 x86_64 buildonly-randconfig-003-20250220gcc-12 x86_64 buildonly-randconfig-004-20250220gcc-12 x86_64 buildonly-randconfig-005-20250220gcc-12 x86_64 buildonly-randconfig-006-20250220gcc-12 x86_64 defconfiggcc-11 xtensa randconfig-001-20250220gcc-14.2.0 xtensa randconfig-002-20250220gcc-14.2.0 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[Intel-wired-lan] [tnguy-net-queue:dev-queue] BUILD SUCCESS a67a634dde15f8decd1d18738fe672afb185732b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue branch HEAD: a67a634dde15f8decd1d18738fe672afb185732b idpf: check error for register_netdev() on init elapsed time: 1456m configs tested: 74 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc randconfig-001-20250220gcc-13.2.0 arc randconfig-002-20250220gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allyesconfiggcc-14.2.0 arm randconfig-001-20250220gcc-14.2.0 arm randconfig-002-20250220gcc-14.2.0 arm randconfig-003-20250220gcc-14.2.0 arm randconfig-004-20250220gcc-14.2.0 arm64 allmodconfigclang-18 arm64randconfig-001-20250220gcc-14.2.0 arm64randconfig-002-20250220gcc-14.2.0 arm64randconfig-003-20250220clang-21 arm64randconfig-004-20250220gcc-14.2.0 csky randconfig-001-20250220gcc-14.2.0 csky randconfig-002-20250220gcc-14.2.0 hexagon allmodconfigclang-21 hexagon allyesconfigclang-18 hexagon randconfig-001-20250220clang-21 hexagon randconfig-002-20250220clang-21 i386allmodconfiggcc-12 i386 allnoconfiggcc-12 i386allyesconfiggcc-12 i386 buildonly-randconfig-001-20250220gcc-12 i386 buildonly-randconfig-002-20250220gcc-12 i386 buildonly-randconfig-003-20250220gcc-12 i386 buildonly-randconfig-004-20250220clang-19 i386 buildonly-randconfig-005-20250220clang-19 i386 buildonly-randconfig-006-20250220clang-19 i386 defconfigclang-19 loongarchrandconfig-001-20250220gcc-14.2.0 loongarchrandconfig-002-20250220gcc-14.2.0 nios2randconfig-001-20250220gcc-14.2.0 nios2randconfig-002-20250220gcc-14.2.0 parisc randconfig-001-20250220gcc-14.2.0 parisc randconfig-002-20250220gcc-14.2.0 powerpc randconfig-001-20250220gcc-14.2.0 powerpc randconfig-002-20250220clang-16 powerpc randconfig-003-20250220clang-21 powerpc64randconfig-001-20250220clang-16 powerpc64randconfig-002-20250220clang-18 powerpc64randconfig-003-20250220gcc-14.2.0 riscvrandconfig-001-20250220gcc-14.2.0 riscvrandconfig-002-20250220clang-21 s390allmodconfigclang-19 s390allyesconfiggcc-14.2.0 s390 randconfig-001-20250220clang-19 s390 randconfig-002-20250220gcc-14.2.0 sh allmodconfiggcc-14.2.0 sh allyesconfiggcc-14.2.0 sh randconfig-001-20250220gcc-14.2.0 sh randconfig-002-20250220gcc-14.2.0 sparc allmodconfiggcc-14.2.0 sparcrandconfig-001-20250220gcc-14.2.0 sparcrandconfig-002-20250220gcc-14.2.0 sparc64 randconfig-001-20250220gcc-14.2.0 sparc64 randconfig-002-20250220gcc-14.2.0 um allmodconfigclang-21 um allyesconfiggcc-12 um randconfig-001-20250220gcc-12 um randconfig-002-20250220gcc-12 x86_64 allnoconfigclang-19 x86_64 allyesconfigclang-19 x86_64 buildonly-randconfig-001-20250220gcc-12 x86_64 buildonly-randconfig-002-20250220gcc-12 x86_64 buildonly-randconfig-003-20250220gcc-12 x86_64 buildonly-randconfig-004-20250220gcc-12 x86_64 buildonly-randconfig-005-20250220gcc-12 x86_64 buildonly-randconfig-006-20250220gcc-12 x86_64 defconfiggcc-11 xtensa randconfig-001-20250220gcc-14.2.0 xtensa randconfig-002-20250220gcc-14.2.0 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[Intel-wired-lan] The ice driver may rarely return incorrect statistics counter values
We have observed a very rare issue in Intel E810 environments where SNMP-retrieved TX/RX counter values are sometimes nearly twice the actual values. Upon investigation, we identified a problem in the process that updates the transmit and receive ring statistics in the ice driver. This issue occurs when the counter update process is executed simultaneously on different CPU cores. I have attached a patch to fix this issue. This patch is intended for Linux kernel 5.15 on Ubuntu 22.04, as my environment is Ubuntu 22.04. In my test environment, applying this patch prevents the issue from occurring. The function ice_update_vsi_ring_stats takes a pointer to a struct ice_vsi as an argument. This structure is allocated on the heap and shared across all CPU cores. The function resets the counter values to zero and then accumulates the values from each ring of the NIC. However, since struct ice_vsi is shared across all CPU cores, the following race condition can occur when ice_update_vsi_ring_stats is executed simultaneously on different CPUs: 1. Multiple CPU cores reset the counter values in struct ice_vsi to zero at the same time. 2. Each CPU core independently increments the counter values. As a result, the counter values may be updated to a higher-than-actual value. The attached patch modifies the implementation to store the counter values on the stack, initialize them to zero, increment them with the values from each ring, and finally update struct ice_vsi. By avoiding the use of shared data for intermediate calculations, this fix prevents the issue. In my environment, multiple Intel E810 NICs are bonded together. I use Zabbix to graph the RX/TX counters of the bonding interface. However, due to the way bonding ignores decreases in the counters of slave interfaces, this issue makes the statistics completely unreliable. Graphs generated from the slave interfaces may appear normal because, even if the counter temporarily increases, it is corrected in the next observation. When I reported this issue to the Ubuntu bug tracking system, I was told to get it merged upstream first. I would like this issue to be fixed, but what should I do to get it accepted? Any advice would be greatly appreciated. ice_update_vsi_ring_stats.patch Description: Binary data
Re: [Intel-wired-lan] [PATCH iwl-net] ice: fix Get Tx Topology AQ command error on E830
On Thu, Feb 20, 2025 at 02:45:41PM -0800, Jacob Keller wrote:
>
>
> On 2/19/2025 1:37 AM, Michal Swiatkowski wrote:
> > On Tue, Feb 18, 2025 at 04:46:34PM -0800, Jacob Keller wrote:
> >> From: Paul Greenwalt
> >>
> >> With E830 Get Tx Topology AQ command (opcode 0x0418) returns an error when
> >> setting the AQ command read flag, and since the get command is a direct
> >> command there is no need to set the read flag.
> >>
> >> Fix this by only setting read flag on set command.
> >
> > Why it isn't true for other hw? I mean, why not:
> > if (set)
> > RD_FLAG
> > else
> > NOT_RD_FLAG
> > Other hw needs RD flag in case of get too?
> >
>
> From what I understand, we didn't anticipate this flow changing. E810
> and E822 hardware require FLAG_RD for both get and set, while E825-C and
> E830 expect FLAG_RD only for set, but not for get.
>
Thanks for explanation. Seems resonable from driver perspective and not
so reasonable from firmware, but maybe this difference is somehow
important.
Thanks,
Michal
> >>
> >
> > Don't you need fixes tag?
>
> You're correct. I'll add it in v2
>
> >> Signed-off-by: Paul Greenwalt
> >> Signed-off-by: Jacob Keller
> >> ---
> >> drivers/net/ethernet/intel/ice/ice_ddp.c | 10 +-
> >> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c
> >> b/drivers/net/ethernet/intel/ice/ice_ddp.c
> >> index
> >> 03988be03729b76e96188864896527060c8c4d5b..49bd49ab3ccf36c990144894e887341459377a2d
> >> 100644
> >> --- a/drivers/net/ethernet/intel/ice/ice_ddp.c
> >> +++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
> >> @@ -2345,15 +2345,15 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf,
> >> u16 buf_size,
> >>cmd->set_flags |= ICE_AQC_TX_TOPO_FLAGS_SRC_RAM |
> >> ICE_AQC_TX_TOPO_FLAGS_LOAD_NEW;
> >>
> >> - if (ice_is_e825c(hw))
> >> - desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> >> + desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> >>} else {
> >>ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_get_tx_topo);
> >>cmd->get_flags = ICE_AQC_TX_TOPO_GET_RAM;
> >> - }
> >>
> >> - if (!ice_is_e825c(hw))
> >> - desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> >> + if (hw->mac_type != ICE_MAC_GENERIC_3K_E825 &&
> >> + hw->mac_type != ICE_MAC_E830)
> >> + desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
> >> + }
> >>
> >>status = ice_aq_send_cmd(hw, &desc, buf, buf_size, cd);
> >>if (status)
> >>
> >
> > In general looks fine, only one question.
> >
> > Thanks,
> > Michal
>
> Thanks for the review, I'll send a v2 with this cleaned up and include a
> fixes tag.
>
> >
> >> ---
> >> base-commit: f5da7c45188eea71394bf445655cae2df88a7788
> >> change-id: 20250218-jk-e830-ddp-loading-fix-9efdbdfc270a
> >>
> >> Best regards,
> >> --
> >> Jacob Keller
>
Re: [Intel-wired-lan] [PATCH iwl-next 3/3] ice: add ice driver PTP pin documentation
On Fri, Feb 07, 2025 at 07:02:54PM +0100, Arkadiusz Kubalewski wrote: > 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 Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v4 5/6] ice: support egress drop rules on PF
On Fri, Feb 14, 2025 at 09:50:39AM +0100, Larysa Zaremba wrote: > tc clsact qdisc allows us to add offloaded egress rules with commands such > as the following one: > > tc filter add dev egress protocol lldp flower skip_sw action drop > > Support the egress rule drop action when added to PF, with a few caveats: > * in switchdev mode, all PF traffic has to go uplink with an exception for > LLDP that can be delegated to a single VSI at a time > * in legacy mode, we cannot delegate LLDP functionality to another VSI, so > such packets from PF should not be blocked. > > Also, simplify the rule direction logic, it was previously derived from > actions, but actually can be inherited from the tc block (and flipped in > case of port representors). > > Reviewed-by: Michal Swiatkowski > Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v4 6/6] ice: enable LLDP TX for VFs through tc
On Fri, Feb 14, 2025 at 09:50:40AM +0100, Larysa Zaremba wrote: > Only a single VSI can be in charge of sending LLDP frames, sometimes it is > beneficial to assign this function to a VF, that is possible to do with tc > capabilities in the switchdev mode. It requires first blocking the PF from > sending the LLDP frames with a following command: > > tc filter add dev egress protocol lldp flower skip_sw action drop > > Then it becomes possible to configure a forward rule from a VF port > representor to uplink instead. > > tc filter add dev ingress protocol lldp flower skip_sw > action mirred egress redirect dev > > How LLDP exclusivity was done previously is LLDP traffic was blocked for a > whole port by a single rule and PF was bypassing that. Now at least in the > switchdev mode, every separate VSI has to have its own drop rule. Another > complication is the fact that tc does not respect when the driver refuses > to delete a rule, so returning an error results in a HW rule still present > with no way to reference it through tc. This is addressed by allowing the > PF rule to be deleted at any time, but making the VF forward rule "dormant" > in such case, this means it is deleted from HW but stays in tc and driver's > bookkeeping to be restored when drop rule is added back to the PF. > > Implement tc configuration handling which enables the user to transmit LLDP > packets from VF instead of PF. > > Reviewed-by: Michal Swiatkowski > Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v4 1/6] ice: fix check for existing switch rule
On Fri, Feb 14, 2025 at 09:50:35AM +0100, Larysa Zaremba wrote: > From: Mateusz Pacuszka > > In case the rule already exists and another VSI wants to subscribe to it > new VSI list is being created and both VSIs are moved to it. > Currently, the check for already existing VSI with the same rule is done > based on fdw_id.hw_vsi_id, which applies only to LOOKUP_RX flag. > Change it to vsi_handle. This is software VSI ID, but it can be applied > here, because vsi_map itself is also based on it. > > Additionally change return status in case the VSI already exists in the > VSI map to "Already exists". Such case should be handled by the caller. FWIIW, I might have made this two patches, but I don't feel particularly strongly about it. > > Signed-off-by: Mateusz Pacuszka > Reviewed-by: Przemek Kitszel > Reviewed-by: Michal Swiatkowski > Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next v4 4/6] ice: remove headers argument from ice_tc_count_lkups
On Fri, Feb 14, 2025 at 09:50:38AM +0100, Larysa Zaremba wrote: > Remove the headers argument from the ice_tc_count_lkups() function, because > it is not used anywhere. > > Reviewed-by: Michal Swiatkowski > Signed-off-by: Larysa Zaremba Reviewed-by: Simon Horman
[Intel-wired-lan] [PATCH iwl-net] ice: fix fwlog after driver reinit
Fix an issue when firmware logging stops after devlink reload action
driver_reinit or driver reset. Fix it by restoring fw logging when
it was previously registered before these events.
Restoring fw logging in these cases was faultily removed with new
debugfs fw logging implementation.
Failure to init fw logging is not a critical error so it is safely
ignored.
Fixes: 73671c3162c8 ("ice: enable FW logging")
Reviewed-by: Przemek Kitszel
Signed-off-by: Martyna Szapar-Mudlaw
---
drivers/net/ethernet/intel/ice/ice_main.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
b/drivers/net/ethernet/intel/ice/ice_main.c
index a03e1819e6d5..6d6873003bcb 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5151,6 +5151,13 @@ int ice_load(struct ice_pf *pf)
devl_assert_locked(priv_to_devlink(pf));
+ if (pf->hw.fwlog_cfg.options & ICE_FWLOG_OPTION_IS_REGISTERED) {
+ err = ice_fwlog_register(&pf->hw);
+ if (err)
+ pf->hw.fwlog_cfg.options &=
+ ~ICE_FWLOG_OPTION_IS_REGISTERED;
+ }
+
vsi = ice_get_main_vsi(pf);
/* init channel list */
@@ -7701,6 +7708,13 @@ static void ice_rebuild(struct ice_pf *pf, enum
ice_reset_req reset_type)
goto err_init_ctrlq;
}
+ if (hw->fwlog_cfg.options & ICE_FWLOG_OPTION_IS_REGISTERED) {
+ err = ice_fwlog_register(hw);
+ if (err)
+ hw->fwlog_cfg.options &=
+ ~ICE_FWLOG_OPTION_IS_REGISTERED;
+ }
+
/* if DDP was previously loaded successfully */
if (!ice_is_safe_mode(pf)) {
/* reload the SW DB of filter tables */
--
2.47.0
Re: [Intel-wired-lan] [PATCH iwl-next v4 2/6] ice: do not add LLDP-specific filter if not necessary
On Fri, Feb 14, 2025 at 09:50:36AM +0100, Larysa Zaremba wrote:
> Commit 34295a3696fb ("ice: implement new LLDP filter command")
> introduced the ability to use LLDP-specific filter that directs all
> LLDP traffic to a single VSI. However, current goal is for all trusted VFs
> to be able to see LLDP neighbors, which is impossible to do with the
> special filter.
>
> Make using the generic filter the default choice and fall back to special
> one only if a generic filter cannot be added. That way setups with "NVMs
> where an already existent LLDP filter is blocking the creation of a filter
> to allow LLDP packets" will still be able to configure software Rx LLDP on
> PF only, while all other setups would be able to forward them to VFs too.
>
> Reviewed-by: Michal Swiatkowski
> Signed-off-by: Larysa Zaremba
Reviewed-by: Simon Horman
...
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c
> b/drivers/net/ethernet/intel/ice/ice_common.c
> index aaa592ffd2d8..f2e51bacecf8 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -6010,15 +6010,21 @@ bool ice_fw_supports_lldp_fltr_ctrl(struct ice_hw *hw)
> /**
> * ice_lldp_fltr_add_remove - add or remove a LLDP Rx switch filter
> * @hw: pointer to HW struct
> - * @vsi_num: absolute HW index for VSI
> + * @vsi: VSI to add the filter to
> * @add: boolean for if adding or removing a filter
> + *
> + * Return: 0 on success, -EOPNOTSUPP if the operation cannot be performed
> + * with this HW or VSI, otherwise an error corresponding to
> + * the AQ transaction result.
> */
Thanks for adding the Return section to the kernel doc.
> -int
> -ice_lldp_fltr_add_remove(struct ice_hw *hw, u16 vsi_num, bool add)
> +int ice_lldp_fltr_add_remove(struct ice_hw *hw, struct ice_vsi *vsi, bool
> add)
> {
> struct ice_aqc_lldp_filter_ctrl *cmd;
> struct ice_aq_desc desc;
>
> + if (vsi->type != ICE_VSI_PF || !ice_fw_supports_lldp_fltr_ctrl(hw))
> + return -EOPNOTSUPP;
> +
> cmd = &desc.params.lldp_filter_ctrl;
>
> ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_lldp_filter_ctrl);
...
Re: [Intel-wired-lan] [ixgbe] Crash when running an XDP program
Hey,
Thanks for cooperation. The issue seems to be fixed in
kernel-6.14.0-0.rc3.29.eln146.
Sam.
On Wed, Feb 12, 2025 at 2:04 PM Toke Høiland-Jørgensen wrote:
>
> Maciej Fijalkowski writes:
>
> > On Wed, Feb 12, 2025 at 01:33:09PM +0100, Toke Høiland-Jørgensen wrote:
> >> Hi folks,
> >>
> >> Our LNST testing team uncovered a crash in ixgbe when running an XDP
> >> program, see this report:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2343204
> >>
> >> From looking at the code, it seems to me that the culprit is this commit:
> >>
> >> c824125cbb18 ("ixgbe: Fix passing 0 to ERR_PTR in ixgbe_run_xdp()")
> >>
> >> after that commit, the IS_ERR(skb) check in ixgbe_put_rx_buffer() no
> >> longer triggers, and that function tries to dereference a NULL skb
> >> pointer after an XDP program dropped the frame.
> >>
> >> Could you please fix this?
> >
> > Hi Toke,
> >
> > https://lore.kernel.org/netdev/20250211214343.4092496-5-anthony.l.ngu...@intel.com/
> >
> > can you see if this fixes it?
>
> Ah! I went looking in the -net and -net-next git trees to see if you'd
> already fixed this, but didn't check the list. Thanks for the pointer,
> will see if we can get this tested.
>
> > Validation in our company has always been a mystery to me, sorry for this
> > inconvenience and that we were bad at reviewing :<
>
> No worries, bugs happen; thankfully we caught it early. Also mostly
> meant it as a nudge to try to give XDP testing a more prominent spot :)
>
> -Toke
>
Re: [Intel-wired-lan] [PATCH iwl-next v4 3/6] ice: receive LLDP on trusted VFs
On Fri, Feb 14, 2025 at 09:50:37AM +0100, Larysa Zaremba wrote: > From: Mateusz Pacuszka > > When a trusted VF tries to configure an LLDP multicast address, configure a > rule that would mirror the traffic to this VF, untrusted VFs are not > allowed to receive LLDP at all, so the request to add LLDP MAC address will > always fail for them. > > Add a forwarding LLDP filter to a trusted VF when it tries to add an LLDP > multicast MAC address. The MAC address has to be added after enabling > trust (through restarting the LLDP service). > > Signed-off-by: Mateusz Pacuszka > Co-developed-by: Larysa Zaremba > Signed-off-by: Larysa Zaremba > Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman
[Intel-wired-lan] [tnguy-net-queue:200GbE] BUILD SUCCESS a92c3228766429fe175ecc815f895043ea505587
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 200GbE branch HEAD: a92c3228766429fe175ecc815f895043ea505587 Merge branch 'net-fix-race-of-rtnl_net_lock-dev_net-dev' elapsed time: 2339m configs tested: 95 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfiggcc-14.2.0 alphaallyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allnoconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc randconfig-001-20250220gcc-13.2.0 arc randconfig-002-20250220gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-17 arm allyesconfiggcc-14.2.0 arm randconfig-001-20250220gcc-14.2.0 arm randconfig-002-20250220gcc-14.2.0 arm randconfig-003-20250220gcc-14.2.0 arm randconfig-004-20250220gcc-14.2.0 arm64allmodconfigclang-18 arm64 allnoconfiggcc-14.2.0 arm64 randconfig-001-20250220gcc-14.2.0 arm64 randconfig-002-20250220gcc-14.2.0 arm64 randconfig-003-20250220clang-21 arm64 randconfig-004-20250220gcc-14.2.0 csky allnoconfiggcc-14.2.0 csky randconfig-001-20250220gcc-14.2.0 csky randconfig-002-20250220gcc-14.2.0 hexagon allmodconfigclang-21 hexagon allnoconfigclang-21 hexagon allyesconfigclang-18 hexagon randconfig-001-20250220clang-21 hexagon randconfig-002-20250220clang-21 i386 allmodconfiggcc-12 i386 allnoconfiggcc-12 i386 allyesconfiggcc-12 i386buildonly-randconfig-001-20250220gcc-12 i386buildonly-randconfig-002-20250220gcc-12 i386buildonly-randconfig-003-20250220gcc-12 i386buildonly-randconfig-004-20250220clang-19 i386buildonly-randconfig-005-20250220clang-19 i386buildonly-randconfig-006-20250220clang-19 i386defconfigclang-19 loongarchallmodconfiggcc-14.2.0 loongarch allnoconfiggcc-14.2.0 loongarch randconfig-001-20250220gcc-14.2.0 loongarch randconfig-002-20250220gcc-14.2.0 m68k allmodconfiggcc-14.2.0 m68k allnoconfiggcc-14.2.0 m68k allyesconfiggcc-14.2.0 microblaze allmodconfiggcc-14.2.0 microblaze allyesconfiggcc-14.2.0 mips allnoconfiggcc-14.2.0 nios2 allnoconfiggcc-14.2.0 nios2 randconfig-001-20250220gcc-14.2.0 nios2 randconfig-002-20250220gcc-14.2.0 openrisc allnoconfiggcc-14.2.0 pariscallnoconfiggcc-14.2.0 pariscrandconfig-001-20250220gcc-14.2.0 pariscrandconfig-002-20250220gcc-14.2.0 powerpc allnoconfiggcc-14.2.0 powerpc randconfig-001-20250220gcc-14.2.0 powerpc randconfig-002-20250220clang-16 powerpc randconfig-003-20250220clang-21 powerpc64 randconfig-001-20250220clang-16 powerpc64 randconfig-002-20250220clang-18 powerpc64 randconfig-003-20250220gcc-14.2.0 riscv allnoconfiggcc-14.2.0 riscv randconfig-001-20250220gcc-14.2.0 riscv randconfig-002-20250220clang-21 s390 allmodconfigclang-19 s390 allnoconfigclang-21 s390 allyesconfiggcc-14.2.0 s390 randconfig-001-20250220clang-19 s390 randconfig-002-20250220gcc-14.2.0 sh allmodconfiggcc-14.2.0 sh allyesconfiggcc-14.2.0 shrandconfig-001-20250220gcc-14.2.0 shrandconfig-002-20250220gcc-14.2.0 sparcallmodconfiggcc-14.2.0 sparc randconfig-001-20250220gcc-14.2.0 sparc randconfig-002-20250220gcc-14.2.0 sparc64 randconfig-001-20250220
Re: [Intel-wired-lan] [PATCH iwl-net] ice: fix fwlog after driver reinit
Dear Martyna,
Thank you for your patch.
Am 20.02.25 um 16:04 schrieb Martyna Szapar-Mudlaw:
Fix an issue when firmware logging stops after devlink reload action
driver_reinit or driver reset. Fix it by restoring fw logging when
Maybe elaborate, why/how driver reinit or reset disables fwlog.
it was previously registered before these events.
I’d add a blank line between paragraphs.
Restoring fw logging in these cases was faultily removed with new
debugfs fw logging implementation.
Failure to init fw logging is not a critical error so it is safely
ignored.
How can this be tested?
Fixes: 73671c3162c8 ("ice: enable FW logging")
Reviewed-by: Przemek Kitszel
Signed-off-by: Martyna Szapar-Mudlaw
---
drivers/net/ethernet/intel/ice/ice_main.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
b/drivers/net/ethernet/intel/ice/ice_main.c
index a03e1819e6d5..6d6873003bcb 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5151,6 +5151,13 @@ int ice_load(struct ice_pf *pf)
devl_assert_locked(priv_to_devlink(pf));
+ if (pf->hw.fwlog_cfg.options & ICE_FWLOG_OPTION_IS_REGISTERED) {
+ err = ice_fwlog_register(&pf->hw);
+ if (err)
+ pf->hw.fwlog_cfg.options &=
+ ~ICE_FWLOG_OPTION_IS_REGISTERED;
Should an error be logged in the failure case?
+ }
+
vsi = ice_get_main_vsi(pf);
/* init channel list */
@@ -7701,6 +7708,13 @@ static void ice_rebuild(struct ice_pf *pf, enum
ice_reset_req reset_type)
goto err_init_ctrlq;
}
+ if (hw->fwlog_cfg.options & ICE_FWLOG_OPTION_IS_REGISTERED) {
+ err = ice_fwlog_register(hw);
+ if (err)
+ hw->fwlog_cfg.options &=
+ ~ICE_FWLOG_OPTION_IS_REGISTERED;
+ }
Ditto.
+
/* if DDP was previously loaded successfully */
if (!ice_is_safe_mode(pf)) {
/* reload the SW DB of filter tables */
Kind regards,
Paul
Re: [Intel-wired-lan] [PATCH iwl-next 2/3] ice: change SMA pins to SDP in PTP API
On Fri, Feb 07, 2025 at 07:02:53PM +0100, Arkadiusz Kubalewski wrote: > 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 Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH iwl-next 1/3] ice: redesign dpll sma/u.fl pins control
On Fri, Feb 07, 2025 at 07:02:52PM +0100, Arkadiusz Kubalewski wrote: > 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 Reviewed-by: Simon Horman
Re: [Intel-wired-lan] [PATCH bpf-next v12 1/5] xsk: Add launch time hardware offload support to XDP Tx metadata
On Sun, 16 Feb 2025 17:34:26 +0800 Song Yoong Siang wrote: > Extend the XDP Tx metadata framework so that user can requests launch time > hardware offload, where the Ethernet device will schedule the packet for > transmission at a pre-determined time called launch time. The value of > launch time is communicated from user space to Ethernet driver via > launch_time field of struct xsk_tx_metadata. > > Suggested-by: Stanislav Fomichev > Acked-by: Stanislav Fomichev > Signed-off-by: Song Yoong Siang Acked-by: Jakub Kicinski
Re: [Intel-wired-lan] [PATCH iwl-next v5 5/9] igc: Add support for frame preemption verification
On Wed, Feb 19, 2025 at 09:53:45PM -0500, Faizal Rahim wrote:
> @@ -3956,6 +3970,30 @@ static int igc_uc_unsync(struct net_device *netdev,
> const unsigned char *addr)
> return 0;
> }
>
> +/**
> + * igc_enable_empty_addr_recv - Enable rx of packets with all-zeroes MAC
> address
> + * @adapter: Pointer to the igc_adapter structure.
> + *
> + * Frame preemption verification requires that packets with the all-zeroes
> + * MAC address are allowed to be received by IGC. This function adds the
> + * all-zeroes destination address to the list of acceptable addresses.
> + *
> + * Return: 0 on success, negative value otherwise.
> + */
> +int igc_enable_empty_addr_recv(struct igc_adapter *adapter)
> +{
> + u8 empty[ETH_ALEN] = { };
> +
> + return igc_add_mac_filter(adapter, IGC_MAC_FILTER_TYPE_DST, empty, -1);
> +}
> +
> +void igc_disable_empty_addr_recv(struct igc_adapter *adapter)
> +{
> + u8 empty[ETH_ALEN] = { };
> +
> + igc_del_mac_filter(adapter, IGC_MAC_FILTER_TYPE_DST, empty);
> +}
> +
> /**
> * igc_set_rx_mode - Secondary Unicast, Multicast and Promiscuous mode set
> * @netdev: network interface device structure
> @@ -434,6 +569,11 @@ int igc_tsn_reset(struct igc_adapter *adapter)
> unsigned int new_flags;
> int err = 0;
>
> + if (adapter->fpe.mmsv.pmac_enabled)
> + igc_enable_empty_addr_recv(adapter);
> + else
> + igc_disable_empty_addr_recv(adapter);
> +
> new_flags = igc_tsn_new_flags(adapter);
>
> if (!(new_flags & IGC_FLAG_TSN_ANY_ENABLED))
Please monitor failures to add this MAC address filter somehow, don't
let errors be silent. If it returns -ENOSPC, you won't be able to
receive verification frames, but you'll never know it from the logs
(assuming the netdev_dbg() on the igc_add_mac_filter() success path
doesn't get printed anyway).
Re: [Intel-wired-lan] [PATCH iwl-next v5 9/9] igc: Block setting preemptible traffic class in taprio
On Wed, Feb 19, 2025 at 09:53:49PM -0500, Faizal Rahim wrote: > Since preemptible tc implementation is not ready yet, block it from being > set in taprio. The existing code already blocks it in mqprio. > > Signed-off-by: Faizal Rahim > --- > drivers/net/ethernet/intel/igc/igc_main.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c > b/drivers/net/ethernet/intel/igc/igc_main.c > index 5a6648a12a53..e6a398dbf09b 100644 > --- a/drivers/net/ethernet/intel/igc/igc_main.c > +++ b/drivers/net/ethernet/intel/igc/igc_main.c > @@ -6408,6 +6408,10 @@ static int igc_save_qbv_schedule(struct igc_adapter > *adapter, > if (!validate_schedule(adapter, qopt)) > return -EINVAL; > > + /* preemptible isn't supported yet */ > + if (qopt->mqprio.preemptible_tcs) > + return -EOPNOTSUPP; > + > igc_ptp_read(adapter, &now); > > if (igc_tsn_is_taprio_activated_by_user(adapter) && > -- > 2.34.1 > This patch should be before the patch that makes ethtool_dev_mm_supported() return true for igc, i.e. 7/9 "igc: Add support to get MAC Merge data via ethtool". You don't want the kernel to be in a state at all where it accepts a configuration it doesn't support, even if it's temporary and you're fixing it up within the same patch set, because it may be visible during e.g. a git bisect.
