aboutsummaryrefslogtreecommitdiffstatshomepage
AgeCommit message (Collapse)AuthorFilesLines
2026-05-05Merge branch 'first-series-for-xpcs-based-rsfec-configuration'develdavem/net-nextPaolo Abeni3-24/+122
Mike Marciniszyn says: ==================== first series for xpcs based rsfec configuration The series: - Fixes an addr validation error - Adds MDIO defines associated with RS-FEC - consolidates the handling of the boilerplat ID registers into a routine to report id'ish registers and reduces the lines of code across the entire set of c45 routines. - adds PMA read/write routines https://lore.kernel.org/all/20260428172810.175077-2-mike.marciniszyn@gmail.com/ has been removed from the series and submitted to net as https://lore.kernel.org/all/20260429150049.1643-1-mike.marciniszyn@gmail.com/ pcs reads for DEVS1 and DEVS2 cleaned up 2/3 ==================== Link: https://patch.msgid.link/20260430150802.3521-1-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-05net: eth: fbnic: Add pma read and write accessMike Marciniszyn (Meta)2-0/+72
Document the MDIO interface topology with an ASCII diagram showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD (MMD 1) blocks and their interconnects. The diagram illustrates how 4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to 2 lanes at the PMD. The c45 read and write routines are enhanced to support read and write of the separated PMA for the fbnic. Co-developed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-4-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-05net: eth: fbnic: Consolidate register reads for ids and devsMike Marciniszyn (Meta)1-24/+40
Consolidate the register reads for boiler plate registers to reduce LOC and cleanup pcs reads for DEVS1 to fetch overrides for reserved bits that the hardware does not return. Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-3-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-05net: mdio: Add support for RSFEC Control register for PMAMike Marciniszyn (Meta)1-0/+10
Add the constants associated with RS-FEC configuration and status as well as the indicated separated bits for DEVS1 to convey a separated PMA. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-2-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-04net/sched: speedup tc_dump_qdisc() when tcm_handle is providedEric Dumazet1-10/+17
"tc qdisc show ... handle xxx" filtering can be done by the kernel. A followup patch can do the same for tcm_parent. iproute2/tc needs a small companion patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260503114515.2460477-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: airoha: Introduce airoha_fe_get()/airoha_qdma_get() register read helpersLorenzo Bianconi3-12/+10
Add airoha_fe_get() and airoha_qdma_get() as utility routines for reading a masked field from a specified register. This is a non-functional refactor, no logical changes are introduced to the existing codebase. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260501-airoha_fe_get-airoha_qdma_get-v3-1-126c6f647ccb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: phy: realtek: replace magic number with register bit macrosAleksander Jan Bajkowski1-1/+6
Replace magic number with register bit macros. The description of the RTL8211B interrupt register is obtained from publicly available datasheet (RTL8211B(L) Rev. 1.5 Datasheet) Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20260502092857.156831-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: mana: hardening: Reject zero max_num_queues from GDMA_QUERY_MAX_RESOURCESErni Sri Satya Vennela1-0/+3
In a CVM environment, hardware responses cannot be trusted. The GDMA_QUERY_MAX_RESOURCES command returns resource limits used to determine the maximum number of queues. In mana_gd_query_max_resources(), gc->max_num_queues is initialized from num_online_cpus() and successively clamped by the hardware-reported max_eq, max_cq, max_sq, max_rq, and num_msix_usable values. If any of these hardware values is zero, gc->max_num_queues becomes zero and the function returns success. This leads to a confusing failure later when alloc_etherdev_mq() is called with zero queues, returning NULL and producing a misleading -ENOMEM error. Add an explicit zero check for gc->max_num_queues after all clamping steps and return -ENOSPC for a clear early failure, consistent with the existing gc->num_msix_usable <= 1 guard. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://patch.msgid.link/20260430083627.1873757-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIGErni Sri Satya Vennela1-0/+6
As a part of MANA hardening for CVM, validate that max_num_sq and max_num_rq returned by MANA_QUERY_VPORT_CONFIG are not zero. These values flow into apc->num_queues, which is used as an allocation count and loop bound. A zero value would result in zero-size allocations and incorrect driver behavior. Return -EPROTO if either value is zero. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Link: https://patch.msgid.link/20260430085638.1875400-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04Merge branch 'net-bridge-mcast-support-exponential-field-encoding'Jakub Kicinski6-55/+482
Ujjal Roy says: ==================== net: bridge: mcast: support exponential field encoding Description: This series addresses a mismatch in how multicast query intervals and response codes are handled across IPv4 (IGMPv3) and IPv6 (MLDv2). While decoding logic currently exists, the corresponding encoding logic is missing during query packet generation. This leads to incorrect intervals being transmitted when values exceed their linear thresholds. The patches introduce a unified floating-point encoding approach based on RFC3376 and RFC3810, ensuring that large intervals are correctly represented in QQIC and MRC fields using the exponent-mantissa format. Key Changes: * ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation Removes legacy macros in favor of a cleaner, unified calculation for retrieving intervals from encoded fields, improving code maintainability. * ipv6: mld: rename mldv2_mrc() and add mldv2_qqi() Standardizes MLDv2 terminology by renaming mldv2_mrc() to mldv2_mrd() (Maximum Response Delay) and introducing a new API mldv2_qqi for QQI calculation, improving code readability. * ipv4: igmp: encode multicast exponential fields Introduces the logic to dynamically calculate the exponent and mantissa using bit-scan (fls). This ensures QQIC and MRC fields (8-bit) are properly encoded when transmitting query packets with intervals that exceed their respective linear threshold value of 128 (for QQI/MRT). * ipv6: mld: encode multicast exponential fields Applies similar encoding logic for MLDv2. This ensures QQIC (8-bit) and MRC (16-bit) fields are properly encoded when transmitting query packets with intervals that exceed their respective linear thresholds (128 for QQI; 32768 for MRD). * selftests: net: bridge: add MRC and QQIC field encoding tests Updates bridge selftests to validate both linear and non-linear (exponential) encoding for MRC and QQIC fields, ensuring protocol compliance across IGMPv3 and MLDv2. Impact: These changes ensure that multicast queriers and listeners stay synchronized on timing intervals, preventing protocol timeouts or premature group membership expiration caused by incorrectly formatted packet headers. ==================== Link: https://patch.msgid.link/20260502131907.987-1-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04selftests: net: bridge: add MRC and QQIC field encoding testsUjjal Roy1-8/+132
Enhance vlmc_query_intvl_test and vlmc_query_response_intvl_test in bridge_vlan_mcast.sh to validate IGMPv3/MLDv2 protocol compliance for MRC and QQIC field encoding across both linear and exponential ranges. TEST: Vlan multicast snooping enable [ OK ] TEST: Vlan mcast_query_interval global option default value [ OK ] TEST: Number of tagged IGMPv2 general query [ OK ] TEST: IGMPv3 QQIC linear value 60(s) [ OK ] TEST: MLDv2 QQIC linear value 60(s) [ OK ] TEST: IGMPv3 QQIC non linear value 160(s) [ OK ] TEST: MLDv2 QQIC non linear value 160(s) [ OK ] TEST: Vlan mcast_query_response_interval global option default value [ OK ] TEST: IGMPv3 MRC linear value of 60(x0.1s) [ OK ] TEST: MLDv2 MRC linear value of 24000(ms) [ OK ] TEST: IGMPv3 MRC non linear value of 240(x0.1s) [ OK ] TEST: MLDv2 MRC non linear value of 48000(ms) [ OK ] Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ujjal Roy <royujjal@gmail.com> Link: https://patch.msgid.link/20260502131907.987-6-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04ipv6: mld: encode multicast exponential fieldsUjjal Roy2-2/+121
In MLD, MRC and QQIC fields are not correctly encoded when generating query packets. Since the receiver of the query interprets these fields using the MLDv2 floating-point decoding logic, any value that exceeds the linear threshold is incorrectly parsed as an exponential value, leading to an incorrect interval calculation. Encode and assign the corresponding protocol fields during query generation. Introduce the logic to dynamically calculate the exponent and mantissa using bit-scan (fls). This ensures MRC (16-bit) and QQIC (8-bit) fields are properly encoded when transmitting query packets with intervals that exceed their respective linear thresholds (32768 for MRD; 128 for QQI). RFC3810: If Maximum Response Code >= 32768, the Maximum Response Code field represents a floating-point value as follows: 0 1 2 3 4 5 6 7 8 9 A B C D E F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| exp | mant | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC3810: If QQIC >= 128, the QQIC field represents a floating-point value as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1| exp | mant | +-+-+-+-+-+-+-+-+ Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ujjal Roy <royujjal@gmail.com> Link: https://patch.msgid.link/20260502131907.987-5-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04ipv4: igmp: encode multicast exponential fieldsUjjal Roy2-8/+93
In IGMP, MRC and QQIC fields are not correctly encoded when generating query packets. Since the receiver of the query interprets these fields using the IGMPv3 floating- point decoding logic, any value that exceeds the linear threshold is incorrectly parsed as an exponential value, leading to an incorrect interval calculation. Encode and assign the corresponding protocol fields during query generation. Introduce the logic to dynamically calculate the exponent and mantissa using bit-scan (fls). This ensures MRC and QQIC fields (8-bit) are properly encoded when transmitting query packets with intervals that exceed their respective linear threshold value of 128 (for MRT/QQI). RFC3376: for both MRC and QQIC, values >= 128 represent the same floating-point encoding as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1| exp | mant | +-+-+-+-+-+-+-+-+ Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ujjal Roy <royujjal@gmail.com> Link: https://patch.msgid.link/20260502131907.987-4-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()Ujjal Roy3-26/+61
Rename mldv2_mrc() to mldv2_mrd() as it is used to calculate the Maximum Response Delay from the Maximum Response Code. Introduce a new API mldv2_qqi() to define the existing calculation logic of QQI from QQIC. This also organizes the existing mld_update_qi() API. Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ujjal Roy <royujjal@gmail.com> Link: https://patch.msgid.link/20260502131907.987-3-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculationUjjal Roy3-11/+75
Get rid of the IGMPV3_MRC macro and use the igmpv3_mrt() API to calculate the Max Resp Time from the Maximum Response Code. Similarly, for IGMPV3_QQIC, use the igmpv3_qqi() API to calculate the Querier's Query Interval from the QQIC field. Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ujjal Roy <royujjal@gmail.com> Link: https://patch.msgid.link/20260502131907.987-2-royujjal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04Merge branch 'net-convert-af_netlink-and-af_vsock-to-getsockopt_iter-api'Jakub Kicinski4-19/+232
Breno Leitao says: ==================== net: Convert AF_NETLINK and AF_VSOCK to getsockopt_iter API Continue the work to convert protocols to the new getsockopt_iter API. Convert AF_NETLINK and AF_VSOCK getsockopt implementations to the new sockopt_t/getsockopt_iter API, and add kselftests that verify the size and errno semantics are preserved across the conversion. I chose these two socket families because they are probably one of the most used protocols,, ensuring that any potential bugs will be discovered and reported quickly. ==================== Link: https://patch.msgid.link/20260501-getsock_one-v1-0-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: selftests: add getsockopt_iter regression testsBreno Leitao2-0/+214
Add a single kselftest covering the proto_ops getsockopt_iter conversions for AF_NETLINK and AF_VSOCK, using one fixture per protocol: netlink: NETLINK_PKTINFO covers the flag-style int path (exact size, oversize clamp, undersize -EINVAL); NETLINK_LIST_MEMBERSHIPS covers the size-discovery path that always reports the required buffer length back via optlen, even when the user buffer is too small to receive any group bits. vsock: SO_VM_SOCKETS_BUFFER_SIZE covers the u64 path (exact size, oversize clamp, undersize -EINVAL). Each fixture also exercises an unknown optname and a bogus level so the returned-length / errno semantics preserved by the sockopt_t conversion are pinned down. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260501-getsock_one-v1-3-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04vsock: convert to getsockopt_iterBreno Leitao1-9/+7
Convert AF_VSOCK's getsockopt implementation to use the new getsockopt_iter callback with sockopt_t. The single vsock_connectible_getsockopt() callback is shared by both vsock_stream_ops and vsock_seqpacket_ops, so both proto_ops are updated to use .getsockopt_iter. Key changes: - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt - Use opt->optlen for buffer length (input) and returned size (output) - Use copy_to_iter() instead of put_user()/copy_to_user() Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260501-getsock_one-v1-2-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04netlink: convert to getsockopt_iterBreno Leitao1-10/+11
Convert AF_NETLINK's getsockopt implementation to use the new getsockopt_iter callback with sockopt_t. Key changes: - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt - Use opt->optlen for buffer length (input) and returned size (output) - Use copy_to_iter() instead of put_user()/copy_to_user() - For NETLINK_LIST_MEMBERSHIPS: walk the groups bitmap and emit each u32 sequentially via copy_to_iter(), then set opt->optlen to the total size required (ALIGN(BITS_TO_BYTES(ngroups), sizeof(u32))). The wrapper writes opt->optlen back to userspace even on partial failure, preserving the existing API that lets userspace discover the needed allocation size. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260501-getsock_one-v1-1-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net/sched: add qstats_cpu_drop_inc() helperEric Dumazet11-15/+20
1) Using this_cpu_inc() is better than going through this_cpu_ptr(): - Single instruction on x86. - Store tearing prevention. 2) Change tcf_action_update_stats() to use this_cpu_add(). 3) Add WRITE_ONCE() to __qdisc_qstats_drop() and qstats_drop_inc() in preparation for lockless "tc qdisc show". $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 3/17 up/down: 72/-216 (-144) Function old new delta dualpi2_enqueue_skb 462 511 +49 tcf_ife_act 1061 1077 +16 taprio_enqueue 613 620 +7 codel_qdisc_enqueue 149 143 -6 tcf_vlan_act 684 676 -8 tcf_skbedit_act 626 618 -8 tcf_police_act 725 717 -8 tcf_mpls_act 1297 1289 -8 tcf_gate_act 310 302 -8 tcf_gact_act 222 214 -8 tcf_csum_act 2438 2430 -8 tcf_bpf_act 709 701 -8 tcf_action_update_stats 124 115 -9 pie_qdisc_enqueue 865 856 -9 pfifo_enqueue 116 107 -9 choke_enqueue 2069 2059 -10 plug_enqueue 139 128 -11 bfifo_enqueue 121 110 -11 tcf_nat_act 1501 1489 -12 gred_enqueue 1743 1668 -75 Total: Before=24388609, After=24388465, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260501135916.2566766-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net: phy: realtek: Add support for PHY LEDs on RTL8221BChukun Pan1-0/+165
Realtek RTL8221B Ethernet PHY supports three LED pins which are used to indicate link status and activity. Add netdev trigger support for them. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260501100002.755672-1-amadeus@jmu.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04net/sched: taprio: prepare taprio_dump() for RTNL removalEric Dumazet1-18/+24
We soon will no longer hold RTNL in qdisc dumps. Add READ_ONCE()/WRITE_ONCE() annotations. Note: taprio already uses RCU to protect most of its fields. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260501064247.2027688-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02Merge branch 'intel-wired-lan-updates-2024-04-30-ixgbe-i40e-ice'Jakub Kicinski13-73/+337
Jacob Keller says: ==================== Intel Wired LAN Updates 2024-04-30 (ixgbe, i40e, ice) This series includes updates to support Energy-Efficient Ethernet (EEE) on E610 devices in the ixgbe driver, support for an unmanaged DPLL output on E830, as well as some other minor cleanups and improvements across ixgbe, i40e, and ice. Jedrzej begins with the first six patches preparing the ixgbe driver to support EEE, adding a EEE capability flag, updating the supported EEE speeds, updating the ACI command structures with the fields related to EEE, moving the EEE config validation out for re-use, and finally implementing the EEE support for E610 hardware. Aleksandr fixes the ixgbe_update_flash_X550() logic to prevent unaligned access in ixgbe_host_interface_command(). Note: this has no functional change on x86, and is being sent through net-next as it is considered a minor cleanup. Jacob (hi!) modifies the i40e driver to only timestamp PTP event packets, instead of timestamping every V2 event frame. This avoids wasting the limited number of timestamp slots for frames which the PTP protocol does not care about. Jacob also extends the devlink flash notification message reporting that users can activate the new firmware via devlink reload to explicitly indicate the required "fw_activate" action. Byungchul Park fixes the ice_lbtest_receive_frames() function to use netmem_desc instead of the page structure. Przemyslaw Korba fixes a truncation warning in ice_dpll_init_fwnode_pins() by increasing the allowed length of the pin_name string on the stack to 16. Ivan Vecera adds some bounds checking to ice_dpll_rclk_state_on_pin_get/set() and moves the CGU register macros to be under the header guard ifdef in ice_dpll.h ==================== Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-0-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ice: dpll: Fix compilation warningPrzemyslaw Korba1-1/+1
Introduced by commit ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery"): ice_dpll.c: In function ‘ice_dpll_init’: ice_dpll.c:3588:59: error: ‘%u’ directive output may be truncated writing between 1 and 10 bytes into a region of size 4 [-Werror=format-truncation=] snprintf(pin_name, sizeof(pin_name), "rclk%u", i); Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-13-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ice: access @pp through netmem_desc instead of pageByungchul Park1-1/+1
To eliminate the use of struct page in page pool, the page pool users should use netmem descriptor and APIs instead. Make ice driver access @pp through netmem_desc instead of page. Signed-off-by: Byungchul Park <byungchul@sk.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-12-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ice: mention fw_activate action along with devlink reloadJacob Keller1-1/+1
The ice driver reports a helpful status message when updating firmware indicating what action is necessary to enable the new firmware. This is done because some updates require power cycling or rebooting the machine but some can be activated via devlink. The ice driver only supports activating firmware with the specific action of "fw_activate" a bare "devlink dev reload" will *not* update the firmware, and will only perform driver reinitialization. Update the status message to explicitly reflect that the reload must use the fw_activate action. I considered modifying the text to spell out the full command, but felt that was both overkill and something that would belong better as part of the user space program and not hard coded into the kernel driver output. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-11-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02i40e: only timestamp PTP event packetsJacob Keller2-6/+13
The i40e_ptp_set_timestamp_mode() function is responsible for configuring hardware timestamping. When programming receive timestamping, the logic must determine how to configure the PRTTSYN_CTL1 register for receive timestamping. The i40e hardware does not support timestamping all frames. Instead, timestamps are captured into one of the four PRTTSYN_RXTIME registers. Currently, the driver configures hardware to timestamp all V2 packets on ports 319 and 320, including all message types. This timestamps significantly more packets than is actually requested by the HWTSTAMP_FILTER_PTP_V2_EVENT filter type. The documentation for HWTSTAMP_FILTER_PTP_V2_EVENT indicates that it should timestamp PTP v2 messages on any layer, including any kind of event packets. Timestamping other packets is acceptable, but not required by the filter. Doing so wastes valuable slots in the Rx timestamp registers. For most applications this doesn't cause a problem. However, for extremely high rates of messages, it becomes possible that one of the critical event packets is not timestamped. The PTP protocol only requires timestamps for event messages on port 319, but hardware is timestamping on both 319 and 320, and timestamping message types which do not need a timestamp value. The i40e hardware actually has a more strict filtering option. First, only timestamp layer 4 messages on port 319 instead of both 319 and 320. Second, note that hardware has a specific mode to timestamp only event packets (those with message type < 8). Update the configuration to use the strict mode that only timestamps event messages, switching the TSYNTYPE field from 10b to 11b which limits the timestamping only to eventpackets with a Message Type of < 8. Note that the X700 series datasheet seems to indicate that the V2MSESTYPE field is no longer relevant. However, we only tested and validated with leaving the V2MESSTYPE field set to 0xF for the "wildcard" behavior it documents. This might not be required but it in that case setting it appears harmless, so leave it as is. This avoids wasting the valuable Rx timestamp register slots on non-event frames, and may reduce faults when operating under high event rates. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-10-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()Aleksandr Loktionov2-1/+2
ixgbe_host_interface_command() treats its buffer as a u32 array. The local buffer we pass in was a union of byte-sized fields, which gives it 1-byte alignment on the stack. On strict-align architectures this can cause unaligned 32-bit accesses. Add a u32 member to union ixgbe_hic_hdr2 so the object is 4-byte aligned, and pass the u32 member when calling ixgbe_host_interface_command(). No functional change on x86; prevents unaligned accesses on architectures that enforce natural alignment. Fixes: 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type") Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Fixes: 6a14ee0cfb19 ("ixgbe: Add X550 support function pointers") Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-9-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: E610: add EEE supportJedrzej Jagielski5-5/+212
Add E610 specific implementation of .get_eee() and .set_eee() ethtool callbacks. Introduce ixgbe_setup_eee_e610() which is used to set EEE config on E610 device via ixgbe_aci_set_phy_cfg() (0x0601 ACI command). Assign it to dedicated mac operation. E610 devices support EEE feature specifically for 2.5, 5 and 10G link speeds. When user try to set EEE for unsupported speeds log it. Setting timer and setting EEE advertised speeds are not yet supported. EEE shall be enabled by default for E610 devices. Add EEE statuis logging during link watchdog run. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-6-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: move EEE config validation out of ixgbe_set_eee()Jedrzej Jagielski1-41/+57
To make this part of the code mode reusable move all EEE input checks out of ixgbe_set_eee(). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-5-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: E610: update ACI command structs with EEE fieldsJedrzej Jagielski2-7/+11
There were recent changes in some of the ACI commands, which have been extended with EEE related fields. Set PHY Config, Get PHY Caps and Get Link Info have been affected. Align SW structs to the recent FW changes. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-4-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: E610: use new version of 0x601 ACI command bufferJedrzej Jagielski2-7/+25
Since FW version 1.40, buffer size of the 0x601 cmd has been increased by 2B - from 24 to 26B. Buffer has been extended with new field which can be used to configure EEE entry delay. Pre-1.40 FW versions still expect 24B buffer and throws error when receipts 26B buffer. To keep compatibility, check whether EEE device capability flag is set and basing on it use appropriate size of the command buffer. Additionally place Set PHY Config capabilities defines out of structs definitions. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-3-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: E610: update EEE supported speedsJedrzej Jagielski2-3/+9
Despite there was no EEE (Energy Efficient Ethernet) feature support for E610 adapters, eee_speeds_supported variable was defined and even initialized with some EEE speeds. As E610 adapter supports EEE only for 10G, 5G and 2.5G speeds, update hw.phy.eee_speeds_supported. Remove unsupported speeds - 10M, 100M and 1G. Add also entry for 5G speed in EEE speeds mapping array used by ethtool callbacks. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-2-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02ixgbe: E610: add discovering EEE capabilityJedrzej Jagielski3-0/+5
Add detecting and parsing EEE device capability. Recently EEE functionality support has been introduced to E610 FW. Currently ixgbe driver has no possibility to detect whether NVM loaded on given adapter supports EEE. There's dedicated device capability element reflecting FW support for given EEE link speed. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260430-jk-iwl-net-next-2026-04-30-v1-1-6f27ae1cd073@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02Merge branch 'net-dsa-yt921x-add-port-police-support'Jakub Kicinski6-74/+509
David Yang says: ==================== net: dsa: yt921x: Add port police support ==================== Link: https://patch.msgid.link/20260430114529.3536911-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02net: dsa: yt921x: Add port police supportDavid Yang2-1/+373
Enable rate meter ability and support limiting the rate of incoming traffic. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260430114529.3536911-4-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02net: dsa: yt921x: Refactor long register helpersDavid Yang2-69/+129
Dealing long registers with u64 is good, until you realize there are longer 96-bit registers. Refactor reg64 helpers to use u32 arrays instead of u64 values, in preparation for 96-bit registers. We do not keep the separate u64 version for reg64 to avoid duplicated wrappers, although it looks better when dealing with reg64 *only*. Helpers for reg96 should be added when they are actually used to avoid function unused warnings. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260430114529.3536911-3-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02net: dsa: pass extack to dsa_switch_ops :: port_policer_add()David Yang4-4/+7
Drivers might have error messages to propagate to user space. Propagate the netlink extack so that they can inform user space in a verbal way of their limitations. Make the according transformations to the two users (sja1105 and felix). Signed-off-by: David Yang <mmyangfl@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260430114529.3536911-2-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02net/mlx5: Add vhca_id_type support to IPsec alias creationPatrisious Haddad3-0/+12
When creating an alias FT for MPV IPsec, if alias creation with sw_vhca_id is supported use it instead of using the hw_vhca_id. This in turn allows IPsec to work properly after live migration, in case a VF was live migrated and his hw_vhca_id changed due to migration which can happen if you migrate to a VF with a different index than yours, IPsec would fail to start post migration, this patch resolves the issue by using sw_vhca_id instead which doesn't change post migration. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260430061958.225245-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02Documentation/tcp_ao: Document the supported MAC algorithms and lengthsEric Biggers1-11/+27
Update the TCP-AO documentation to fix some incorrect terminology and claims regarding the MAC algorithms, and document which MAC algorithms and lengths the Linux implementation supports. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260429210856.725667-1-ebiggers@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01Merge branch 'net-mlx5-enable-sub-page-allocations-for-mlx5_frag_buf'Jakub Kicinski4-34/+277
Tariq Toukan says: ==================== net/mlx5: enable sub-page allocations for mlx5_frag_buf This series aims to improve memory utilization for DMA-coherent fragmented-buffer allocations on systems with large PAGE_SIZE. Before this change, such allocations were page-granular, as they were backed by full pages. On large-page systems this caused significant internal waste for small objects. For example, a single 4K request consumed an entire 64K page. The common kernel solution for sub-page coherent DMA allocations is the DMA pool API. However, those pools do not return pages to the system until teardown. That behavior is not a good fit for mlx5_frag_buf allocations, since they back interface resources (WQs and CQs). Interfaces may be removed dynamically, so their memory footprint should reflect live usage to avoid situations where large amounts of memory remain tied up in pools. This series introduces a lightweight mlx5-local pool implementation for sub-page coherent DMA allocations, which immediately returns free backing pages. It wires mlx5_frag_buf allocations to use these internal pools, while keeping the mechanism reusable for other mlx5-internal coherent DMA allocation users in follow-up work. ==================== Link: https://patch.msgid.link/20260429201429.223809-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01net/mlx5: use internal dma pools for frag buf allocNimrod Oren2-32/+140
Add mlx5_dma_pool alloc/free paths, and wire mlx5_frag_buf allocation and free paths to use them. mlx5_frag_buf_alloc_node() now selects an mlx5_dma_pool to allocate fragments from, instead of directly allocating full coherent pages. mlx5_frag_buf_free() frees from the respective pool. mlx5_dma_pool_alloc() keeps allocation fast by maintaining pages with available indexes at the head of the list, so the common allocation path can take a free index immediately. New backing pages are allocated only when no free index is available. mlx5_dma_pool_free() returns released indexes to the pool and frees a backing page once all of its indexes become free. This avoids keeping fully free pages for the lifetime of the pool and reduces coherent DMA memory footprint. Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260429201429.223809-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01net/mlx5: add frag buf pools create/destroy pathsNimrod Oren2-4/+119
Introduce mlx5 DMA pool and pool-page data structures, and add the creation and teardown paths. Each NUMA node owns a set of mlx5_dma_pool instances, each one with a different block size. The sizes are defined as all powers of two starting from MLX5_ADAPTER_PAGE_SHIFT and up to PAGE_SHIFT. Since mlx5_frag_bufs are used to back objects whose sizes are encoded relative to MLX5_ADAPTER_PAGE_SHIFT, a smaller block_shift value cannot be used. Requests larger than PAGE_SIZE continue to be handled as page-sized fragments, as in the existing frag-buf allocation model. Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260429201429.223809-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01net/mlx5: wire frag buf pools lifecycle hooksNimrod Oren3-0/+20
Wire mlx5_frag_buf pools init/cleanup hooks into mlx5_mdev_init()/uninit() and the init unwind path. Keep temporary no-op stubs in alloc.c so lifecycle ordering is in place before the coherent DMA sub-page allocator implementation is added in follow-up patches. Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260429201429.223809-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01pppoe: optimize hash with word accessQingfang Deng1-6/+6
Currently, hash_item() processes the 6-byte Ethernet address and the 2-byte session ID byte-wise to compute a hash. Optimize this by using 16-bit word operations: XOR three 16-bit words from the Ethernet address and the 16-bit session ID, then fold the result. This reduces the total number of loads and XORs. The Ethernet addresses in a skb and struct pppoe_addr are both 2-byte aligned, so the u16 pointer cast is safe. Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev> Link: https://patch.msgid.link/20260429023848.153425-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01net: airoha: configure QoS channel for HW accelerated flowtable trafficLorenzo Bianconi1-1/+9
As done for the SW path, configure the QoS channel for HW accelerated traffic according to the user port index when forwarding to a DSA port, or rely on the GDM port identifier otherwise. This allows HTB shaping to be applied to HW accelerated traffic. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260430-airoha-ppe-qos-channel-v1-1-5ef9221e85c1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01Merge branch 'tcp-move-some-fastpath-fields-to-appropriate-groups'Jakub Kicinski3-36/+36
Eric Dumazet says: ==================== tcp: move some fastpath fields to appropriate groups Move following fields to better groups to increase data locality. - delivered - delivered_ce - segs_in - segs_out - first_tx_mstamp - delivered_mstamp - max_packets_out - cwnd_usage_seq - rate_delivered - rate_interval_us No change in overall tcp_sock size. ==================== Link: https://patch.msgid.link/20260430100021.211139-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01tcp: move max_packets_out, cwnd_usage_seq, rate_delivered and rate_interval_us to tcp_sock_write_tx groupEric Dumazet2-8/+8
These fields are used in TX path. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260430100021.211139-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01tcp: move tp->bytes_acked to tcp_sock_write_tx groupEric Dumazet3-6/+6
tp->bytes_acked is touched in TX path only. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260430100021.211139-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01tcp: move tp->first_tx_mstamp and tp->delivered_mstamp to tcp_sock_write_txEric Dumazet2-4/+4
These fields are touched in when payload is sent. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260430100021.211139-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>