* [PATCH v2 2/2] arm64: dts: qcom: monaco: Add monaco-ac EVK board
From: Umang Chheda @ 2026-03-31 18:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda, netdev,
Faruque Ansari
In-Reply-To: <20260401-monaco-evk-ac-sku-v2-0-27b5f702cfba@oss.qualcomm.com>
Add initial device tree support for monaco-ac EVK board,
based on Qualcomm's monaco-ac (QCS8300-AC) variant SoC.
monaco-ac EVK is single board supporting these peripherals :
- Storage: 1 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
and eMMC.
- Audio/Video, Camera & Display ports.
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD.
- PCIe ports.
- USB & UART ports.
Compared to "monaco-evk" variant, which utilizes higher tier QCS8300-AA
SKU (supporting 40 TOPS of NPU) and a 4-PMIC (2x PM8650AU + Maxim MAX20018
+ TI TPS6594) power delivery network (PDN) to support higher power
requirement. This board utilizes lower tier QCS8300-AC SKU
(Supporting 20 TOPS of NPU) and a simplified 2 PMIC(2x PM8650AU) PDN.
Add support for the following components :
- GPI (Generic Peripheral Interface) and QUPv3-0/1
controllers to facilitate DMA and peripheral communication.
- TCA9534 I/O expander via I2C to provide 8 additional GPIO
lines for extended I/O functionality.
- USB1 controller routed to a TypeC connector in device mode to
support USB peripheral operations.
- Remoteproc subsystems for supported DSPs such as Audio DSP,
Compute DSP and Generic DSP, along with their corresponding
firmware.
- Configure nvmem-layout on the I2C EEPROM to store data for Ethernet
and other consumers.
- QCA8081 2.5G Ethernet PHY on port-0 and expose the
Ethernet MAC address via nvmem for network configuration.
It depends on CONFIG_QCA808X_PHY to use QCA8081 PHY.
- Support for the Iris video decoder, including the required
firmware, to enable video decoding capabilities.
- PCIe0 and PCIe1 controller and phy-nodes.
- Sound card and max98357a based I2S speaker amplifier.
Written with inputs from:
Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> - GPIO
Expander.
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> - GPI/QUP.
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> - Ethernet.
Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
Swati Agarwal <swati.agarwal@oss.qualcomm.com> - USB.
Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com> - PCIe.
Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> - Audio.
Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts | 730 +++++++++++++++++++++++++
2 files changed, 731 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c46d94bb6dd5..1d8c2a3db6c0 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -57,6 +57,7 @@ dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-arduino-monza.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ac-sku.dtb
monaco-evk-camera-imx577-dtbs := monaco-evk.dtb monaco-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts b/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts
new file mode 100644
index 000000000000..f6294b2a486d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts
@@ -0,0 +1,730 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "monaco.dtsi"
+#include "monaco-pmics.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Monaco-ac EVK";
+ compatible = "qcom,monaco-evk-ac", "qcom,qcs8300";
+
+ aliases {
+ ethernet0 = ðernet0;
+ i2c1 = &i2c1;
+ serial0 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ dmic: audio-codec-0 {
+ compatible = "dmic-codec";
+ #sound-dai-cells = <0>;
+ num-channels = <1>;
+ };
+
+ max98357a: audio-codec-1 {
+ compatible = "maxim,max98357a";
+ #sound-dai-cells = <0>;
+ };
+
+ sound {
+ compatible = "qcom,qcs8275-sndcard";
+ model = "MONACO-EVK";
+
+ pinctrl-0 = <&hs0_mi2s_active>, <&mi2s1_active>;
+ pinctrl-names = "default";
+
+ hs0-mi2s-playback-dai-link {
+ link-name = "HS0 MI2S Playback";
+
+ codec {
+ sound-dai = <&max98357a>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ sec-mi2s-capture-dai-link {
+ link-name = "Secondary MI2S Capture";
+
+ codec {
+ sound-dai = <&dmic>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai SECONDARY_MI2S_TX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l3a: ldo3 {
+ regulator-name = "vreg_l3a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4a: ldo4 {
+ regulator-name = "vreg_l4a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5a: ldo5 {
+ regulator-name = "vreg_l5a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6a: ldo6 {
+ regulator-name = "vreg_l6a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7a: ldo7 {
+ regulator-name = "vreg_l7a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8a: ldo8 {
+ regulator-name = "vreg_l8a";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9a: ldo9 {
+ regulator-name = "vreg_l9a";
+ regulator-min-microvolt = <2970000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4a: smps4 {
+ regulator-name = "vreg_s4a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9a: smps9 {
+ regulator-name = "vreg_s9a";
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vreg_l1c: ldo1 {
+ regulator-name = "vreg_l1c";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c: ldo2 {
+ regulator-name = "vreg_l2c";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c: ldo4 {
+ regulator-name = "vreg_l4c";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c: ldo6 {
+ regulator-name = "vreg_l6c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c: ldo7 {
+ regulator-name = "vreg_l7c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c: ldo8 {
+ regulator-name = "vreg_l8c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c: ldo9 {
+ regulator-name = "vreg_l9c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5c: smps5 {
+ regulator-name = "vreg_s5c";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+ðernet0 {
+ phy-mode = "2500base-x";
+ phy-handle = <&hsgmii_phy0>;
+
+ pinctrl-0 = <ðernet0_default>;
+ pinctrl-names = "default";
+
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ nvmem-cells = <&mac_addr0>;
+ nvmem-cell-names = "mac-address";
+
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hsgmii_phy0: ethernet-phy@1c {
+ compatible = "ethernet-phy-id004d.d101";
+ reg = <0x1c>;
+ reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-0 = <&qup_i2c1_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ pagesize = <64>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac_addr0: mac-addr@0 {
+ reg = <0x0 0x6>;
+ };
+ };
+ };
+};
+
+&i2c15 {
+ pinctrl-0 = <&qup_i2c15_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ expander0: gpio@38 {
+ compatible = "ti,tca9538";
+ reg = <0x38>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 56 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander0_int>;
+ pinctrl-names = "default";
+ };
+
+ expander1: gpio@39 {
+ compatible = "ti,tca9538";
+ reg = <0x39>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 16 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander1_int>;
+ pinctrl-names = "default";
+ };
+
+ expander2: gpio@3a {
+ compatible = "ti,tca9538";
+ reg = <0x3a>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 95 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander2_int>;
+ pinctrl-names = "default";
+ };
+
+ expander3: gpio@3b {
+ compatible = "ti,tca9538";
+ reg = <0x3b>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 24 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander3_int>;
+ pinctrl-names = "default";
+ };
+
+ expander4: gpio@3c {
+ compatible = "ti,tca9538";
+ reg = <0x3c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 96 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander4_int>;
+ pinctrl-names = "default";
+ };
+
+ expander5: gpio@3d {
+ compatible = "ti,tca9538";
+ reg = <0x3d>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander5_int>;
+ pinctrl-names = "default";
+ };
+
+ expander6: gpio@3e {
+ compatible = "ti,tca9538";
+ reg = <0x3e>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 52 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander6_int>;
+ pinctrl-names = "default";
+ };
+};
+
+&iris {
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pcie1_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcieport0 {
+ reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+};
+
+&pcieport1 {
+ reset-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+};
+
+&qupv3_id_0 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs8300/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs8300/cdsp0.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_gpdsp {
+ firmware-name = "qcom/qcs8300/gpdsp0.mbn";
+
+ status = "okay";
+};
+
+&serdes0 {
+ phy-supply = <&vreg_l4a>;
+
+ status = "okay";
+};
+
+&spi10 {
+ status = "okay";
+
+ tpm@0 {
+ compatible = "st,st33htpm-spi", "tcg,tpm_tis-spi";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&tlmm {
+
+ pcie0_default_state: pcie0-default-state {
+ wake-pins {
+ pins = "gpio0";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio1";
+ function = "pcie0_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio2";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ expander5_int: expander5-int-state {
+ pins = "gpio3";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ ethernet0_default: ethernet0-default-state {
+ ethernet0_mdc: ethernet0-mdc-pins {
+ pins = "gpio5";
+ function = "emac0_mdc";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+
+ ethernet0_mdio: ethernet0-mdio-pins {
+ pins = "gpio6";
+ function = "emac0_mdio";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+ };
+
+ expander1_int: expander1-int-state {
+ pins = "gpio16";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ qup_i2c1_default: qup-i2c1-state {
+ pins = "gpio19", "gpio20";
+ function = "qup0_se1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ qup_i2c1_default: qup-i2c1-state {
+ pins = "gpio19", "gpio20";
+ function = "qup0_se1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ pcie1_default_state: pcie1-default-state {
+ wake-pins {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio22";
+ function = "pcie1_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio23";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ expander3_int: expander3-int-state {
+ pins = "gpio24";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander6_int: expander6-int-state {
+ pins = "gpio52";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander0_int: expander0-int-state {
+ pins = "gpio56";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ qup_i2c15_default: qup-i2c15-state {
+ pins = "gpio91", "gpio92";
+ function = "qup1_se7";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ expander2_int: expander2-int-state {
+ pins = "gpio95";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander4_int: expander4-int-state {
+ pins = "gpio96";
+ function = "gpio";
+ bias-pull-up;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l8a>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l4c>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l4a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l7c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
+
+&usb_qmpphy {
+ vdda-phy-supply = <&vreg_l7a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Umang Chheda @ 2026-03-31 18:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda, netdev
In-Reply-To: <20260401-monaco-evk-ac-sku-v2-0-27b5f702cfba@oss.qualcomm.com>
Introduce bindings for the monaco-evk-ac IoT board, which is
based on the monaco-ac (QCS8300-AC) SoC variant.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index ca880c105f3b..c76365a89687 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -918,6 +918,7 @@ properties:
- enum:
- arduino,monza
- qcom,monaco-evk
+ - qcom,monaco-evk-ac
- qcom,qcs8300-ride
- const: qcom,qcs8300
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: qcom: Introduce support for Monaco-ac-sku Evaluation Kit
From: Umang Chheda @ 2026-03-31 18:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda, netdev,
Faruque Ansari
Add support for Qualcomm's Monaco-ac-sku Evaluation Kit (EVK) without
safety monitoring feature of Safety Island(SAIL) subsystem.
This board is based on Qualcomm's QCS8300-AC variant SoC.
Monaco-ac-sku EVK board is a single board computer (SBC) that supports various
industrial applications, including factory automation, industrial
robots, drones, edge AI boxes, machine vision, autonomous mobile
robots (AMRs), and industrial gateways.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
Changes in v2:
- Drop keyword "sku" from the compatible string of board bindings
- Krzysztof.
- Wrap commit text of dt-bindings change based on upstream guidelines
- Krzysztof.
- Link to v1: https://patch.msgid.link/20260328-monaco-evk-ac-sku-v1-0-79d166fa5571@oss.qualcomm.com
---
Umang Chheda (2):
dt-bindings: arm: qcom: Add monaco-evk-ac support
arm64: dts: qcom: monaco: Add monaco-ac EVK board
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts | 730 ++++++++++++++++++++++++
3 files changed, 732 insertions(+)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260328-monaco-evk-ac-sku-6d66f965335c
Best regards,
--
Umang Chheda <umang.chheda@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v7 1/3] PCI: AtomicOps: Do not enable requests by RCiEPs
From: Kuehling, Felix @ 2026-03-31 18:39 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Gerd Bayer, Alex Deucher, Christian König, Selvin Xavier,
Kalesh AP, Jason Gunthorpe, Leon Romanovsky, Michal Kalderon,
Saeed Mahameed, Tariq Toukan, Mark Bloch, Bjorn Helgaas,
Jay Cornwall, Ilpo Järvinen, Christian Borntraeger,
Niklas Schnelle, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Sven Schnelle, Alexander Schmidt, linux-s390,
linux-pci, linux-kernel, netdev, linux-rdma
In-Reply-To: <20260331180952.GA148118@bhelgaas>
On 2026-03-31 14:09, Bjorn Helgaas wrote:
> On Mon, Mar 30, 2026 at 08:01:57PM -0400, Kuehling, Felix wrote:
>> On 2026-03-30 17:42, Bjorn Helgaas wrote:
>>> [+to amdgpu, bnxe_re, mlx5 IB, qedr, mlx5 maintainers]
>>>
>>> On Mon, Mar 30, 2026 at 03:09:44PM +0200, Gerd Bayer wrote:
>>>> Since root complex integrated end points (RCiEPs) attach to a bus that
>>>> has no bridge device describing the root port, the capability to
>>>> complete AtomicOps requests cannot be determined with PCIe methods.
>>>>
>>>> Change default of pci_enable_atomic_ops_to_root() to not enable
>>>> AtomicOps requests on RCiEPs.
>>> I know I suggested this because there's nothing explicit that tells us
>>> whether the RC supports atomic ops from RCiEPs [1]. But I'm concerned
>>> that GPUs, infiniband HCAs, and NICs that use atomic ops may be
>>> implemented as RCiEPs and would be broken by this.
>> FWIW, on AMD APUs our driver doesn't call pci_enable_atomic_ops_to_root. It
>> just assumes that the GPU can do atomic accesses because it doesn't actually
>> go through PCIe: https://elixir.bootlin.com/linux/v6.19.10/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L4785
> What does this mean for the other branch that *does* use
> pci_enable_atomic_ops_to_root()? Can any of those devices be RCiEPs?
Most AMD GPUs are not integrated endpoints. APUs are integrated. There
are A+A GPUs where the GPUs are separate from the CPU but part of the
same coherent data fabric as the CPU (adev->gmc.xbmi.connected_to_cpu ==
true). Those may also be considered RCiEPs. (I'm not sure about that, is
there an easy way to check with lspci?) We may need to include that in
the same branch as APUs.
You can see that we did that for a new generation of A+A GPU here:
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c?ref_type=heads#L3920.
We'd need to confirm that the same works for MI200 A+A GPUs as well.
Regards,
Felix
>
>>> These drivers use pci_enable_atomic_ops_to_root():
>>>
>>> amdgpu
>>> bnxt_re (infiniband)
>>> mlx5 (infinband)
>>> qedr (infiniband)
>>> mlx5 (ethernet)
>>>
>>> Maybe we should assume that because RCiEPs are directly integrated
>>> into the RC, the RCiEP would only allow AtomicOp Requester Enable to
>>> be set if the RC supports atomic ops?
>>>
>>> I don't like making assumptions like that, but it'd be worse to break
>>> these devices.
>>>
>>> [1] https://lore.kernel.org/all/20260326164002.GA1325368@bhelgaas
>>>
>>>> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>> ---
>>>> drivers/pci/pci.c | 5 ++---
>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index 8479c2e1f74f1044416281aba11bf071ea89488a..135e5b591df405e87e7f520a618d7e2ccba55ce1 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3692,15 +3692,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>> /*
>>>> * Per PCIe r4.0, sec 6.15, endpoints and root ports may be
>>>> - * AtomicOp requesters. For now, we only support endpoints as
>>>> - * requesters and root ports as completers. No endpoints as
>>>> + * AtomicOp requesters. For now, we only support (legacy) endpoints
>>>> + * as requesters and root ports as completers. No endpoints as
>>>> * completers, and no peer-to-peer.
>>>> */
>>>> switch (pci_pcie_type(dev)) {
>>>> case PCI_EXP_TYPE_ENDPOINT:
>>>> case PCI_EXP_TYPE_LEG_END:
>>>> - case PCI_EXP_TYPE_RC_END:
>>>> break;
>>>> default:
>>>> return -EINVAL;
>>>>
>>>> --
>>>> 2.51.0
>>>>
^ permalink raw reply
* Re: [PATCH v7 1/3] PCI: AtomicOps: Do not enable requests by RCiEPs
From: Bjorn Helgaas @ 2026-03-31 18:09 UTC (permalink / raw)
To: Kuehling, Felix
Cc: Gerd Bayer, Alex Deucher, Christian König, Selvin Xavier,
Kalesh AP, Jason Gunthorpe, Leon Romanovsky, Michal Kalderon,
Saeed Mahameed, Tariq Toukan, Mark Bloch, Bjorn Helgaas,
Jay Cornwall, Ilpo Järvinen, Christian Borntraeger,
Niklas Schnelle, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Sven Schnelle, Alexander Schmidt, linux-s390,
linux-pci, linux-kernel, netdev, linux-rdma
In-Reply-To: <2ab40ebb-6ce6-490f-a22b-6b2ee873c085@amd.com>
On Mon, Mar 30, 2026 at 08:01:57PM -0400, Kuehling, Felix wrote:
> On 2026-03-30 17:42, Bjorn Helgaas wrote:
> > [+to amdgpu, bnxe_re, mlx5 IB, qedr, mlx5 maintainers]
> >
> > On Mon, Mar 30, 2026 at 03:09:44PM +0200, Gerd Bayer wrote:
> > > Since root complex integrated end points (RCiEPs) attach to a bus that
> > > has no bridge device describing the root port, the capability to
> > > complete AtomicOps requests cannot be determined with PCIe methods.
> > >
> > > Change default of pci_enable_atomic_ops_to_root() to not enable
> > > AtomicOps requests on RCiEPs.
> > I know I suggested this because there's nothing explicit that tells us
> > whether the RC supports atomic ops from RCiEPs [1]. But I'm concerned
> > that GPUs, infiniband HCAs, and NICs that use atomic ops may be
> > implemented as RCiEPs and would be broken by this.
>
> FWIW, on AMD APUs our driver doesn't call pci_enable_atomic_ops_to_root. It
> just assumes that the GPU can do atomic accesses because it doesn't actually
> go through PCIe: https://elixir.bootlin.com/linux/v6.19.10/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L4785
What does this mean for the other branch that *does* use
pci_enable_atomic_ops_to_root()? Can any of those devices be RCiEPs?
> > These drivers use pci_enable_atomic_ops_to_root():
> >
> > amdgpu
> > bnxt_re (infiniband)
> > mlx5 (infinband)
> > qedr (infiniband)
> > mlx5 (ethernet)
> >
> > Maybe we should assume that because RCiEPs are directly integrated
> > into the RC, the RCiEP would only allow AtomicOp Requester Enable to
> > be set if the RC supports atomic ops?
> >
> > I don't like making assumptions like that, but it'd be worse to break
> > these devices.
> >
> > [1] https://lore.kernel.org/all/20260326164002.GA1325368@bhelgaas
> >
> > > Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
> > > ---
> > > drivers/pci/pci.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 8479c2e1f74f1044416281aba11bf071ea89488a..135e5b591df405e87e7f520a618d7e2ccba55ce1 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -3692,15 +3692,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
> > > /*
> > > * Per PCIe r4.0, sec 6.15, endpoints and root ports may be
> > > - * AtomicOp requesters. For now, we only support endpoints as
> > > - * requesters and root ports as completers. No endpoints as
> > > + * AtomicOp requesters. For now, we only support (legacy) endpoints
> > > + * as requesters and root ports as completers. No endpoints as
> > > * completers, and no peer-to-peer.
> > > */
> > > switch (pci_pcie_type(dev)) {
> > > case PCI_EXP_TYPE_ENDPOINT:
> > > case PCI_EXP_TYPE_LEG_END:
> > > - case PCI_EXP_TYPE_RC_END:
> > > break;
> > > default:
> > > return -EINVAL;
> > >
> > > --
> > > 2.51.0
> > >
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] gve: implement PTP gettimex64
From: Naman Gulati @ 2026-03-31 18:05 UTC (permalink / raw)
To: Jordan Rhee
Cc: Jakub Kicinski, hramamurthy, netdev, joshwash, andrew+netdev,
davem, edumazet, pabeni, richardcochran, willemb, nktgrg, jfraker,
ziweixiao, maolson, thostet, jefrogers, alok.a.tiwari, yyd,
linux-kernel
In-Reply-To: <CA+mzVtuK6NSrnZdcwyToTseFqBU86jRn9nbdeLGFjhjeok=q2g@mail.gmail.com>
On Sun, Mar 29, 2026 at 9:31 PM Jordan Rhee <jordanrhee@google.com> wrote:
>
> On Sun, Mar 29, 2026 at 2:20 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > ---
> > Subject: gve: implement PTP gettimex64
> >
> > This commit implements the PTP gettimex64 function to enable chrony and
> > phc2sys to synchronize the system clock to the NIC clock. It reads the
> > NIC timestamp along with pre and post system cycle counters to minimize
> > the uncertainty window.
> >
> > > diff --git a/drivers/net/ethernet/google/gve/gve_ptp.c b/drivers/net/ethernet/google/gve/gve_ptp.c
> > > index 140b8fbce4f4..bea794541f30 100644
> > > --- a/drivers/net/ethernet/google/gve/gve_ptp.c
> > > +++ b/drivers/net/ethernet/google/gve/gve_ptp.c
> > > @@ -10,28 +10,203 @@
> >
> > [ ... ]
> >
> > > +static int gve_adminq_read_timestamp(struct gve_priv *priv,
> > > + cycles_t *pre_cycles,
> > > + cycles_t *post_cycles)
> > > +{
> > > + unsigned long delay_us = 1000;
> > > + int retry_count = 0;
> > > + int err;
> > > +
> > > + lockdep_assert_held(&priv->nic_ts_read_lock);
> > > +
> > > + do {
> > > + *pre_cycles = get_cycles();
> > > + err = gve_adminq_report_nic_ts(priv, priv->nic_ts_report_bus);
> > > +
> > > + /* Ensure cycle counter is sampled after AdminQ cmd returns */
> > > + rmb();
> > > + *post_cycles = get_cycles();
> >
> > Are execution barriers needed around get_cycles() here? rmb() orders
> > memory accesses, but the CPU might still speculatively execute the cycle
> > counter reads out of order with respect to the AdminQ commands.
> >
> > Could this speculative reordering cause the strict bounds validation in
> > gve_ptp_gettimex64() to fail spuriously?
>
> I will add mb() barriers to be totally safe.
I'm not so sure that rmb() is insufficient here. In x86_64 rmb() is an
lfence. lfence is used to prevent speculative execution (per the x86
barrier_nospec implementation) and rdtsc_ordered, which is called by
the ktime* helpers, also prefaces rdtsc with an lfence. On ARM the
get_cycles implementation adds an isb instruction before reading
cntvct_el0.
>
> > [ ... ]
> >
> > > static int gve_ptp_gettimex64(struct ptp_clock_info *info,
> > > struct timespec64 *ts,
> > > struct ptp_system_timestamp *sts)
> > > {
> > > - return -EOPNOTSUPP;
> > > + struct gve_ptp *ptp = container_of(info, struct gve_ptp, info);
> > > + struct gve_sysclock_sample sysclock = {0};
> > > + struct gve_priv *priv = ptp->priv;
> > > + struct system_time_snapshot snap;
> > > + u64 nic_ts;
> > > + int err;
> > > +
> > > + /* Take system clock snapshot before sampling cycle counters */
> > > + if (sts)
> > > + ktime_get_snapshot(&snap);
> > > +
> > > + err = gve_clock_nic_ts_read(priv, &nic_ts, &sysclock);
> >
> > Could the system time snapshot become stale here?
> >
> > If priv->nic_ts_read_lock is contended, or if gve_adminq_read_timestamp()
> > retries and sleeps, the snapshot might be taken significantly before the
> > actual hardware read.
> >
> > Would it be more accurate to take the snapshot immediately before reading the
> > hardware, inside the mutex?
>
> Ack, will fix.
>
> >
> > > + if (err)
> > > + return err;
> > > +
> > > + if (sts) {
> > > + /* Reject samples with out of order system clock values */
> > > + if (!(sysclock.host_pre_cycles <= sysclock.nic_pre_cycles &&
> > > + sysclock.nic_pre_cycles <= sysclock.nic_post_cycles &&
> > > + sysclock.nic_post_cycles <= sysclock.host_post_cycles)) {
> > > + dev_err_ratelimited(&priv->pdev->dev,
> > > + "AdminQ system clock cycle counts out of order. Expecting %llu <= %llu <= %llu <= %llu\n",
> > > + (u64)sysclock.host_pre_cycles,
> > > + sysclock.nic_pre_cycles,
> > > + sysclock.nic_post_cycles,
> > > + (u64)sysclock.host_post_cycles);
> > > + return -EBADMSG;
> >
> > How does this behave on architectures where get_cycles() is not implemented
> > and returns 0, or with older firmware that leaves nic_pre_cycles and
> > nic_post_cycles as 0?
>
> Firmware is not allowed to return 0. 0 should trigger the check.
>
> > It looks like the bounds check would unconditionally fail and return -EBADMSG.
> > Since userspace tools like chrony usually expect -EOPNOTSUPP for unsupported
> > extended ioctls to fall back to basic PTP ioctls, will returning -EBADMSG
> > cause a hard failure for clock synchronization?
>
> Will fix. GVE is only supported on x86_64 and arm64, and will fail on
> other architectures with -EOPNOTSUPP due to the check in
> gve_cycles_to_clock_fn(). However, if an architecture returns
> get_cycles() as 0, it will fail here first with -EBADMSG. I will add
> an explicit check for x86 || arm64 earlier in this function.
>
> >
> > [ ... ]
> >
> > > @@ -132,7 +307,7 @@ int gve_init_clock(struct gve_priv *priv)
> > > goto release_ptp;
> > > }
> > > mutex_init(&priv->nic_ts_read_lock);
> > > - err = gve_clock_nic_ts_read(priv, &nic_raw);
> > > + err = gve_clock_nic_ts_read(priv, &nic_raw, NULL);
> > > if (err) {
> > > dev_err(&priv->pdev->dev, "failed to read NIC clock %d\n", err);
> > > goto release_nic_ts_report;
> >
> > Is there a race condition exposing the PTP device to userspace before its
> > resources are fully initialized?
> >
> > Looking at gve_init_clock(), gve_ptp_init() is called before allocating
> > nic_ts_report and initializing nic_ts_read_lock:
> >
> > err = gve_ptp_init(priv);
> > if (err)
> > return err;
> >
> > priv->nic_ts_report = dma_alloc_coherent(...);
> > ...
> > mutex_init(&priv->nic_ts_read_lock);
> >
> > If a concurrent userspace process immediately invokes the
> > PTP_SYS_OFFSET_EXTENDED ioctl after gve_ptp_init() registers the /dev/ptpX
> > device, could it call gve_ptp_gettimex64() and attempt to lock the
> > uninitialized mutex or dereference the NULL nic_ts_report pointer?
> >
> > Additionally, in the error path for gve_init_clock():
> >
> > release_nic_ts_report:
> > mutex_destroy(&priv->nic_ts_read_lock);
> > dma_free_coherent(...);
> > priv->nic_ts_report = NULL;
> > release_ptp:
> > gve_ptp_release(priv);
> >
> > Could destroying the mutex and freeing the memory before gve_ptp_release()
> > create a use-after-free window if an ioctl is currently running?
>
> Will be fixed in the previous patch in the series.
^ permalink raw reply
* Re: [PATCH net-next] net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIG
From: Erni Sri Satya Vennela @ 2026-03-31 18:02 UTC (permalink / raw)
To: Paolo Abeni
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, ssengar, dipayanroy, gargaditya, shirazsaleem,
kees, linux-hyperv, netdev, linux-kernel
In-Reply-To: <f0bc585f-b1d2-46e6-b0eb-801881862692@redhat.com>
> +
> > + if (*max_sq == 0 || *max_rq == 0) {
> > + netdev_err(apc->ndev, "Invalid max queues from vPort config\n");
> > + return -EPROTO;
>
> AI review says:
>
> Will returning -EPROTO here expose a pre-existing resource leak in the
> driver's teardown path?
> If mana_query_vport_cfg() returns an error, mana_init_port() fails and
> mana_probe_port() frees the ndev, leaving ac->ports[i] as NULL. In
> mana_probe(), the port initialization loop breaks upon this error, but
> the err variable is then overwritten:
>
> mana_probe() {
> ...
> for (i = 0; i < ac->num_ports; i++) {
> err = mana_probe_port(ac, i, &ac->ports[i]);
> if (err) {
> dev_err(dev, "Probe Failed for port %d\n", i);
> break;
> }
> }
>
> err = add_adev(gd, "eth");
> ...
> }
>
> If add_adev() succeeds, mana_probe() completes successfully instead of
> failing, masking the earlier error while leaving ac->ports[0] as NULL.
> Later, when the driver is unloaded or if add_adev() fails and triggers
> immediate cleanup, mana_remove() is called. It iterates over ac->ports
> and, upon encountering the NULL device, immediately executes goto out:
>
> mana_remove() {
> ...
> for (i = 0; i < ac->num_ports; i++) {
> ndev = ac->ports[i];
> if (!ndev) {
> if (i == 0)
> ...
> goto out;
> }
> ...
> }
>
> mana_destroy_eq(ac);
> out:
> ...
> }
>
> Because the out label in mana_remove() is located after the
> mana_destroy_eq(ac) call, jumping there completely skips destroying the
> event queues allocated earlier by mana_create_eq(ac).
> In a Confidential Virtual Machine context, could an untrusted hypervisor
> repeatedly return invalid configs to continuously leak guest memory and
> hardware queues?
Thankyou for the review.
Since these issues are pre-existing, I will send it in a separate
patchset.
The patchset will also include the issues reported in:
[PATCH net-next] net: mana: hardening: Validate adapter_mtu from
MANA_QUERY_DEV_CONFIG
- Vennela
^ permalink raw reply
* Re: [PATCH net-next] net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG
From: Erni Sri Satya Vennela @ 2026-03-31 18:00 UTC (permalink / raw)
To: Paolo Abeni
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, ssengar, dipayanroy, gargaditya, shirazsaleem,
kees, linux-hyperv, netdev, linux-kernel
In-Reply-To: <4ceecee2-ea5a-4026-ad38-66c0a7d263cd@redhat.com>
> > - if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2)
> > + if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2) {
> > + if (resp.adapter_mtu < ETH_MIN_MTU + ETH_HLEN) {
> > + dev_err(dev, "Adapter MTU too small: %u\n",
> > + resp.adapter_mtu);
> > + return -EPROTO;
>
> AI review says:
>
> If this returns -EPROTO, does the caller mana_probe() jump to an error
> label and call mana_remove()?
> If so, mana_remove() unconditionally calls
> disable_work_sync(&ac->link_change_work) and
> cancel_delayed_work_sync(&ac->gf_stats_work).
> Since mana_query_device_cfg() is called before INIT_WORK() and
> INIT_DELAYED_WORK() in the probe sequence, wouldn't this result in
> calling sync cancellation functions on uninitialized, zeroed work
> structures?
> This can lead to a WARN_ON(!work->func) in __flush_work(), or debug
> object warnings if CONFIG_DEBUG_OBJECTS_WORK is enabled.
> While this initialization issue appears to already exist for other early
> error paths, this new error path can also trigger it.
Thankyou for the review.
Since the issue is pre-existing. I will send it in a separate patchset.
The patchset will include the the issue reported with:
[PATCH net-next] net: mana: hardening: Reject zero max_num_queues from
MANA_QUERY_VPORT_CONFIG
- Vennela
^ permalink raw reply
* Re: [PATCH net-next v4] net: mana: Expose hardware diagnostic info via debugfs
From: Erni Sri Satya Vennela @ 2026-03-31 17:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, pabeni, kotaranov, horms, shradhagupta, shirazsaleem,
dipayanroy, yury.norov, kees, ssengar, gargaditya, linux-hyperv,
netdev, linux-kernel, linux-rdma
In-Reply-To: <20260330152318.144c1b30@kernel.org>
On Mon, Mar 30, 2026 at 03:23:18PM -0700, Jakub Kicinski wrote:
> On Mon, 30 Mar 2026 12:09:52 -0700 Erni Sri Satya Vennela wrote:
> > Just a quick follow‑up on this. Since these issues were pre‑existing and
> > not introduced by this patch, would you prefer that I send them as a
> > separate fix patch, or fold the fixes into the current patch?
>
> Anything that's pre-existing should be a separate patch, before any new
> code. If the bug exists only in net-next - earlier in the same series,
> if the bug exists in net - posted separately for the net tree.
Thankyou for the explanation.
I will send it in a separate patch.
- Vennela
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Jordan Rife, netdev
Cc: oe-kbuild-all, Jordan Rife, bpf, Willem de Bruijn, Eric Dumazet,
Daniel Borkmann, Martin KaFai Lau, Stanislav Fomichev,
Andrii Nakryiko, Yusuke Suzuki, Jakub Kicinski, Kuniyuki Iwashima
In-Reply-To: <20260330215707.2374657-3-jrife@google.com>
Hi Jordan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Jordan-Rife/udp-Only-compare-daddr-dport-when-sk_state-TCP_ESTABLISHED/20260331-082300
base: net-next/main
patch link: https://lore.kernel.org/r/20260330215707.2374657-3-jrife%40google.com
patch subject: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
config: sparc64-randconfig-r071-20260331 (https://download.01.org/0day-ci/archive/20260401/202604010154.iewJbUya-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 8.5.0
smatch: v0.5.0-9004-gb810ac53
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010154.iewJbUya-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010154.iewJbUya-lkp@intel.com/
All warnings (new ones prefixed by >>):
net/ipv4/udp.c: In function 'udp_disconnect_unhash4':
net/ipv4/udp.c:2182:31: error: implicit declaration of function 'udp_get_table_prot'; did you mean 'vm_get_page_prot'? [-Werror=implicit-function-declaration]
struct udp_table *udptable = udp_get_table_prot(sk);
^~~~~~~~~~~~~~~~~~
vm_get_page_prot
>> net/ipv4/udp.c:2182:31: warning: initialization of 'struct udp_table *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
cc1: some warnings being treated as errors
vim +2182 net/ipv4/udp.c
2179
2180 static int udp_disconnect_unhash4(struct sock *sk, int flags)
2181 {
> 2182 struct udp_table *udptable = udp_get_table_prot(sk);
2183
2184 udp_unhash4(udptable, sk);
2185 __udp_disconnect(sk, flags);
2186
2187 return 0;
2188 }
2189
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v8 04/10] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
From: Sean Christopherson @ 2026-03-31 17:50 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260324-vmscape-bhb-v8-4-68bb524b3ab9@linux.intel.com>
On Tue, Mar 24, 2026, Pawan Gupta wrote:
> With the upcoming changes x86_ibpb_exit_to_user will also be used when BHB
> clearing sequence is used. Rename it cover both the cases.
>
> No functional change.
>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
Acked-by: Sean Christopherson <seanjc@google.com>
^ permalink raw reply
* [PATCH v2 net-next] ipv6: move ip6_dst_hoplimit() to net/ipv6/ip6_output.c
From: Eric Dumazet @ 2026-03-31 17:47 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, David Ahern, netdev, eric.dumazet, Eric Dumazet,
Fernando Fernandez Mancera, Kuniyuki Iwashima
Move ip6_dst_hoplimit() to net/ipv6/ip6_output.c so that compiler
can (auto)inline it from ip6_xmit().
$ scripts/bloat-o-meter -t vmlinux.0 vmlinux.1
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11 (-11)
Function old new delta
ip6_xmit 1684 1673 -11
Total: Before=29655407, After=29655396, chg -0.00%
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
---
v2: Resend after IPv6 is no longer a module.
Added Fernando and Kuniyuki 'Reviewed-by'
net/ipv6/ip6_output.c | 21 +++++++++++++++++++++
net/ipv6/output_core.c | 23 -----------------------
2 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 63abc4fddaee8e9cf2ad2ef0873c963eaea63247..7e92909ab5be3f86b10bf9527e97f3bfe794e9e9 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -259,6 +259,27 @@ bool ip6_autoflowlabel(struct net *net, const struct sock *sk)
return inet6_test_bit(AUTOFLOWLABEL, sk);
}
+int ip6_dst_hoplimit(struct dst_entry *dst)
+{
+ int hoplimit = dst_metric_raw(dst, RTAX_HOPLIMIT);
+
+ rcu_read_lock();
+ if (hoplimit == 0) {
+ struct net_device *dev = dst_dev_rcu(dst);
+ struct inet6_dev *idev;
+
+ idev = __in6_dev_get(dev);
+ if (idev)
+ hoplimit = READ_ONCE(idev->cnf.hop_limit);
+ else
+ hoplimit = READ_ONCE(dev_net(dev)->ipv6.devconf_all->hop_limit);
+ }
+ rcu_read_unlock();
+
+ return hoplimit;
+}
+EXPORT_SYMBOL(ip6_dst_hoplimit);
+
/*
* xmit an sk_buff (used by TCP and SCTP)
* Note : socket lock is not held for SYNACK packets, but might be modified
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index cba1684a3f30ff98517d873ddb8e97f32adc9791..64b1eeb79b572b8b412c60f832c4a7984ac8276f 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -100,29 +100,6 @@ int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
}
EXPORT_SYMBOL(ip6_find_1stfragopt);
-#if IS_ENABLED(CONFIG_IPV6)
-int ip6_dst_hoplimit(struct dst_entry *dst)
-{
- int hoplimit = dst_metric_raw(dst, RTAX_HOPLIMIT);
-
- rcu_read_lock();
- if (hoplimit == 0) {
- struct net_device *dev = dst_dev_rcu(dst);
- struct inet6_dev *idev;
-
- idev = __in6_dev_get(dev);
- if (idev)
- hoplimit = READ_ONCE(idev->cnf.hop_limit);
- else
- hoplimit = READ_ONCE(dev_net(dev)->ipv6.devconf_all->hop_limit);
- }
- rcu_read_unlock();
-
- return hoplimit;
-}
-EXPORT_SYMBOL(ip6_dst_hoplimit);
-#endif
-
int __ip6_local_out(struct net *net, struct sock *sk, struct sk_buff *skb)
{
ipv6_set_payload_len(ipv6_hdr(skb), skb->len - sizeof(struct ipv6hdr));
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* Re: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
From: kernel test robot @ 2026-03-31 17:42 UTC (permalink / raw)
To: Jordan Rife, netdev
Cc: oe-kbuild-all, Jordan Rife, bpf, Willem de Bruijn, Eric Dumazet,
Daniel Borkmann, Martin KaFai Lau, Stanislav Fomichev,
Andrii Nakryiko, Yusuke Suzuki, Jakub Kicinski, Kuniyuki Iwashima
In-Reply-To: <20260330215707.2374657-3-jrife@google.com>
Hi Jordan,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Jordan-Rife/udp-Only-compare-daddr-dport-when-sk_state-TCP_ESTABLISHED/20260331-082300
base: net-next/main
patch link: https://lore.kernel.org/r/20260330215707.2374657-3-jrife%40google.com
patch subject: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260331/202603311954.k4BkWpJN-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603311954.k4BkWpJN-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603311954.k4BkWpJN-lkp@intel.com/
All errors (new ones prefixed by >>):
net/ipv4/udp.c: In function 'udp_disconnect_unhash4':
>> net/ipv4/udp.c:2182:38: error: implicit declaration of function 'udp_get_table_prot'; did you mean 'vm_get_page_prot'? [-Wimplicit-function-declaration]
2182 | struct udp_table *udptable = udp_get_table_prot(sk);
| ^~~~~~~~~~~~~~~~~~
| vm_get_page_prot
>> net/ipv4/udp.c:2182:38: error: initialization of 'struct udp_table *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
vim +2182 net/ipv4/udp.c
2179
2180 static int udp_disconnect_unhash4(struct sock *sk, int flags)
2181 {
> 2182 struct udp_table *udptable = udp_get_table_prot(sk);
2183
2184 udp_unhash4(udptable, sk);
2185 __udp_disconnect(sk, flags);
2186
2187 return 0;
2188 }
2189
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Fernando Fernandez Mancera @ 2026-03-31 17:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
In-Reply-To: <20260331103538.103e3778@kernel.org>
On 3/31/26 7:35 PM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 13:59:43 +0200 Fernando Fernandez Mancera wrote:
>> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
>> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
>> single nexthops and small Equal-Cost Multi-Path groups, this fixed
>> allocation fails for large nexthop groups like 512+ nexthops.
>
> router_mpath_seed.sh says:
>
> [ 9.366434] WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x181/0x1b0, CPU#0: ip/342
> [ 9.366490] Modules linked in: vrf veth
> [ 9.366519] CPU: 0 UID: 0 PID: 342 Comm: ip Not tainted 7.0.0-rc5-virtme #1 PREEMPT(lazy)
> [ 9.366567] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 9.366610] RIP: 0010:rtm_get_nexthop+0x181/0x1b0
> [ 9.366649] Code: 25 a7 ee ff eb 80 48 c7 c7 a0 ee af ae e8 57 30 f5 ff 4d 85 ed 74 08 49 c7 45 00 a0 ee af ae b8 ea ff ff ff e9 5d ff ff ff 90 <0f> 0b 90 ba 02 00 00 00 4c 89 ee 31 ff e8 2d 84 eb ff b8 a6 ff ff
> [ 9.366754] RSP: 0018:ff5db175808bf9d8 EFLAGS: 00010286
> [ 9.366790] RAX: 00000000ffffffa6 RBX: ff3c7cb941dab700 RCX: 0000000000000000
> [ 9.366835] RDX: 0000000000000003 RSI: 0000000000000000 RDI: ff3c7cb94404a300
> [ 9.366872] RBP: ff3c7cb94404a400 R08: ff3c7cb9413f25a8 R09: ff3c7cb94196cb40
> [ 9.366916] R10: ff3c7cb94196ca00 R11: 000000000000000e R12: ffffffffaf8df6c0
> [ 9.366967] R13: ff3c7cb94404a300 R14: ff3c7cb94525e180 R15: ff3c7cb94404a400
> [ 9.367018] FS: 00007fa1f5261440(0000) GS:ff3c7cb9cf3fb000(0000) knlGS:0000000000000000
> [ 9.367064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 9.367102] CR2: 000000000044f720 CR3: 000000000573f001 CR4: 0000000000771ef0
> [ 9.367149] PKRU: 55555554
> [ 9.367165] Call Trace:
> [ 9.367183] <TASK>
> [ 9.367201] rtnetlink_rcv_msg+0x13a/0x3e0
> [ 9.367227] ? get_page_from_freelist+0x1109/0x16c0
> [ 9.367259] ? rtnl_calcit.isra.0+0x120/0x120
> [ 9.367286] netlink_rcv_skb+0x59/0x100
> [ 9.367310] netlink_unicast+0x255/0x380
> [ 9.367333] netlink_sendmsg+0x1cc/0x3e0
> [ 9.367356] ____sys_sendmsg+0x164/0x260
> [ 9.367390] ___sys_sendmsg+0x99/0xe0
> [ 9.367415] __sys_sendmsg+0x8a/0xe0
> [ 9.367441] do_syscall_64+0x101/0xfc0
> [ 9.367466] ? exc_page_fault+0x6e/0x170
> [ 9.367493] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 9.367528] RIP: 0033:0x7fa1f53bbc5e
> [ 9.367550] Code: 4d 89 d8 e8 34 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa
> [ 9.367653] RSP: 002b:00007ffc00947ff0 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
> [ 9.367700] RAX: ffffffffffffffda RBX: 000000000048ba90 RCX: 00007fa1f53bbc5e
> [ 9.367744] RDX: 0000000000000000 RSI: 00007ffc009480b0 RDI: 0000000000000005
> [ 9.367787] RBP: 00007ffc00948000 R08: 0000000000000000 R09: 0000000000000000
> [ 9.367835] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000049d620
> [ 9.367889] R13: 0000000069cbe823 R14: 0000000000000004 R15: 000000000049d620
>
> decoded:
> https://netdev-ctrl.bots.linux.dev/logs/vmksft/forwarding/results/582821/vm-crash-thr4-1
Hi Jakub,
thanks for sharing. As I replied to Eric this is the main reason why a
V2 is needed. There is also another bug I discovered while fixing this.
When dumping the stats NHA_HW_STATS_ENABLE is being included twice per
group. I am fixing that in another patch that will be included on the V2
series.
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH net-next 01/15] igc: Call netif_queue_set_napi() with rtnl locked
From: Bjorn Helgaas @ 2026-03-31 17:37 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Mika Westerberg, andriy.shevchenko, ilpo.jarvinen, dima.ruinskiy,
mbloch, leon, linux-pci, saeedm, tariqt, lukas, bhelgaas,
richardcochran, Vinicius Costa Gomes, Jacob Keller, Avigail Dahan
In-Reply-To: <20260330230248.646900-2-anthony.l.nguyen@intel.com>
On Mon, Mar 30, 2026 at 04:02:30PM -0700, Tony Nguyen wrote:
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
>
> When runtime resuming igc we get:
>
> [ 516.161666] RTNL: assertion failed at ./include/net/netdev_lock.h (72)
>
> Happens because commit 310ae9eb2617 ("net: designate queue -> napi
> linking as "ops protected"") added check for this. For this reason drop
> the special case for runtime PM from __igc_resume(). This makes it take
> rtnl lock unconditionally.
Taking the rtnl lock unconditionally certainly makes the code nicer,
but the commit log only mentions the "avoid the warning" benefit, not
the actual reason this is safe to do.
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Avigail Dahan <avigailx.dahan@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 72bc5128d8b8..98024b46789f 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -7536,7 +7536,7 @@ static void igc_deliver_wake_packet(struct net_device *netdev)
> netif_rx(skb);
> }
>
> -static int __igc_resume(struct device *dev, bool rpm)
> +static int __igc_resume(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct net_device *netdev = pci_get_drvdata(pdev);
> @@ -7581,11 +7581,9 @@ static int __igc_resume(struct device *dev, bool rpm)
> wr32(IGC_WUS, ~0);
>
> if (netif_running(netdev)) {
> - if (!rpm)
> - rtnl_lock();
> + rtnl_lock();
> err = __igc_open(netdev, true);
> - if (!rpm)
> - rtnl_unlock();
> + rtnl_unlock();
> if (!err)
> netif_device_attach(netdev);
> }
> @@ -7595,12 +7593,12 @@ static int __igc_resume(struct device *dev, bool rpm)
>
> static int igc_resume(struct device *dev)
> {
> - return __igc_resume(dev, false);
> + return __igc_resume(dev);
> }
>
> static int igc_runtime_resume(struct device *dev)
> {
> - return __igc_resume(dev, true);
> + return __igc_resume(dev);
> }
>
> static int igc_suspend(struct device *dev)
> --
> 2.47.1
>
^ permalink raw reply
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Jakub Kicinski @ 2026-03-31 17:35 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
In-Reply-To: <20260331115943.10404-1-fmancera@suse.de>
On Tue, 31 Mar 2026 13:59:43 +0200 Fernando Fernandez Mancera wrote:
> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> allocation fails for large nexthop groups like 512+ nexthops.
router_mpath_seed.sh says:
[ 9.366434] WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x181/0x1b0, CPU#0: ip/342
[ 9.366490] Modules linked in: vrf veth
[ 9.366519] CPU: 0 UID: 0 PID: 342 Comm: ip Not tainted 7.0.0-rc5-virtme #1 PREEMPT(lazy)
[ 9.366567] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 9.366610] RIP: 0010:rtm_get_nexthop+0x181/0x1b0
[ 9.366649] Code: 25 a7 ee ff eb 80 48 c7 c7 a0 ee af ae e8 57 30 f5 ff 4d 85 ed 74 08 49 c7 45 00 a0 ee af ae b8 ea ff ff ff e9 5d ff ff ff 90 <0f> 0b 90 ba 02 00 00 00 4c 89 ee 31 ff e8 2d 84 eb ff b8 a6 ff ff
[ 9.366754] RSP: 0018:ff5db175808bf9d8 EFLAGS: 00010286
[ 9.366790] RAX: 00000000ffffffa6 RBX: ff3c7cb941dab700 RCX: 0000000000000000
[ 9.366835] RDX: 0000000000000003 RSI: 0000000000000000 RDI: ff3c7cb94404a300
[ 9.366872] RBP: ff3c7cb94404a400 R08: ff3c7cb9413f25a8 R09: ff3c7cb94196cb40
[ 9.366916] R10: ff3c7cb94196ca00 R11: 000000000000000e R12: ffffffffaf8df6c0
[ 9.366967] R13: ff3c7cb94404a300 R14: ff3c7cb94525e180 R15: ff3c7cb94404a400
[ 9.367018] FS: 00007fa1f5261440(0000) GS:ff3c7cb9cf3fb000(0000) knlGS:0000000000000000
[ 9.367064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.367102] CR2: 000000000044f720 CR3: 000000000573f001 CR4: 0000000000771ef0
[ 9.367149] PKRU: 55555554
[ 9.367165] Call Trace:
[ 9.367183] <TASK>
[ 9.367201] rtnetlink_rcv_msg+0x13a/0x3e0
[ 9.367227] ? get_page_from_freelist+0x1109/0x16c0
[ 9.367259] ? rtnl_calcit.isra.0+0x120/0x120
[ 9.367286] netlink_rcv_skb+0x59/0x100
[ 9.367310] netlink_unicast+0x255/0x380
[ 9.367333] netlink_sendmsg+0x1cc/0x3e0
[ 9.367356] ____sys_sendmsg+0x164/0x260
[ 9.367390] ___sys_sendmsg+0x99/0xe0
[ 9.367415] __sys_sendmsg+0x8a/0xe0
[ 9.367441] do_syscall_64+0x101/0xfc0
[ 9.367466] ? exc_page_fault+0x6e/0x170
[ 9.367493] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 9.367528] RIP: 0033:0x7fa1f53bbc5e
[ 9.367550] Code: 4d 89 d8 e8 34 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa
[ 9.367653] RSP: 002b:00007ffc00947ff0 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
[ 9.367700] RAX: ffffffffffffffda RBX: 000000000048ba90 RCX: 00007fa1f53bbc5e
[ 9.367744] RDX: 0000000000000000 RSI: 00007ffc009480b0 RDI: 0000000000000005
[ 9.367787] RBP: 00007ffc00948000 R08: 0000000000000000 R09: 0000000000000000
[ 9.367835] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000049d620
[ 9.367889] R13: 0000000069cbe823 R14: 0000000000000004 R15: 000000000049d620
decoded:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/forwarding/results/582821/vm-crash-thr4-1
^ permalink raw reply
* Re: [PATCH net-next 02/15] igc: Let the PCI core deal with the PM resume flow
From: Bjorn Helgaas @ 2026-03-31 17:34 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Mika Westerberg, andriy.shevchenko, ilpo.jarvinen, dima.ruinskiy,
mbloch, leon, linux-pci, saeedm, tariqt, lukas, bhelgaas,
richardcochran, Vinicius Costa Gomes, Jacob Keller, Avigail Dahan
In-Reply-To: <20260330230248.646900-3-anthony.l.nguyen@intel.com>
On Mon, Mar 30, 2026 at 04:02:31PM -0700, Tony Nguyen wrote:
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
>
> Currently igc driver calls pci_set_power_state() and pci_restore_state()
> and the like to bring the device back from low power states. However,
> PCI core handles all this on behalf of the driver. Furthermore with PTM
> enabled the PCI core re-enables it on resume but the driver calls
> pci_restore_state() which ends up disabling it again.
>
> For this reason let the PCI core handle the common PM resume flow.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Avigail Dahan <avigailx.dahan@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
I love it, thanks a lot for doing this!
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 98024b46789f..0e785af0a3a3 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -7544,9 +7544,6 @@ static int __igc_resume(struct device *dev)
> struct igc_hw *hw = &adapter->hw;
> u32 err, val;
>
> - pci_set_power_state(pdev, PCI_D0);
> - pci_restore_state(pdev);
> -
> if (!pci_device_is_present(pdev))
> return -ENODEV;
> err = pci_enable_device_mem(pdev);
__igc_shutdown() calls pci_disable_device() in the suspend paths,
which disables bus mastering. There are only a relative handful of
drivers that do this, mostly for NICs, so I'm not sure if it's really
necessary or if it's been cargo-culted.
Here in the resume path we call pci_enable_device_mem(),
pci_set_master(), and conditionally call pci_disable_link_state(). I
suspect all those are unnecessary because pci_pm_resume() should have
called pci_restore_state() before we get here.
> @@ -7556,9 +7553,6 @@ static int __igc_resume(struct device *dev)
> }
> pci_set_master(pdev);
>
> - pci_enable_wake(pdev, PCI_D3hot, 0);
> - pci_enable_wake(pdev, PCI_D3cold, 0);
> -
> if (igc_is_device_id_i226(hw))
> pci_disable_link_state(pdev, PCIE_LINK_STATE_L1_2);
>
> --
> 2.47.1
>
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
From: kernel test robot @ 2026-03-31 17:33 UTC (permalink / raw)
To: Jordan Rife, netdev
Cc: oe-kbuild-all, Jordan Rife, bpf, Willem de Bruijn, Eric Dumazet,
Daniel Borkmann, Martin KaFai Lau, Stanislav Fomichev,
Andrii Nakryiko, Yusuke Suzuki, Jakub Kicinski, Kuniyuki Iwashima
In-Reply-To: <20260330215707.2374657-3-jrife@google.com>
Hi Jordan,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Jordan-Rife/udp-Only-compare-daddr-dport-when-sk_state-TCP_ESTABLISHED/20260331-082300
base: net-next/main
patch link: https://lore.kernel.org/r/20260330215707.2374657-3-jrife%40google.com
patch subject: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
config: openrisc-defconfig (https://download.01.org/0day-ci/archive/20260401/202604010147.jxlA7slL-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010147.jxlA7slL-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010147.jxlA7slL-lkp@intel.com/
All errors (new ones prefixed by >>):
net/ipv4/udp.c: In function 'udp_disconnect_unhash4':
>> net/ipv4/udp.c:2182:38: error: implicit declaration of function 'udp_get_table_prot'; did you mean 'vm_get_page_prot'? [-Wimplicit-function-declaration]
2182 | struct udp_table *udptable = udp_get_table_prot(sk);
| ^~~~~~~~~~~~~~~~~~
| vm_get_page_prot
>> net/ipv4/udp.c:2182:38: error: initialization of 'struct udp_table *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
vim +2182 net/ipv4/udp.c
2179
2180 static int udp_disconnect_unhash4(struct sock *sk, int flags)
2181 {
> 2182 struct udp_table *udptable = udp_get_table_prot(sk);
2183
2184 udp_unhash4(udptable, sk);
2185 __udp_disconnect(sk, flags);
2186
2187 return 0;
2188 }
2189
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next 0/7] Decouple receive and transmit enablement in team driver
From: Jakub Kicinski @ 2026-03-31 17:33 UTC (permalink / raw)
To: Marc Harvey
Cc: jiri, andrew+netdev, willemb, maheshb, netdev, linux-kselftest
In-Reply-To: <20260331053353.2504254-1-marcharvey@google.com>
On Tue, 31 Mar 2026 05:33:46 +0000 Marc Harvey wrote:
> Allow independent control over receive and transmit enablement states
> for aggregated ports in the team driver.
>
> The motivation is that IEE 802.3ad LACP "independent control" can't
> be implemented for the team driver currently. This was added to the
> bonding driver in commit 240fd405528b ("bonding: Add independent
> control state machine").
>
> This series also has a few patches that add tests to show that the old
> coupled enablement still works and that the new decoupled enalbment
> works as intended (4, 5, and 7).
>
> There are three patches with small fixes as well, with the goal of
> making the final decouplement patch clearer (1, 2, and 3).
The tests don't pass for us, any dependencies we should be aware of?
# selftests: drivers/net/team: teamd_activebackup.sh
# Setting up two-link aggregation for runner activebackup
# Conf files are /tmp/tmp.zYDeygAAcf and /tmp/tmp.y5dfmFapAj
# This program is not intended to be run as root.
# This program is not intended to be run as root.
# Created team devices
# PING fd00::2 (fd00::2) 56 data bytes
# 64 bytes from fd00::2: icmp_seq=1 ttl=64 time=233 ms
#
# --- fd00::2 ping statistics ---
# 1 packets transmitted, 1 received, 0% packet loss, time 0ms
# rtt min/avg/max/mdev = 233.163/233.163/233.163/0.000 ms/bin/bash: line 1: pv: command not found
# Packet count for test_team2 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# Packet count for eth0 was 0
# Packet count for eth1 was 0
# TEST: teamd active backup runner test [FAIL]
# Traffic did not reach team interface in NS2.
# ./team_lib.sh: line 87: kill: (597) - No such process
# Tearing down two-link aggregation
# Failed to kill daemon: Timer expired
--
pw-bot: defer
^ permalink raw reply
* Re: [syzbot] [net] INFO: task hung in tun_chr_close (5)
From: syzbot @ 2026-03-31 17:17 UTC (permalink / raw)
To: andrew+netdev, andrew, davem, edumazet, jason, jasowang, jhs,
jiri, kuba, linux-kernel, mail, netdev, newsletter, pabeni,
syzkaller-bugs, vinicius.gomes, willemdebruijn.kernel, wireguard,
xiyou.wangcong
In-Reply-To: <000000000000bd671b06222de427@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 47ab2c12c87a Merge branch 'correct-bd-length-masks-and-bql..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=153aed02580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6754c86e8d9e4c91
dashboard link: https://syzkaller.appspot.com/bug?extid=b0ae8f1abf7d891e0426
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1286e8d2580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=106df5da580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/289234295ce6/disk-47ab2c12.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b3f30eb7dc01/vmlinux-47ab2c12.xz
kernel image: https://storage.googleapis.com/syzbot-assets/62a0f5642c08/bzImage-47ab2c12.xz
The issue was bisected to:
commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date: Sat Sep 29 00:59:43 2018 +0000
tc: Add support for configuring the taprio scheduler
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11535418580000
final oops: https://syzkaller.appspot.com/x/report.txt?x=13535418580000
console output: https://syzkaller.appspot.com/x/log.txt?x=15535418580000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b0ae8f1abf7d891e0426@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
INFO: task syz-executor:5978 blocked for more than 143 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor state:D stack:22400 pid:5978 tgid:5978 ppid:1 task_flags:0x40054c flags:0x00080003
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x15dd/0x52d0 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7008
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7065
__mutex_lock_common kernel/locking/mutex.c:692 [inline]
__mutex_lock+0x7fe/0x1300 kernel/locking/mutex.c:776
tun_detach drivers/net/tun.c:634 [inline]
tun_chr_close+0x3e/0x1c0 drivers/net/tun.c:3436
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* Re: [RESEND PATCH] ice: access @pp through netmem_desc instead of page
From: Tony Nguyen @ 2026-03-31 17:08 UTC (permalink / raw)
To: Byungchul Park
Cc: netdev, kuba, linux-kernel, kernel_team, harry.yoo, david, willy,
toke, asml.silence, almasrymina, przemyslaw.kitszel,
andrew+netdev, davem, edumazet, pabeni, intel-wired-lan
In-Reply-To: <20260331081145.GA54972@system.software.com>
On 3/31/2026 1:11 AM, Byungchul Park wrote:
> On Thu, Feb 26, 2026 at 10:13:14AM -0800, Tony Nguyen wrote:
>> On 2/25/2026 5:08 PM, Byungchul Park wrote:
>>> On Tue, Feb 24, 2026 at 02:35:46PM +0900, Byungchul Park wrote:
>>>> 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.
>>>
>>> Hi Tony and Przemek,
>>>
>>> Is there something that I'm missing or something wrong with this? Your
>>> feedback would be appreciated. Thanks!
>>
>> Hi Byungchul,
>>
>> Nothing wrong. I plan to apply it today.
>
> Hi Tony,
>
> Sorry bothering you but could you tell me where I can see the patch
> ready in a tree, maybe yours? I failed to locate it.
>
> This patch is very important for the project removing pp fields from
> struct page to go ahead. Thanks in advance.
Hi Byungchul,
I actually heard from my validation about this yesterday. They're seeing
issues on the loopback test. We're working on isolating the problem to
determine/ensure it wasn't due to this patch. Hopefully that will be
done soon and, if not the problem, I'll get it sent out shortly thereafter.
Thanks,
Tony
> Byungchul
>
>> Thanks,
>> Tony
>>
>>> Byungchul
>>>
>>>> Signed-off-by: Byungchul Park <byungchul@sk.com>
>>>> ---
>>>> drivers/net/ethernet/intel/ice/ice_ethtool.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>>> index c6bc29cfb8e6..c16e54dbe75b 100644
>>>> --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>>> +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>>> @@ -1251,7 +1251,7 @@ static int ice_lbtest_receive_frames(struct ice_rx_ring *rx_ring)
>>>> rx_buf = &rx_ring->rx_fqes[i];
>>>> page = __netmem_to_page(rx_buf->netmem);
>>>> received_buf = page_address(page) + rx_buf->offset +
>>>> - page->pp->p.offset;
>>>> + pp_page_to_nmdesc(page)->pp->p.offset;
>>>>
>>>> if (ice_lbtest_check_frame(received_buf))
>>>> valid_frames++;
>>>> --
>>>> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
From: kernel test robot @ 2026-03-31 16:51 UTC (permalink / raw)
To: Jordan Rife, netdev
Cc: llvm, oe-kbuild-all, Jordan Rife, bpf, Willem de Bruijn,
Eric Dumazet, Daniel Borkmann, Martin KaFai Lau,
Stanislav Fomichev, Andrii Nakryiko, Yusuke Suzuki,
Jakub Kicinski, Kuniyuki Iwashima
In-Reply-To: <20260330215707.2374657-3-jrife@google.com>
Hi Jordan,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Jordan-Rife/udp-Only-compare-daddr-dport-when-sk_state-TCP_ESTABLISHED/20260331-082300
base: net-next/main
patch link: https://lore.kernel.org/r/20260330215707.2374657-3-jrife%40google.com
patch subject: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260331/202603311827.nefybt0I-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603311827.nefybt0I-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603311827.nefybt0I-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/ipv4/udp.c:2182:31: error: call to undeclared function 'udp_get_table_prot'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
2182 | struct udp_table *udptable = udp_get_table_prot(sk);
| ^
net/ipv4/udp.c:2182:31: note: did you mean 'vm_get_page_prot'?
include/linux/mm.h:4105:10: note: 'vm_get_page_prot' declared here
4105 | pgprot_t vm_get_page_prot(vm_flags_t vm_flags);
| ^
>> net/ipv4/udp.c:2182:20: error: incompatible integer to pointer conversion initializing 'struct udp_table *' with an expression of type 'int' [-Wint-conversion]
2182 | struct udp_table *udptable = udp_get_table_prot(sk);
| ^ ~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
vim +/udp_get_table_prot +2182 net/ipv4/udp.c
2179
2180 static int udp_disconnect_unhash4(struct sock *sk, int flags)
2181 {
> 2182 struct udp_table *udptable = udp_get_table_prot(sk);
2183
2184 udp_unhash4(udptable, sk);
2185 __udp_disconnect(sk, flags);
2186
2187 return 0;
2188 }
2189
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 1/1] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
From: Konstantin Khorenko @ 2026-03-31 16:50 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Thomas Weißschuh
Cc: Simon Horman, Arnd Bergmann, netdev, linux-kernel,
Konstantin Khorenko
In-Reply-To: <20260331165125.959833-1-khorenko@virtuozzo.com>
When CONFIG_GCOV_PROFILE_ALL=y is enabled, the kernel fails to build:
In file included from <command-line>:
In function 'skb_extensions_init',
inlined from 'skb_init' at net/core/skbuff.c:5214:2:
././include/linux/compiler_types.h:706:45: error: call to
'__compiletime_assert_1490' declared with attribute error:
BUILD_BUG_ON failed: skb_ext_total_length() > 255
CONFIG_GCOV_PROFILE_ALL adds -fprofile-arcs -ftest-coverage
-fno-tree-loop-im to CFLAGS globally. GCC inserts branch profiling
counters into the skb_ext_total_length() loop and, combined with
-fno-tree-loop-im (which disables loop invariant motion), cannot
constant-fold the result. BUILD_BUG_ON requires a compile-time constant
and fails.
The issue manifests in kernels with 5+ SKB extension types enabled
(e.g., after addition of SKB_EXT_CAN, SKB_EXT_PSP). With 4 extensions
GCC can still unroll and fold the loop despite GCOV instrumentation;
with 5+ it gives up.
Mark skb_ext_total_length() with __no_profile to prevent GCOV from
inserting counters into this function. Without counters the loop is
"clean" and GCC can constant-fold it even with -fno-tree-loop-im active.
This allows BUILD_BUG_ON to work correctly while keeping GCOV profiling
for the rest of the kernel.
This also removes the CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard
introduced by d6e5794b06c0, as __no_profile handles both GCOV and KCOV
instrumentation at the root cause level rather than just disabling the
check.
Fixes: 5d21d0a65b57 ("net: generalize calculation of skb extensions length")
Fixes: d6e5794b06c0 ("net: avoid build bug in skb extension length calculation")
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
---
net/core/skbuff.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0e217041958a..47c7f0ab6e84 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5145,7 +5145,7 @@ static const u8 skb_ext_type_len[] = {
#endif
};
-static __always_inline unsigned int skb_ext_total_length(void)
+static __always_inline __no_profile unsigned int skb_ext_total_length(void)
{
unsigned int l = SKB_EXT_CHUNKSIZEOF(struct skb_ext);
int i;
@@ -5159,9 +5159,7 @@ static __always_inline unsigned int skb_ext_total_length(void)
static void skb_extensions_init(void)
{
BUILD_BUG_ON(SKB_EXT_NUM > 8);
-#if !IS_ENABLED(CONFIG_KCOV_INSTRUMENT_ALL)
BUILD_BUG_ON(skb_ext_total_length() > 255);
-#endif
skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),
--
2.43.5
^ permalink raw reply related
* [PATCH v2 0/1] Fix kernel build failure with CONFIG_GCOV_PROFILE_ALL=y
From: Konstantin Khorenko @ 2026-03-31 16:50 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Thomas Weißschuh
Cc: Simon Horman, Arnd Bergmann, netdev, linux-kernel,
Konstantin Khorenko
This patch fixes a build failure in net/core/skbuff.c that occurs when
CONFIG_GCOV_PROFILE_ALL=y is enabled.
v2: use __no_profile instead of preprocessor guards, as suggested
by Thomas Weißschuh. This solves the root cause (GCOV counters
preventing constant folding) and also removes the existing
CONFIG_KCOV_INSTRUMENT_ALL guard which is no longer needed.
Build failure without this patch
---------------------------------
With the following configuration:
CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y
# CONFIG_GCOV_PROFILE_FTRACE is not set
CONFIG_GCOV_PROFILE_RDS=y
CONFIG_GCOV_PROFILE_URING=y
The kernel fails to build with:
In file included from <command-line>:
In function 'skb_extensions_init',
inlined from 'skb_init' at net/core/skbuff.c:5214:2:
././include/linux/compiler_types.h:706:45: error: call to '__compiletime_assert_1490' declared with attribute error: BUILD_BUG_ON failed: skb_ext_total_length() > 255
706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
././include/linux/compiler_types.h:687:25: note: in definition of macro '__compiletime_assert'
687 | prefix ## suffix(); \
| ^~~~~~
././include/linux/compiler_types.h:706:9: note: in expansion of macro '_compiletime_assert'
706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:40:37: note: in expansion of macro 'compiletime_assert'
40 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:51:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
51 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
net/core/skbuff.c:5163:9: note: in expansion of macro 'BUILD_BUG_ON'
5163 | BUILD_BUG_ON(skb_ext_total_length() > 255);
| ^~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:289: net/core/skbuff.o] Error 1
Testing
-------
Tested with GCC 11.4.1 and GCC 16.0.1 20260327 (experimental) - both
exhibit the same build failure without the patch. Both compile
successfully with the patch applied.
Konstantin Khorenko (1):
net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
net/core/skbuff.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--
2.43.5
^ permalink raw reply
* [PATCH-next v2 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
From: Waiman Long @ 2026-03-31 16:50 UTC (permalink / raw)
To: Simon Horman, Julian Anastasov, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Pablo Neira Ayuso,
Florian Westphal, Phil Sutter, Frederic Weisbecker, Chen Ridong,
Phil Auld
Cc: linux-kernel, netdev, lvs-devel, netfilter-devel, coreteam,
sheviks, Waiman Long
In-Reply-To: <20260331165015.2777765-1-longman@redhat.com>
The ip_vs_ctl.c file and the associated ip_vs.h file are the only places
in the kernel where HK_TYPE_KTHREAD cpumask is being retrieved and used.
Now that HK_TYPE_KTHREAD/HK_TYPE_DOMAIN cpumask can be changed at run
time. We need to use RCU to guard access to this cpumask to avoid a
potential UAF problem as the returned cpumask may be freed before it
is being used.
We can replace HK_TYPE_KTHREAD by HK_TYPE_DOMAIN as they are aliases
of each other, but keeping the HK_TYPE_KTHREAD name can highlight the
fact that it is the kthread initiated by ipvs that is being controlled.
Signed-off-by: Waiman Long <longman@redhat.com>
---
include/net/ip_vs.h | 20 ++++++++++++++++----
net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++-----
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 72d325c81313..7bda92fd3fe6 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1411,7 +1411,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)
return ipvs->sysctl_run_estimation;
}
-static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)
+static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)
{
if (ipvs->est_cpulist_valid)
return ipvs->sysctl_est_cpulist;
@@ -1529,7 +1529,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)
return 1;
}
-static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)
+static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)
{
return housekeeping_cpumask(HK_TYPE_KTHREAD);
}
@@ -1564,6 +1564,18 @@ static inline int sysctl_svc_lfactor(struct netns_ipvs *ipvs)
return READ_ONCE(ipvs->sysctl_svc_lfactor);
}
+static inline bool sysctl_est_cpulist_empty(struct netns_ipvs *ipvs)
+{
+ guard(rcu)();
+ return cpumask_empty(__sysctl_est_cpulist(ipvs));
+}
+
+static inline unsigned int sysctl_est_cpulist_weight(struct netns_ipvs *ipvs)
+{
+ guard(rcu)();
+ return cpumask_weight(__sysctl_est_cpulist(ipvs));
+}
+
/* IPVS core functions
* (from ip_vs_core.c)
*/
@@ -1895,7 +1907,7 @@ static inline void ip_vs_est_stopped_recalc(struct netns_ipvs *ipvs)
/* Stop tasks while cpulist is empty or if disabled with flag */
ipvs->est_stopped = !sysctl_run_estimation(ipvs) ||
(ipvs->est_cpulist_valid &&
- cpumask_empty(sysctl_est_cpulist(ipvs)));
+ sysctl_est_cpulist_empty(ipvs));
#endif
}
@@ -1911,7 +1923,7 @@ static inline bool ip_vs_est_stopped(struct netns_ipvs *ipvs)
static inline int ip_vs_est_max_threads(struct netns_ipvs *ipvs)
{
unsigned int limit = IPVS_EST_CPU_KTHREADS *
- cpumask_weight(sysctl_est_cpulist(ipvs));
+ sysctl_est_cpulist_weight(ipvs);
return max(1U, limit);
}
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 032425025d88..e253a1ceef48 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2338,11 +2338,14 @@ static int ipvs_proc_est_cpumask_get(const struct ctl_table *table,
mutex_lock(&ipvs->est_mutex);
- if (ipvs->est_cpulist_valid)
- mask = *valp;
- else
- mask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);
- ret = scnprintf(buffer, size, "%*pbl\n", cpumask_pr_args(mask));
+ /* HK_TYPE_KTHREAD cpumask needs RCU protection */
+ scoped_guard(rcu) {
+ if (ipvs->est_cpulist_valid)
+ mask = *valp;
+ else
+ mask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);
+ ret = scnprintf(buffer, size, "%*pbl\n", cpumask_pr_args(mask));
+ }
mutex_unlock(&ipvs->est_mutex);
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox