kernel/drivers/net/ethernet/intel/igc/igc.h, branch linux-6.18.y

igc: don't fail igc_probe() on LED setup error

2025-09-16T21:01:53Z

When igc_led_setup() fails, igc_probe() fails and triggers kernel panic in free_netdev() since unregister_netdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2] Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind Fixes: ea578703b03d ("igc: Add support for LEDs on i225/i226") Signed-off-by: Kohei Enju Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Reviewed-by: Vitaly Lifshits Reviewed-by: Kurt Kanzenbach Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: Add wildcard rule support to ethtool NFC using Default Queue

2025-07-18T16:02:28Z

Introduce support for a lowest priority wildcard (catch-all) rule in ethtool's Network Flow Classification (NFC) for the igc driver. The wildcard rule directs all unmatched network traffic, including traffic not captured by Receive Side Scaling (RSS), to a specified queue. This functionality utilizes the Default Queue feature available in I225/I226 hardware. The implementation has been validated on Intel ADL-S systems with two back-to-back connected I226 network interfaces. Testing Procedure: 1. On the Device Under Test (DUT), verify the initial statistic: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 0 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 2. From the Link Partner, send 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 3. On the DUT, verify the packet reception on Queue 0: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 4. On the DUT, add a wildcard rule to route all packets to Queue 3: $ sudo ethtool -N enp1s0 flow-type ether queue 3 5. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 6. Now, packets are routed to Queue 3 by the wildcard (Default Queue) rule: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 10 7. On the DUT, add a EtherType rule to route ARP packet to Queue 1: $ sudo ethtool -N enp1s0 flow-type ether proto 0x0806 queue 1 8. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 9. Now, packets are routed to Queue 1 by the EtherType rule because it is higher priority than the wildcard (Default Queue) rule: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 10 rx_queue_2_packets: 0 rx_queue_3_packets: 10 10. On the DUT, delete all the NFC rules: $ sudo ethtool -N enp1s0 delete 63 $ sudo ethtool -N enp1s0 delete 64 11. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 12. Now, packets are routed to Queue 0 because the value of Default Queue is reset back to 0: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 20 rx_queue_1_packets: 10 rx_queue_2_packets: 0 rx_queue_3_packets: 10 Reviewed-by: Kurt Kanzenbach Co-developed-by: Blanco Alcaine Hector Signed-off-by: Blanco Alcaine Hector Signed-off-by: Song Yoong Siang Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: Relocate RSS field definitions to igc_defines.h

2025-07-18T16:02:28Z

Move the RSS field definitions related to IPv4 and IPv6 UDP from igc.h to igc_defines.h to consolidate the RSS field definitions in a single header file, improving code organization and maintainability. This refactoring does not alter the functionality of the driver but enhances the logical grouping of related constants Reviewed-by: Kurt Kanzenbach Signed-off-by: Song Yoong Siang Reviewed-by: Aleksandr Loktionov Reviewed-by: Brett Creeley Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()

2025-07-03T16:38:33Z

New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the Intel igc driver to the new API, so that timestamping configuration can be removed from the ndo_eth_ioctl() path completely. Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Reviewed-by: Vitaly Lifshits Reviewed-by: Vadim Fedorenko Reviewed-by: Milena Olech Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: add preemptible queue support in taprio

2025-06-11T17:06:24Z

Changes: 1. Introduce tx_enabled flag to control preemptible queue. tx_enabled is set via mmsv module based on multiple factors, including link up/down status, to determine if FPE is active or inactive. 2. Add priority field to TXDCTL for express queue to improve data fetch performance. 3. Block preemptible queue setup in taprio unless reverse-tsn-txq-prio private flag is set. Encourages adoption of standard queue priority scheme for new features. 4. Hardware-padded frames from preemptible queues result in incorrect mCRC values, as padding bytes are excluded from the computation. Pad frames to at least 60 bytes using skb_padto() before transmission to ensure the hardware includes padding in the mCRC calculation. Tested preemption with taprio by: 1. Enable FPE: ethtool --set-mm enp1s0 pmac-enabled on tx-enabled on verify-enabled on 2. Enable private flag to reverse TX queue priority: ethtool --set-priv-flags enp1s0 reverse-txq-prio on 3. Enable preemptible queue in taprio: taprio num_tc 4 map 0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 \ queues 1@0 1@1 1@2 1@3 \ fp P P P E Reviewed-by: Aleksandr Loktionov Co-developed-by: Chwee-Lin Choong Signed-off-by: Chwee-Lin Choong Signed-off-by: Faizal Rahim Reviewed-by: Simon Horman Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: add private flag to reverse TX queue priority in TSN mode

2025-06-11T17:06:24Z

By default, igc assigns TX hw queue 0 the highest priority and queue 3 the lowest. This is opposite of most NICs, where TX hw queue 3 has the highest priority and queue 0 the lowest. mqprio in igc already uses TX arbitration unconditionally to reverse TX queue priority when mqprio is enabled. The TX arbitration logic does not require a private flag, because mqprio was added recently and no known users depend on the default queue ordering, which differs from the typical convention. taprio does not use TX arbitration, so it inherits the default igc TX queue priority order. This causes tc command inconsistencies when configuring frame preemption with taprio compared to mqprio in igc. Other tc command inconsistencies and configuration issues already exist when using taprio on igc compared to other network controllers. These issues are described in a later section. To harmonize TX queue priority behavior between taprio and mqprio, and to fix these issues without breaking long-standing taprio use cases, this patch adds a new private flag, called reverse-tsn-txq-prio, to reverse the TX queue priority. It makes queue 3 the highest and queue 0 the lowest, reusing the TX arbitration logic already used by mqprio. Users must set the private flag when enabling frame preemption with taprio to follow the standard convention. Doing so promotes adoption of the correct priority model for new features while preserving compatibility with legacy configurations. This new private flag addresses: 1. Non-standard socket -> tc -> TX hw queue mapping for taprio in igc Without the private flag: - taprio maps (socket -> tc -> TX hardware queue) differently on igc compared to other network controllers - On igc, mqprio maps tc differently from taprio, since mqprio already uses TX arbitration The following examples compare taprio configuration on igc and other network controllers: a) On other NICs (TX hw queue 3 is highest priority): taprio num_tc 4 map 0 1 2 3 .... \ queues 1@0 1@1 1@2 1@3 Mapping translates to: socket 0 -> tc 0 -> queue 0 socket 3 -> tc 3 -> queue 3 This is the normal mapping that respects the standard convention: higher socket number -> higher tc -> higher priority TX hw queue b) On igc (TX hw queue 0 is highest priority by default): taprio num_tc 4 map 3 2 1 0 .... \ queues 1@0 1@1 1@2 1@3 Mapping translates to: socket 0 -> tc 3 -> queue 3 socket 3 -> tc 0 -> queue 0 This igc tc mapping example is based on Intel's TSN validation test case, where a higher socket priority maps to a higher priority queue. It respects the mapping: higher socket number -> higher priority TX hw queue but breaks the expected ordering: higher tc -> higher priority TX hw queue as defined in [Ref1]. This custom mapping complicates common taprio setup across NICs. 2. Non-standard frame preemption mapping for taprio in igc Without the private flag: - Compared to other network controllers, taprio on igc must flip the expected fp sequence, since express traffic is expected to map to the highest priority queue and preemptible traffic to lower ones - On igc, frame preemption configuration for mqprio differs from taprio, since mqprio already uses TX arbitration The following examples compare taprio frame preemption configuration on igc and other network controllers: a) On other NICs (TX hw queue 3 is highest priority): taprio num_tc 4 map ..... \ queues 1@0 1@1 1@2 1@3 \ fp P P P E Mapping translates to: tc0, tc1, tc2 -> preemptible -> queue 0, 1, 2 tc3 -> express -> queue 3 This is the normal mapping that respects the standard convention: higher tc -> express traffic -> higher priority TX hw queue lower tc -> preemptible traffic -> lower priority TX hw queue b) On igc (TX hw queue 0 is highest priority by default): taprio num_tc 4 map ...... \ queues 1@0 1@1 1@2 1@3 \ fp E P P P Mapping translates to: tc0 -> express -> queue 0 tc1, tc2, tc3 -> preemptible -> queue 1, 2, 3 This inversion respects the mapping of: express traffic -> higher priority TX hw queue but breaks the expected ordering: higher tc -> express traffic as defined in [Ref1] where higher tc indicates higher priority. In this case, the lower tc0 is assigned to express traffic. This custom mapping further complicates common preemption setup across NICs. Tests were performed on taprio with the following combinations, where two apps send traffic simultaneously on different queues: Private Flag Traffic Sent By Traffic Sent By ---------------------------------------------------------------- enabled iperf3 (queue 3) iperf3 (queue 0) disabled iperf3 (queue 0) iperf3 (queue 3) enabled iperf3 (queue 3) real-time app (queue 0) disabled iperf3 (queue 0) real-time app (queue 3) enabled real-time app (queue 3) iperf3 (queue 0) disabled real-time app (queue 0) iperf3 (queue 3) enabled real-time app (queue 3) real-time app (queue 0) disabled real-time app (queue 0) real-time app (queue 3) Private flag is controlled with: ethtool --set-priv-flags enp1s0 reverse-tsn-txq-prio [Ref1] IEEE 802.1Q clause 8.6.8 Transmission selection: "For a given Port and traffic class, frames are selected from the corresponding queue for transmission if and only if: ... b) For each queue corresponding to a numerically higher value of traffic class supported by the Port, the operation of the transmission selection algorithm supported by that queue determines that there is no frame available for transmission." Reviewed-by: Simon Horman Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: refactor TXDCTL macros to use FIELD_PREP and GEN_MASK

2025-06-11T15:56:48Z

Refactor TXDCTL macro handling to use FIELD_PREP and GENMASK macros. This prepares the code for adding a new TXDCTL priority field in an upcoming patch. Verified that the macro values remain unchanged before and after refactoring. Reviewed-by: Simon Horman Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: add DCTL prefix to related macros

2025-06-11T15:55:46Z

Rename macros to use the DCTL prefix for consistency with existing macros that reference the same register. This prepares for an upcoming patch that adds new fields to TXDCTL. Reviewed-by: Simon Horman Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: move TXDCTL and RXDCTL related macros

2025-06-11T15:52:14Z

Move and consolidate TXDCTL and RXDCTL macros in preparation for upcoming TXDCTL changes. This improves organization and readability. Reviewed-by: Simon Horman Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: Change Tx mode for MQPRIO offloading

2025-04-29T22:13:43Z

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 regular TSN Tx mode. This mode also uses four packet buffers and considers queue priorities. In addition to the legacy mode, transmission is always coupled to Qbv. The driver already has mechanisms to use a dummy schedule of 1 second with all gates open for ETF. Simply use this for MQPRIO too. This reduces code and makes it easier to add support for frame preemption later. Tested on i225 with real time application using high priority queue, iperf3 using low priority queue and network TAP device. Acked-by: Faizal Rahim Signed-off-by: Kurt Kanzenbach Reviewed-by: Simon Horman Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen