From luca.weiss at fairphone.com  Fri Apr  3 06:52:47 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:47 +0200
Subject: [PATCH v2 1/7] regulator: dt-bindings: qcom,qca6390-pmu: Document
 WCN6755 PMU
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-1-393322b27c5f@fairphone.com>

Document the WCN6755 PMU using a fallback to WCN6750 since the two chips
seem to be completely pin and software compatible. In fact the original
downstream kernel just pretends the WCN6755 is a WCN6750.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 .../devicetree/bindings/regulator/qcom,qca6390-pmu.yaml  | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
index 47c425c9fff1..105174df7df2 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
@@ -16,11 +16,17 @@ description:
 
 properties:
   compatible:
-    enum:
-      - qcom,qca6390-pmu
-      - qcom,wcn6750-pmu
-      - qcom,wcn6855-pmu
-      - qcom,wcn7850-pmu
+    oneOf:
+      - items:
+          - enum:
+              - qcom,wcn6755-pmu
+          - const: qcom,wcn6750-pmu
+
+      - enum:
+          - qcom,qca6390-pmu
+          - qcom,wcn6750-pmu
+          - qcom,wcn6855-pmu
+          - qcom,wcn7850-pmu
 
   vdd-supply:
     description: VDD supply regulator handle

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:46 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:46 +0200
Subject: [PATCH v2 0/7] Enable Bluetooth and WiFi on Fairphone (Gen. 6)
Message-ID: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>

Add the required bits to enable Bluetooth and WiFi on the Milos
SoC-based Fairphone (Gen. 6) smartphone.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
Changes in v2:
- Drop applied pd-mapper patch
- Add compatibles for wcn6755 with fallback to wcn6750 (wifi & bt)
- Rebase on linux-next
- Pick up one tag (discard the rest due to addition of wcn6755
  compatibles)
- Link to v1: https://lore.kernel.org/r/20260116-milos-fp6-bt-wifi-v1-0-27b4fbb77e9c at fairphone.com

---
Luca Weiss (7):
      regulator: dt-bindings: qcom,qca6390-pmu: Document WCN6755 PMU
      dt-bindings: bluetooth: qcom,wcn6750-bt: Document WCN6755 Bluetooth
      dt-bindings: net: wireless: ath11k: Document WCN6755 WiFi
      arm64: dts: qcom: milos: Split up uart11 pinctrl
      arm64: dts: qcom: milos: Add WCN6755 WiFi node
      arm64: dts: qcom: milos-fairphone-fp6: Enable Bluetooth
      arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi

 .../bindings/net/bluetooth/qcom,wcn6750-bt.yaml    |  10 +-
 .../bindings/net/wireless/qcom,ath11k.yaml         |  16 +-
 .../bindings/regulator/qcom,qca6390-pmu.yaml       |  16 +-
 arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts   | 191 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/milos.dtsi                |  74 ++++++--
 5 files changed, 285 insertions(+), 22 deletions(-)
---
base-commit: 83acad05dee54a5cff0c98dd7962e55d4c6b145a
change-id: 20260116-milos-fp6-bt-wifi-22faa7b15e8c

Best regards,
--  
Luca Weiss <luca.weiss at fairphone.com>



From luca.weiss at fairphone.com  Fri Apr  3 06:52:48 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:48 +0200
Subject: [PATCH v2 2/7] dt-bindings: bluetooth: qcom,wcn6750-bt: Document
 WCN6755 Bluetooth
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-2-393322b27c5f@fairphone.com>

Document the WCN6755 Bluetooth using a fallback to WCN6750 since the two
chips seem to be completely pin and software compatible. In fact the
original downstream kernel just pretends the WCN6755 is a WCN6750.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 .../devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml     | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
index 8606a45ac9b9..79522409d709 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
@@ -12,8 +12,14 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - qcom,wcn6750-bt
+    oneOf:
+      - items:
+          - enum:
+              - qcom,wcn6755-bt
+          - const: qcom,wcn6750-bt
+
+      - enum:
+          - qcom,wcn6750-bt
 
   enable-gpios:
     maxItems: 1

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:49 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:49 +0200
Subject: [PATCH v2 3/7] dt-bindings: net: wireless: ath11k: Document
 WCN6755 WiFi
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>

Document the WCN6755 WiFi using a fallback to WCN6750 since the two
chips seem to be completely pin and software compatible. In fact the
original downstream kernel just pretends the WCN6755 is a WCN6750.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 .../devicetree/bindings/net/wireless/qcom,ath11k.yaml    | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index 0cc1dbf2beef..94f8f8551756 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -16,11 +16,17 @@ description: |
 
 properties:
   compatible:
-    enum:
-      - qcom,ipq8074-wifi
-      - qcom,ipq6018-wifi
-      - qcom,wcn6750-wifi
-      - qcom,ipq5018-wifi
+    oneOf:
+      - items:
+          - enum:
+              - qcom,wcn6755-wifi
+          - const: qcom,wcn6750-wifi
+
+      - enum:
+          - qcom,ipq8074-wifi
+          - qcom,ipq6018-wifi
+          - qcom,wcn6750-wifi
+          - qcom,ipq5018-wifi
 
   reg:
     maxItems: 1

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:51 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:51 +0200
Subject: [PATCH v2 5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>

Add a node for the WCN6755 WiFi found with the Milos SoC.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 arch/arm64/boot/dts/qcom/milos.dtsi | 46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 71292dfd6e08..3a3d7f2134e8 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -2438,6 +2438,52 @@ gic_its: msi-controller at 17140000 {
 			};
 		};
 
+		wifi: wifi at 17110040 {
+			compatible = "qcom,wcn6755-wifi", "qcom,wcn6750-wifi";
+			reg = <0x0 0x17110040 0x0 0x0>;
+
+			iommus = <&apps_smmu 0x1400 0x1>;
+
+			interrupts = <GIC_SPI 768 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 769 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 770 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 771 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 772 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 773 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 774 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 775 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 776 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 777 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 778 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 779 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 780 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 781 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 782 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 783 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 784 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 785 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 786 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 787 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 788 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 789 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 790 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 791 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 792 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 793 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 794 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 795 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 796 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 797 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 798 IRQ_TYPE_EDGE_RISING 0>,
+				     <GIC_SPI 799 IRQ_TYPE_EDGE_RISING 0>;
+
+			qcom,rproc = <&remoteproc_wpss>;
+			qcom,smem-states = <&smp2p_wlan_out 0>;
+			qcom,smem-state-names = "wlan-smp2p-out";
+
+			status = "disabled";
+		};
+
 		timer at 17420000 {
 			compatible = "arm,armv7-timer-mem";
 			reg = <0x0 0x17420000 0x0 0x1000>;

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:52 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:52 +0200
Subject: [PATCH v2 6/7] arm64: dts: qcom: milos-fairphone-fp6: Enable
 Bluetooth
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-6-393322b27c5f@fairphone.com>

Add the nodes to describe the WCN6755 chip with its PMU and Bluetooth
parts.

Thanks to Alexander Koskovich for helping with the bringup, adding
'clocks' to the PMU node to make Bluetooth work.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 174 +++++++++++++++++++++++
 1 file changed, 174 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index c1899db46e71..db72418b7195 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -24,6 +24,7 @@ / {
 
 	aliases {
 		serial0 = &uart5;
+		serial1 = &uart11;
 	};
 
 	gpio-keys {
@@ -225,6 +226,67 @@ trip1 {
 			};
 		};
 	};
+
+	wcn6750-pmu {
+		compatible = "qcom,wcn6755-pmu", "qcom,wcn6750-pmu";
+
+		vddaon-supply = <&vreg_s3b>;
+		vddasd-supply = <&vreg_l7b>;
+		vddpmu-supply = <&vreg_s3b>;
+		vddrfa0p8-supply = <&vreg_s3b>;
+		vddrfa1p2-supply = <&vreg_s2b>;
+		vddrfa1p7-supply = <&vreg_s1b>;
+		vddrfa2p2-supply = <&vreg_s1j>;
+
+		bt-enable-gpios = <&tlmm 53 GPIO_ACTIVE_HIGH>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK1>;
+
+		pinctrl-0 = <&bluetooth_enable_default>;
+		pinctrl-names = "default";
+
+		regulators {
+			vreg_pmu_rfa_cmn: ldo0 {
+				regulator-name = "vreg_pmu_rfa_cmn";
+			};
+
+			vreg_pmu_aon_0p59: ldo1 {
+				regulator-name = "vreg_pmu_aon_0p59";
+			};
+
+			vreg_pmu_wlcx_0p8: ldo2 {
+				regulator-name = "vreg_pmu_wlcx_0p8";
+			};
+
+			vreg_pmu_wlmx_0p85: ldo3 {
+				regulator-name = "vreg_pmu_wlmx_0p85";
+			};
+
+			vreg_pmu_btcmx_0p85: ldo4 {
+				regulator-name = "vreg_pmu_btcmx_0p85";
+			};
+
+			vreg_pmu_rfa_0p8: ldo5 {
+				regulator-name = "vreg_pmu_rfa_0p8";
+			};
+
+			vreg_pmu_rfa_1p2: ldo6 {
+				regulator-name = "vreg_pmu_rfa_1p2";
+			};
+
+			vreg_pmu_rfa_1p7: ldo7 {
+				regulator-name = "vreg_pmu_rfa_1p7";
+			};
+
+			vreg_pmu_pcie_0p9: ldo8 {
+				regulator-name = "vreg_pmu_pcie_0p9";
+			};
+
+			vreg_pmu_pcie_1p8: ldo9 {
+				regulator-name = "vreg_pmu_pcie_1p8";
+			};
+		};
+	};
 };
 
 &apps_rsc {
@@ -752,6 +814,39 @@ &pon_resin {
 	status = "okay";
 };
 
+&qup_uart11_cts {
+	/*
+	 * Configure a bias-bus-hold on CTS to lower power
+	 * usage when Bluetooth is turned off. Bus hold will
+	 * maintain a low power state regardless of whether
+	 * the Bluetooth module drives the pin in either
+	 * direction or leaves the pin fully unpowered.
+	 */
+	bias-bus-hold;
+};
+
+&qup_uart11_rts {
+	/* We'll drive RTS, so no pull */
+	drive-strength = <2>;
+	bias-disable;
+};
+
+&qup_uart11_rx {
+	/*
+	 * Configure a pull-up on RX. This is needed to avoid
+	 * garbage data when the TX pin of the Bluetooth module is
+	 * in tri-state (module powered off or not driving the
+	 * signal yet).
+	 */
+	bias-pull-up;
+};
+
+&qup_uart11_tx {
+	/* We'll drive TX, so no pull */
+	drive-strength = <2>;
+	bias-disable;
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };
@@ -810,6 +905,59 @@ &tlmm {
 			       <13 1>, /* NC */
 			       <63 2>; /* WLAN UART */
 
+	qup_uart11_sleep_cts: qup-uart11-sleep-cts-state {
+		pins = "gpio48";
+		function = "gpio";
+		/*
+		 * Configure a bias-bus-hold on CTS to lower power
+		 * usage when Bluetooth is turned off. Bus hold will
+		 * maintain a low power state regardless of whether
+		 * the Bluetooth module drives the pin in either
+		 * direction or leaves the pin fully unpowered.
+		 */
+		bias-bus-hold;
+	};
+
+	qup_uart11_sleep_rts: qup-uart11-sleep-rts-state {
+		pins = "gpio49";
+		function = "gpio";
+		/*
+		 * Configure pull-down on RTS. As RTS is active low
+		 * signal, pull it low to indicate the BT SoC that it
+		 * can wakeup the system anytime from suspend state by
+		 * pulling RX low (by sending wakeup bytes).
+		 */
+		bias-pull-down;
+	};
+
+	qup_uart11_sleep_tx: qup-uart11-sleep-tx-state {
+		pins = "gpio50";
+		function = "gpio";
+		/*
+		 * Configure pull-up on TX when it isn't actively driven
+		 * to prevent BT SoC from receiving garbage during sleep.
+		 */
+		bias-pull-up;
+	};
+
+	qup_uart11_sleep_rx: qup-uart11-sleep-rx-state {
+		pins = "gpio51";
+		function = "gpio";
+		/*
+		 * Configure a pull-up on RX. This is needed to avoid
+		 * garbage data when the TX pin of the Bluetooth module
+		 * is floating which may cause spurious wakeups.
+		 */
+		bias-pull-up;
+	};
+
+	bluetooth_enable_default: bluetooth-enable-default-state {
+		pins = "gpio53";
+		function = "gpio";
+		output-low;
+		bias-disable;
+	};
+
 	sdc2_card_det_n: sdc2-card-det-state {
 		pins = "gpio65";
 		function = "gpio";
@@ -836,6 +984,32 @@ &uart5 {
 	status = "okay";
 };
 
+&uart11 {
+	/delete-property/ interrupts;
+	interrupts-extended = <&intc GIC_SPI 586 IRQ_TYPE_LEVEL_HIGH 0>,
+			      <&tlmm 51 IRQ_TYPE_EDGE_FALLING>;
+
+	pinctrl-1 =  <&qup_uart11_sleep_cts>,
+		     <&qup_uart11_sleep_rts>,
+		     <&qup_uart11_sleep_tx>,
+		     <&qup_uart11_sleep_rx>;
+	pinctrl-names = "default",
+			"sleep";
+
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn6755-bt", "qcom,wcn6750-bt";
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+	};
+};
+
 &ufs_mem_hc {
 	reset-gpios = <&tlmm 167 GPIO_ACTIVE_LOW>;
 

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:50 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:50 +0200
Subject: [PATCH v2 4/7] arm64: dts: qcom: milos: Split up uart11 pinctrl
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-4-393322b27c5f@fairphone.com>

In order to set the pinctrl for the individual CTS, RTS, TX and RX pins,
split up the pinctrl configuration into 4 nodes so that boards can set
some properties separately.

Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 arch/arm64/boot/dts/qcom/milos.dtsi | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..71292dfd6e08 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -2099,19 +2099,27 @@ qup_i2c7_data_clk: qup-i2c7-data-clk-state {
 			};
 
 			qup_uart11_cts_rts: qup-uart11-cts-rts-state {
-				/* CTS, RTS */
-				pins = "gpio48", "gpio49";
-				function = "qup1_se4";
-				drive-strength = <2>;
-				bias-pull-down;
+				qup_uart11_cts: cts-pins {
+					pins = "gpio48";
+					function = "qup1_se4";
+				};
+
+				qup_uart11_rts: rts-pins {
+					pins = "gpio49";
+					function = "qup1_se4";
+				};
 			};
 
 			qup_uart11_default: qup-uart11-default-state {
-				/* TX, RX */
-				pins = "gpio50", "gpio51";
-				function = "qup1_se4";
-				drive-strength = <2>;
-				bias-pull-up;
+				qup_uart11_tx: tx-pins {
+					pins = "gpio50";
+					function = "qup1_se4";
+				};
+
+				qup_uart11_rx: rx-pins {
+					pins = "gpio51";
+					function = "qup1_se4";
+				};
 			};
 
 			sdc2_default: sdc2-default-state {

-- 
2.53.0



From luca.weiss at fairphone.com  Fri Apr  3 06:52:53 2026
From: luca.weiss at fairphone.com (Luca Weiss)
Date: Fri, 03 Apr 2026 15:52:53 +0200
Subject: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <20260403-milos-fp6-bt-wifi-v2-7-393322b27c5f@fairphone.com>

Configure and enable the WiFi node, and add the required pinctrl to
provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.

Thanks to Alexander Koskovich for helping with the bringup, adding
the missing pinctrl to make the WPSS stop crashing.

Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY at fairphone.com/
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
---
 arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index db72418b7195..d8ac495ca7c8 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -242,7 +242,7 @@ wcn6750-pmu {
 
 		clocks = <&rpmhcc RPMH_RF_CLK1>;
 
-		pinctrl-0 = <&bluetooth_enable_default>;
+		pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
 		pinctrl-names = "default";
 
 		regulators {
@@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
 	qcom,tune-usb2-preem = /bits/ 8 <0x6>;
 };
 
+&pmk8550_gpios {
+	pmk8550_sleep_clk_default: sleep-clk-default-state {
+		pins = "gpio5";
+		function = "func1";
+		input-disable;
+		output-enable;
+		bias-disable;
+		power-source = <0>;
+	};
+};
+
 &pmr735b_gpios {
 	s1j_enable_default: s1j-enable-default-state {
 		pins = "gpio1";
@@ -1049,3 +1060,9 @@ &usb_1_hsphy {
 
 	status = "okay";
 };
+
+&wifi {
+	qcom,calibration-variant = "Fairphone_Gen_6";
+
+	status = "okay";
+};

-- 
2.53.0



From dmitry.baryshkov at oss.qualcomm.com  Fri Apr  3 12:32:31 2026
From: dmitry.baryshkov at oss.qualcomm.com (Dmitry Baryshkov)
Date: Fri, 3 Apr 2026 22:32:31 +0300
Subject: [PATCH v2 4/7] arm64: dts: qcom: milos: Split up uart11 pinctrl
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-4-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-4-393322b27c5f@fairphone.com>
Message-ID: <ep7xrcp5pvtcepq4wmiy7p2qal2qaupz3pae2cxopfnqwxqtij@ftzlldtpowdg>

On Fri, Apr 03, 2026 at 03:52:50PM +0200, Luca Weiss wrote:
> In order to set the pinctrl for the individual CTS, RTS, TX and RX pins,
> split up the pinctrl configuration into 4 nodes so that boards can set
> some properties separately.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  arch/arm64/boot/dts/qcom/milos.dtsi | 28 ++++++++++++++++++----------
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at oss.qualcomm.com  Fri Apr  3 12:33:07 2026
From: dmitry.baryshkov at oss.qualcomm.com (Dmitry Baryshkov)
Date: Fri, 3 Apr 2026 22:33:07 +0300
Subject: [PATCH v2 5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
Message-ID: <7edl5o4lc2jk5exozyxomxjzooqqhek5zyvmp6e3p4ndxweulg@h2dwmk2zizgj>

On Fri, Apr 03, 2026 at 03:52:51PM +0200, Luca Weiss wrote:
> Add a node for the WCN6755 WiFi found with the Milos SoC.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  arch/arm64/boot/dts/qcom/milos.dtsi | 46 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at oss.qualcomm.com  Fri Apr  3 12:33:39 2026
From: dmitry.baryshkov at oss.qualcomm.com (Dmitry Baryshkov)
Date: Fri, 3 Apr 2026 22:33:39 +0300
Subject: [PATCH v2 6/7] arm64: dts: qcom: milos-fairphone-fp6: Enable
 Bluetooth
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-6-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-6-393322b27c5f@fairphone.com>
Message-ID: <cwhd2tcs3asdxqcjspq6sqefx4srixgkje37hf4fylc24glqey@nkxctkq32hwn>

On Fri, Apr 03, 2026 at 03:52:52PM +0200, Luca Weiss wrote:
> Add the nodes to describe the WCN6755 chip with its PMU and Bluetooth
> parts.
> 
> Thanks to Alexander Koskovich for helping with the bringup, adding
> 'clocks' to the PMU node to make Bluetooth work.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 174 +++++++++++++++++++++++
>  1 file changed, 174 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>


-- 
With best wishes
Dmitry


From dmitry.baryshkov at oss.qualcomm.com  Fri Apr  3 12:35:07 2026
From: dmitry.baryshkov at oss.qualcomm.com (Dmitry Baryshkov)
Date: Fri, 3 Apr 2026 22:35:07 +0300
Subject: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-7-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-7-393322b27c5f@fairphone.com>
Message-ID: <4fbs4arx6sez6fffy75ctmzecfvitr6aocau3cczlr2ps2ptld@v7wpa2irsihl>

On Fri, Apr 03, 2026 at 03:52:53PM +0200, Luca Weiss wrote:
> Configure and enable the WiFi node, and add the required pinctrl to
> provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.
> 
> Thanks to Alexander Koskovich for helping with the bringup, adding
> the missing pinctrl to make the WPSS stop crashing.
> 
> Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY at fairphone.com/
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
> index db72418b7195..d8ac495ca7c8 100644
> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
> @@ -242,7 +242,7 @@ wcn6750-pmu {
>  
>  		clocks = <&rpmhcc RPMH_RF_CLK1>;
>  
> -		pinctrl-0 = <&bluetooth_enable_default>;
> +		pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
>  		pinctrl-names = "default";
>  
>  		regulators {
> @@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
>  	qcom,tune-usb2-preem = /bits/ 8 <0x6>;
>  };
>  
> +&pmk8550_gpios {
> +	pmk8550_sleep_clk_default: sleep-clk-default-state {
> +		pins = "gpio5";
> +		function = "func1";
> +		input-disable;
> +		output-enable;

Hmm, if it's a sleep_clk, should it not be handled via the power
sequencer?

> +		bias-disable;
> +		power-source = <0>;
> +	};
> +};
> +
>  &pmr735b_gpios {
>  	s1j_enable_default: s1j-enable-default-state {
>  		pins = "gpio1";
> @@ -1049,3 +1060,9 @@ &usb_1_hsphy {
>  
>  	status = "okay";
>  };
> +
> +&wifi {
> +	qcom,calibration-variant = "Fairphone_Gen_6";
> +
> +	status = "okay";
> +};
> 
> -- 
> 2.53.0
> 

-- 
With best wishes
Dmitry


From wei.zhang at oss.qualcomm.com  Fri Apr  3 21:30:50 2026
From: wei.zhang at oss.qualcomm.com (Wei Zhang)
Date: Fri,  3 Apr 2026 21:30:50 -0700
Subject: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI shutdown
Message-ID: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>

A reboot can crash the kernel if it overlaps with WLAN firmware crash
recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
path while freeing DMA-backed MHI contexts.

Simplified trace:
  dma_free_attrs
  mhi_deinit_dev_ctxt [mhi]
  ath11k_pci_power_down [ath11k_pci]
  ath11k_pci_shutdown [ath11k_pci]
  device_shutdown
  kernel_restart

On the host side, SSR is driven by the MHI RDDM callback, which queues
reset_work to perform device recovery. reset_work power-cycles the device
by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The
power-down phase deinitializes MHI and frees DMA resources.

Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR
recovery flow. As a result, the shutdown path
(ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR
recovery sequence.

Fix this by canceling SSR-related work items during PCI shutdown, marking
the device as unregistering, and serializing the RDDM callback path that
checks and queues reset_work. This ensures that no new SSR recovery work
can be queued once teardown has started, and that any in-flight recovery
work is fully synchronized before device power-down, preventing MHI
teardown and DMA resource freeing from running more than once.

Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k
devices do not queue reset_work in normal SSR flows.

Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855")
Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support")
Signed-off-by: Wei Zhang <wei.zhang at oss.qualcomm.com>
---
 drivers/net/wireless/ath/ath11k/mhi.c | 4 +++-
 drivers/net/wireless/ath/ath11k/pci.c | 8 ++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/mhi.c b/drivers/net/wireless/ath/ath11k/mhi.c
index f994233df2bb..a6c9ff112c68 100644
--- a/drivers/net/wireless/ath/ath11k/mhi.c
+++ b/drivers/net/wireless/ath/ath11k/mhi.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: BSD-3-Clause-Clear
 /*
  * Copyright (c) 2020 The Linux Foundation. All rights reserved.
- * Copyright (c) 2021-2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
 #include <linux/msi.h>
@@ -282,8 +282,10 @@ static void ath11k_mhi_op_status_cb(struct mhi_controller *mhi_cntrl,
 			break;
 		}
 
+		spin_lock_bh(&ab->base_lock);
 		if (!(test_bit(ATH11K_FLAG_UNREGISTERING, &ab->dev_flags)))
 			queue_work(ab->workqueue_aux, &ab->reset_work);
+		spin_unlock_bh(&ab->base_lock);
 
 		break;
 	default:
diff --git a/drivers/net/wireless/ath/ath11k/pci.c b/drivers/net/wireless/ath/ath11k/pci.c
index 7114eca8810d..35bb9e7a63a2 100644
--- a/drivers/net/wireless/ath/ath11k/pci.c
+++ b/drivers/net/wireless/ath/ath11k/pci.c
@@ -1210,6 +1210,14 @@ static void ath11k_pci_shutdown(struct pci_dev *pdev)
 	struct ath11k_pci *ab_pci = ath11k_pci_priv(ab);
 
 	ath11k_pci_set_irq_affinity_hint(ab_pci, NULL);
+
+	spin_lock_bh(&ab->base_lock);
+	set_bit(ATH11K_FLAG_UNREGISTERING, &ab->dev_flags);
+	spin_unlock_bh(&ab->base_lock);
+
+	cancel_work_sync(&ab->reset_work);
+	cancel_work_sync(&ab->dump_work);
+
 	ath11k_pci_power_down(ab, false);
 }
 

base-commit: 15551ababf6d4e857f2101366a0c3eaa86dd822c
-- 
2.34.1



From krzk at kernel.org  Sat Apr  4 03:57:41 2026
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 4 Apr 2026 12:57:41 +0200
Subject: [PATCH v2 1/7] regulator: dt-bindings: qcom,qca6390-pmu:
 Document WCN6755 PMU
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-1-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-1-393322b27c5f@fairphone.com>
Message-ID: <20260404-lynx-of-extreme-chaos-1aa3f5@quoll>

On Fri, Apr 03, 2026 at 03:52:47PM +0200, Luca Weiss wrote:
> Document the WCN6755 PMU using a fallback to WCN6750 since the two chips
> seem to be completely pin and software compatible. In fact the original
> downstream kernel just pretends the WCN6755 is a WCN6750.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  .../devicetree/bindings/regulator/qcom,qca6390-pmu.yaml  | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>

Best regards,
Krzysztof



From krzk at kernel.org  Sat Apr  4 03:58:10 2026
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 4 Apr 2026 12:58:10 +0200
Subject: [PATCH v2 2/7] dt-bindings: bluetooth: qcom,wcn6750-bt: Document
 WCN6755 Bluetooth
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-2-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-2-393322b27c5f@fairphone.com>
Message-ID: <20260404-fast-quaint-agama-8afbfe@quoll>

On Fri, Apr 03, 2026 at 03:52:48PM +0200, Luca Weiss wrote:
> Document the WCN6755 Bluetooth using a fallback to WCN6750 since the two
> chips seem to be completely pin and software compatible. In fact the
> original downstream kernel just pretends the WCN6755 is a WCN6750.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  .../devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml     | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>

Best regards,
Krzysztof



From krzk at kernel.org  Sat Apr  4 04:03:39 2026
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Sat, 4 Apr 2026 13:03:39 +0200
Subject: [PATCH v2 3/7] dt-bindings: net: wireless: ath11k: Document
 WCN6755 WiFi
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>
Message-ID: <20260404-sceptical-benign-chachalaca-e13aa9@quoll>

On Fri, Apr 03, 2026 at 03:52:49PM +0200, Luca Weiss wrote:
> Document the WCN6755 WiFi using a fallback to WCN6750 since the two
> chips seem to be completely pin and software compatible. In fact the
> original downstream kernel just pretends the WCN6755 is a WCN6750.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath11k.yaml    | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>

Best regards,
Krzysztof



From jjohnson at kernel.org  Sun Apr  5 15:28:42 2026
From: jjohnson at kernel.org (Jeff Johnson)
Date: Sun, 5 Apr 2026 15:28:42 -0700
Subject: [PATCH v2 3/7] dt-bindings: net: wireless: ath11k: Document
 WCN6755 WiFi
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-3-393322b27c5f@fairphone.com>
Message-ID: <b7520942-865a-450f-8b06-1b5cbc95c7c2@kernel.org>

On 4/3/2026 6:52 AM, Luca Weiss wrote:
> Document the WCN6755 WiFi using a fallback to WCN6750 since the two
> chips seem to be completely pin and software compatible. In fact the
> original downstream kernel just pretends the WCN6755 is a WCN6750.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>

Bjorn, will you take this entire series through your tree?

Acked-by: Jeff Johnson <jjohnson at kernel.org>




From broonie at kernel.org  Mon Apr  6 06:17:28 2026
From: broonie at kernel.org (Mark Brown)
Date: Mon, 06 Apr 2026 14:17:28 +0100
Subject: (subset) [PATCH v2 0/7] Enable Bluetooth and WiFi on Fairphone
 (Gen. 6)
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <177548144839.46304.13972601101594073712.b4-ty@b4>

On Fri, 03 Apr 2026 15:52:46 +0200, Luca Weiss wrote:
> Enable Bluetooth and WiFi on Fairphone (Gen. 6)
> 
> Add the required bits to enable Bluetooth and WiFi on the Milos
> SoC-based Fairphone (Gen. 6) smartphone.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1

Thanks!

[1/7] regulator: dt-bindings: qcom,qca6390-pmu: Document WCN6755 PMU
      https://git.kernel.org/broonie/regulator/c/b043657c35e5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



From joshuaklinesmith at gmail.com  Mon Apr  6 19:48:36 2026
From: joshuaklinesmith at gmail.com (Joshua Klinesmith)
Date: Mon,  6 Apr 2026 22:48:36 -0400
Subject: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by using correct descriptor size
Message-ID: <20260407024836.53871-1-joshuaklinesmith@gmail.com>

The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
compute the packet buffer offset. This is the size of the union of all
chip-specific descriptors (the maximum), not the actual descriptor size
for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
the front of the skb.

On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
end of every monitor mode frame delivered to userspace. On WCN6855 the
sizes happen to match so the bug is not visible.

The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
fragment length calculation for multi-buffer MSDUs, under-counting
intermediate fragments by 8 bytes and over-counting the last fragment.

Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
monitor mpdu_pop functions and passing it through to set_frag_len.

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Link: https://github.com/openwrt/openwrt/issues/16183
Signed-off-by: Joshua Klinesmith <joshuaklinesmith at gmail.com>
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 85defe11750d..c86ffc203f15 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
 	return 0;
 }
 
-static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
+static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
+				       u32 hal_desc_sz)
 {
-	if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
-		*frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
+	if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
+		*frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
 		*total_len -= *frag_len;
 	} else {
 		*frag_len = *total_len;
@@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
 
 static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
 				      bool *is_frag, u32 *total_len,
-				      u32 *frag_len, u32 *msdu_cnt)
+				      u32 *frag_len, u32 *msdu_cnt,
+				      u32 hal_desc_sz)
 {
 	if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
 		if (!*is_frag) {
 			*total_len = info->msdu_len;
 			*is_frag = true;
 		}
-		ath11k_dp_mon_set_frag_len(total_len,
-					   frag_len);
+		ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
 	} else {
 		if (*is_frag) {
-			ath11k_dp_mon_set_frag_len(total_len,
-						   frag_len);
+			ath11k_dp_mon_set_frag_len(total_len, frag_len,
+						   hal_desc_sz);
 		} else {
 			*frag_len = info->msdu_len;
 		}
@@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
 
 			rx_desc = (struct hal_rx_desc *)msdu->data;
 
-			rx_pkt_offset = sizeof(struct hal_rx_desc);
+			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
 			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
 
 			if (is_first_msdu) {
@@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
 			}
 			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
 						  &is_frag, &total_len,
-						  &frag_len, &msdu_cnt);
+						  &frag_len, &msdu_cnt,
+						  rx_pkt_offset);
 			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
 
 			ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
@@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
 
 			rx_desc = (struct hal_rx_desc *)msdu->data;
 
-			rx_pkt_offset = sizeof(struct hal_rx_desc);
+			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
 			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
 
 			if (is_first_msdu) {
@@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
 
 			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
 						  &is_frag, &total_len,
-						  &frag_len, &msdu_cnt);
+						  &frag_len, &msdu_cnt,
+						  rx_pkt_offset);
 
 			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
 
-- 
2.43.0



From konrad.dybcio at oss.qualcomm.com  Tue Apr  7 02:35:35 2026
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Tue, 7 Apr 2026 11:35:35 +0200
Subject: [PATCH v2 5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-5-393322b27c5f@fairphone.com>
Message-ID: <14c61b77-d790-4e75-be79-caf8b7ee8e4f@oss.qualcomm.com>

On 4/3/26 3:52 PM, Luca Weiss wrote:
> Add a node for the WCN6755 WiFi found with the Milos SoC.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---

Acked-by: Konrad Dybcio <konrad.dybcio at oss.qualcomm.com>

Konrad


From konrad.dybcio at oss.qualcomm.com  Tue Apr  7 06:07:10 2026
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Tue, 7 Apr 2026 15:07:10 +0200
Subject: [PATCH v2 4/7] arm64: dts: qcom: milos: Split up uart11 pinctrl
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-4-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-4-393322b27c5f@fairphone.com>
Message-ID: <fd0919f7-e510-4560-b355-15b86ee9e5a3@oss.qualcomm.com>

On 4/3/26 3:52 PM, Luca Weiss wrote:
> In order to set the pinctrl for the individual CTS, RTS, TX and RX pins,
> split up the pinctrl configuration into 4 nodes so that boards can set
> some properties separately.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---


Reviewed-by: Konrad Dybcio <konrad.dybcio at oss.qualcomm.com>

Konrad


From konrad.dybcio at oss.qualcomm.com  Tue Apr  7 06:10:26 2026
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Tue, 7 Apr 2026 15:10:26 +0200
Subject: [PATCH v2 6/7] arm64: dts: qcom: milos-fairphone-fp6: Enable
 Bluetooth
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-6-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-6-393322b27c5f@fairphone.com>
Message-ID: <dc2dbc10-e1d6-4b1c-8903-7c8c612517ab@oss.qualcomm.com>

On 4/3/26 3:52 PM, Luca Weiss wrote:
> Add the nodes to describe the WCN6755 chip with its PMU and Bluetooth
> parts.
> 
> Thanks to Alexander Koskovich for helping with the bringup, adding
> 'clocks' to the PMU node to make Bluetooth work.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---

[...]

> +	wcn6750-pmu {
> +		compatible = "qcom,wcn6755-pmu", "qcom,wcn6750-pmu";
> +
> +		vddaon-supply = <&vreg_s3b>;
> +		vddasd-supply = <&vreg_l7b>;
> +		vddpmu-supply = <&vreg_s3b>;
> +		vddrfa0p8-supply = <&vreg_s3b>;
> +		vddrfa1p2-supply = <&vreg_s2b>;
> +		vddrfa1p7-supply = <&vreg_s1b>;
> +		vddrfa2p2-supply = <&vreg_s1j>;
> +
> +		bt-enable-gpios = <&tlmm 53 GPIO_ACTIVE_HIGH>;
> +
> +		clocks = <&rpmhcc RPMH_RF_CLK1>;

nit: I should have caught this.. intriguing order of properties where
supplies are topmost during r3g2 review, which is presumably where
this originated from.. not a big deal though..

[...]

> +	bluetooth_enable_default: bluetooth-enable-default-state {
> +		pins = "gpio53";
> +		function = "gpio";
> +		output-low;
> +		bias-disable;

nit: you shouldn't need to initially actively drive the pin, a
pull-down should be sufficient

(if insist you do, output-foo is usually below bias properties)

with or without changes:

Reviewed-by: Konrad Dybcio <konrad.dybcio at oss.qualcomm.com>

Konrad


From konrad.dybcio at oss.qualcomm.com  Tue Apr  7 06:16:00 2026
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Tue, 7 Apr 2026 15:16:00 +0200
Subject: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
In-Reply-To: <4fbs4arx6sez6fffy75ctmzecfvitr6aocau3cczlr2ps2ptld@v7wpa2irsihl>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
 <20260403-milos-fp6-bt-wifi-v2-7-393322b27c5f@fairphone.com>
 <4fbs4arx6sez6fffy75ctmzecfvitr6aocau3cczlr2ps2ptld@v7wpa2irsihl>
Message-ID: <2514523f-a43f-4470-a69b-3d5175d10385@oss.qualcomm.com>

On 4/3/26 9:35 PM, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 03:52:53PM +0200, Luca Weiss wrote:
>> Configure and enable the WiFi node, and add the required pinctrl to
>> provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.
>>
>> Thanks to Alexander Koskovich for helping with the bringup, adding
>> the missing pinctrl to make the WPSS stop crashing.
>>
>> Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY at fairphone.com/
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
>> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
>> ---
>>  arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> index db72418b7195..d8ac495ca7c8 100644
>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> @@ -242,7 +242,7 @@ wcn6750-pmu {
>>  
>>  		clocks = <&rpmhcc RPMH_RF_CLK1>;
>>  
>> -		pinctrl-0 = <&bluetooth_enable_default>;
>> +		pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
>>  		pinctrl-names = "default";
>>  
>>  		regulators {
>> @@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
>>  	qcom,tune-usb2-preem = /bits/ 8 <0x6>;
>>  };
>>  
>> +&pmk8550_gpios {
>> +	pmk8550_sleep_clk_default: sleep-clk-default-state {
>> +		pins = "gpio5";
>> +		function = "func1";
>> +		input-disable;
>> +		output-enable;
> 
> Hmm, if it's a sleep_clk, should it not be handled via the power
> sequencer?

If you mean that it may be needed to toggle it with specific timings,
possibly..  seems that WCN6855 has a "xo-clk" GPIO defined. I requested
access to some docs that I think should have the answer, hopefully should
get it soon.

Or maybe +Jeff/Baochen could answer faster?

Konrad


From jeff.johnson at oss.qualcomm.com  Tue Apr  7 18:51:39 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Tue, 7 Apr 2026 18:51:39 -0700
Subject: pull-request: ath-next-20260407
Message-ID: <5af2dde5-a1d2-4c72-bbed-f0a2ef4b9788@oss.qualcomm.com>

The following changes since commit aa5e9884a2d63aa20fc3396d369382c1ecd16109:

  Merge tag 'rtw-next-2026-04-02' of https://github.com/pkshih/rtw into wireless-next (2026-04-07 16:20:55 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260407

for you to fetch changes up to 8fb66931fe31094aa2e1b2a5c015050b8b4cb2ec:

  wifi: ath12k: Enable IPQ5424 WiFi device support (2026-04-07 17:28:22 -0700)

----------------------------------------------------------------
ath.git patches for v7.1 (PR #3)

Add ath12k support for IPQ5424.

And of course there is the usual set of cleanups and bug fixes touching
the ath10k and ath12k drivers.

----------------------------------------------------------------
Avula Sri Charan (1):
      wifi: ath12k: Skip adding inactive partner vdev info

Baochen Qiang (1):
      wifi: ath10k: fix station lookup failure during disconnect

Harish Rachakonda (1):
      wifi: ath12k: Support channel change stats

Raj Kumar Bhagat (2):
      dt-bindings: net: wireless: add ath12k wifi device IPQ5424
      wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424

Roopni Devanathan (2):
      wifi: ath12k: Rename hw_link_id to radio_idx in ath12k_ah_to_ar()
      wifi: ath12k: Create symlink for each radio in a wiphy

Saravanakumar Duraisamy (3):
      wifi: ath12k: Add ath12k_hw_params for IPQ5424
      wifi: ath12k: add ath12k_hw_regs for IPQ5424
      wifi: ath12k: Add CE remap hardware parameters for IPQ5424

Sowmiya Sree Elavalagan (1):
      wifi: ath12k: Enable IPQ5424 WiFi device support

 .../bindings/net/wireless/qcom,ipq5332-wifi.yaml   |  1 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c          | 26 +++---
 drivers/net/wireless/ath/ath12k/ahb.c              | 36 ++++----
 drivers/net/wireless/ath/ath12k/ahb.h              |  1 +
 drivers/net/wireless/ath/ath12k/ce.h               | 13 ++-
 drivers/net/wireless/ath/ath12k/core.c             |  4 +-
 drivers/net/wireless/ath/ath12k/core.h             | 13 +--
 drivers/net/wireless/ath/ath12k/debugfs.c          | 29 +++++--
 .../net/wireless/ath/ath12k/debugfs_htt_stats.c    | 72 ++++++++++++++++
 .../net/wireless/ath/ath12k/debugfs_htt_stats.h    | 26 ++++++
 drivers/net/wireless/ath/ath12k/mac.c              |  4 +-
 drivers/net/wireless/ath/ath12k/wifi7/ahb.c        |  8 ++
 drivers/net/wireless/ath/ath12k/wifi7/hal.c        |  7 ++
 drivers/net/wireless/ath/ath12k/wifi7/hal.h        |  3 +
 .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c    | 88 ++++++++++++++++++++
 .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h    |  1 +
 drivers/net/wireless/ath/ath12k/wifi7/hw.c         | 97 +++++++++++++++++++++-
 17 files changed, 383 insertions(+), 46 deletions(-)


From baochen.qiang at oss.qualcomm.com  Tue Apr  7 23:06:00 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Wed, 8 Apr 2026 14:06:00 +0800
Subject: [PATCH 0/2] wifi: ath: Use static calibration variant table for
 devicetree platforms
In-Reply-To: <fasihmiu2szj6m2r3qef5slvzlvdjo2ajhrd6xyqsa5cajrbzq@a5dyulg2dnac>
References: <20251114-ath-variant-tbl-v1-0-a9adfc49e3f3@oss.qualcomm.com>
 <2fd84ab2-2e3e-4d05-add5-17930a35fedf@oss.qualcomm.com>
 <jnggqxqv3rjzhyevovnnxzplfhl3t6auhhvmoz7wxmsf6awgdx@dusdgxwsxvts>
 <b8277024-f9d4-4f17-946f-c2c390669067@oss.qualcomm.com>
 <exfmj52dqu3uctwsb2gopcjg7744vq5avlkahtmgfw4opw4mfl@t2svrln72u53>
 <f853d9b2-47f8-47b5-a02d-6aa8f12a4283@oss.qualcomm.com>
 <trr5j57vwk2dhoibdgdxnlkftnmfcmjkwmicsiltmhybxanjaf@tzaeeqcyz56l>
 <fasihmiu2szj6m2r3qef5slvzlvdjo2ajhrd6xyqsa5cajrbzq@a5dyulg2dnac>
Message-ID: <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>



On 11/25/2025 5:57 PM, Ernest Van Hoecke wrote:
> On Tue, Nov 18, 2025 at 12:23:20PM +0530, Manivannan Sadhasivam wrote:
>>
>> ath12k doesn't seem to require a calibration variant. But even if the user
>> replaces ath11k chipset with ath10k one, the calibration variant should be the
>> same as it is platform specific except for WSI.
>>
>> - Mani
>>
>> -- 
>> ????????? ????????
>>
> 
> Hi all,
> 
> Jumping in on this thread to ask about how we should handle variants.
> 
> We are using the WCN7850 device with the ath12k driver and received three
> board files for this from Silex, signed by Qualcomm. All three support the
> same board (SX-PCEBE), where one is the board file to be used for the
> US/EU/JP and the other two are one for higher emissions in the UK/CA and
> one for lower emissions in the UK/CA.
> 
> Since these are needed for regulatory differences but support the same
> board, we were wondering about your views on how to handle that in
> mainline. I see that there is no support for the board file selection in
> the device tree for ath12k, and that there is some discussion on how to
> handle variants in general. We are using a device tree-based setup and no
> ACPI.

does your machine has different 'model' property for different BDFs ?
does the existing ath11k 'calibration' property based mechanism satisfy your requirement?

> 
> Thanks!
> 
> Kind regards,
> Ernest



From jeff.johnson at oss.qualcomm.com  Wed Apr  8 10:40:30 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Wed, 8 Apr 2026 10:40:30 -0700
Subject: pull-request: ath-next-20260408
Message-ID: <aa4cecc7-d5fc-41dc-ad36-80f010e5f426@oss.qualcomm.com>

This was missing a DT review when I sent my v7.1 PR #3.
Hope to get this in the merge windows since there is an in-flight patch
that would leverage it:
https://lore.kernel.org/all/20260331-judyln-dts-v7-11-87217b15fefb at postmarketos.org/

---

The following changes since commit 8c6d03b7a249ffe85ba2bda09a2a7614c0ff03db:

  crypto: Remove michael_mic from crypto_shash API (2026-04-08 10:11:37 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260408

for you to fetch changes up to 6a7693873b20680a3c33bae0c9f9cb3185f64ade:

  wifi: ath10k: Add device-tree quirk to skip host cap QMI requests (2026-04-08 10:13:09 -0700)

----------------------------------------------------------------
ath.git patches for v7.1 (PR #4)

Add support for an ath10k device-tree quirk to skip host cap QMI requests.

----------------------------------------------------------------
Amit Pundir (2):
      dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
      wifi: ath10k: Add device-tree quirk to skip host cap QMI requests

 .../devicetree/bindings/net/wireless/qcom,ath10k.yaml       | 11 +++++++++++
 drivers/net/wireless/ath/ath10k/qmi.c                       | 13 ++++++++++---
 drivers/net/wireless/ath/ath10k/snoc.c                      |  3 +++
 drivers/net/wireless/ath/ath10k/snoc.h                      |  1 +
 4 files changed, 25 insertions(+), 3 deletions(-)


From ernestvanhoecke at gmail.com  Mon Apr 13 02:32:15 2026
From: ernestvanhoecke at gmail.com (Ernest Van Hoecke)
Date: Mon, 13 Apr 2026 11:32:15 +0200
Subject: [PATCH 0/2] wifi: ath: Use static calibration variant table for
 devicetree platforms
In-Reply-To: <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>
References: <20251114-ath-variant-tbl-v1-0-a9adfc49e3f3@oss.qualcomm.com>
 <2fd84ab2-2e3e-4d05-add5-17930a35fedf@oss.qualcomm.com>
 <jnggqxqv3rjzhyevovnnxzplfhl3t6auhhvmoz7wxmsf6awgdx@dusdgxwsxvts>
 <b8277024-f9d4-4f17-946f-c2c390669067@oss.qualcomm.com>
 <exfmj52dqu3uctwsb2gopcjg7744vq5avlkahtmgfw4opw4mfl@t2svrln72u53>
 <f853d9b2-47f8-47b5-a02d-6aa8f12a4283@oss.qualcomm.com>
 <trr5j57vwk2dhoibdgdxnlkftnmfcmjkwmicsiltmhybxanjaf@tzaeeqcyz56l>
 <fasihmiu2szj6m2r3qef5slvzlvdjo2ajhrd6xyqsa5cajrbzq@a5dyulg2dnac>
 <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>
Message-ID: <77vowy4ax4cl6dlc45i2q3fjmwn3q676wqghq267tmbix7773b@27h5t66mflur>

On Wed, Apr 08, 2026 at 02:06:00PM +0800, Baochen Qiang wrote:
> 
> 
> On 11/25/2025 5:57 PM, Ernest Van Hoecke wrote:
> > On Tue, Nov 18, 2025 at 12:23:20PM +0530, Manivannan Sadhasivam wrote:
> >>
> >> ath12k doesn't seem to require a calibration variant. But even if the user
> >> replaces ath11k chipset with ath10k one, the calibration variant should be the
> >> same as it is platform specific except for WSI.
> >>
> >> - Mani
> >>
> >> -- 
> >> ????????? ????????
> >>
> > 
> > Hi all,
> > 
> > Jumping in on this thread to ask about how we should handle variants.
> > 
> > We are using the WCN7850 device with the ath12k driver and received three
> > board files for this from Silex, signed by Qualcomm. All three support the
> > same board (SX-PCEBE), where one is the board file to be used for the
> > US/EU/JP and the other two are one for higher emissions in the UK/CA and
> > one for lower emissions in the UK/CA.
> > 
> > Since these are needed for regulatory differences but support the same
> > board, we were wondering about your views on how to handle that in
> > mainline. I see that there is no support for the board file selection in
> > the device tree for ath12k, and that there is some discussion on how to
> > handle variants in general. We are using a device tree-based setup and no
> > ACPI.
> 
> does your machine has different 'model' property for different BDFs ?
> does the existing ath11k 'calibration' property based mechanism satisfy your requirement?
> 

We have a SoM with always the same WiFi SoC on board. These SoMs are
then mated with a carrier board, in our case often a development board,
and together they form a whole machine for which we have a specific
device tree with a specific model and compatible name.

Customers that create their own carrier board would have their own
device tree with their own model string. These carrier board device
trees include the base SoM dtsi.

When these devices are sold in multiple markets, the model string is
thus not specific to it. For example, the same model string can be sold
in Japan and in Canada, with different regulatory requirements and thus
a different board file that needs to be used.

In short: no, the machine does not have a different model property for
different BDFs.

Similarly, the WCN7850 would also not have a different PCI ID in
different regions since the hardware sold is the same.

The existing ath11k calibration property did provide a way to specify in
the DT which BDF should be used, so in that way it can provide a
solution yes. Of course, with the drawback that the PCI device has to be
specified in the DT.

This would allow customers to ship their device with a different DT
based on the the target market and its regulatory requirements. Another
mechanism that allows them to specify which variant to use in SW/HW
in- or outside the device tree would also work.

Thanks for looking at this and kind regards,
Ernest


From baochen.qiang at oss.qualcomm.com  Mon Apr 13 23:43:13 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Tue, 14 Apr 2026 14:43:13 +0800
Subject: [PATCH v2] wifi: ath11k: apply existing PM quirk to ThinkPad P14s
 Gen 5 AMD
In-Reply-To: <CAOPSVF0VHR4BQsmfWFeFnANsQYBw-x7fHxH2JFNO=oWjgeS66Q@mail.gmail.com>
References: <20260330-p14s-pm-quirk-v2-1-ef18ce07996b@gmail.com>
 <082b3d13-6fb1-4041-a187-fddec3b013e4@oss.qualcomm.com>
 <CAOPSVF0VHR4BQsmfWFeFnANsQYBw-x7fHxH2JFNO=oWjgeS66Q@mail.gmail.com>
Message-ID: <ba4d194b-6d31-4d8a-a6a6-da116f9f56ac@oss.qualcomm.com>



On 4/1/2026 11:48 AM, Kyle Farnung wrote:
> On Tue, Mar 31, 2026 at 7:08?PM Baochen Qiang
> <baochen.qiang at oss.qualcomm.com> wrote:
>>
>>
>>
>> On 3/31/2026 2:32 PM, Kyle Farnung via B4 Relay wrote:
>>> From: Kyle Farnung <kfarnung at gmail.com>
>>>
>>> Some ThinkPad P14s Gen 5 AMD systems experience suspend/resume
>>> reliability issues similar to those reported in [1]. These platforms
>>
>> how similar it is? can you describe the issue in details?
> 
> The issue is that intermittently after suspend my WiFi adapter connects
> successfully for a few minutes and then drops. It will then keep trying to
> reconnect in a loop but never succeed. A reboot will fix it, but eventually
> I found that reloading the module also resolves the issue
> (modprobe -r ath11k_pci && modprobe ath11k_pci). Based on some searching, I
> did try adding "ath11k_pci.disable_idle_ps=1" to my kernel arguments. At
> first it looked like maybe it worked, but then I hit the same problem
> again. At that point I decided to try building a custom module with the
> ATH11K_PM_WOW override and so far I'm two days and 10 suspends in without
> issue.
> 
> Looking through kernel logs, the issue appears to have started with kernel
> version 6.17.4. It looks like my Fedora install jumped from 6.16.10 to
> 6.17.4 on October 22, 2025 and I started seeing the issue two days later.
> 
> Here are the logs from the most recent occurrence (filtered for brevity):
> 
> Mar 29 15:26:24 kjfp14sg5 kernel: PM: suspend exit
> Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: chip_id
> 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
> Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: fw_version
> 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id
> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:35 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-CONNECTED - Connection to 68:d7:9a:2a:94:f8 completed [id=0
> id_str=]
> Mar 29 15:26:49 kjfp14sg5 wpa_supplicant[2373]: wlp2s0: CTRL-EVENT-BEACON-LOSS

this is the reason to your disconnection

> Mar 29 15:26:55 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: failed to
> flush transmit queue, data pkts pending 9
> Mar 29 15:26:55 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=4
> locally_generated=1
> Mar 29 15:27:00 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=80:2a:a8:98:26:3e reason=6
> Mar 29 15:27:05 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=74:ac:b9:df:54:36 reason=6
> Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=2
> Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Batman" auth_failures=1
> duration=10 reason=CONN_FAILED

and the bssid is disabled so association to this AP won't happen in a period.

Anyway, although it works, using the PM quirk seems not the right fix. As you mentioned it
seems like a regression starting to show in 6.17.4, can you do regression test to locate
the issue commit?

> 
>>
>>> were not previously included in the ath11k PM quirk table.
>>>
>>> Add DMI matches for product IDs 21ME and 21MF to apply the existing
>>> ATH11K_PM_WOW override, improving suspend/resume behavior on these
>>> systems.
>>>
>>> Tested on a ThinkPad P14s Gen 5 AMD (21ME) running 6.19.9.
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
>>> [2] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/
>>>
>>> Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
>>> Cc: stable at vger.kernel.org
>>> Signed-off-by: Kyle Farnung <kfarnung at gmail.com>
>>> ---
>>> Changes in v2:
>>> - Fix missing mailing list recipients (linux-wireless, ath11k, linux-kernel)
>>> - Link to v1: https://lore.kernel.org/r/20260330-p14s-pm-quirk-v1-1-cf2fa39cc2d5 at gmail.com
>>> ---
>>>  drivers/net/wireless/ath/ath11k/core.c | 14 ++++++++++++++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
>>> index 3f6f4db5b7ee1aba79fd7526e5d59d068e0f4a2e..21d366224e75904feeae6cb9c93d9ef692d127fe 100644
>>> --- a/drivers/net/wireless/ath/ath11k/core.c
>>> +++ b/drivers/net/wireless/ath/ath11k/core.c
>>> @@ -1041,6 +1041,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
>>>                       DMI_MATCH(DMI_PRODUCT_NAME, "21D5"),
>>>               },
>>>       },
>>> +     {
>>> +             .driver_data = (void *)ATH11K_PM_WOW,
>>> +             .matches = { /* P14s G5 AMD #1 */
>>> +                     DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
>>> +                     DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
>>> +             },
>>> +     },
>>> +     {
>>> +             .driver_data = (void *)ATH11K_PM_WOW,
>>> +             .matches = { /* P14s G5 AMD #2 */
>>> +                     DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
>>> +                     DMI_MATCH(DMI_PRODUCT_NAME, "21MF"),
>>> +             },
>>> +     },
>>>       {}
>>>  };
>>>
>>>
>>> ---
>>> base-commit: dbd94b9831bc52a1efb7ff3de841ffc3457428ce
>>> change-id: 20260330-p14s-pm-quirk-0a51ba19235f
>>>
>>> Best regards,
>>



From baochen.qiang at oss.qualcomm.com  Tue Apr 14 00:06:33 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Tue, 14 Apr 2026 15:06:33 +0800
Subject: [PATCH] ath11k: workaround firmware bug where peer_id=0
In-Reply-To: <87h5pxlpg4.fsf@collabora.com>
References: <20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8@collabora.com>
 <87h5pxlpg4.fsf@collabora.com>
Message-ID: <7dbc3836-c42c-4cbb-a50a-011d82a0ee81@oss.qualcomm.com>



On 3/30/2026 3:57 PM, Matthew Leach wrote:
> Hello,
> 
> Matthew Leach <matthew.leach at collabora.com> writes:
> 
>> This patch caches the peer enctype during the MSDU processing loop,
>> caching it on the first AMSDU sub-frame (is_first_msdu=1
>> is_last_msdu=0) and setting the correct enctype for any subsequent
>> sub-MSDUs.
> 
> I've been looking at creating a patch that addresses the root cause,
> rather than patching incoming frame's flags:
> 
> --8<---------------cut here---------------start------------->8---
> diff --git a/drivers/net/wireless/ath/ath11k/peer.c b/drivers/net/wireless/ath/ath11k/peer.c
> index 6d0126c39301..98348ccfdfbe 100644
> --- a/drivers/net/wireless/ath/ath11k/peer.c
> +++ b/drivers/net/wireless/ath/ath11k/peer.c
> @@ -347,7 +347,7 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
>  	return 0;
>  }
>  
> -int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, u8 *addr)
> +int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
>  {
>  	int ret;
>  
> @@ -372,7 +372,7 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
>  {
>  	struct ath11k_peer *peer;
>  	struct ath11k_sta *arsta;
> -	int ret, fbret;
> +	int ret, fbret, retries = 3;
>  
>  	lockdep_assert_held(&ar->conf_mutex);
>  
> @@ -400,6 +400,8 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
>  	spin_unlock_bh(&ar->ab->base_lock);
>  	mutex_unlock(&ar->ab->tbl_mtx_lock);
>  
> +retry:
> +
>  	ret = ath11k_wmi_send_peer_create_cmd(ar, param);
>  	if (ret) {
>  		ath11k_warn(ar->ab,
> @@ -427,6 +429,18 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
>  		goto cleanup;
>  	}
>  
> +	if (!peer->peer_id) {
> +		if (retries--) {
> +			spin_unlock_bh(&ar->ab->base_lock);
> +			mutex_unlock(&ar->ab->tbl_mtx_lock);
> +			ath11k_peer_delete(ar, param->vdev_id, param->peer_addr);
> +			goto retry;
> +		} else {
> +			ath11k_warn(ar->ab, "Null peer workaround failed for peer %pM, adding anyway",
> +				    param->peer_addr);
> +		}
> +	}
> +
>  	ret = ath11k_peer_rhash_add(ar->ab, peer);
>  	if (ret) {
>  		spin_unlock_bh(&ar->ab->base_lock);
> diff --git a/drivers/net/wireless/ath/ath11k/peer.h b/drivers/net/wireless/ath/ath11k/peer.h
> index 3ad2f3355b14..6325c4d157c7 100644
> --- a/drivers/net/wireless/ath/ath11k/peer.h
> +++ b/drivers/net/wireless/ath/ath11k/peer.h
> @@ -47,7 +47,7 @@ struct ath11k_peer *ath11k_peer_find_by_addr(struct ath11k_base *ab,
>  					     const u8 *addr);
>  struct ath11k_peer *ath11k_peer_find_by_id(struct ath11k_base *ab, int peer_id);
>  void ath11k_peer_cleanup(struct ath11k *ar, u32 vdev_id);
> -int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, u8 *addr);
> +int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr);
>  int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
>  		       struct ieee80211_sta *sta, struct peer_create_params *param);
>  int ath11k_wait_for_peer_delete_done(struct ath11k *ar, u32 vdev_id,
> --8<---------------cut here---------------end--------------->8---
> 
> This patch detects the error condition at the point where a peer map
> request reply is received from the firmware. If the firmware maps with
> peer_id=0, we request that the firmware unmap that peer and map again,
> hoping it selects a peer_id!=0. We attempt this up to three times, at
> which point we give up and let the peer be mapped with an ID of 0.
> 
> This patch addresses the root cause, but I think it's more invasive. I'd
> appreciate some comments as to which approach upstream would prefer. If
> the preference is for the above, I'll send out a v2.

for chips like QCA2066 and WCN6855 etc 0 is a valid value, however this is not for chips
like QCN9074 etc.

so a possible fix would be to add hardware ops based on chips: for QCN9074 we keep the
existing validation on 0 in the ops, while for QCA2066 the ops is a null func. Or even
simper we can remove the validation for all chips.

> 
> Regards,



From matthew.leach at collabora.com  Tue Apr 14 05:54:47 2026
From: matthew.leach at collabora.com (Matthew Leach)
Date: Tue, 14 Apr 2026 13:54:47 +0100
Subject: [PATCH] ath11k: workaround firmware bug where peer_id=0
In-Reply-To: <7dbc3836-c42c-4cbb-a50a-011d82a0ee81@oss.qualcomm.com> (Baochen
	Qiang's message of "Tue, 14 Apr 2026 15:06:33 +0800")
References: <20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8@collabora.com>
	<87h5pxlpg4.fsf@collabora.com>
	<7dbc3836-c42c-4cbb-a50a-011d82a0ee81@oss.qualcomm.com>
Message-ID: <87a4v54s88.fsf@collabora.com>

Hi Baochen,

Baochen Qiang <baochen.qiang at oss.qualcomm.com> writes:

> On 3/30/2026 3:57 PM, Matthew Leach wrote:
>> Hello,
>> 
>> Matthew Leach <matthew.leach at collabora.com> writes:
>> 

[...]

> for chips like QCA2066 and WCN6855 etc 0 is a valid value, however
> this is not for chips like QCN9074 etc.
>
> so a possible fix would be to add hardware ops based on chips: for
> QCN9074 we keep the existing validation on 0 in the ops, while for
> QCA2066 the ops is a null func. Or even simper we can remove the
> validation for all chips.

In that case, does it make sense to remove the condition check

if (rxcb->peer_id)

in ath11k_dp_rx_h_find_peer()? It looks like this has been used as a
small optimisation, where if peer_id isn't valid it skips checking for
it in the peer hash table. However, if on newer chips peer_id=0 is
valid, we should remove this?

Regards,
-- 
Matt


From baochen.qiang at oss.qualcomm.com  Tue Apr 14 20:16:00 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Wed, 15 Apr 2026 11:16:00 +0800
Subject: [PATCH] ath11k: workaround firmware bug where peer_id=0
In-Reply-To: <87a4v54s88.fsf@collabora.com>
References: <20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8@collabora.com>
 <87h5pxlpg4.fsf@collabora.com>
 <7dbc3836-c42c-4cbb-a50a-011d82a0ee81@oss.qualcomm.com>
 <87a4v54s88.fsf@collabora.com>
Message-ID: <b71bca62-e467-4c88-a6e5-c44f13d48b4d@oss.qualcomm.com>



On 4/14/2026 8:54 PM, Matthew Leach wrote:
> Hi Baochen,
> 
> Baochen Qiang <baochen.qiang at oss.qualcomm.com> writes:
> 
>> On 3/30/2026 3:57 PM, Matthew Leach wrote:
>>> Hello,
>>>
>>> Matthew Leach <matthew.leach at collabora.com> writes:
>>>
> 
> [...]
> 
>> for chips like QCA2066 and WCN6855 etc 0 is a valid value, however
>> this is not for chips like QCN9074 etc.
>>
>> so a possible fix would be to add hardware ops based on chips: for
>> QCN9074 we keep the existing validation on 0 in the ops, while for
>> QCA2066 the ops is a null func. Or even simper we can remove the
>> validation for all chips.
> 
> In that case, does it make sense to remove the condition check
> 
> if (rxcb->peer_id)
> 
> in ath11k_dp_rx_h_find_peer()? It looks like this has been used as a
> small optimisation, where if peer_id isn't valid it skips checking for
> it in the peer hash table. However, if on newer chips peer_id=0 is
> valid, we should remove this?

yeah, I think so. This check was also based on the non-zero peer id assumption.

> 
> Regards,



From mitltlatltl at gmail.com  Wed Apr 15 02:59:42 2026
From: mitltlatltl at gmail.com (Pengyu Luo)
Date: Wed, 15 Apr 2026 17:59:42 +0800
Subject: ath11k: WCN6855 hw2.1: board file for Huawei Gaokun3(qmi-chip-id=18)
Message-ID: <CAH2e8h6B3u_myFhiGWRNHMGD=bV57uVch6kceeWSuA-mu33FEg@mail.gmail.com>

Add board file for Huawei Gaokun3(qmi-chip-id=18), which is a SC8280XP
based device.

* description for what hardware this is:

A WCN6855 module found in a SC8280XP based board.
"bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=18,qmi-board-id=255"

* origin of the board file (did you create it yourself or where you
  downloaded)

It is from device firmware and varies between units. It seems that
Huawei creates for every unit. Anyways it is compatible with other
units.

* ids to be used with the board file (ATH10K_BD_IE_BOARD_NAME in ath10k)

ids: "bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=18,qmi-board-id=255,variant=HW_GK3"
sha256sum: c162232ed6988a8d2404137675e3153ee0ee2a42fccfed56425569773349aec8

Best wishes,
Pengyu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=18,qmi-board-id=255,variant=HW_GK3
Type: application/octet-stream
Size: 59908 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20260415/6708e7f1/attachment-0001.obj>

From matthew.leach at collabora.com  Wed Apr 15 04:39:02 2026
From: matthew.leach at collabora.com (Matthew Leach)
Date: Wed, 15 Apr 2026 12:39:02 +0100
Subject: [PATCH v2] ath11k: fix peer resolution on rx path when peer_id=0
Message-ID: <20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16@collabora.com>

It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of standard MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source mac address.

However, on an aggregated link, reception of AMSDUs results in the peer
not being resolved for the second (any any subsequent) sub-MSDUs due to
the peer_id guard in ath11k_dp_rx_h_find_peer(). This causes the
encryption type of the frame to be set to an incorrect value, resulting
in the sub-MSDUs being dropped by ieee80211.

ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1

This patch removes the null peer_id check in ath11k_dp_rx_h_find_peer(),
allowing peer's with an assigned ID of 0 to be resolved.

Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
---
Changes in v2:

- Since peer_id=0 is a valid condition on some chips, remove the guard
  that prevented the peer lookup.
- Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com

To: Jeff Johnson <jjohnson at kernel.org>
Cc: linux-wireless at vger.kernel.org
Cc: ath11k at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 49d959b2e148..ff2c78a4e5f3 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
 
 	lockdep_assert_held(&ab->base_lock);
 
-	if (rxcb->peer_id)
-		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
+	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
 
 	if (peer)
 		return peer;

---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1

Best regards,
--  
Matt



From baochen.qiang at oss.qualcomm.com  Wed Apr 15 20:04:34 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Thu, 16 Apr 2026 11:04:34 +0800
Subject: [PATCH v2] ath11k: fix peer resolution on rx path when peer_id=0
In-Reply-To: <20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16@collabora.com>
References: <20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16@collabora.com>
Message-ID: <85c4d942-39f3-4cb3-93f1-29f932387e70@oss.qualcomm.com>



On 4/15/2026 7:39 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of standard MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source mac address.
> 
> However, on an aggregated link, reception of AMSDUs results in the peer
> not being resolved for the second (any any subsequent) sub-MSDUs due to
> the peer_id guard in ath11k_dp_rx_h_find_peer(). This causes the

it is necessary to point out that the mac address based fallback does not work for those
sub-MSDUs as well, since the mpdu_start descriptor from where mac address is obtained is
not populated by hardware.

> encryption type of the frame to be set to an incorrect value, resulting
> in the sub-MSDUs being dropped by ieee80211.
> 
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
> 
> This patch removes the null peer_id check in ath11k_dp_rx_h_find_peer(),
> allowing peer's with an assigned ID of 0 to be resolved.
> 
> Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
> ---
> Changes in v2:
> 
> - Since peer_id=0 is a valid condition on some chips, remove the guard
>   that prevented the peer lookup.
> - Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com
> 
> To: Jeff Johnson <jjohnson at kernel.org>
> Cc: linux-wireless at vger.kernel.org
> Cc: ath11k at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/wireless/ath/ath11k/dp_rx.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 49d959b2e148..ff2c78a4e5f3 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
>  
>  	lockdep_assert_held(&ab->base_lock);
>  
> -	if (rxcb->peer_id)
> -		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
> +	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>  
>  	if (peer)
>  		return peer;

the other instance in ath11k_hal_rx_parse_mon_status_tlv() is missed.

> 
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
> 
> Best regards,
> --  
> Matt
> 



From matthew.leach at collabora.com  Fri Apr 17 04:07:48 2026
From: matthew.leach at collabora.com (Matthew Leach)
Date: Fri, 17 Apr 2026 12:07:48 +0100
Subject: [PATCH v3] ath11k: fix peer resolution on rx path when peer_id=0
Message-ID: <20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com>

It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of non-aggregated MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source MAC address. On an aggregated link, the mpdu_start
header is only populated by hardware on the first sub-MSDU. This causes
the peer resolution to be skipped for the subsequent MSDUs and the
encryption type of these frames to be set to an incorrect value,
resulting in these MSDUs being dropped by ieee80211.

ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1

Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
of 0 to be resolved.

Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
---
Changes in v3:
- Clarified that the mpdu_start header isn't populated by the h/w for
  all sub-MSDUs in the commit message.
- Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
- Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16 at collabora.com

Changes in v2:

- Since peer_id=0 is a valid condition on some chips, remove the guard
  that prevented the peer lookup.
- Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com

To: Jeff Johnson <jjohnson at kernel.org>
Cc: linux-wireless at vger.kernel.org
Cc: ath11k at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/wireless/ath/ath11k/dp_rx.c  | 3 +--
 drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 49d959b2e148..ff2c78a4e5f3 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
 
 	lockdep_assert_held(&ab->base_lock);
 
-	if (rxcb->peer_id)
-		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
+	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
 
 	if (peer)
 		return peer;
diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
index 753bd93f0212..51e0840bc0d1 100644
--- a/drivers/net/wireless/ath/ath11k/hal_rx.c
+++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
@@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
 	case HAL_RX_MPDU_START: {
 		struct hal_rx_mpdu_info *mpdu_info =
 				(struct hal_rx_mpdu_info *)tlv_data;
-		u16 peer_id;
 
-		peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
-		if (peer_id)
-			ppdu_info->peer_id = peer_id;
+		ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
 		break;
 	}
 	case HAL_RXPCU_PPDU_END_INFO: {

---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1

Best regards,
--  
Matt



From baochen.qiang at oss.qualcomm.com  Sun Apr 19 19:22:05 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Mon, 20 Apr 2026 10:22:05 +0800
Subject: [PATCH v3] ath11k: fix peer resolution on rx path when peer_id=0
In-Reply-To: <20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com>
References: <20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com>
Message-ID: <44c5e877-15eb-4a89-8498-328b77d27d0f@oss.qualcomm.com>



On 4/17/2026 7:07 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of non-aggregated MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source MAC address. On an aggregated link, the mpdu_start
> header is only populated by hardware on the first sub-MSDU. This causes
> the peer resolution to be skipped for the subsequent MSDUs and the
> encryption type of these frames to be set to an incorrect value,
> resulting in these MSDUs being dropped by ieee80211.
> 
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
> 
> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
> of 0 to be resolved.
> 
> Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
> ---
> Changes in v3:
> - Clarified that the mpdu_start header isn't populated by the h/w for
>   all sub-MSDUs in the commit message.
> - Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
> - Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16 at collabora.com
> 
> Changes in v2:
> 
> - Since peer_id=0 is a valid condition on some chips, remove the guard
>   that prevented the peer lookup.
> - Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com
> 
> To: Jeff Johnson <jjohnson at kernel.org>
> Cc: linux-wireless at vger.kernel.org
> Cc: ath11k at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/wireless/ath/ath11k/dp_rx.c  | 3 +--
>  drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 49d959b2e148..ff2c78a4e5f3 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
>  
>  	lockdep_assert_held(&ab->base_lock);
>  
> -	if (rxcb->peer_id)
> -		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
> +	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>  
>  	if (peer)
>  		return peer;
> diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
> index 753bd93f0212..51e0840bc0d1 100644
> --- a/drivers/net/wireless/ath/ath11k/hal_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
> @@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
>  	case HAL_RX_MPDU_START: {
>  		struct hal_rx_mpdu_info *mpdu_info =
>  				(struct hal_rx_mpdu_info *)tlv_data;
> -		u16 peer_id;
>  
> -		peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
> -		if (peer_id)
> -			ppdu_info->peer_id = peer_id;
> +		ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
>  		break;
>  	}
>  	case HAL_RXPCU_PPDU_END_INFO: {
> 
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
> 
> Best regards,
> --  
> Matt
> 

Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>



From jtornosm at redhat.com  Mon Apr 20 04:01:29 2026
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Mon, 20 Apr 2026 13:01:29 +0200
Subject: [PATCH] wifi: ath11k: fix warning when unbinding
Message-ID: <20260420110130.509670-1-jtornosm@redhat.com>

If there is an error during some initialization related to firmware,
the buffers dp->tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath11k_pci),
and we get:
WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
Call Trace:
free_large_kmalloc
ath11k_dp_free
ath11k_core_deinit
ath11k_pci_remove
...

The issue is always reproducible from a VM because the MSI addressing
initialization is failing.

In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Cc: stable at vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm at redhat.com>
---
 drivers/net/wireless/ath/ath11k/dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
index bbb86f165141..5a50b623bd07 100644
--- a/drivers/net/wireless/ath/ath11k/dp.c
+++ b/drivers/net/wireless/ath/ath11k/dp.c
@@ -1040,6 +1040,7 @@ void ath11k_dp_free(struct ath11k_base *ab)
 		idr_destroy(&dp->tx_ring[i].txbuf_idr);
 		spin_unlock_bh(&dp->tx_ring[i].tx_idr_lock);
 		kfree(dp->tx_ring[i].tx_status);
+		dp->tx_ring[i].tx_status = NULL;
 	}
 
 	/* Deinit any SOC level resource */
-- 
2.53.0



From sidepipeuk at gmail.com  Tue Apr 21 06:35:08 2026
From: sidepipeuk at gmail.com (Adam Hill)
Date: Tue, 21 Apr 2026 14:35:08 +0100
Subject: Multiple radios/single phy - should the wiphy struct radios[] be set?
Message-ID: <CALgbQMzF65j7n+R6MEftB-uSgmxtcH4dq7tSt4Os_jnwrZirVw@mail.gmail.com>

I've been trying to get a WCN6856 card working as an AP on OpenWrt (
but using a custom kernel and build ) and was hitting a brick wall
getting DBDC to work. I was starting from almost zero knowledge of
Linux WiFi in general which made it harder ( and means I might be
barking up the wrong tree ) - however, it seems that OpenWrt ( at
least ) relies on netlink returning a radio array to detect devices
that have multiple radios on a single phy, which doesn't seem
unreasonable to me.

I've hacked my OpenWrt build to assume that num_channels = 2 on a
second interface combination is the same thing ( which is what ath11k
seems to do when support_dual_stations is true) and confirmed that the
DBDC setup works with this mod. Shouldn't the ath11k driver be changed
to populate the radio list the same way ath12k does? What I've done
with OpenWrt is a bit of a hack, and who knows what else relies on
radios being defined!


From jeff.johnson at oss.qualcomm.com  Tue Apr 21 07:36:08 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Tue, 21 Apr 2026 07:36:08 -0700
Subject: [PULL linux-firmware] ath10k, ath11k and ath12k firmware ath-20260421
Message-ID: <b581cc04-f5cd-4e99-9251-523e50623b03@oss.qualcomm.com>

Hi,
Here's a new pull request for ath10k, ath11k and ath12k firmware.

There are no changes for ath10k or ath11k.
For ath12k, add the initial firmware and board files for IPQ5424 and QCC2072.

Please let me know if there are any problems.

Thanks,
/jeff
---

The following changes since commit 3fc7117bb925983bc39d7ba957ce5fafe1f65d41:

  Merge branch 'wcn6855' into 'main' (2026-04-17 13:57:51 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ath/linux-firmware.git ath-20260421

for you to fetch changes up to 5bd6cbb6ae899e81c1ac3f6915af05e26a354b51:

  ath12k: QCC2072 hw1.0: add to WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1 (2026-04-21 07:06:36 -0700)

----------------------------------------------------------------
Jeff Johnson (4):
      ath12k: IPQ5424 hw1.0: add board-2.bin
      ath12k: IPQ5424 hw1.0: add to WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
      ath12k: QCC2072 hw1.0: add board-2.bin
      ath12k: QCC2072 hw1.0: add to WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1

 WHENCE                               |   11 +
 ath12k/IPQ5424/hw1.0/Notice.txt      | 3987 ++++++++++++++++++++++++++++++++++
 ath12k/IPQ5424/hw1.0/board-2.bin     |  Bin 0 -> 353740 bytes
 ath12k/IPQ5424/hw1.0/iu_fw.mbn       |  Bin 0 -> 348152 bytes
 ath12k/IPQ5424/hw1.0/q6_fw0.mbn      |  Bin 0 -> 878224 bytes
 ath12k/IPQ5424/hw1.0/q6_fw1.mbn      |  Bin 0 -> 5623872 bytes
 ath12k/IPQ5424/hw1.0/qdsp6sw_dtb.mbn |  Bin 0 -> 20404 bytes
 ath12k/QCC2072/hw1.0/Notice.txt      | 3386 +++++++++++++++++++++++++++++
 ath12k/QCC2072/hw1.0/board-2.bin     |  Bin 0 -> 401232 bytes
 ath12k/QCC2072/hw1.0/firmware-2.bin  |  Bin 0 -> 7111860 bytes
 10 files changed, 7384 insertions(+)
 create mode 100644 ath12k/IPQ5424/hw1.0/Notice.txt
 create mode 100644 ath12k/IPQ5424/hw1.0/board-2.bin
 create mode 100644 ath12k/IPQ5424/hw1.0/iu_fw.mbn
 create mode 100644 ath12k/IPQ5424/hw1.0/q6_fw0.mbn
 create mode 100644 ath12k/IPQ5424/hw1.0/q6_fw1.mbn
 create mode 100644 ath12k/IPQ5424/hw1.0/qdsp6sw_dtb.mbn
 create mode 100644 ath12k/QCC2072/hw1.0/Notice.txt
 create mode 100644 ath12k/QCC2072/hw1.0/board-2.bin
 create mode 100644 ath12k/QCC2072/hw1.0/firmware-2.bin


From dmitry.baryshkov at oss.qualcomm.com  Tue Apr 21 08:33:13 2026
From: dmitry.baryshkov at oss.qualcomm.com (Dmitry Baryshkov)
Date: Tue, 21 Apr 2026 18:33:13 +0300
Subject: [PULL linux-firmware] ath10k, ath11k and ath12k firmware
 ath-20260421
In-Reply-To: <b581cc04-f5cd-4e99-9251-523e50623b03@oss.qualcomm.com>
References: <b581cc04-f5cd-4e99-9251-523e50623b03@oss.qualcomm.com>
Message-ID: <wxnc2oczwg3hakkjxms53qbeckmy4oncp42mnqq5t7xs7lsvdc@4mmbo74zs3e2>

On Tue, Apr 21, 2026 at 07:36:08AM -0700, Jeff Johnson wrote:
> Hi,
> Here's a new pull request for ath10k, ath11k and ath12k firmware.
> 
> There are no changes for ath10k or ath11k.
> For ath12k, add the initial firmware and board files for IPQ5424 and QCC2072.

Merged and pushed out, thanks!

https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1010

> 
> Please let me know if there are any problems.
> 
> Thanks,
> /jeff
> ---

-- 
With best wishes
Dmitry


From robh at kernel.org  Tue Apr 21 12:55:25 2026
From: robh at kernel.org (Rob Herring (Arm))
Date: Tue, 21 Apr 2026 14:55:25 -0500
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
Message-ID: <20260421195836.1547469-1-robh@kernel.org>

The unfortunately named 'phandle-array' property type is really a matrix
with phandle and fixed arg cells entries. A matrix property should have 2
levels of items constraints.

Signed-off-by: Rob Herring (Arm) <robh at kernel.org>
---
Can someone from QCom provide some descriptions for 'qcom,smem-states'
properties.
---
 .../display/rockchip/rockchip,rk3399-cdn-dp.yaml         | 2 ++
 .../bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml      | 7 ++++---
 Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml | 6 ++++++
 Documentation/devicetree/bindings/net/qcom,ipa.yaml      | 6 ++++++
 .../devicetree/bindings/net/wireless/qcom,ath10k.yaml    | 5 ++++-
 .../devicetree/bindings/net/wireless/qcom,ath11k.yaml    | 5 ++++-
 .../bindings/net/wireless/qcom,ipq5332-wifi.yaml         | 9 +++++++++
 .../devicetree/bindings/pci/toshiba,tc9563.yaml          | 5 +++--
 .../bindings/remoteproc/qcom,msm8916-mss-pil.yaml        | 3 +++
 .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml        | 3 +++
 .../devicetree/bindings/remoteproc/qcom,pas-common.yaml  | 4 ++++
 .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml        | 4 ++++
 .../bindings/remoteproc/qcom,sc7180-mss-pil.yaml         | 3 +++
 .../bindings/remoteproc/qcom,sc7280-adsp-pil.yaml        | 3 +++
 .../bindings/remoteproc/qcom,sc7280-mss-pil.yaml         | 3 +++
 .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml        | 3 +++
 .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml        | 3 +++
 .../devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml   | 3 +++
 Documentation/devicetree/bindings/sound/samsung,tm2.yaml | 2 ++
 .../devicetree/bindings/spi/st,stm32mp25-ospi.yaml       | 5 +++--
 .../devicetree/bindings/usb/chipidea,usb2-common.yaml    | 2 ++
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml  | 7 ++++---
 22 files changed, 81 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
index 1a33128e77f5..195f665970bf 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
@@ -41,7 +41,9 @@ properties:
     minItems: 1
     items:
       - description: Extcon device providing the cable state for DP PHY device 0
+        maxItems: 1
       - description: Extcon device providing the cable state for DP PHY device 1
+        maxItems: 1
     description:
       List of phandle to the extcon device providing the cable state for the DP PHY.
 
diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
index 41c9b22523e7..e447579e0f22 100644
--- a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
@@ -39,10 +39,11 @@ properties:
     $ref: /schemas/types.yaml#/definitions/phandle-array
     description: |
       DWMMC core on Hi3798MV2x SoCs has a delay-locked-loop(DLL) attached to card data input path.
-      It is integrated into CRG core on the SoC and has to be controlled during tuning.
+      It is integrated into CRG core on the SoC and has to be controlled during tuning
     items:
-      - description: A phandle pointed to the CRG syscon node
-      - description: Sample DLL register offset in CRG address space
+      - items:
+          - description: A phandle pointed to the CRG syscon node
+          - description: Sample DLL register offset in CRG address space
 
 required:
   - compatible
diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
index b30544410d09..e47e1e09300a 100644
--- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
@@ -42,7 +42,13 @@ properties:
     description: State bits used by the AP to signal the modem.
     items:
       - description: Power control
+        items:
+          - description: Phandle to ???
+          - description: ???
       - description: Power control acknowledgment
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: Names for the state bits used by the AP to signal the modem.
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index c7f5f2ef7452..c53f63068b77 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -123,7 +123,13 @@ properties:
     description: State bits used in by the AP to signal the modem.
     items:
       - description: Whether the "ipa-clock-enabled" state bit is valid
+        items:
+          - description: Phandle to ???
+          - description: ???
       - description: Whether the IPA clock is enabled (if valid)
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index f2440d39b7eb..5c580bc7df08 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -158,7 +158,10 @@ properties:
     description: State bits used by the AP to signal the WLAN Q6.
     items:
       - description: Signal bits used to enable/disable low power mode
-                     on WCN in the case of WoW (Wake on Wireless).
+          on WCN in the case of WoW (Wake on Wireless).
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output.
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index 0cc1dbf2beef..326c1a94a1a0 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -80,7 +80,10 @@ properties:
     description: State bits used by the AP to signal the WLAN Q6.
     items:
       - description: Signal bits used to enable/disable low power mode
-                     on WCN6750 in the case of WoW (Wake on Wireless).
+          on WCN6750 in the case of WoW (Wake on Wireless).
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output.
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
index 363a0ecb6ad9..ea8df6890478 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
@@ -167,8 +167,17 @@ properties:
     description: States used by the AP to signal the remote processor
     items:
       - description: Shutdown WCSS pd
+        items:
+          - description: Phandle to ???
+          - description: ???
       - description: Stop WCSS pd
+        items:
+          - description: Phandle to ???
+          - description: ???
       - description: Spawn WCSS pd
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description:
diff --git a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
index fae466064780..b3ad05d90201 100644
--- a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
+++ b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
@@ -49,8 +49,9 @@ properties:
       A phandle to the parent I2C node and the slave address of the device
       used to configure tc9563 to change FTS, tx amplitude etc.
     items:
-      - description: Phandle to the I2C controller node
-      - description: I2C slave address
+      - items:
+          - description: Phandle to the I2C controller node
+          - description: I2C slave address
 
 patternProperties:
   "^pcie@[1-3],0$":
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
index c179b560572b..3c614cb7ce88 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
@@ -104,6 +104,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: Names of the states used by the AP to signal the Hexagon core
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
index 4d2055f283ac..d459296df0c2 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
@@ -101,6 +101,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: Names of the states used by the AP to signal the Hexagon core
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
index 68c17bf18987..6260f77b7e4b 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -60,6 +60,10 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
+
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
index bca59394aef4..3e410cbd45cf 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
@@ -92,6 +92,10 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
+
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
index b1402bef0ebe..f0bee69baf0d 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
@@ -134,6 +134,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
index 94ca7a0cc203..3ea83207ae32 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
@@ -91,6 +91,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
index 005cb21732af..1f1d73610510 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
@@ -148,6 +148,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
index f4118b2da5f6..0111384d55d5 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
@@ -104,6 +104,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
index a3c74871457f..b9325967b8a3 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
@@ -92,6 +92,9 @@ properties:
     description: States used by the AP to signal the Hexagon core
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
index 117fb4d0c4ad..e009f8ed9e8c 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
@@ -84,6 +84,9 @@ properties:
       States used by the AP to signal the WCNSS core that it should shutdown
     items:
       - description: Stop the modem
+        items:
+          - description: Phandle to ???
+          - description: ???
 
   qcom,smem-state-names:
     description: The names of the state bits used for SMP2P output
diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
index 67586ba3e0a0..c752e4874e7f 100644
--- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
@@ -46,7 +46,9 @@ properties:
     $ref: /schemas/types.yaml#/definitions/phandle-array
     items:
       - description: Phandle to I2S0.
+        maxItems: 1
       - description: Phandle to I2S1.
+        maxItems: 1
 
   mic-bias-gpios:
     description: GPIO pin that enables the Main Mic bias regulator.
diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
index 272bc308726b..b6be47f67fcb 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
@@ -49,8 +49,9 @@ properties:
     description: configure OCTOSPI delay block.
     $ref: /schemas/types.yaml#/definitions/phandle-array
     items:
-      - description: phandle to syscfg
-      - description: register offset within syscfg
+      - items:
+          - description: phandle to syscfg
+          - description: register offset within syscfg
 
   access-controllers:
     description: phandle to the rifsc device to check access right
diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
index 10020af15afc..e6a5e79df348 100644
--- a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
+++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
@@ -97,7 +97,9 @@ properties:
     minItems: 1
     items:
       - description: vbus extcon
+        maxItems: 1
       - description: id extcon
+        maxItems: 1
 
   phy-clkgate-delay-us:
     description:
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
index 691d6cf02c27..fec04702f530 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -61,9 +61,10 @@ properties:
       offset, and phy index
     $ref: /schemas/types.yaml#/definitions/phandle-array
     items:
-      - description: phandle to TCSR node
-      - description: register offset
-      - description: phy index
+      - items:
+          - description: phandle to TCSR node
+          - description: register offset
+          - description: phy index
 
   nvidia,phy:
     description: phandle of usb phy that connects to the port. Use "phys" instead.
-- 
2.53.0



From broonie at kernel.org  Tue Apr 21 13:00:06 2026
From: broonie at kernel.org (Mark Brown)
Date: Tue, 21 Apr 2026 21:00:06 +0100
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
References: <20260421195836.1547469-1-robh@kernel.org>
Message-ID: <ddeb29fc-1292-4191-8963-8ba817410740@sirena.org.uk>

On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.

Acked-by: Mark Brown <broonie at kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20260421/367eb72d/attachment.sig>

From robh at kernel.org  Tue Apr 21 14:33:30 2026
From: robh at kernel.org (Rob Herring (Arm))
Date: Tue, 21 Apr 2026 16:33:30 -0500
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
References: <20260421195836.1547469-1-robh@kernel.org>
Message-ID: <177680720998.183058.5012840252939438533.robh@kernel.org>


On Tue, 21 Apr 2026 14:55:25 -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
> 
> Signed-off-by: Rob Herring (Arm) <robh at kernel.org>
> ---
> Can someone from QCom provide some descriptions for 'qcom,smem-states'
> properties.
> ---
>  .../display/rockchip/rockchip,rk3399-cdn-dp.yaml         | 2 ++
>  .../bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml      | 7 ++++---
>  Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml | 6 ++++++
>  Documentation/devicetree/bindings/net/qcom,ipa.yaml      | 6 ++++++
>  .../devicetree/bindings/net/wireless/qcom,ath10k.yaml    | 5 ++++-
>  .../devicetree/bindings/net/wireless/qcom,ath11k.yaml    | 5 ++++-
>  .../bindings/net/wireless/qcom,ipq5332-wifi.yaml         | 9 +++++++++
>  .../devicetree/bindings/pci/toshiba,tc9563.yaml          | 5 +++--
>  .../bindings/remoteproc/qcom,msm8916-mss-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml        | 3 +++
>  .../devicetree/bindings/remoteproc/qcom,pas-common.yaml  | 4 ++++
>  .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml        | 4 ++++
>  .../bindings/remoteproc/qcom,sc7180-mss-pil.yaml         | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-adsp-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-mss-pil.yaml         | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml        | 3 +++
>  .../devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml   | 3 +++
>  Documentation/devicetree/bindings/sound/samsung,tm2.yaml | 2 ++
>  .../devicetree/bindings/spi/st,stm32mp25-ospi.yaml       | 5 +++--
>  .../devicetree/bindings/usb/chipidea,usb2-common.yaml    | 2 ++
>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml  | 7 ++++---
>  22 files changed, 81 insertions(+), 12 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml:99:1: [warning] too many blank lines (2 > 1) (empty-lines)
./Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml:67:1: [warning] too many blank lines (2 > 1) (empty-lines)

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.example.dtb: i2c-mux3 (i2c-demux-pinctrl): i2c-parent:0: [2, 3, 4] is too long
	from schema $id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/samsung,tm2.example.dtb: sound (samsung,tm2-audio): i2s-controller: [[4294967295], [0], [4294967295], [0]] is too long
	from schema $id: http://devicetree.org/schemas/sound/samsung,tm2.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260421195836.1547469-1-robh at kernel.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.



From jeff.johnson at oss.qualcomm.com  Tue Apr 21 16:03:34 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Tue, 21 Apr 2026 16:03:34 -0700
Subject: [PATCH ath-next] wifi: ath11k: use kzalloc_flex
In-Reply-To: <20260313001608.118294-1-rosenp@gmail.com>
References: <20260313001608.118294-1-rosenp@gmail.com>
Message-ID: <ebca61af-7873-4a6a-aae7-151e81b328e5@oss.qualcomm.com>

On 3/12/2026 5:16 PM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
> 
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation as required by __counted_by.

can you update this like you did for the ath12k patch?



From rosenp at gmail.com  Tue Apr 21 16:12:05 2026
From: rosenp at gmail.com (Rosen Penev)
Date: Tue, 21 Apr 2026 16:12:05 -0700
Subject: [PATCHv2 ath-next] wifi: ath11k: use kzalloc_flex
Message-ID: <20260421231205.77361-1-rosenp@gmail.com>

Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.

Add __counted_by to get extra runtime analysis. Move counting variable
assignment immediately after allocation before any potential accesses.
kzalloc_flex does this anyway for GCC >= 15.

Signed-off-by: Rosen Penev <rosenp at gmail.com>
---
 v2: reword counting variable comment.
 drivers/net/wireless/ath/ath11k/mac.c | 71 ++++++++++-----------------
 drivers/net/wireless/ath/ath11k/wmi.h |  2 +-
 2 files changed, 28 insertions(+), 45 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 4a68bb9ca4fa..b5f3d7221b5f 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -4228,13 +4228,14 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 	if (ret)
 		goto exit;

-	arg = kzalloc_obj(*arg);
+	arg = kzalloc_flex(*arg, chan_list, req->n_channels);

 	if (!arg) {
 		ret = -ENOMEM;
 		goto exit;
 	}

+	arg->num_chan = req->n_channels;
 	ath11k_wmi_start_scan_init(ar, arg);
 	arg->vdev_id = arvif->vdev_id;
 	arg->scan_id = ATH11K_SCAN_ID;
@@ -4262,38 +4263,27 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 		arg->scan_f_passive = 1;
 	}

-	if (req->n_channels) {
-		arg->num_chan = req->n_channels;
-		arg->chan_list = kcalloc(arg->num_chan, sizeof(*arg->chan_list),
-					 GFP_KERNEL);
+	for (i = 0; i < arg->num_chan; i++) {
+		if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
+			     ar->ab->wmi_ab.svc_map)) {
+			arg->chan_list[i] =
+				u32_encode_bits(req->channels[i]->center_freq,
+						WMI_SCAN_CONFIG_PER_CHANNEL_MASK);

-		if (!arg->chan_list) {
-			ret = -ENOMEM;
-			goto exit;
-		}
-
-		for (i = 0; i < arg->num_chan; i++) {
-			if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
-				     ar->ab->wmi_ab.svc_map)) {
-				arg->chan_list[i] =
-					u32_encode_bits(req->channels[i]->center_freq,
-							WMI_SCAN_CONFIG_PER_CHANNEL_MASK);
-
-				/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
-				 * flags, then scan all PSC channels in 6 GHz band and
-				 * those non-PSC channels where RNR IE is found during
-				 * the legacy 2.4/5 GHz scan.
-				 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
-				 * then all channels in 6 GHz will be scanned.
-				 */
-				if (req->channels[i]->band == NL80211_BAND_6GHZ &&
-				    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
-				    !cfg80211_channel_is_psc(req->channels[i]))
-					arg->chan_list[i] |=
-						WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
-			} else {
-				arg->chan_list[i] = req->channels[i]->center_freq;
-			}
+			/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
+			 * flags, then scan all PSC channels in 6 GHz band and
+			 * those non-PSC channels where RNR IE is found during
+			 * the legacy 2.4/5 GHz scan.
+			 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
+			 * then all channels in 6 GHz will be scanned.
+			 */
+			if (req->channels[i]->band == NL80211_BAND_6GHZ &&
+			    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
+			    !cfg80211_channel_is_psc(req->channels[i]))
+				arg->chan_list[i] |=
+					WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
+		} else {
+			arg->chan_list[i] = req->channels[i]->center_freq;
 		}
 	}

@@ -9736,19 +9726,14 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,

 	scan_time_msec = ar->hw->wiphy->max_remain_on_channel_duration * 2;

-	arg = kzalloc_obj(*arg);
+	arg = kzalloc_flex(*arg, chan_list, 1);
 	if (!arg) {
 		ret = -ENOMEM;
 		goto exit;
 	}
-	ath11k_wmi_start_scan_init(ar, arg);
+
 	arg->num_chan = 1;
-	arg->chan_list = kcalloc(arg->num_chan, sizeof(*arg->chan_list),
-				 GFP_KERNEL);
-	if (!arg->chan_list) {
-		ret = -ENOMEM;
-		goto free_arg;
-	}
+	ath11k_wmi_start_scan_init(ar, arg);

 	arg->vdev_id = arvif->vdev_id;
 	arg->scan_id = ATH11K_SCAN_ID;
@@ -9769,7 +9754,7 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 		spin_lock_bh(&ar->data_lock);
 		ar->scan.state = ATH11K_SCAN_IDLE;
 		spin_unlock_bh(&ar->data_lock);
-		goto free_chan_list;
+		goto free_arg;
 	}

 	ret = wait_for_completion_timeout(&ar->scan.on_channel, 3 * HZ);
@@ -9779,7 +9764,7 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 		if (ret)
 			ath11k_warn(ar->ab, "failed to stop scan: %d\n", ret);
 		ret = -ETIMEDOUT;
-		goto free_chan_list;
+		goto free_arg;
 	}

 	ieee80211_queue_delayed_work(ar->hw, &ar->scan.timeout,
@@ -9787,8 +9772,6 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,

 	ret = 0;

-free_chan_list:
-	kfree(arg->chan_list);
 free_arg:
 	kfree(arg);
 exit:
diff --git a/drivers/net/wireless/ath/ath11k/wmi.h b/drivers/net/wireless/ath/ath11k/wmi.h
index baed501b640b..b2dade0516ac 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.h
+++ b/drivers/net/wireless/ath/ath11k/wmi.h
@@ -3423,7 +3423,6 @@ struct scan_req_params {
 	u32 num_bssid;
 	u32 num_ssids;
 	u32 n_probes;
-	u32 *chan_list;
 	u32 notify_scan_events;
 	struct wlan_ssid ssid[WLAN_SCAN_PARAMS_MAX_SSID];
 	struct wmi_mac_addr bssid_list[WLAN_SCAN_PARAMS_MAX_BSSID];
@@ -3436,6 +3435,7 @@ struct scan_req_params {
 	struct hint_bssid hint_bssid[WLAN_SCAN_MAX_HINT_BSSID];
 	struct wmi_mac_addr mac_addr;
 	struct wmi_mac_addr mac_mask;
+	u32 chan_list[] __counted_by(num_chan);
 };

 struct wmi_ssid_arg {
--
2.53.0



From rosenp at gmail.com  Tue Apr 21 16:12:25 2026
From: rosenp at gmail.com (Rosen Penev)
Date: Tue, 21 Apr 2026 16:12:25 -0700
Subject: [PATCH ath-next] wifi: ath11k: use kzalloc_flex
In-Reply-To: <ebca61af-7873-4a6a-aae7-151e81b328e5@oss.qualcomm.com>
References: <20260313001608.118294-1-rosenp@gmail.com> <ebca61af-7873-4a6a-aae7-151e81b328e5@oss.qualcomm.com>
Message-ID: <CAKxU2N--N9psvqkoHetoz+o49ipBxfTT_gP23zA5Wd4p=+nDhw@mail.gmail.com>

On Tue, Apr 21, 2026 at 4:03?PM Jeff Johnson
<jeff.johnson at oss.qualcomm.com> wrote:
>
> On 3/12/2026 5:16 PM, Rosen Penev wrote:
> > Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
> >
> > Add __counted_by to get extra runtime analysis. Move counting variable
> > assignment immediately after allocation as required by __counted_by.
>
> can you update this like you did for the ath12k patch?
Done.
>


From gregkh at linuxfoundation.org  Tue Apr 21 22:46:40 2026
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 22 Apr 2026 07:46:40 +0200
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
References: <20260421195836.1547469-1-robh@kernel.org>
Message-ID: <2026042233-barometer-backroom-d544@gregkh>

On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
> 
> Signed-off-by: Rob Herring (Arm) <robh at kernel.org>
> ---
> Can someone from QCom provide some descriptions for 'qcom,smem-states'
> properties.
> ---
>  .../display/rockchip/rockchip,rk3399-cdn-dp.yaml         | 2 ++
>  .../bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml      | 7 ++++---
>  Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml | 6 ++++++
>  Documentation/devicetree/bindings/net/qcom,ipa.yaml      | 6 ++++++
>  .../devicetree/bindings/net/wireless/qcom,ath10k.yaml    | 5 ++++-
>  .../devicetree/bindings/net/wireless/qcom,ath11k.yaml    | 5 ++++-
>  .../bindings/net/wireless/qcom,ipq5332-wifi.yaml         | 9 +++++++++
>  .../devicetree/bindings/pci/toshiba,tc9563.yaml          | 5 +++--
>  .../bindings/remoteproc/qcom,msm8916-mss-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,msm8996-mss-pil.yaml        | 3 +++
>  .../devicetree/bindings/remoteproc/qcom,pas-common.yaml  | 4 ++++
>  .../bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml        | 4 ++++
>  .../bindings/remoteproc/qcom,sc7180-mss-pil.yaml         | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-adsp-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-mss-pil.yaml         | 3 +++
>  .../bindings/remoteproc/qcom,sc7280-wpss-pil.yaml        | 3 +++
>  .../bindings/remoteproc/qcom,sdm845-adsp-pil.yaml        | 3 +++
>  .../devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml   | 3 +++
>  Documentation/devicetree/bindings/sound/samsung,tm2.yaml | 2 ++
>  .../devicetree/bindings/spi/st,stm32mp25-ospi.yaml       | 5 +++--
>  .../devicetree/bindings/usb/chipidea,usb2-common.yaml    | 2 ++
>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml  | 7 ++++---
>  22 files changed, 81 insertions(+), 12 deletions(-)

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>


From rameshkumar.sundaram at oss.qualcomm.com  Wed Apr 22 00:22:02 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Wed, 22 Apr 2026 12:52:02 +0530
Subject: [PATCH v3] ath11k: fix peer resolution on rx path when peer_id=0
In-Reply-To: <20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com>
References: <20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com>
Message-ID: <afa0f129-d8bc-454e-9e76-88cb097955f6@oss.qualcomm.com>

On 4/17/2026 4:37 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of non-aggregated MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source MAC address. On an aggregated link, the mpdu_start
> header is only populated by hardware on the first sub-MSDU. This causes
> the peer resolution to be skipped for the subsequent MSDUs and the
> encryption type of these frames to be set to an incorrect value,
> resulting in these MSDUs being dropped by ieee80211.
> 
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
> 
> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
> of 0 to be resolved.
> 

Please add a Fixes: tag, since this addresses a real RX-path bug.
At least the dp_rx.c change seems to trace back to
2167fa606c0f ("ath11k: Add support for RX decapsulation offload").

Please also use the usual wireless subject prefix, e.g.
wifi: ath11k: fix peer resolution on rx path when peer_id=0

It would also be useful to add a Tested-on: tag if this was validated on
affected hardware, as suggested in the ath11k submission guidelines.





From krzk at kernel.org  Wed Apr 22 02:19:59 2026
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 22 Apr 2026 11:19:59 +0200
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
References: <20260421195836.1547469-1-robh@kernel.org>
Message-ID: <20260422-proud-quartz-mastodon-fafb9e@quoll>

On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
> 
> Signed-off-by: Rob Herring (Arm) <robh at kernel.org>
> ---
> Can someone from QCom provide some descriptions for 'qcom,smem-states'
> properties.

Working on it...

Best regards,
Krzysztof



From krzk at kernel.org  Wed Apr 22 03:22:06 2026
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 22 Apr 2026 12:22:06 +0200
Subject: [PATCH] dt-bindings: Fix phandle-array constraints, again
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
References: <20260421195836.1547469-1-robh@kernel.org>
Message-ID: <20260422-spectral-caped-albatross-9debf2@quoll>

On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index b30544410d09..e47e1e09300a 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -42,7 +42,13 @@ properties:
>      description: State bits used by the AP to signal the modem.
>      items:
>        - description: Power control
> +        items:
> +          - description: Phandle to ???
> +          - description: ???
>        - description: Power control acknowledgment
> +        items:
> +          - description: Phandle to ???
> +          - description: ???
>  

Here and in all cases except qcom,msm8916-mss-pil:

 - description: Phandle to the Shared Memory Point 2 Point device
     handling the communication with a remote processor

 - description: Single bit index to toggle in the value sent to
     the remote processor
   maximum: 32

...

> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index c179b560572b..3c614cb7ce88 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> @@ -104,6 +104,9 @@ properties:
>      description: States used by the AP to signal the Hexagon core
>      items:
>        - description: Stop modem
> +        items:
> +          - description: Phandle to ???
> +          - description: ???

 - description: Phandle to the Shared Memory Point 2 Point or Shared
     Memory Manager device handling the communication with a remote
     processor

 - description: Single bit index to toggle in the value sent to
     the remote processor
   maximum: 32


Best regards,
Krzysztof



From santiagorr at riseup.net  Thu Apr 23 14:14:54 2026
From: santiagorr at riseup.net (=?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?=)
Date: Thu, 23 Apr 2026 18:14:54 -0300
Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
Message-ID: <20260423211458.458911-1-santiagorr@riseup.net>

Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
table") added some Lenovo platform IDs to the quirk table to address a
wakeup from suspend issue [1].  However, at least two more platform ID
are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
and P14s Gen 3 AMD.  This commit adds one ID for each.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
[2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23

Tested-on: P14s G3 AMD.

Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
Signed-off-by: Santiago Ruano Rinc?n <santiagorr at riseup.net>
---
 drivers/net/wireless/ath/ath11k/core.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index 3f6f4db5b7ee..56938d5d42a1 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -957,6 +957,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "21K4"),
 		},
 	},
+	{
+		.driver_data = (void *)ATH11K_PM_WOW,
+		.matches = { /* P14s G3 AMD */
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "21J5"),
+		},
+	},
 	{
 		.driver_data = (void *)ATH11K_PM_WOW,
 		.matches = { /* P14s G4 AMD #1 */
@@ -971,6 +978,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "21K6"),
 		},
 	},
+	{
+		.driver_data = (void *)ATH11K_PM_WOW,
+		.matches = { /* P14s Gen 5 AMD */
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
+		},
+	},
 	{
 		.driver_data = (void *)ATH11K_PM_WOW,
 		.matches = { /* T16 G2 AMD #1 */
-- 
2.53.0



From kfarnung at outlook.com  Thu Apr 23 19:07:03 2026
From: kfarnung at outlook.com (Kyle Farnung)
Date: Fri, 24 Apr 2026 02:07:03 +0000
Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk
 table
In-Reply-To: <20260423211458.458911-1-santiagorr@riseup.net>
References: <20260423211458.458911-1-santiagorr@riseup.net>
Message-ID: <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>

> 
> 
> 
> ________________________________________
> From: Santiago Ruano Rinc?n <santiagorr at riseup.net>
> Sent: Thursday, April 23, 2026 2:14 PM
> To: Jeff Johnson; linux-wireless at vger.kernel.org; ath11k at lists.infradead.org; linux-kernel at vger.kernel.org
> Cc: Mark Pearson; kfarnung at outlook.com; koike at igalia.com
> Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
> 
> Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
> table") added some Lenovo platform IDs to the quirk table to address a
> wakeup from suspend issue [1].  However, at least two more platform ID
> are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
> and P14s Gen 3 AMD.  This commit adds one ID for each.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
> 
> Tested-on: P14s G3 AMD.

Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
well. I submitted a patch myself [5], but I've been investigating another
symptom.

I have the same "wake on power removed" issue, but I have another issue
that's more annoying where the wifi just dies randomly. I only have the
wake issue when power is disconnected, not when power is connected again.
I mostly leave my device connected, so I only realized the behavior while
doing the regression testing requested in the other patch.

[3] https://pcsupport.lenovo.com/jm/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-3-type-21j5-21j6/21j5
[4] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/21me/21me000pge
[5] https://lore.kernel.org/all/ba4d194b-6d31-4d8a-a6a6-da116f9f56ac at oss.qualcomm.com/

> 
> Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
> Signed-off-by: Santiago Ruano Rinc?n <santiagorr at riseup.net>
> ---
>  drivers/net/wireless/ath/ath11k/core.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index 3f6f4db5b7ee..56938d5d42a1 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -957,6 +957,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
>                         DMI_MATCH(DMI_PRODUCT_NAME, "21K4"),
>                 },
>         },
> +       {
> +               .driver_data = (void *)ATH11K_PM_WOW,
> +               .matches = { /* P14s G3 AMD */
> +                       DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "21J5"),
> +               },
> +       },
>         {
>                 .driver_data = (void *)ATH11K_PM_WOW,
>                 .matches = { /* P14s G4 AMD #1 */
> @@ -971,6 +978,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
>                         DMI_MATCH(DMI_PRODUCT_NAME, "21K6"),
>                 },
>         },
> +       {
> +               .driver_data = (void *)ATH11K_PM_WOW,
> +               .matches = { /* P14s Gen 5 AMD */
> +                       DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
> +               },
> +       },
>         {
>                 .driver_data = (void *)ATH11K_PM_WOW,
>                 .matches = { /* T16 G2 AMD #1 */
> --
> 2.53.0
> 


From matthew.leach at collabora.com  Fri Apr 24 02:50:35 2026
From: matthew.leach at collabora.com (Matthew Leach)
Date: Fri, 24 Apr 2026 10:50:35 +0100
Subject: [PATCH v4] wifi: ath11k: fix peer resolution on rx path when
 peer_id=0
Message-ID: <20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com>

It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of non-aggregated MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source MAC address. On an aggregated link, the mpdu_start
header is only populated by hardware on the first sub-MSDU. This causes
the peer resolution to be skipped for the subsequent MSDUs and the
encryption type of these frames to be set to an incorrect value,
resulting in these MSDUs being dropped by ieee80211.

ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1

Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
of 0 to be resolved.

Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>
Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
---
Changes in v4:
- Prefix subsystem with 'wifi:'.
- Added the 'Tested-by' and 'Fixes' trailers.
- Link to v3: https://patch.msgid.link/20260417-ath11k-null-peerid-workaround-v3-1-d04302284486 at collabora.com

Changes in v3:
- Clarified that the mpdu_start header isn't populated by the h/w for
  all sub-MSDUs in the commit message.
- Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
- Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16 at collabora.com

Changes in v2:

- Since peer_id=0 is a valid condition on some chips, remove the guard
  that prevented the peer lookup.
- Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com

To: Jeff Johnson <jjohnson at kernel.org>
Cc: linux-wireless at vger.kernel.org
Cc: ath11k at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/wireless/ath/ath11k/dp_rx.c  | 3 +--
 drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 49d959b2e148..ff2c78a4e5f3 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
 
 	lockdep_assert_held(&ab->base_lock);
 
-	if (rxcb->peer_id)
-		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
+	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
 
 	if (peer)
 		return peer;
diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
index 753bd93f0212..51e0840bc0d1 100644
--- a/drivers/net/wireless/ath/ath11k/hal_rx.c
+++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
@@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
 	case HAL_RX_MPDU_START: {
 		struct hal_rx_mpdu_info *mpdu_info =
 				(struct hal_rx_mpdu_info *)tlv_data;
-		u16 peer_id;
 
-		peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
-		if (peer_id)
-			ppdu_info->peer_id = peer_id;
+		ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
 		break;
 	}
 	case HAL_RXPCU_PPDU_END_INFO: {

---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1

Best regards,
--  
Matt



From mpearson-lenovo at squebb.ca  Fri Apr 24 07:14:21 2026
From: mpearson-lenovo at squebb.ca (Mark Pearson)
Date: Fri, 24 Apr 2026 10:14:21 -0400
Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
In-Reply-To: <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
References: <20260423211458.458911-1-santiagorr@riseup.net>
 <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <c3e0eff6-afa6-4054-9a37-fa3943442657@app.fastmail.com>


On Thu, Apr 23, 2026, at 10:07 PM, Kyle Farnung wrote:
>> 
>> 
>> 
>> ________________________________________
>> From: Santiago Ruano Rinc?n <santiagorr at riseup.net>
>> Sent: Thursday, April 23, 2026 2:14 PM
>> To: Jeff Johnson; linux-wireless at vger.kernel.org; ath11k at lists.infradead.org; linux-kernel at vger.kernel.org
>> Cc: Mark Pearson; kfarnung at outlook.com; koike at igalia.com
>> Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
>> 
>> Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
>> table") added some Lenovo platform IDs to the quirk table to address a
>> wakeup from suspend issue [1].  However, at least two more platform ID
>> are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
>> and P14s Gen 3 AMD.  This commit adds one ID for each.
>> 
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
>> [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
>> 
>> Tested-on: P14s G3 AMD.
>
> Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
> well. I submitted a patch myself [5], but I've been investigating another
> symptom.
>

Thanks - you beat me to it.
Confirmed that you'll want to add those two.

Mark


From santiagorr at riseup.net  Fri Apr 24 08:10:17 2026
From: santiagorr at riseup.net (Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?=)
Date: Fri, 24 Apr 2026 12:10:17 -0300
Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk
 table
In-Reply-To: <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
References: <20260423211458.458911-1-santiagorr@riseup.net>
 <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <aeuH2chCSi57RYVU@voleno>

El 24/04/26 a las 02:07, Kyle Farnung escribi?:
> > From: Santiago Ruano Rinc?n <santiagorr at riseup.net>
> > Sent: Thursday, April 23, 2026 2:14 PM
> > To: Jeff Johnson; linux-wireless at vger.kernel.org; ath11k at lists.infradead.org; linux-kernel at vger.kernel.org
> > Cc: Mark Pearson; kfarnung at outlook.com; koike at igalia.com
> > Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
> > 
> > Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
> > table") added some Lenovo platform IDs to the quirk table to address a
> > wakeup from suspend issue [1].  However, at least two more platform ID
> > are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
> > and P14s Gen 3 AMD.  This commit adds one ID for each.
> > 
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> > [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
> > 
> > Tested-on: P14s G3 AMD.
> 
> Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
> well. I submitted a patch myself [5], but I've been investigating another
> symptom.

Thanks for the notice. I will adapt my patch to remove the conflict with yours.

> 
> I have the same "wake on power removed" issue, but I have another issue
> that's more annoying where the wifi just dies randomly. I only have the
> wake issue when power is disconnected, not when power is connected again.
> I mostly leave my device connected, so I only realized the behavior while
> doing the regression testing requested in the other patch.

I've also been hit by a similar annoying wifi randomly dying issue that
you describe [deb#1132343].  With the patch that I attached applied to
7.0.0, my P14s G3 AMD laptop has been running for more that 3 days, with
several suspends / weak ups, either with power connected or
disconnected.  And I haven't encountered that problem since it booted so
I concluded that the patch fixed it.  But chances are that I am wrong.

[deb#1132343] https://bugs.debian.org/1132343

The latest bad version I tested where the wifi died was 6.9.11.  I plan
test the patch on top of it.

> 
> [3] https://pcsupport.lenovo.com/jm/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-3-type-21j5-21j6/21j5
> [4] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/21me/21me000pge
> [5] https://lore.kernel.org/all/ba4d194b-6d31-4d8a-a6a6-da116f9f56ac at oss.qualcomm.com/

[snip]


From kfarnung at gmail.com  Sun Apr 26 10:44:43 2026
From: kfarnung at gmail.com (Kyle Farnung)
Date: Sun, 26 Apr 2026 10:44:43 -0700
Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
In-Reply-To: <aeuH2chCSi57RYVU@voleno>
References: <20260423211458.458911-1-santiagorr@riseup.net>
 <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
 <aeuH2chCSi57RYVU@voleno>
Message-ID: <CAOPSVF3=BmOUw5+nnk-EYnpP_ff7wXsFAaz6sHbw-brLy-HojA@mail.gmail.com>

On Fri, Apr 24, 2026 at 8:10?AM Santiago Ruano Rinc?n
<santiagorr at riseup.net> wrote:
>
> El 24/04/26 a las 02:07, Kyle Farnung escribi?:
> > > From: Santiago Ruano Rinc?n <santiagorr at riseup.net>
> > > Sent: Thursday, April 23, 2026 2:14 PM
> > > To: Jeff Johnson; linux-wireless at vger.kernel.org; ath11k at lists.infradead.org; linux-kernel at vger.kernel.org
> > > Cc: Mark Pearson; kfarnung at outlook.com; koike at igalia.com
> > > Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
> > >
> > > Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
> > > table") added some Lenovo platform IDs to the quirk table to address a
> > > wakeup from suspend issue [1].  However, at least two more platform ID
> > > are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
> > > and P14s Gen 3 AMD.  This commit adds one ID for each.
> > >
> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> > > [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
> > >
> > > Tested-on: P14s G3 AMD.
> >
> > Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
> > well. I submitted a patch myself [5], but I've been investigating another
> > symptom.
>
> Thanks for the notice. I will adapt my patch to remove the conflict with yours.

Feel free to just merge yours and I'll withdraw mine. I'm regression
testing the WiFi disconnect issue I'm encountering, so I'll just focus on
that. In the meantime this seems righteous.

>
> >
> > I have the same "wake on power removed" issue, but I have another issue
> > that's more annoying where the wifi just dies randomly. I only have the
> > wake issue when power is disconnected, not when power is connected again.
> > I mostly leave my device connected, so I only realized the behavior while
> > doing the regression testing requested in the other patch.
>
> I've also been hit by a similar annoying wifi randomly dying issue that
> you describe [deb#1132343].  With the patch that I attached applied to
> 7.0.0, my P14s G3 AMD laptop has been running for more that 3 days, with
> several suspends / weak ups, either with power connected or
> disconnected.  And I haven't encountered that problem since it booted so
> I concluded that the patch fixed it.  But chances are that I am wrong.
>
> [deb#1132343] https://bugs.debian.org/1132343
>
> The latest bad version I tested where the wifi died was 6.9.11.  I plan
> test the patch on top of it.

6.9 or 6.19? My issue started between 6.16.10 and 6.17.4.

>
> >
> > [3] https://pcsupport.lenovo.com/jm/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-3-type-21j5-21j6/21j5
> > [4] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/21me/21me000pge
> > [5] https://lore.kernel.org/all/ba4d194b-6d31-4d8a-a6a6-da116f9f56ac at oss.qualcomm.com/
>
> [snip]


From krzysztof.kozlowski at oss.qualcomm.com  Mon Apr 27 00:00:41 2026
From: krzysztof.kozlowski at oss.qualcomm.com (Krzysztof Kozlowski)
Date: Mon, 27 Apr 2026 09:00:41 +0200
Subject: [PATCH] wifi: ath: Unify user-visible "Qualcomm" name
Message-ID: <20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com>

Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies.  Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>

---

And "Qualcomm Technologies" has even variations over the tree:
Qualcomm Technologies
Qualcomm Technologies Inc.
Qualcomm Technologies, Inc.

I am doing this tree wide:
https://lore.kernel.org/all/?q=f%3Akrzysztof+s%3A%22Unify+user-visible%22+s%3AQualcomm
---
 drivers/net/wireless/ath/ath11k/Kconfig | 2 +-
 drivers/net/wireless/ath/ath12k/Kconfig | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/Kconfig b/drivers/net/wireless/ath/ath11k/Kconfig
index 385513cfdc30..122726f84492 100644
--- a/drivers/net/wireless/ath/ath11k/Kconfig
+++ b/drivers/net/wireless/ath/ath11k/Kconfig
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: BSD-3-Clause-Clear
 config ATH11K
-	tristate "Qualcomm Technologies 802.11ax chipset support"
+	tristate "Qualcomm 802.11ax chipset support"
 	depends on MAC80211 && HAS_DMA
 	select ATH_COMMON
 	select QCOM_QMI_HELPERS
diff --git a/drivers/net/wireless/ath/ath12k/Kconfig b/drivers/net/wireless/ath/ath12k/Kconfig
index d39c075758bd..4a2b240f967a 100644
--- a/drivers/net/wireless/ath/ath12k/Kconfig
+++ b/drivers/net/wireless/ath/ath12k/Kconfig
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: BSD-3-Clause-Clear
 config ATH12K
-	tristate "Qualcomm Technologies Wi-Fi 7 support (ath12k)"
+	tristate "Qualcomm Wi-Fi 7 support (ath12k)"
 	depends on MAC80211 && HAS_DMA && PCI
 	select QCOM_QMI_HELPERS
 	select MHI_BUS
@@ -15,7 +15,7 @@ config ATH12K
 	  If you choose to build a module, it'll be called ath12k.
 
 config ATH12K_AHB
-	bool "QTI ath12k AHB support"
+	bool "Qualcomm ath12k AHB support"
 	depends on ATH12K && REMOTEPROC
 	select QCOM_MDT_LOADER
 	select QCOM_SCM
@@ -33,7 +33,7 @@ config ATH12K_DEBUG
 	  you want optimal performance choose N.
 
 config ATH12K_DEBUGFS
-	bool "QTI ath12k debugfs support"
+	bool "Qualcomm ath12k debugfs support"
 	depends on ATH12K && MAC80211_DEBUGFS
 	help
 	  Enable ath12k debugfs support
-- 
2.51.0



From jeff.johnson at oss.qualcomm.com  Mon Apr 27 07:01:42 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Mon, 27 Apr 2026 07:01:42 -0700
Subject: pull-request: ath-current-20260427
Message-ID: <411dfb79-9449-4c7c-af0e-d9d1dc81f3c6@oss.qualcomm.com>

The following changes since commit 1f5ffc672165ff851063a5fd044b727ab2517ae3:

  Fix mismerge of the arm64 / timer-core interrupt handling changes (2026-04-14 23:03:02 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-current-20260427

for you to fetch changes up to 4498664e2d5888efabb96428196a926acdaa25ed:

  wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions (2026-04-23 10:57:50 -0700)

----------------------------------------------------------------
ath.git update for v7.1-rc2

Fix an ath10k build dependency issue along with a few ath12k bugs.

----------------------------------------------------------------
Aaradhana Sahu (1):
      wifi: ath12k: fix OF node refcount imbalance in WSI graph traversal

Baochen Qiang (1):
      wifi: ath12k: prepare REO update element only for primary link

Dmitry Baryshkov (1):
      wifi: ath10k: snoc: select POWER_SEQUENCING

Yu-Hsiang Tseng (1):
      wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions

 drivers/net/wireless/ath/ath10k/Kconfig |  1 +
 drivers/net/wireless/ath/ath12k/core.c  | 77 ++++++++++++++++++++-------------
 drivers/net/wireless/ath/ath12k/dp_rx.c |  3 ++
 drivers/net/wireless/ath/ath12k/mac.c   |  2 +-
 drivers/net/wireless/ath/ath12k/p2p.c   |  2 +-
 5 files changed, 54 insertions(+), 31 deletions(-)


From jeff.johnson at oss.qualcomm.com  Mon Apr 27 07:11:43 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Mon, 27 Apr 2026 07:11:43 -0700
Subject: pull-request: ath-next-20260427
Message-ID: <b1071639-e724-45f4-a1f0-51706acb7ccf@oss.qualcomm.com>

The following changes since commit 929298742bb5dfacd53ea99cf989cc81210f90a3:

  Merge tag 'ath-next-20260408' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath (2026-04-08 23:26:19 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260427

for you to fetch changes up to 34a5329beee86a22a446e27eb37f06caa63479ca:

  wifi: ath9k: Obtain system GPIOS from descriptors (2026-04-22 06:57:12 -0700)

----------------------------------------------------------------
ath.git patches for v7.2 (PR #1)

For ath9k:
- improve the GPIO interface.

For ath12k:
- replace dynamic memory allocation in WMI rx path
- avoid buffer overread when configuring IRQs
- code housekeeping

----------------------------------------------------------------
Aaradhana Sahu (1):
      wifi: ath12k: Fix invalid IRQ requests during AHB probe

Jeff Johnson (3):
      wifi: ath12k: Fix HTC prototype ath12k_base parameters
      wifi: ath12k: Fix ath12k_dp_htt_tlv_iter()'s iter() signature
      wifi: ath12k: Remove macro HAL_RX_EHT_SIG_OFDMA_EB2_MCS

Linus Walleij (1):
      wifi: ath9k: Obtain system GPIOS from descriptors

Nicolas Escande (1):
      wifi: ath12k: avoid dynamic alloc when parsing wmi tb

 drivers/gpio/gpio-ath79.c                      |  57 ++++++-
 drivers/net/wireless/ath/ath12k/ahb.c          |  25 +--
 drivers/net/wireless/ath/ath12k/core.c         |   6 +
 drivers/net/wireless/ath/ath12k/dp_htt.c       |   2 +-
 drivers/net/wireless/ath/ath12k/dp_htt.h       |   2 +-
 drivers/net/wireless/ath/ath12k/htc.h          |   8 +-
 drivers/net/wireless/ath/ath12k/wifi7/hal_rx.h |   1 -
 drivers/net/wireless/ath/ath12k/wmi.c          | 217 +++++++++----------------
 drivers/net/wireless/ath/ath12k/wmi.h          |   3 +
 drivers/net/wireless/ath/ath9k/hw.c            |  33 ++--
 drivers/net/wireless/ath/ath9k/hw.h            |   3 +-
 11 files changed, 188 insertions(+), 169 deletions(-)


From jeff.johnson at oss.qualcomm.com  Mon Apr 27 07:53:28 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Mon, 27 Apr 2026 07:53:28 -0700
Subject: Multiple radios/single phy - should the wiphy struct radios[] be
 set?
In-Reply-To: <CALgbQMzF65j7n+R6MEftB-uSgmxtcH4dq7tSt4Os_jnwrZirVw@mail.gmail.com>
References: <CALgbQMzF65j7n+R6MEftB-uSgmxtcH4dq7tSt4Os_jnwrZirVw@mail.gmail.com>
Message-ID: <f77ebaf4-820c-4527-b2ba-8325735b2340@oss.qualcomm.com>

On 4/21/2026 6:35 AM, Adam Hill wrote:
> I've been trying to get a WCN6856 card working as an AP on OpenWrt (
> but using a custom kernel and build ) and was hitting a brick wall
> getting DBDC to work. I was starting from almost zero knowledge of
> Linux WiFi in general which made it harder ( and means I might be
> barking up the wrong tree ) - however, it seems that OpenWrt ( at
> least ) relies on netlink returning a radio array to detect devices
> that have multiple radios on a single phy, which doesn't seem
> unreasonable to me.
> 
> I've hacked my OpenWrt build to assume that num_channels = 2 on a
> second interface combination is the same thing ( which is what ath11k
> seems to do when support_dual_stations is true) and confirmed that the
> DBDC setup works with this mod. Shouldn't the ath11k driver be changed
> to populate the radio list the same way ath12k does? What I've done
> with OpenWrt is a bit of a hack, and who knows what else relies on
> radios being defined!

The radio array exists to support Wi-Fi 7 Multi-link operation, and since
ath11k doesn't support Wi-Fi 7, it should not populate the radio array.

Also note the WCN series of devices are tailored for mobile station usage, and
the firmware and driver are designed to model the hardware as a single
multi-band radio that is capable of concurrent operation on multiple channels.

If you want to work with OpenWrt then I suggest working with a chipset already
supported by it such as QCN9074.

I'll let Baochen add any additional observations.

/jeff


From sidepipeuk at gmail.com  Mon Apr 27 09:12:42 2026
From: sidepipeuk at gmail.com (Adam Hill)
Date: Mon, 27 Apr 2026 17:12:42 +0100
Subject: Multiple radios/single phy - should the wiphy struct radios[] be set?
In-Reply-To: <CALgbQMwLkbyF0rOtvPYWu=tgUffWGHUyGgn=jMbV3W7SggfyrQ@mail.gmail.com>
References: <CALgbQMzF65j7n+R6MEftB-uSgmxtcH4dq7tSt4Os_jnwrZirVw@mail.gmail.com>
 <f77ebaf4-820c-4527-b2ba-8325735b2340@oss.qualcomm.com> <CALgbQMwLkbyF0rOtvPYWu=tgUffWGHUyGgn=jMbV3W7SggfyrQ@mail.gmail.com>
Message-ID: <CALgbQMwJ1V36SX4H2a7TQYn+_VbU4jO6qZr17bCDp6aj3tWDmQ@mail.gmail.com>

Thanks for the reply, Jeff. As it happens, I AM building a mobile
access point, but that's not really relevant. My assertion was simply
that since the WCN6856 et al do indeed have two radios ( they must, to
allow them to transmit on two frequencies simultaneously? ) but
presented on a single phy, then maybe they should populate the radios
array accordingly. However, if you're saying that the ONLY reason for
that array is WiFi 7 multilink then that's fine, I'll continue to use
the fact that num_channels is 2 on one of the presented combinations
to detect the additional radio - I now have my build supporting the
two radios of the WCN6856 and happily running an AP on two bands
simultaneously - it just seemed sensible to me that if there were two
radios then they should be presented in some sensible/consistent way
across devices and the radios array was it - but if you disagree then
that's fine... you know an order of magnitude more about this stuff
than I do!

As for the QCN9074, my requirement was for a DBDC capable AP card in
M2 E Key 2230 format - I'm not sure that chip suits the requirement?


On Mon, 27 Apr 2026 at 17:11, Adam Hill <sidepipeuk at gmail.com> wrote:
>
> Thanks for the reply, Jeff. As it happens, I AM building a mobile access point, but that's not really relevant. My assertion was simply that since the WCN6856 et al do indeed have two radios ( they must, to allow them to transmit on two frequencies simultaneously? ) but presented on a single phy, then maybe they should populate the radios array accordingly. However, if you're saying that the ONLY reason for that array is WiFi 7 multilink then that's fine, I'll continue to use the fact that num_channels is 2 on one of the presented combinations to detect the additional radio - I now have my build supporting the two radios of the WCN6856 and happily running an AP on two bands simultaneously - it just seemed sensible to me that if there were two radios then they should be presented in some sensible/consistent way across devices and the radios array was it - but if you disagree then that's fine... you know an order of magnitude more about this stuff than I do!
>
> As for the QCN9074, my requirement was for a DBDC capable AP card in M2 E Key 2230 format - I'm not sure that chip suits the requirement?
>
>
> On Mon, 27 Apr 2026 at 15:53, Jeff Johnson <jeff.johnson at oss.qualcomm.com> wrote:
>>
>> On 4/21/2026 6:35 AM, Adam Hill wrote:
>> > I've been trying to get a WCN6856 card working as an AP on OpenWrt (
>> > but using a custom kernel and build ) and was hitting a brick wall
>> > getting DBDC to work. I was starting from almost zero knowledge of
>> > Linux WiFi in general which made it harder ( and means I might be
>> > barking up the wrong tree ) - however, it seems that OpenWrt ( at
>> > least ) relies on netlink returning a radio array to detect devices
>> > that have multiple radios on a single phy, which doesn't seem
>> > unreasonable to me.
>> >
>> > I've hacked my OpenWrt build to assume that num_channels = 2 on a
>> > second interface combination is the same thing ( which is what ath11k
>> > seems to do when support_dual_stations is true) and confirmed that the
>> > DBDC setup works with this mod. Shouldn't the ath11k driver be changed
>> > to populate the radio list the same way ath12k does? What I've done
>> > with OpenWrt is a bit of a hack, and who knows what else relies on
>> > radios being defined!
>>
>> The radio array exists to support Wi-Fi 7 Multi-link operation, and since
>> ath11k doesn't support Wi-Fi 7, it should not populate the radio array.
>>
>> Also note the WCN series of devices are tailored for mobile station usage, and
>> the firmware and driver are designed to model the hardware as a single
>> multi-band radio that is capable of concurrent operation on multiple channels.
>>
>> If you want to work with OpenWrt then I suggest working with a chipset already
>> supported by it such as QCN9074.
>>
>> I'll let Baochen add any additional observations.
>>
>> /jeff


From baochen.qiang at oss.qualcomm.com  Mon Apr 27 19:05:45 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Tue, 28 Apr 2026 10:05:45 +0800
Subject: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI
 shutdown
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
References: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
Message-ID: <6826ce13-ed2f-42a2-8b46-1357b4a9b4ee@oss.qualcomm.com>



On 4/4/2026 12:30 PM, Wei Zhang wrote:
> A reboot can crash the kernel if it overlaps with WLAN firmware crash
> recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
> path while freeing DMA-backed MHI contexts.
> 
> Simplified trace:
>   dma_free_attrs
>   mhi_deinit_dev_ctxt [mhi]
>   ath11k_pci_power_down [ath11k_pci]
>   ath11k_pci_shutdown [ath11k_pci]
>   device_shutdown
>   kernel_restart
> 
> On the host side, SSR is driven by the MHI RDDM callback, which queues
> reset_work to perform device recovery. reset_work power-cycles the device
> by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The
> power-down phase deinitializes MHI and frees DMA resources.
> 
> Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR
> recovery flow. As a result, the shutdown path
> (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR
> recovery sequence.
> 
> Fix this by canceling SSR-related work items during PCI shutdown, marking
> the device as unregistering, and serializing the RDDM callback path that
> checks and queues reset_work. This ensures that no new SSR recovery work
> can be queued once teardown has started, and that any in-flight recovery
> work is fully synchronized before device power-down, preventing MHI
> teardown and DMA resource freeing from running more than once.
> 
> Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k
> devices do not queue reset_work in normal SSR flows.
> 
> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
> 
> Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855")
> Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support")
> Signed-off-by: Wei Zhang <wei.zhang at oss.qualcomm.com>

Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>



From baochen.qiang at oss.qualcomm.com  Mon Apr 27 19:28:41 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Tue, 28 Apr 2026 10:28:41 +0800
Subject: [PATCH] wifi: ath11k: fix warning when unbinding
In-Reply-To: <20260420110130.509670-1-jtornosm@redhat.com>
References: <20260420110130.509670-1-jtornosm@redhat.com>
Message-ID: <c0d2b6df-4109-4c93-b229-7eb2d3fca6a7@oss.qualcomm.com>



On 4/20/2026 7:01 PM, Jose Ignacio Tornos Martinez wrote:
> If there is an error during some initialization related to firmware,
> the buffers dp->tx_ring[i].tx_status are released.
> However this is released again when the device is unbinded (ath11k_pci),
> and we get:
> WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
> Call Trace:
> free_large_kmalloc
> ath11k_dp_free
> ath11k_core_deinit
> ath11k_pci_remove
> ...
> 
> The issue is always reproducible from a VM because the MSI addressing
> initialization is failing.

MSI initialization runs at probe time but I don't see an error path doing
dp->tx_ring[i].tx_status release. So can you help elaborate? what is the call path when
the dp->tx_ring[i].tx_status is first released?

> 
> In order to fix the issue, just set the buffers to NULL after releasing in
> order to avoid the double free.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Cc: stable at vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm at redhat.com>
> ---
>  drivers/net/wireless/ath/ath11k/dp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
> index bbb86f165141..5a50b623bd07 100644
> --- a/drivers/net/wireless/ath/ath11k/dp.c
> +++ b/drivers/net/wireless/ath/ath11k/dp.c
> @@ -1040,6 +1040,7 @@ void ath11k_dp_free(struct ath11k_base *ab)
>  		idr_destroy(&dp->tx_ring[i].txbuf_idr);
>  		spin_unlock_bh(&dp->tx_ring[i].tx_idr_lock);
>  		kfree(dp->tx_ring[i].tx_status);
> +		dp->tx_ring[i].tx_status = NULL;
>  	}
>  
>  	/* Deinit any SOC level resource */



From baochen.qiang at oss.qualcomm.com  Mon Apr 27 19:37:17 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Tue, 28 Apr 2026 10:37:17 +0800
Subject: [PATCHv2 ath-next] wifi: ath11k: use kzalloc_flex
In-Reply-To: <20260421231205.77361-1-rosenp@gmail.com>
References: <20260421231205.77361-1-rosenp@gmail.com>
Message-ID: <263f598b-93e8-483e-95b6-3ba9b19ee8f9@oss.qualcomm.com>



On 4/22/2026 7:12 AM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
> 
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
> 
> Signed-off-by: Rosen Penev <rosenp at gmail.com>

Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>



From rameshkumar.sundaram at oss.qualcomm.com  Tue Apr 28 00:19:14 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Tue, 28 Apr 2026 12:49:14 +0530
Subject: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI
 shutdown
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
References: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
Message-ID: <7d59bfa4-ea59-4527-ab5b-1e2350d08de7@oss.qualcomm.com>

On 4/4/2026 10:00 AM, Wei Zhang wrote:
> A reboot can crash the kernel if it overlaps with WLAN firmware crash
> recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
> path while freeing DMA-backed MHI contexts.
> 
> Simplified trace:
>    dma_free_attrs
>    mhi_deinit_dev_ctxt [mhi]
>    ath11k_pci_power_down [ath11k_pci]
>    ath11k_pci_shutdown [ath11k_pci]
>    device_shutdown
>    kernel_restart
> 
> On the host side, SSR is driven by the MHI RDDM callback, which queues
> reset_work to perform device recovery. reset_work power-cycles the device
> by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The
> power-down phase deinitializes MHI and frees DMA resources.
> 
> Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR
> recovery flow. As a result, the shutdown path
> (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR
> recovery sequence.
> 
> Fix this by canceling SSR-related work items during PCI shutdown, marking
> the device as unregistering, and serializing the RDDM callback path that
> checks and queues reset_work. This ensures that no new SSR recovery work
> can be queued once teardown has started, and that any in-flight recovery
> work is fully synchronized before device power-down, preventing MHI
> teardown and DMA resource freeing from running more than once.
> 
> Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k
> devices do not queue reset_work in normal SSR flows.
> 
> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
> 
> Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855")
> Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support")
> Signed-off-by: Wei Zhang <wei.zhang at oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram at oss.qualcomm.com>


From rameshkumar.sundaram at oss.qualcomm.com  Tue Apr 28 02:50:34 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Tue, 28 Apr 2026 15:20:34 +0530
Subject: [PATCHv2 ath-next] wifi: ath11k: use kzalloc_flex
In-Reply-To: <20260421231205.77361-1-rosenp@gmail.com>
References: <20260421231205.77361-1-rosenp@gmail.com>
Message-ID: <582155ff-1cac-4d88-a6b2-006146ba4e67@oss.qualcomm.com>

On 4/22/2026 4:42 AM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
> 
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
> 
> Signed-off-by: Rosen Penev <rosenp at gmail.com>
> ---
>   v2: reword counting variable comment.
>   drivers/net/wireless/ath/ath11k/mac.c | 71 ++++++++++-----------------
>   drivers/net/wireless/ath/ath11k/wmi.h |  2 +-
>   2 files changed, 28 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index 4a68bb9ca4fa..b5f3d7221b5f 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -4228,13 +4228,14 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
>   	if (ret)
>   		goto exit;
> 
> -	arg = kzalloc_obj(*arg);
> +	arg = kzalloc_flex(*arg, chan_list, req->n_channels);
> 
>   	if (!arg) {
>   		ret = -ENOMEM;
>   		goto exit;
>   	}
> 
> +	arg->num_chan = req->n_channels;
>   	ath11k_wmi_start_scan_init(ar, arg);
>   	arg->vdev_id = arvif->vdev_id;
>   	arg->scan_id = ATH11K_SCAN_ID;
> @@ -4262,38 +4263,27 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
>   		arg->scan_f_passive = 1;
>   	}
> 
> -	if (req->n_channels) {
> -		arg->num_chan = req->n_channels;
> -		arg->chan_list = kcalloc(arg->num_chan, sizeof(*arg->chan_list),
> -					 GFP_KERNEL);
> +	for (i = 0; i < arg->num_chan; i++) {
> +		if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
> +			     ar->ab->wmi_ab.svc_map)) {
> +			arg->chan_list[i] =
> +				u32_encode_bits(req->channels[i]->center_freq,
> +						WMI_SCAN_CONFIG_PER_CHANNEL_MASK);
> 
> -		if (!arg->chan_list) {
> -			ret = -ENOMEM;
> -			goto exit;
> -		}
> -
> -		for (i = 0; i < arg->num_chan; i++) {
> -			if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
> -				     ar->ab->wmi_ab.svc_map)) {
> -				arg->chan_list[i] =
> -					u32_encode_bits(req->channels[i]->center_freq,
> -							WMI_SCAN_CONFIG_PER_CHANNEL_MASK);
> -
> -				/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
> -				 * flags, then scan all PSC channels in 6 GHz band and
> -				 * those non-PSC channels where RNR IE is found during
> -				 * the legacy 2.4/5 GHz scan.
> -				 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
> -				 * then all channels in 6 GHz will be scanned.
> -				 */
> -				if (req->channels[i]->band == NL80211_BAND_6GHZ &&
> -				    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
> -				    !cfg80211_channel_is_psc(req->channels[i]))
> -					arg->chan_list[i] |=
> -						WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
> -			} else {
> -				arg->chan_list[i] = req->channels[i]->center_freq;
> -			}
> +			/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
> +			 * flags, then scan all PSC channels in 6 GHz band and
> +			 * those non-PSC channels where RNR IE is found during
> +			 * the legacy 2.4/5 GHz scan.
> +			 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
> +			 * then all channels in 6 GHz will be scanned.
> +			 */
> +			if (req->channels[i]->band == NL80211_BAND_6GHZ &&
> +			    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
> +			    !cfg80211_channel_is_psc(req->channels[i]))
> +				arg->chan_list[i] |=
> +					WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
> +		} else {
> +			arg->chan_list[i] = req->channels[i]->center_freq;
>   		}
>   	}
> 


the exit: label at the end of the function has kfree(arg->chan_list); 
which now must be removed.



--
Ramesh


From jeff.johnson at oss.qualcomm.com  Tue Apr 28 09:39:51 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Tue, 28 Apr 2026 09:39:51 -0700
Subject: [PATCH v2 2/4] wifi: ath: Use the unified QMI service ID instead
 of defining it locally
In-Reply-To: <51e28a7f-8362-4bf1-9b9a-9af9cda1d748@oss.qualcomm.com>
References: <20260316171419.2619620-1-daniel.lezcano@oss.qualcomm.com>
 <20260316171419.2619620-3-daniel.lezcano@oss.qualcomm.com>
 <51e28a7f-8362-4bf1-9b9a-9af9cda1d748@oss.qualcomm.com>
Message-ID: <e8c37614-354f-40d3-be3c-983f45e5bb3f@oss.qualcomm.com>

On 3/19/2026 7:26 AM, Jeff Johnson wrote:
> On 3/16/2026 10:14 AM, Daniel Lezcano wrote:
>> Instead of defining a local macro with a custom name for the QMI
>> service identifier, use the one provided in qmi.h and remove the
>> locally defined macro.
>>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at oss.qualcomm.com>
> 
> Bjorn,
> Feel free to take this through your tree since I don't think it will conflict
> with anything in mine and it will take time for the definition to propagate
> back to my tree via the normal workflow (which I would prefer over merging the
> immutable branch).
> 
> Acked-by: Jeff Johnson <jeff.johnson at oss.qualcomm.com>

Now NAK...

The definitions have now propagated back to my tree, so I'll now take this
patch through my tree.

/jeff


From elder at ieee.org  Tue Apr 28 09:47:26 2026
From: elder at ieee.org (Alex Elder)
Date: Tue, 28 Apr 2026 11:47:26 -0500
Subject: [PATCH v2 1/4] net: ipa: Use the unified QMI service ID instead
 of defining it locally
In-Reply-To: <20260316171419.2619620-2-daniel.lezcano@oss.qualcomm.com>
References: <20260316171419.2619620-1-daniel.lezcano@oss.qualcomm.com>
 <20260316171419.2619620-2-daniel.lezcano@oss.qualcomm.com>
Message-ID: <bf380b65-1513-4792-9e3c-d03bff17c141@ieee.org>

On 3/16/26 12:14 PM, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at oss.qualcomm.com>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at oss.qualcomm.com>

Looks good!

Reviewed-by: Alex Elder <elder at riscstar.com>

> ---
>   drivers/net/ipa/ipa_qmi.c | 6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
> index d771f3a71f94..37936ad132a2 100644
> --- a/drivers/net/ipa/ipa_qmi.c
> +++ b/drivers/net/ipa/ipa_qmi.c
> @@ -66,11 +66,9 @@
>    *   determination of when things are "ready"
>    */
>   
> -#define IPA_HOST_SERVICE_SVC_ID		0x31
>   #define IPA_HOST_SVC_VERS		1
>   #define IPA_HOST_SERVICE_INS_ID		1
>   
> -#define IPA_MODEM_SERVICE_SVC_ID	0x31
>   #define IPA_MODEM_SERVICE_INS_ID	2
>   #define IPA_MODEM_SVC_VERS		1
>   
> @@ -484,7 +482,7 @@ int ipa_qmi_setup(struct ipa *ipa)
>   	if (ret)
>   		return ret;
>   
> -	ret = qmi_add_server(&ipa_qmi->server_handle, IPA_HOST_SERVICE_SVC_ID,
> +	ret = qmi_add_server(&ipa_qmi->server_handle, QMI_SERVICE_ID_IPA,
>   			     IPA_HOST_SVC_VERS, IPA_HOST_SERVICE_INS_ID);
>   	if (ret)
>   		goto err_server_handle_release;
> @@ -501,7 +499,7 @@ int ipa_qmi_setup(struct ipa *ipa)
>   	/* We need this ready before the service lookup is added */
>   	INIT_WORK(&ipa_qmi->init_driver_work, ipa_client_init_driver_work);
>   
> -	ret = qmi_add_lookup(&ipa_qmi->client_handle, IPA_MODEM_SERVICE_SVC_ID,
> +	ret = qmi_add_lookup(&ipa_qmi->client_handle, QMI_SERVICE_ID_IPA,
>   			     IPA_MODEM_SVC_VERS, IPA_MODEM_SERVICE_INS_ID);
>   	if (ret)
>   		goto err_client_handle_release;



From rosenp at gmail.com  Tue Apr 28 13:50:17 2026
From: rosenp at gmail.com (Rosen Penev)
Date: Tue, 28 Apr 2026 13:50:17 -0700
Subject: [PATCHv3 ath-next] wifi: ath11k: use kzalloc_flex
Message-ID: <20260428205017.26288-1-rosenp@gmail.com>

Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.

Add __counted_by to get extra runtime analysis. Move counting variable
assignment immediately after allocation before any potential accesses.
kzalloc_flex does this anyway for GCC >= 15.

Signed-off-by: Rosen Penev <rosenp at gmail.com>
---
 v3: remove one more kfree for chan_list.
 v2: reword counting variable comment.
 drivers/net/wireless/ath/ath11k/mac.c | 72 ++++++++++-----------------
 drivers/net/wireless/ath/ath11k/wmi.h |  2 +-
 2 files changed, 28 insertions(+), 46 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 4a68bb9ca4fa..8d9e1e33e47d 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -4228,13 +4228,14 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 	if (ret)
 		goto exit;
 
-	arg = kzalloc_obj(*arg);
+	arg = kzalloc_flex(*arg, chan_list, req->n_channels);
 
 	if (!arg) {
 		ret = -ENOMEM;
 		goto exit;
 	}
 
+	arg->num_chan = req->n_channels;
 	ath11k_wmi_start_scan_init(ar, arg);
 	arg->vdev_id = arvif->vdev_id;
 	arg->scan_id = ATH11K_SCAN_ID;
@@ -4262,38 +4263,27 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 		arg->scan_f_passive = 1;
 	}
 
-	if (req->n_channels) {
-		arg->num_chan = req->n_channels;
-		arg->chan_list = kcalloc(arg->num_chan, sizeof(*arg->chan_list),
-					 GFP_KERNEL);
+	for (i = 0; i < arg->num_chan; i++) {
+		if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
+			     ar->ab->wmi_ab.svc_map)) {
+			arg->chan_list[i] =
+				u32_encode_bits(req->channels[i]->center_freq,
+						WMI_SCAN_CONFIG_PER_CHANNEL_MASK);
 
-		if (!arg->chan_list) {
-			ret = -ENOMEM;
-			goto exit;
-		}
-
-		for (i = 0; i < arg->num_chan; i++) {
-			if (test_bit(WMI_TLV_SERVICE_SCAN_CONFIG_PER_CHANNEL,
-				     ar->ab->wmi_ab.svc_map)) {
-				arg->chan_list[i] =
-					u32_encode_bits(req->channels[i]->center_freq,
-							WMI_SCAN_CONFIG_PER_CHANNEL_MASK);
-
-				/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
-				 * flags, then scan all PSC channels in 6 GHz band and
-				 * those non-PSC channels where RNR IE is found during
-				 * the legacy 2.4/5 GHz scan.
-				 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
-				 * then all channels in 6 GHz will be scanned.
-				 */
-				if (req->channels[i]->band == NL80211_BAND_6GHZ &&
-				    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
-				    !cfg80211_channel_is_psc(req->channels[i]))
-					arg->chan_list[i] |=
-						WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
-			} else {
-				arg->chan_list[i] = req->channels[i]->center_freq;
-			}
+			/* If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set in scan
+			 * flags, then scan all PSC channels in 6 GHz band and
+			 * those non-PSC channels where RNR IE is found during
+			 * the legacy 2.4/5 GHz scan.
+			 * If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set,
+			 * then all channels in 6 GHz will be scanned.
+			 */
+			if (req->channels[i]->band == NL80211_BAND_6GHZ &&
+			    req->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ &&
+			    !cfg80211_channel_is_psc(req->channels[i]))
+				arg->chan_list[i] |=
+					WMI_SCAN_CH_FLAG_SCAN_ONLY_IF_RNR_FOUND;
+		} else {
+			arg->chan_list[i] = req->channels[i]->center_freq;
 		}
 	}
 
@@ -4336,7 +4326,6 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 
 exit:
 	if (arg) {
-		kfree(arg->chan_list);
 		kfree(arg->extraie.ptr);
 		kfree(arg);
 	}
@@ -9736,19 +9725,14 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 
 	scan_time_msec = ar->hw->wiphy->max_remain_on_channel_duration * 2;
 
-	arg = kzalloc_obj(*arg);
+	arg = kzalloc_flex(*arg, chan_list, 1);
 	if (!arg) {
 		ret = -ENOMEM;
 		goto exit;
 	}
-	ath11k_wmi_start_scan_init(ar, arg);
+
 	arg->num_chan = 1;
-	arg->chan_list = kcalloc(arg->num_chan, sizeof(*arg->chan_list),
-				 GFP_KERNEL);
-	if (!arg->chan_list) {
-		ret = -ENOMEM;
-		goto free_arg;
-	}
+	ath11k_wmi_start_scan_init(ar, arg);
 
 	arg->vdev_id = arvif->vdev_id;
 	arg->scan_id = ATH11K_SCAN_ID;
@@ -9769,7 +9753,7 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 		spin_lock_bh(&ar->data_lock);
 		ar->scan.state = ATH11K_SCAN_IDLE;
 		spin_unlock_bh(&ar->data_lock);
-		goto free_chan_list;
+		goto free_arg;
 	}
 
 	ret = wait_for_completion_timeout(&ar->scan.on_channel, 3 * HZ);
@@ -9779,7 +9763,7 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 		if (ret)
 			ath11k_warn(ar->ab, "failed to stop scan: %d\n", ret);
 		ret = -ETIMEDOUT;
-		goto free_chan_list;
+		goto free_arg;
 	}
 
 	ieee80211_queue_delayed_work(ar->hw, &ar->scan.timeout,
@@ -9787,8 +9771,6 @@ static int ath11k_mac_op_remain_on_channel(struct ieee80211_hw *hw,
 
 	ret = 0;
 
-free_chan_list:
-	kfree(arg->chan_list);
 free_arg:
 	kfree(arg);
 exit:
diff --git a/drivers/net/wireless/ath/ath11k/wmi.h b/drivers/net/wireless/ath/ath11k/wmi.h
index baed501b640b..b2dade0516ac 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.h
+++ b/drivers/net/wireless/ath/ath11k/wmi.h
@@ -3423,7 +3423,6 @@ struct scan_req_params {
 	u32 num_bssid;
 	u32 num_ssids;
 	u32 n_probes;
-	u32 *chan_list;
 	u32 notify_scan_events;
 	struct wlan_ssid ssid[WLAN_SCAN_PARAMS_MAX_SSID];
 	struct wmi_mac_addr bssid_list[WLAN_SCAN_PARAMS_MAX_BSSID];
@@ -3436,6 +3435,7 @@ struct scan_req_params {
 	struct hint_bssid hint_bssid[WLAN_SCAN_MAX_HINT_BSSID];
 	struct wmi_mac_addr mac_addr;
 	struct wmi_mac_addr mac_mask;
+	u32 chan_list[] __counted_by(num_chan);
 };
 
 struct wmi_ssid_arg {
-- 
2.54.0



From rameshkumar.sundaram at oss.qualcomm.com  Tue Apr 28 21:54:12 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Wed, 29 Apr 2026 10:24:12 +0530
Subject: [PATCHv3 ath-next] wifi: ath11k: use kzalloc_flex
In-Reply-To: <20260428205017.26288-1-rosenp@gmail.com>
References: <20260428205017.26288-1-rosenp@gmail.com>
Message-ID: <535dddaf-0275-4f16-b221-a593ff6f7611@oss.qualcomm.com>

On 4/29/2026 2:20 AM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
> 
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
> 
> Signed-off-by: Rosen Penev <rosenp at gmail.com>

Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram at oss.qualcomm.com>


From jtornosm at redhat.com  Tue Apr 28 22:14:03 2026
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Wed, 29 Apr 2026 07:14:03 +0200
Subject: [PATCH] wifi: ath11k: fix warning when unbinding
In-Reply-To: <c0d2b6df-4109-4c93-b229-7eb2d3fca6a7@oss.qualcomm.com>
References: <c0d2b6df-4109-4c93-b229-7eb2d3fca6a7@oss.qualcomm.com>
Message-ID: <20260429051414.6625-1-jtornosm@redhat.com>

Hello Baochen,

As I try to comment in the commit description, the warning is not at
the intialization, but comes up when the device is unbinded after a
problem at the initialization stage, because due to the problem the
buffers were released (probe). Later after the problem, if the unbinding
is commanded the buffers are released again.
Setting to NUll after releasing avoids the double free.

The easiest way to reproduce it is to run in a VM the default upstream
kernel (that is always failing on VMs) and just unbind the device
(ath11k_pci).

The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
("wifi: ath12k: fix warning when unbinding"), and I have seen the same problem
is also happening for ath11k driver.

Thanks

Best regards
Jos? Ignacio



From baochen.qiang at oss.qualcomm.com  Wed Apr 29 00:23:51 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Wed, 29 Apr 2026 15:23:51 +0800
Subject: [PATCH] wifi: ath11k: fix warning when unbinding
In-Reply-To: <20260429051414.6625-1-jtornosm@redhat.com>
References: <c0d2b6df-4109-4c93-b229-7eb2d3fca6a7@oss.qualcomm.com>
 <20260429051414.6625-1-jtornosm@redhat.com>
Message-ID: <0ae92497-91b7-4eb9-951a-dcd2258f538f@oss.qualcomm.com>



On 4/29/2026 1:14 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Baochen,
> 
> As I try to comment in the commit description, the warning is not at
> the intialization, but comes up when the device is unbinded after a
> problem at the initialization stage, because due to the problem the
> buffers were released (probe). Later after the problem, if the unbinding
> is commanded the buffers are released again.
> Setting to NUll after releasing avoids the double free.
> 

OK, seems the first release happens during the error handling path of
ath11k_core_qmi_firmware_ready().

> The easiest way to reproduce it is to run in a VM the default upstream
> kernel (that is always failing on VMs) and just unbind the device
> (ath11k_pci).
> 
> The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
> ("wifi: ath12k: fix warning when unbinding"), and I have seen the same problem
> is also happening for ath11k driver.
> 
> Thanks
> 
> Best regards
> Jos? Ignacio
> 



From baochen.qiang at oss.qualcomm.com  Wed Apr 29 00:36:24 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Wed, 29 Apr 2026 15:36:24 +0800
Subject: [PATCH v4] wifi: ath11k: fix peer resolution on rx path when
 peer_id=0
In-Reply-To: <20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com>
References: <20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com>
Message-ID: <530a9e0b-ae5e-48ae-a2c8-73152e2dd6df@oss.qualcomm.com>



On 4/24/2026 5:50 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of non-aggregated MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source MAC address. On an aggregated link, the mpdu_start
> header is only populated by hardware on the first sub-MSDU. This causes
> the peer resolution to be skipped for the subsequent MSDUs and the
> encryption type of these frames to be set to an incorrect value,
> resulting in these MSDUs being dropped by ieee80211.
> 
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
> 
> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
> of 0 to be resolved.
> 
> Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
> Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9

Tested-on: is not an official tag but is ath driver specific, so generally it is put above
all official tags:

Tested-on: ...
<blank line>
Fixes: ...
s-o-b: ...

But since this is trivial I think Jeff can make the change when he merges it, so no need
to respin just for it.

> Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>
> Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
> ---
> Changes in v4:
> - Prefix subsystem with 'wifi:'.
> - Added the 'Tested-by' and 'Fixes' trailers.
> - Link to v3: https://patch.msgid.link/20260417-ath11k-null-peerid-workaround-v3-1-d04302284486 at collabora.com
> 
> Changes in v3:
> - Clarified that the mpdu_start header isn't populated by the h/w for
>   all sub-MSDUs in the commit message.
> - Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
> - Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16 at collabora.com
> 
> Changes in v2:
> 
> - Since peer_id=0 is a valid condition on some chips, remove the guard
>   that prevented the peer lookup.
> - Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com
> 
> To: Jeff Johnson <jjohnson at kernel.org>
> Cc: linux-wireless at vger.kernel.org
> Cc: ath11k at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/wireless/ath/ath11k/dp_rx.c  | 3 +--
>  drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 49d959b2e148..ff2c78a4e5f3 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
>  
>  	lockdep_assert_held(&ab->base_lock);
>  
> -	if (rxcb->peer_id)
> -		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
> +	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>  
>  	if (peer)
>  		return peer;
> diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
> index 753bd93f0212..51e0840bc0d1 100644
> --- a/drivers/net/wireless/ath/ath11k/hal_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
> @@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
>  	case HAL_RX_MPDU_START: {
>  		struct hal_rx_mpdu_info *mpdu_info =
>  				(struct hal_rx_mpdu_info *)tlv_data;
> -		u16 peer_id;
>  
> -		peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
> -		if (peer_id)
> -			ppdu_info->peer_id = peer_id;
> +		ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
>  		break;
>  	}
>  	case HAL_RXPCU_PPDU_END_INFO: {
> 
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
> 
> Best regards,
> --  
> Matt
> 



From rameshkumar.sundaram at oss.qualcomm.com  Wed Apr 29 00:38:10 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Wed, 29 Apr 2026 13:08:10 +0530
Subject: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by
 using correct descriptor size
In-Reply-To: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
References: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
Message-ID: <525f1330-eed2-43ed-a274-ead57b928ae9@oss.qualcomm.com>

On 4/7/2026 8:18 AM, Joshua Klinesmith wrote:
> The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
> ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
> compute the packet buffer offset. This is the size of the union of all
> chip-specific descriptors (the maximum), not the actual descriptor size
> for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
> strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
> the front of the skb.
> 
> On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
> hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
> end of every monitor mode frame delivered to userspace. On WCN6855 the
> sizes happen to match so the bug is not visible.
> 
> The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
> fragment length calculation for multi-buffer MSDUs, under-counting
> intermediate fragments by 8 bytes and over-counting the last fragment.
> 
> Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
> monitor mpdu_pop functions and passing it through to set_frag_len.

It would be useful to add a Tested-on: tag if this was validated on
affected hardware, as suggested in the ath11k submission guidelines.

> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")

Since the full_mon side was added later by 7e2ea2e94704, it may be worth 
adding that as a second Fixes: tag for completeness.

> Link: https://github.com/openwrt/openwrt/issues/16183
> Signed-off-by: Joshua Klinesmith <joshuaklinesmith at gmail.com>
> ---
>   drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
>   1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 85defe11750d..c86ffc203f15 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
>   	return 0;
>   }
>   
> -static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
> +static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
> +				       u32 hal_desc_sz)
>   {
> -	if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
> -		*frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
> +	if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
> +		*frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
>   		*total_len -= *frag_len;
>   	} else {
>   		*frag_len = *total_len;
> @@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
>   
>   static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
>   				      bool *is_frag, u32 *total_len,
> -				      u32 *frag_len, u32 *msdu_cnt)
> +				      u32 *frag_len, u32 *msdu_cnt,
> +				      u32 hal_desc_sz)
>   {
>   	if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
>   		if (!*is_frag) {
>   			*total_len = info->msdu_len;
>   			*is_frag = true;
>   		}
> -		ath11k_dp_mon_set_frag_len(total_len,
> -					   frag_len);
> +		ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
>   	} else {
>   		if (*is_frag) {
> -			ath11k_dp_mon_set_frag_len(total_len,
> -						   frag_len);
> +			ath11k_dp_mon_set_frag_len(total_len, frag_len,
> +						   hal_desc_sz);
>   		} else {
>   			*frag_len = info->msdu_len;
>   		}
> @@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>   
>   			rx_desc = (struct hal_rx_desc *)msdu->data;
>   
> -			rx_pkt_offset = sizeof(struct hal_rx_desc);
> +			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>   			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>   
>   			if (is_first_msdu) {
> @@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>   			}
>   			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>   						  &is_frag, &total_len,
> -						  &frag_len, &msdu_cnt);
> +						  &frag_len, &msdu_cnt,
> +						  rx_pkt_offset);
>   			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>   
>   			ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
> @@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>   
>   			rx_desc = (struct hal_rx_desc *)msdu->data;
>   
> -			rx_pkt_offset = sizeof(struct hal_rx_desc);
> +			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>   			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>   
>   			if (is_first_msdu) {
> @@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>   
>   			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>   						  &is_frag, &total_len,
> -						  &frag_len, &msdu_cnt);
> +						  &frag_len, &msdu_cnt,
> +						  rx_pkt_offset);
>   
>   			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>   

The code change itself looks correct to me.

Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram at oss.qualcomm.com>




From praneesh.p at oss.qualcomm.com  Wed Apr 29 02:52:13 2026
From: praneesh.p at oss.qualcomm.com (Praneesh P)
Date: Wed, 29 Apr 2026 15:22:13 +0530
Subject: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by
 using correct descriptor size
In-Reply-To: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
References: <20260407024836.53871-1-joshuaklinesmith@gmail.com>
Message-ID: <299f83be-748c-458c-be07-df6a0fe02f38@oss.qualcomm.com>

On 4/7/2026 8:18 AM, Joshua Klinesmith wrote:
> The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
> ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
> compute the packet buffer offset. This is the size of the union of all
> chip-specific descriptors (the maximum), not the actual descriptor size
> for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
> strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
> the front of the skb.
>
> On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
> hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
> end of every monitor mode frame delivered to userspace. On WCN6855 the
> sizes happen to match so the bug is not visible.
>
> The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
> fragment length calculation for multi-buffer MSDUs, under-counting
> intermediate fragments by 8 bytes and over-counting the last fragment.
>
> Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
> monitor mpdu_pop functions and passing it through to set_frag_len.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Link: https://github.com/openwrt/openwrt/issues/16183
> Signed-off-by: Joshua Klinesmith <joshuaklinesmith at gmail.com>
> ---
>   drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
>   1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
> index 85defe11750d..c86ffc203f15 100644
> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
> @@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
>   	return 0;
>   }
>   
> -static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
> +static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
> +				       u32 hal_desc_sz)
>   {
> -	if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
> -		*frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
> +	if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
> +		*frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
>   		*total_len -= *frag_len;
>   	} else {
>   		*frag_len = *total_len;
> @@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
>   
>   static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
>   				      bool *is_frag, u32 *total_len,
> -				      u32 *frag_len, u32 *msdu_cnt)
> +				      u32 *frag_len, u32 *msdu_cnt,
> +				      u32 hal_desc_sz)
>   {
>   	if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
>   		if (!*is_frag) {
>   			*total_len = info->msdu_len;
>   			*is_frag = true;
>   		}
> -		ath11k_dp_mon_set_frag_len(total_len,
> -					   frag_len);
> +		ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
>   	} else {
>   		if (*is_frag) {
> -			ath11k_dp_mon_set_frag_len(total_len,
> -						   frag_len);
> +			ath11k_dp_mon_set_frag_len(total_len, frag_len,
> +						   hal_desc_sz);
>   		} else {
>   			*frag_len = info->msdu_len;
>   		}
> @@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>   
>   			rx_desc = (struct hal_rx_desc *)msdu->data;
>   
> -			rx_pkt_offset = sizeof(struct hal_rx_desc);
> +			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>   			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>   
>   			if (is_first_msdu) {
> @@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>   			}
>   			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>   						  &is_frag, &total_len,
> -						  &frag_len, &msdu_cnt);
> +						  &frag_len, &msdu_cnt,
> +						  rx_pkt_offset);
>   			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>   
>   			ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
> @@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>   
>   			rx_desc = (struct hal_rx_desc *)msdu->data;
>   
> -			rx_pkt_offset = sizeof(struct hal_rx_desc);
> +			rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>   			l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>   
>   			if (is_first_msdu) {
> @@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>   
>   			ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>   						  &is_frag, &total_len,
> -						  &frag_len, &msdu_cnt);
> +						  &frag_len, &msdu_cnt,
> +						  rx_pkt_offset);
>   
>   			rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;

Thanks for fixing the offset handling in the monitor Rx path, but still 
there is another instance that still relies on sizeof(struct hal_rx_desc).

ath11k_dp_rx_h_ppdu(), which is also invoked from the monitor path, uses:

ath11k_dbg_dump(ab, ATH11K_DBG_DATA, NULL, "", rx_desc, sizeof(struct 
hal_rx_desc));

This should likewise be converted to use hw_params.hal_desc_sz to avoid 
dumping beyond the chip-specific descriptor size on platforms where they 
differ.



From praneesh.p at oss.qualcomm.com  Wed Apr 29 03:47:22 2026
From: praneesh.p at oss.qualcomm.com (Praneesh P)
Date: Wed, 29 Apr 2026 16:17:22 +0530
Subject: [PATCH v4] wifi: ath11k: fix peer resolution on rx path when
 peer_id=0
In-Reply-To: <530a9e0b-ae5e-48ae-a2c8-73152e2dd6df@oss.qualcomm.com>
References: <20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com>
 <530a9e0b-ae5e-48ae-a2c8-73152e2dd6df@oss.qualcomm.com>
Message-ID: <e248e911-d317-41ee-a590-1385c39ee2e1@oss.qualcomm.com>


On 4/29/2026 1:06 PM, Baochen Qiang wrote:
>
> On 4/24/2026 5:50 PM, Matthew Leach wrote:
>> It has been observed that on certain chipsets a peer can be assigned
>> peer_id=0. For reception of non-aggregated MPDUs this is fine as
>> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
>> based upon the source MAC address. On an aggregated link, the mpdu_start
>> header is only populated by hardware on the first sub-MSDU. This causes
>> the peer resolution to be skipped for the subsequent MSDUs and the
>> encryption type of these frames to be set to an incorrect value,
>> resulting in these MSDUs being dropped by ieee80211.
>>
>> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
>> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
>>
>> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
>> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
>> of 0 to be resolved.
>>
>> Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
>> Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
> Tested-on: is not an official tag but is ath driver specific, so generally it is put above
> all official tags:
>
> Tested-on: ...
> <blank line>
> Fixes: ...
> s-o-b: ...
>
> But since this is trivial I think Jeff can make the change when he merges it, so no need
> to respin just for it.
For QCN9074, IPQ8074, IPQ5018 and IPQ6018, Peer_id 0 is not a expected 
value. Like ath12k, it is better to handle it through hw_params.
>> Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>
>> Signed-off-by: Matthew Leach <matthew.leach at collabora.com>
>> ---
>> Changes in v4:
>> - Prefix subsystem with 'wifi:'.
>> - Added the 'Tested-by' and 'Fixes' trailers.
>> - Link to v3: https://patch.msgid.link/20260417-ath11k-null-peerid-workaround-v3-1-d04302284486 at collabora.com
>>
>> Changes in v3:
>> - Clarified that the mpdu_start header isn't populated by the h/w for
>>    all sub-MSDUs in the commit message.
>> - Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
>> - Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16 at collabora.com
>>
>> Changes in v2:
>>
>> - Since peer_id=0 is a valid condition on some chips, remove the guard
>>    that prevented the peer lookup.
>> - Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8 at collabora.com
>>
>> To: Jeff Johnson <jjohnson at kernel.org>
>> Cc: linux-wireless at vger.kernel.org
>> Cc: ath11k at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   drivers/net/wireless/ath/ath11k/dp_rx.c  | 3 +--
>>   drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
>>   2 files changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> index 49d959b2e148..ff2c78a4e5f3 100644
>> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
>> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> @@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
>>   
>>   	lockdep_assert_held(&ab->base_lock);
>>   
>> -	if (rxcb->peer_id)
>> -		peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>> +	peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
>>   
>>   	if (peer)
>>   		return peer;
>> diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
>> index 753bd93f0212..51e0840bc0d1 100644
>> --- a/drivers/net/wireless/ath/ath11k/hal_rx.c
>> +++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
>> @@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
>>   	case HAL_RX_MPDU_START: {
>>   		struct hal_rx_mpdu_info *mpdu_info =
>>   				(struct hal_rx_mpdu_info *)tlv_data;
>> -		u16 peer_id;
>>   
>> -		peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
>> -		if (peer_id)
>> -			ppdu_info->peer_id = peer_id;
>> +		ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
>>   		break;
>>   	}
>>   	case HAL_RXPCU_PPDU_END_INFO: {
>>
>> ---
>> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
>> change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
>>
>> Best regards,
>> --
>> Matt
>>
>


From patchwork-bot+bluetooth at kernel.org  Thu Apr 30 10:55:41 2026
From: patchwork-bot+bluetooth at kernel.org (patchwork-bot+bluetooth at kernel.org)
Date: Thu, 30 Apr 2026 17:55:41 +0000
Subject: [PATCH v2 0/7] Enable Bluetooth and WiFi on Fairphone (Gen. 6)
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
References: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
Message-ID: <177757174129.3109994.12376905026107591695.git-patchwork-notify@kernel.org>

Hello:

This series was applied to bluetooth/bluetooth-next.git (master)
by Mark Brown <broonie at kernel.org>:

On Fri, 03 Apr 2026 15:52:46 +0200 you wrote:
> Add the required bits to enable Bluetooth and WiFi on the Milos
> SoC-based Fairphone (Gen. 6) smartphone.
> 
> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> ---
> Changes in v2:
> - Drop applied pd-mapper patch
> - Add compatibles for wcn6755 with fallback to wcn6750 (wifi & bt)
> - Rebase on linux-next
> - Pick up one tag (discard the rest due to addition of wcn6755
>   compatibles)
> - Link to v1: https://lore.kernel.org/r/20260116-milos-fp6-bt-wifi-v1-0-27b4fbb77e9c at fairphone.com
> 
> [...]

Here is the summary with links:
  - [v2,1/7] regulator: dt-bindings: qcom,qca6390-pmu: Document WCN6755 PMU
    https://git.kernel.org/bluetooth/bluetooth-next/c/b043657c35e5
  - [v2,2/7] dt-bindings: bluetooth: qcom,wcn6750-bt: Document WCN6755 Bluetooth
    (no matching commit)
  - [v2,3/7] dt-bindings: net: wireless: ath11k: Document WCN6755 WiFi
    (no matching commit)
  - [v2,4/7] arm64: dts: qcom: milos: Split up uart11 pinctrl
    (no matching commit)
  - [v2,5/7] arm64: dts: qcom: milos: Add WCN6755 WiFi node
    (no matching commit)
  - [v2,6/7] arm64: dts: qcom: milos-fairphone-fp6: Enable Bluetooth
    (no matching commit)
  - [v2,7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From jeff.johnson at oss.qualcomm.com  Thu Apr 30 14:30:45 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 30 Apr 2026 14:30:45 -0700
Subject: (subset) [PATCH v2 0/4] Use the QMI service IDs from the QMI
 header
In-Reply-To: <20260316171419.2619620-1-daniel.lezcano@oss.qualcomm.com>
References: <20260316171419.2619620-1-daniel.lezcano@oss.qualcomm.com>
Message-ID: <177758464538.1848985.4937106435944960092.b4-ty@oss.qualcomm.com>


On Mon, 16 Mar 2026 18:14:10 +0100, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
> 
> The QMI service IDs are defined in the qmi.h header file. Use those
> instead of defining the IDs in the protocol implementation file. It
> will result in unifying and providing a consistent way to represent
> the supported protocols.
> 
> [...]

Applied, thanks!

[2/4] wifi: ath: Use the unified QMI service ID instead of defining it locally
      commit: 0e39eea57626e545c596734c0d250c1735f1a7e5

Best regards,
-- 
Jeff Johnson <jeff.johnson at oss.qualcomm.com>



From jeff.johnson at oss.qualcomm.com  Thu Apr 30 14:30:47 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 30 Apr 2026 14:30:47 -0700
Subject: [PATCH] wifi: ath: Unify user-visible "Qualcomm" name
In-Reply-To: <20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com>
References: <20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com>
Message-ID: <177758464704.1848985.17511825714813027637.b4-ty@oss.qualcomm.com>


On Mon, 27 Apr 2026 09:00:41 +0200, Krzysztof Kozlowski wrote:
> Various names for Qualcomm as a company are used in user-visible config
> options: QCOM, Qualcomm and Qualcomm Technologies.  Switch to unified
> "Qualcomm" so it will be easier for users to identify the options when
> for example running menuconfig.
> 
> 

Applied, thanks!

[1/1] wifi: ath: Unify user-visible "Qualcomm" name
      commit: 2419d92ad387ff34376e7c3afc300cff651038da

Best regards,
-- 
Jeff Johnson <jeff.johnson at oss.qualcomm.com>



From jeff.johnson at oss.qualcomm.com  Thu Apr 30 14:30:50 2026
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 30 Apr 2026 14:30:50 -0700
Subject: [PATCH ath-next] wifi: ath11k: cancel SSR work items during
 PCI shutdown
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
References: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
Message-ID: <177758465037.1848985.7425474739277158142.b4-ty@oss.qualcomm.com>


On Fri, 03 Apr 2026 21:30:50 -0700, Wei Zhang wrote:
> A reboot can crash the kernel if it overlaps with WLAN firmware crash
> recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
> path while freeing DMA-backed MHI contexts.
> 
> Simplified trace:
>   dma_free_attrs
>   mhi_deinit_dev_ctxt [mhi]
>   ath11k_pci_power_down [ath11k_pci]
>   ath11k_pci_shutdown [ath11k_pci]
>   device_shutdown
>   kernel_restart
> 
> [...]

Applied, thanks!

[1/1] wifi: ath11k: cancel SSR work items during PCI shutdown
      commit: 8c79aac429b583301f387374ff37c59be671df87

Best regards,
-- 
Jeff Johnson <jeff.johnson at oss.qualcomm.com>



