* [PATCH 5/7] arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
From: Dmitry Baryshkov @ 2026-06-01 9:46 UTC (permalink / raw)
To: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com>
On SM8350 platforms the primary use of UART18 is a 4-pin UART (targeting
Bluetooth or other similar applications). Add all 4 pins to the default
pinctrl entry for the UART.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index c830953156ec..eb2a795d8edb 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -3309,7 +3309,7 @@ qup_uart6_default: qup-uart6-default-state {
};
qup_uart18_default: qup-uart18-default-state {
- pins = "gpio68", "gpio69";
+ pins = "gpio68", "gpio69", "gpio70", "gpio71";
function = "qup18";
drive-strength = <2>;
bias-disable;
--
2.47.3
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: qcom: sm8350: modernize PCIe entries
From: Dmitry Baryshkov @ 2026-06-01 9:46 UTC (permalink / raw)
To: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com>
The recent suggestion is to have PERST# / WAKE pins and PHYs in the PCIe
port rather than RC device. The kernel recently started warning about
the older style of DT. Modernize DT for SM8350 platform by moving the
entries under the root port device node.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 18 +++++++++++-------
arch/arm64/boot/dts/qcom/sm8350.dtsi | 12 ++++--------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index 5f975d009465..4973a3eb11b5 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -493,12 +493,14 @@ &pcie0 {
pinctrl-names = "default";
pinctrl-0 = <&pcie0_default_state>;
- perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
-
status = "okay";
};
+&pcie0_port0 {
+ reset-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+};
+
&pcie0_phy {
vdda-phy-supply = <&vreg_l5b_0p88>;
vdda-pll-supply = <&vreg_l6b_1p2>;
@@ -507,15 +509,17 @@ &pcie0_phy {
};
&pcie1 {
- perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
-
- pinctrl-names = "default";
pinctrl-0 = <&pcie1_default_state>;
+ pinctrl-names = "default";
status = "okay";
};
+&pcie1_port0 {
+ reset-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+};
+
&pcie1_phy {
status = "okay";
vdda-phy-supply = <&vreg_l5b_0p88>;
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index eb2a795d8edb..136daa444865 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1583,12 +1583,9 @@ pcie0: pcie@1c00000 {
power-domains = <&gcc PCIE_0_GDSC>;
- phys = <&pcie0_phy>;
- phy-names = "pciephy";
-
status = "disabled";
- pcie@0 {
+ pcie0_port0: pcie@0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
@@ -1596,6 +1593,7 @@ pcie@0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
+ phys = <&pcie0_phy>;
};
};
@@ -1692,12 +1690,9 @@ pcie1: pcie@1c08000 {
power-domains = <&gcc PCIE_1_GDSC>;
- phys = <&pcie1_phy>;
- phy-names = "pciephy";
-
status = "disabled";
- pcie@0 {
+ pcie1_port0: pcie@0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
@@ -1705,6 +1700,7 @@ pcie@0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
+ phys = <&pcie1_phy>;
};
};
--
2.47.3
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Dmitry Baryshkov @ 2026-06-01 9:46 UTC (permalink / raw)
To: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com>
The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
parts of the device.
The firmware isn't (yet) available as a part of linux-firmware, so it
was verified with the firmware files from the vendor-supplied package
(wcn prefix was applied to Bluetooth firmware files to make them follow
upstream driver changes, vendor provided hpbtfw10.tlv and hpnv10.b06).
Bluetooth: hci0: QCA Product ID :0x00000013
Bluetooth: hci0: QCA SOC Version :0x400c0110
Bluetooth: hci0: QCA ROM Version :0x00000100
Bluetooth: hci0: QCA Patch Version:0x00001017
Bluetooth: hci0: QCA controller version 0x01100100
Bluetooth: hci0: QCA Downloading qca/wcnhpbtfw10.tlv
Bluetooth: hci0: QCA Downloading qca/wcnhpnv10.b06
Bluetooth: hci0: QCA setup on UART is completed
Bluetooth: hci0: HFP non-HCI data transport is supported
ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x605fffff 64bit]: assigned
ath11k_pci 0000:01:00.0: MSI vectors: 32
ath11k_pci 0000:01:00.0: wcn6855 hw1.1
mhi mhi0: Requested to power ON
mhi mhi0: Power on setup success
mhi mhi0: Wait for device to enter SBL or Mission mode
ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x6 soc_id 0x400c0110
ath11k_pci 0000:01:00.0: fw_version 0x110c80c8 fw_build_timestamp 2021-05-25 21:43 fw_build_id WLAN.HSP.1.1.c3-00200-QCAHSPSWPL_V1_V2_SILICONZ-1
ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
For the reference, the driver looks for the board data for
bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=0,qmi-board-id=6,variant=QC_8350_HDK
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 126 ++++++++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index 4973a3eb11b5..8e35216e4272 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -115,6 +115,70 @@ lt9611_3v3: lt9611-3v3-regulator {
regulator-boot-on;
regulator-always-on;
};
+
+ wcn6855-pmu {
+ compatible = "qcom,wcn6851-pmu", "qcom,wcn6855-pmu";
+
+ pinctrl-0 = <&bt_en>, <&wlan_en>, <&swctrl>;
+ pinctrl-names = "default";
+
+ wlan-enable-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 153 GPIO_ACTIVE_HIGH>;
+
+ vddio-supply = <&vreg_s10b_1p8>;
+ vddaon-supply = <&vreg_s11b_0p95>;
+ vddpmu-supply = <&vreg_s11b_0p95>;
+ vddpmumx-supply = <&vreg_s2e_0p85>;
+ vddpmucx-supply = <&vreg_s11b_0p95>;
+ vddrfa0p95-supply = <&vreg_s11b_0p95>;
+ vddrfa1p3-supply = <&vreg_s12b_1p25>;
+ vddrfa1p9-supply = <&vreg_s1c_1p86>;
+ vddpcie1p3-supply = <&vreg_s12b_1p25>;
+ vddpcie1p9-supply = <&vreg_s1c_1p86>;
+
+ regulators {
+ vreg_pmu_rfa_cmn_0p8: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn_0p8";
+ };
+
+ vreg_pmu_aon_0p8: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p8";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p8: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p8";
+ };
+
+ vreg_pmu_btcmx_0p8: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p8";
+ };
+
+ vreg_pmu_pcie_1p8: ldo5 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo6 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_rfa_0p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo8 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo9 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+ };
+ };
};
&adsp {
@@ -373,6 +437,13 @@ vreg_l7e_2p8: ldo7 {
regulator-name = "vreg_l7e_2p8";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
+
+ /*
+ * This is used by the RF front-end for which there is
+ * no way to represent it in DT (yet?).
+ */
+ regulator-boot-on;
+ regulator-always-on;
};
};
};
@@ -499,6 +570,23 @@ &pcie0 {
&pcie0_port0 {
reset-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+
+ wifi@0 {
+ compatible = "pci17cb,1103";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
+
+ qcom,calibration-variant = "QC_8350_HDK";
+ };
};
&pcie0_phy {
@@ -763,6 +851,20 @@ &tlmm {
"HST_WLAN_UART_TX",
"HST_WLAN_UART_RX";
+ wlan_en: wlan-en-state {
+ pins = "gpio64";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ bt_en: bt-en-state {
+ pins = "gpio65";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
pcie0_default_state: pcie0-default-state {
perst-pins {
pins = "gpio94";
@@ -815,12 +917,36 @@ sdc2_card_det_n: sd-card-det-n-state {
drive-strength = <2>;
bias-pull-up;
};
+
+ swctrl: swctrl-state {
+ pins = "gpio153";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
};
&uart2 {
status = "okay";
};
+&uart18 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn6851-bt", "qcom,wcn6855-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+ };
+};
+
&ufs_mem_hc {
status = "okay";
--
2.47.3
^ permalink raw reply related
* Re: [PATCH wireless-next 1/2] wifi: cfg80211: remove 5/10 MHz channel support
From: Lachlan Hodges @ 2026-06-01 10:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20260529084502.080c5885f0b7.I77cc94485b523c3c006005b9233db13cd4e077b3@changeid>
On Fri, May 29, 2026 at 08:40:27AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Remove WIPHY_FLAG_SUPPORTS_5_10_MHZ and 5/10 MHz channel
> width support. We contemplated this back in early 2023
> and didn't do it yet, but nobody stepped up to maintain
> it.
>
> It's already _mostly_ dead code since it can really only
> be used for AP and maybe IBSS and monitor, but not on a
> client since there's no way to scan (and hasn't been in
> a very long time, if ever), so the only thing that ever
> could really happen with it was run syzbot and trip over
> assumptions in the code.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
^ permalink raw reply
* Re: [PATCH wireless-next 2/2] wifi: mac80211: remove 5/10 MHz channel code
From: Lachlan Hodges @ 2026-06-01 10:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20260529084502.4e5a9350206c.I2f6169a067ddd1b5e234668fcb6e07957fafacf2@changeid>
On Fri, May 29, 2026 at 08:40:28AM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Now that cfg80211 refuses all attempts to use 5/10 MHz
> channels, all of this code is unreachable; remove it.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts
From: Rameshkumar Sundaram @ 2026-06-01 10:33 UTC (permalink / raw)
To: Maharaja Kennadyrajan, ath12k; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <20260522091828.3199584-1-maharaja.kennadyrajan@oss.qualcomm.com>
On 5/22/2026 2:48 PM, Maharaja Kennadyrajan wrote:
> From: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
>
> When multiple links switch channel contexts around the same time, mac80211
> may complete CSA for several links together and invoke
> ath12k_mac_op_switch_vif_chanctx() with an array of vifs spanning more than
> one underlying radio in a single-wiphy configuration.
>
> The driver currently assumes that all entries in the vifs array belong to the
> same radio and derives the radio context from the first element. On multi-radio
> hardware, this can lead to incorrect vdev selection/updates and may corrupt
> driver state when the number of vifs exceeds what a single radio supports.
>
> Fix this by validating each vif's switch request and then processing vifs
> grouped by their associated radio. For each vif, ensure the band does not
> change across the switch and that both old/new channel contexts resolve to a
> valid ath12k device. Reject attempts to move a vif between radios (not
> supported for now) and return -EOPNOTSUPP to upper layers.
>
> Then, iterate through the input vifs, collect all unprocessed entries that map
> to the same radio, and invoke ath12k_mac_update_vif_chan() separately for each
> radio group. This removes any reliance on mac80211 providing the array grouped
> by radio or sharing old_ctx pointers across vifs.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
> Co-developed-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts
From: Baochen Qiang @ 2026-06-01 10:51 UTC (permalink / raw)
To: Maharaja Kennadyrajan, ath12k; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <20260522091828.3199584-1-maharaja.kennadyrajan@oss.qualcomm.com>
On 5/22/2026 5:18 PM, Maharaja Kennadyrajan wrote:
> From: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
>
> When multiple links switch channel contexts around the same time, mac80211
> may complete CSA for several links together and invoke
> ath12k_mac_op_switch_vif_chanctx() with an array of vifs spanning more than
> one underlying radio in a single-wiphy configuration.
>
> The driver currently assumes that all entries in the vifs array belong to the
> same radio and derives the radio context from the first element. On multi-radio
> hardware, this can lead to incorrect vdev selection/updates and may corrupt
> driver state when the number of vifs exceeds what a single radio supports.
>
> Fix this by validating each vif's switch request and then processing vifs
> grouped by their associated radio. For each vif, ensure the band does not
> change across the switch and that both old/new channel contexts resolve to a
> valid ath12k device. Reject attempts to move a vif between radios (not
> supported for now) and return -EOPNOTSUPP to upper layers.
>
> Then, iterate through the input vifs, collect all unprocessed entries that map
> to the same radio, and invoke ath12k_mac_update_vif_chan() separately for each
> radio group. This removes any reliance on mac80211 providing the array grouped
> by radio or sharing old_ctx pointers across vifs.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
> Co-developed-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [patch V2 00/25] timekeeping/ptp: Expand snapshot functionality
From: Michael S. Tsirkin @ 2026-06-01 10:59 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
thomas.weissschuh, Arthur Kiyanovski, Rodolfo Giometti,
Vincent Donnefort, Marc Zyngier, Oliver Upton, kvmarm,
Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, virtualization, linux-wireless,
linux-sound, David Woodhouse, Vadim Fedorenko
In-Reply-To: <20260529193435.921555544@kernel.org>
On Fri, May 29, 2026 at 09:59:47PM +0200, Thomas Gleixner wrote:
> This is an update to V1 which can be found here:
>
> https://lore.kernel.org/lkml/20260526165826.392227559@kernel.org
>
> PTP wants to grow new snapshot functionality, which provides not only the
> captured CLOCK* values, but also the underlying clocksource counter value.
>
> https://lore.kernel.org/20260515164033.6403-1-akiyano@amazon.com
>
> There was quite some discussion in seemingly related threads how to capture
> these values and how to provide core infrastructure so that driver writers
> have something to work with
>
> https://lore.kernel.org/20260514225842.110706-1-hramamurthy@google.com
> https://lore.kernel.org/20260520135207.37826-1-dwmw2@infradead.org
virtio bits:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> This series implements the timekeeping related mechanisms to:
>
> 1) Capture CLOCK values along with the clocksource counter value for
> non-hardware based sampling
>
> 2) Expanding the hardware cross time stamp mechanism to hand back the
> clocksource counter value, which was captured by the device, along
> with the related CLOCK values
>
> 3) Adding AUX clock support to the hardware cross timestamping core
>
> 4) Add support for derived clocksources to the snapshot mechanism (New
> in V2)
>
> Changes vs. V1:
>
> - Fixed the ptp_ocp typo - 0-day, Jakub
>
> - Renamed the system_time_snapshot members sys and raw so systime and
> monoraw to make them less ambigous.
>
> - Fixed the error case return values of get_device_system_crosststamp()
>
> - Made ktime_snapshot_id() void as there is no point for the return
> value, which is nowhere checked and cannot be propagated.
> system_time_snapshot::valid has to be evaluated at the call sites
> anyway. - Jacob
>
> - Picked up the first patch from Davids follow up series, which extends
> the snapshot mechanism so that derived clocksources (like kvmclock and
> Hyper-V scaled TSC) can return the actual underlying hardware counter
> value (TSC for the two examples).
>
> - Collected Reviewed/Acked/Tested-by tags
>
> Delta patch against v1 below.
>
> The series is based on v7.1-rc2 and also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git timekeeping-ptp-extend-v2
>
> Thanks,
>
> tglx
> ---
> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index 616062587510..b056c652ff01 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c
> @@ -51,8 +51,8 @@ static void __hyp_clock_work(struct work_struct *work)
>
> hyp_clock = container_of(dwork, struct hyp_trace_clock, work);
>
> - ktime_get_snapshot_id(&snap, CLOCK_BOOTTIME);
> - boot = ktime_to_ns(snap.sys);
> + ktime_get_snapshot_id(CLOCK_BOOTTIME, &snap);
> + boot = ktime_to_ns(snap.systime);
>
> delta_boot = boot - hyp_clock->boot;
> delta_cycles = snap.cycles - hyp_clock->cycles;
> @@ -120,7 +120,7 @@ static void hyp_trace_clock_enable(struct hyp_trace_clock *hyp_clock, bool enabl
>
> ktime_get_snapshot_id(&snap, CLOCK_BOOTTIME);
>
> - hyp_clock->boot = ktime_to_ns(snap.sys);
> + hyp_clock->boot = ktime_to_ns(snap.systime);
> hyp_clock->cycles = snap.cycles;
> hyp_clock->mult = 0;
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index e60cc7ed3e70..b11b8821c9fb 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -28,7 +28,7 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> * system time and counter value must captured at the same
> * time to keep consistency and precision.
> */
> - ktime_get_snapshot_id(&systime_snapshot, CLOCK_REALTIME);
> + ktime_get_snapshot_id(CLOCK_REALTIME, &systime_snapshot);
>
> /*
> * This is only valid if the current clocksource is the
> @@ -61,8 +61,8 @@ static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
> * in the future (about 292 years from 1970, and at that stage
> * nobody will give a damn about it).
> */
> - val[0] = upper_32_bits(systime_snapshot.sys);
> - val[1] = lower_32_bits(systime_snapshot.sys);
> + val[0] = upper_32_bits(systime_snapshot.systime);
> + val[1] = lower_32_bits(systime_snapshot.systime);
> val[2] = upper_32_bits(cycles);
> val[3] = lower_32_bits(cycles);
> }
> diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
> index 1d5fef4df560..2697073dbf90 100644
> --- a/drivers/net/dsa/sja1105/sja1105_main.c
> +++ b/drivers/net/dsa/sja1105/sja1105_main.c
> @@ -2310,10 +2310,10 @@ int sja1105_static_config_reload(struct sja1105_private *priv,
> goto out;
> }
>
> - t1 = ktime_to_ns(ptp_sts_before.pre_sts.sys);
> - t2 = ktime_to_ns(ptp_sts_before.post_sts.sys);
> - t3 = ktime_to_ns(ptp_sts_after.pre_sts.sys);
> - t4 = ktime_to_ns(ptp_sts_after.post_sts.sys);
> + t1 = ktime_to_ns(ptp_sts_before.pre_sts.systime);
> + t2 = ktime_to_ns(ptp_sts_before.post_sts.systime);
> + t3 = ktime_to_ns(ptp_sts_after.pre_sts.systime);
> + t4 = ktime_to_ns(ptp_sts_after.post_sts.systime);
> /* Mid point, corresponds to pre-reset PTPCLKVAL */
> t12 = t1 + (t2 - t1) / 2;
> /* Mid point, corresponds to post-reset PTPCLKVAL, aka 0 */
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index 5023fc1587f9..f9e4ec6f7ebb 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -2117,7 +2117,7 @@ static int ice_capture_crosststamp(ktime_t *device,
> }
>
> /* Snapshot system time for historic interpolation */
> - ktime_get_snapshot_id(&ctx->snapshot, ctx->snapshot_clock_id);
> + ktime_get_snapshot_id(ctx->snapshot_clock_id, &ctx->snapshot);
>
> /* Program cmd to master timer */
> ice_ptp_src_cmd(hw, ICE_PTP_READ_TIME);
> diff --git a/drivers/net/ethernet/intel/igc/igc_ptp.c b/drivers/net/ethernet/intel/igc/igc_ptp.c
> index 9b8b4a04e32d..b40aba9ab685 100644
> --- a/drivers/net/ethernet/intel/igc/igc_ptp.c
> +++ b/drivers/net/ethernet/intel/igc/igc_ptp.c
> @@ -1049,7 +1049,7 @@ static int igc_phc_get_syncdevicetime(ktime_t *device,
> */
> do {
> /* Get a snapshot of system clocks to use as historic value. */
> - ktime_get_snapshot_id(&adapter->snapshot, adapter->snapshot_clock_id);
> + ktime_get_snapshot_id(adapter->snapshot_clock_id, &adapter->snapshot);
>
> igc_ptm_trigger(hw);
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
> index beb80912b9d5..5df786133e4b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
> @@ -340,7 +340,7 @@ static int mlx5_ptp_getcrosststamp(struct ptp_clock_info *ptp,
> goto unlock;
> }
>
> - ktime_get_snapshot_id(&history_begin, cts->clock_id);
> + ktime_get_snapshot_id(cts->clock_id, &history_begin);
>
> err = get_device_system_crosststamp(mlx5_mtctr_syncdevicetime, mdev,
> &history_begin, cts);
> @@ -366,7 +366,7 @@ static int mlx5_ptp_getcrosscycles(struct ptp_clock_info *ptp,
> goto unlock;
> }
>
> - ktime_get_snapshot_id(&history_begin, cts->clock_id);
> + ktime_get_snapshot_id(cts->clock_id, &history_begin);
>
> err = get_device_system_crosststamp(mlx5_mtctr_syncdevicecyclestime,
> mdev, &history_begin, cts);
> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
> index aed5c13cd1be..dc23cd708cfe 100644
> --- a/drivers/ptp/ptp_chardev.c
> +++ b/drivers/ptp/ptp_chardev.c
> @@ -392,11 +392,11 @@ static long ptp_sys_offset_extended(struct ptp_clock *ptp, void __user *arg,
> extoff->ts[i][1].sec = ts.tv_sec;
> extoff->ts[i][1].nsec = ts.tv_nsec;
>
> - ts = ktime_to_timespec64(sts.pre_sts.sys);
> + ts = ktime_to_timespec64(sts.pre_sts.systime);
> extoff->ts[i][0].sec = ts.tv_sec;
> extoff->ts[i][0].nsec = ts.tv_nsec;
>
> - ts = ktime_to_timespec64(sts.post_sts.sys);
> + ts = ktime_to_timespec64(sts.post_sts.systime);
> extoff->ts[i][2].sec = ts.tv_sec;
> extoff->ts[i][2].nsec = ts.tv_nsec;
> }
> diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c
> index b7a23936a44d..28b0302c6250 100644
> --- a/drivers/ptp/ptp_ocp.c
> +++ b/drivers/ptp/ptp_ocp.c
> @@ -1492,7 +1492,7 @@ __ptp_ocp_gettime_locked(struct ptp_ocp *bp, struct timespec64 *ts,
> ptp_read_system_postts(sts);
>
> if (sts && bp->ts_window_adjust)
> - sts->post_ts.sys -= bp->ts_window_adjust;
> + sts->post_sts.systime -= bp->ts_window_adjust;
>
> time_ns = ioread32(&bp->reg->time_ns);
> time_sec = ioread32(&bp->reg->time_sec);
> @@ -4592,8 +4592,8 @@ ptp_ocp_summary_show(struct seq_file *s, void *data)
> struct timespec64 sys_ts;
> s64 pre_ns, post_ns, ns;
>
> - pre_ns = ktime_to_ns(sts.pre_sts.sys);
> - post_ns = ktime_to_ns(sts.post_sts.sys);
> + pre_ns = ktime_to_ns(sts.pre_sts.systime);
> + post_ns = ktime_to_ns(sts.post_sts.systime);
> ns = (pre_ns + post_ns) / 2;
> ns += (s64)bp->utc_tai_offset * NSEC_PER_SEC;
> sys_ts = ns_to_timespec64(ns);
> diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c
> index cb18c15a4697..d6a5a533164a 100644
> --- a/drivers/ptp/ptp_vmclock.c
> +++ b/drivers/ptp/ptp_vmclock.c
> @@ -263,7 +263,7 @@ static int ptp_vmclock_getcrosststamp(struct ptp_clock_info *ptp,
> if (ret == -ENODEV) {
> struct system_time_snapshot systime_snapshot;
>
> - ktime_get_snapshot_id(&systime_snapshot, CLOCK_REALTIME);
> + ktime_get_snapshot_id(CLOCK_REALTIME, &systime_snapshot);
>
> if (systime_snapshot.cs_id == CSID_X86_TSC ||
> systime_snapshot.cs_id == CSID_X86_KVM_CLK) {
> diff --git a/drivers/virtio/virtio_rtc_ptp.c b/drivers/virtio/virtio_rtc_ptp.c
> index e15d00aeb01d..ff8d834493dc 100644
> --- a/drivers/virtio/virtio_rtc_ptp.c
> +++ b/drivers/virtio/virtio_rtc_ptp.c
> @@ -139,7 +139,7 @@ static int viortc_ptp_getcrosststamp(struct ptp_clock_info *ptp,
> if (ret)
> return ret;
>
> - ktime_get_snapshot_id(&history_begin, xtstamp->clock_id);
> + ktime_get_snapshot_id(xtstamp->clock_id, &history_begin);
> if (history_begin.cs_id != cs_id)
> return -EOPNOTSUPP;
>
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index 7c38190b10bf..6d9ddf1587a2 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -31,6 +31,21 @@ struct module;
>
> #include <vdso/clocksource.h>
>
> +/**
> + * struct clocksource_hw_snapshot - Snapshot for the underlying hardware counter of derived
> + * clocksources like kvmclock or Hyper-V scaled TSC
> + * @hw_cycles: The hardware counter value
> + * @hw_csid: Clocksource ID of the hardware counter
> + *
> + * Such clocksources must implement the read_snapshot() callback and fill in the
> + * hardware counter value, the clocksource ID of the hardware counter and derive
> + * the actual clocksource cycles from @hw_cycles to provide an atomic snapshot
> + */
> +struct clocksource_hw_snapshot {
> + u64 hw_cycles;
> + enum clocksource_ids hw_csid;
> +};
> +
> /**
> * struct clocksource - hardware abstraction for a free running counter
> * Provides mostly state-free accessors to the underlying hardware.
> @@ -72,6 +87,14 @@ struct module;
> * @flags: Flags describing special properties
> * @base: Hardware abstraction for clock on which a clocksource
> * is based
> + * @read_snapshot: Extended @read() function for clocksources such as
> + * kvmclock or the Hyper-V scaled TSC where the actual
> + * clocksource value for timekeeping is calculated from an
> + * underlying hardware counter. Returns the timekeeping
> + * relevant cycle value and stores the raw value of the
> + * underlying counter from which it was calculated
> + * including the clocksource ID of that counter in the
> + * clocksource hardware snapshot.
> * @enable: Optional function to enable the clocksource
> * @disable: Optional function to disable the clocksource
> * @suspend: Optional suspend function for the clocksource
> @@ -113,6 +136,7 @@ struct clocksource {
> unsigned long flags;
> struct clocksource_base *base;
>
> + u64 (*read_snapshot)(struct clocksource *cs, struct clocksource_hw_snapshot *chs);
> int (*enable)(struct clocksource *cs);
> void (*disable)(struct clocksource *cs);
> void (*suspend)(struct clocksource *cs);
> diff --git a/include/linux/pps_kernel.h b/include/linux/pps_kernel.h
> index cd80f1cb96a9..9f088c9023b1 100644
> --- a/include/linux/pps_kernel.h
> +++ b/include/linux/pps_kernel.h
> @@ -102,9 +102,9 @@ static inline void pps_get_ts(struct pps_event_time *ts)
> #ifdef CONFIG_NTP_PPS
> struct system_time_snapshot snap;
>
> - ktime_get_snapshot_id(&snap, CLOCK_REALTIME);
> - ts->ts_real = ktime_to_timespec64(snap.sys);
> - ts->ts_raw = ktime_to_timespec64(snap.raw);
> + ktime_get_snapshot_id(CLOCK_REALTIME, &snap);
> + ts->ts_real = ktime_to_timespec64(snap.systime);
> + ts->ts_raw = ktime_to_timespec64(snap.monoraw);
> #else
> ktime_get_real_ts64(&ts->ts_real);
> #endif
> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index df6c9aac458b..36a27a910595 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -511,13 +511,13 @@ static inline ktime_t ptp_convert_timestamp(const ktime_t *hwtstamp,
> static inline void ptp_read_system_prets(struct ptp_system_timestamp *sts)
> {
> if (sts)
> - ktime_get_snapshot_id(&sts->pre_sts, sts->clockid);
> + ktime_get_snapshot_id(sts->clockid, &sts->pre_sts);
> }
>
> static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
> {
> if (sts)
> - ktime_get_snapshot_id(&sts->post_sts, sts->clockid);
> + ktime_get_snapshot_id(sts->clockid, &sts->post_sts);
> }
>
> #endif
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index f7945f1048fc..984a866d293b 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -279,18 +279,24 @@ static inline bool ktime_get_aux_ts64(clockid_t id, struct timespec64 *kt) { ret
> * struct system_time_snapshot - Simultaneous time capture of CLOCK_MONOTONIC_RAW,
> * a selected CLOCK_* and the clocksource counter value
> * @cycles: Clocksource counter value to produce the system times
> - * @sys: The system time of the selected CLOCK ID
> - * @raw: Monotonic raw system time
> + * @hw_cycles: For derived clocksources, the hardware counter value from
> + * which @cycles was derived
> + * @systime: The system time of the selected CLOCK ID
> + * @monoraw: Monotonic raw system time
> * @cs_id: Clocksource ID
> + * @hw_csid: Clocksource ID of the underlying hardware counter for derived
> + * clocksources which implement the read_snapshot() callback.
> * @clock_was_set_seq: The sequence number of clock-was-set events
> * @cs_was_changed_seq: The sequence number of clocksource change events
> * @valid: True if the snapshot is valid
> */
> struct system_time_snapshot {
> u64 cycles;
> - ktime_t sys;
> - ktime_t raw;
> + u64 hw_cycles;
> + ktime_t systime;
> + ktime_t monoraw;
> enum clocksource_ids cs_id;
> + enum clocksource_ids hw_csid;
> unsigned int clock_was_set_seq;
> u8 cs_was_changed_seq;
> u8 valid;
> @@ -348,8 +354,7 @@ extern int get_device_system_crosststamp(
> * Simultaneously snapshot a given clock with MONOTONIC_RAW and the underlying
> * clocksource counter value.
> */
> -extern bool ktime_get_snapshot_id(struct system_time_snapshot *systime_snapshot,
> - clockid_t clock_id);
> +extern void ktime_get_snapshot_id(clockid_t clock_id, struct system_time_snapshot *systime_snapshot);
>
> /*
> * Persistent clock related interfaces
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index c4fd7229b7da..0d5b67f609bb 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -320,6 +320,7 @@ static __always_inline u64 tk_clock_read(const struct tk_read_base *tkr)
>
> return clock->read(clock);
> }
> +
> static inline void clocksource_disable_inline_read(void) { }
> static inline void clocksource_enable_inline_read(void) { }
> #endif
> @@ -1187,14 +1188,26 @@ noinstr time64_t __ktime_get_real_seconds(void)
> return tk->xtime_sec;
> }
>
> +static inline u64 tk_clock_read_snapshot(const struct tk_read_base *tkr,
> + struct clocksource_hw_snapshot *chs)
> +{
> + struct clocksource *clock = READ_ONCE(tkr->clock);
> +
> + if (unlikely(clock->read_snapshot))
> + return clock->read_snapshot(clock, chs);
> +
> + return clock->read(clock);
> +}
> +
> +
> /**
> * ktime_get_snapshot_id - Simultaneously snapshot a given clock ID with
> * CLOCK_MONOTONIC_RAW and the underlying
> * clocksource counter value.
> - * @systime_snapshot: Pointer to struct receiving the system time snapshot
> * @clock_id: The clock ID to snapshot
> + * @systime_snapshot: Pointer to struct receiving the system time snapshot
> */
> -bool ktime_get_snapshot_id(struct system_time_snapshot *systime_snapshot, clockid_t clock_id)
> +void ktime_get_snapshot_id(clockid_t clock_id, struct system_time_snapshot *systime_snapshot)
> {
> ktime_t base_raw, base_sys, offs_sys, *offs, offs_zero = 0;
> u64 nsec_raw, nsec_sys, now;
> @@ -1206,7 +1219,7 @@ bool ktime_get_snapshot_id(struct system_time_snapshot *systime_snapshot, clocki
> systime_snapshot->valid = false;
>
> if (WARN_ON_ONCE(timekeeping_suspended))
> - return false;
> + return;
>
> switch (clock_id) {
> case CLOCK_REALTIME:
> @@ -1226,25 +1239,31 @@ bool ktime_get_snapshot_id(struct system_time_snapshot *systime_snapshot, clocki
> case CLOCK_AUX ... CLOCK_AUX_LAST:
> tkd = aux_get_tk_data(clock_id);
> if (!tkd)
> - return false;
> + return;
> offs = &tkd->timekeeper.offs_aux;
> break;
> default:
> WARN_ON_ONCE(1);
> - return false;
> + return;
> }
>
> tk = &tkd->timekeeper;
>
> do {
> + struct clocksource_hw_snapshot chs = { };
> +
> seq = read_seqcount_begin(&tkd->seq);
>
> /* Aux clocks can be invalid */
> if (!tk->clock_valid)
> - return false;
> + return;
>
> - now = tk_clock_read(&tk->tkr_mono);
> + now = tk_clock_read_snapshot(&tk->tkr_mono, &chs);
> systime_snapshot->cs_id = tk->tkr_mono.clock->id;
> +
> + systime_snapshot->hw_cycles = chs.hw_cycles;
> + systime_snapshot->hw_csid = chs.hw_csid;
> +
> systime_snapshot->cs_was_changed_seq = tk->cs_was_changed_seq;
> systime_snapshot->clock_was_set_seq = tk->clock_was_set_seq;
>
> @@ -1257,18 +1276,17 @@ bool ktime_get_snapshot_id(struct system_time_snapshot *systime_snapshot, clocki
> } while (read_seqcount_retry(&tkd->seq, seq));
>
> systime_snapshot->cycles = now;
> - systime_snapshot->sys = ktime_add_ns(base_sys, offs_sys + nsec_sys);
> - systime_snapshot->raw = ktime_add_ns(base_raw, nsec_raw);
> + systime_snapshot->systime = ktime_add_ns(base_sys, offs_sys + nsec_sys);
> + systime_snapshot->monoraw = ktime_add_ns(base_raw, nsec_raw);
>
> /*
> * Special case for PTP. Just transfer the raw time into sys,
> - * so the call sites can consistently use snap::sys.
> + * so the call sites can consistently use snap::systime.
> */
> if (clock_id == CLOCK_MONOTONIC_RAW)
> - systime_snapshot->sys = systime_snapshot->raw;
> + systime_snapshot->systime = systime_snapshot->monoraw;
> /* Tell the consumer that this snapshot is valid */
> systime_snapshot->valid = true;
> - return true;
> }
> EXPORT_SYMBOL_GPL(ktime_get_snapshot_id);
>
> @@ -1330,7 +1348,7 @@ static int adjust_historical_crosststamp(struct system_time_snapshot *history,
> * Scale the monotonic raw time delta by:
> * partial_history_cycles / total_history_cycles
> */
> - corr_raw = (u64)ktime_to_ns(ktime_sub(ts->sys_monoraw, history->raw));
> + corr_raw = (u64)ktime_to_ns(ktime_sub(ts->sys_monoraw, history->monoraw));
> ret = scale64_check_overflow(partial_history_cycles,
> total_history_cycles, &corr_raw);
> if (ret)
> @@ -1347,7 +1365,7 @@ static int adjust_historical_crosststamp(struct system_time_snapshot *history,
> if (discontinuity) {
> corr_sys = mul_u64_u32_div(corr_raw, tk->tkr_mono.mult, tk->tkr_raw.mult);
> } else {
> - corr_sys = (u64)ktime_to_ns(ktime_sub(ts->sys_systime, history->sys));
> + corr_sys = (u64)ktime_to_ns(ktime_sub(ts->sys_systime, history->systime));
> ret = scale64_check_overflow(partial_history_cycles, total_history_cycles,
> &corr_sys);
> if (ret)
> @@ -1356,8 +1374,8 @@ static int adjust_historical_crosststamp(struct system_time_snapshot *history,
>
> /* Fixup monotonic raw and system time time values */
> if (interp_forward) {
> - ts->sys_monoraw = ktime_add_ns(history->raw, corr_raw);
> - ts->sys_systime = ktime_add_ns(history->sys, corr_sys);
> + ts->sys_monoraw = ktime_add_ns(history->monoraw, corr_raw);
> + ts->sys_systime = ktime_add_ns(history->systime, corr_sys);
> } else {
> ts->sys_monoraw = ktime_sub_ns(ts->sys_monoraw, corr_raw);
> ts->sys_systime = ktime_sub_ns(ts->sys_systime, corr_sys);
> @@ -1521,12 +1539,12 @@ int get_device_system_crosststamp(int (*get_time_fn)
> case CLOCK_AUX ... CLOCK_AUX_LAST:
> tkd = aux_get_tk_data(xtstamp->clock_id);
> if (!tkd)
> - return false;
> + return -ENODEV;
> offs = &tkd->timekeeper.offs_aux;
> break;
> default:
> WARN_ON_ONCE(1);
> - return false;
> + return -ENODEV;
> }
>
> tk = &tkd->timekeeper;
^ permalink raw reply
* Re: [PATCH v3] wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete
From: Felix Fietkau @ 2026-06-01 11:12 UTC (permalink / raw)
To: JB Tsai, lorenzo
Cc: linux-wireless, linux-mediatek, Deren.Wu, Sean.Wang, Quan.Zhou,
Ryder.Lee, Leon.Yen, litien.chang, eason.lai
In-Reply-To: <20260506084315.3143553-1-jb.tsai@mediatek.com>
On 06.05.26 10:43, JB Tsai wrote:
> From: Eason Lai <Eason.Lai@mediatek.com>
>
> A use-after-free issue occurs in mt76_rx_poll_complete due to a race
> condition. The STA has already been removed, but the rx_status still
> had a pointer to the wcid in the STA.
>
> Use wcid_idx instead of storing the wcid pointer, and look up the wcid
> via rcu_dereference() by wcid_idx.
Unless I'm misreading something, it seems to me that this patch papers
over a different bug instead of fixing the root cause.
Right now the rx processing code relies on RCU to protect the wcid and
sta data structures.
The rcu lock/unlock around polling also seems correct to me.
Are the freed wcid pointers maybe related to a vif sta instead of an
actual station? The use of devm_kfree in mt7925_change_vif_links looks
suspicious to me.
Please let me know if I'm missing something here.
- Felix
^ permalink raw reply
* Call for participation: New Age Tooling BoF
From: Jamal Hadi Salim @ 2026-06-01 11:33 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: netfilter-devel, linux-wireless, netfilter, lartc, ovs-dev, bpf,
people, PJ Waskiewicz
Apologies for the shotgun - I wasnt sure how to best reach out given
the short notice.
The recent AI tool bug onslaught (on the victim side for me) has
highlighted the changing landscape on development tooling.
As an initial skeptic I have to say the quality and accuracy of the AI
analysis makes me feel like i have been in some deep slumber. I am
still very clueless.
And for these selfish reasons, I am helping organize a BoF at
netdevconf 0x1A (week of July 13 in Rome.it) to discuss this new age
of tooling.
This BoF is a catch all for folks engaging AI in security (you will be
in a friendly environment!), building tools, doing code reviews,
generating patches and general automation. The intended focus is
networking, but adjacent areas are also welcome.
Come and discuss your tricks of the trade. The contribution can be in
the form of a talk, tutorial or demo.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH mt76] wifi: mt76: mt7915: configure noise floor reporting on reset
From: Felix Fietkau @ 2026-06-01 12:09 UTC (permalink / raw)
To: David Bauer, Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <370e76e3-1d41-469b-8e50-8ace6b5622d2@david-bauer.net>
On 27.05.26 19:05, David Bauer wrote:
> Hi Felix,
>
> On 5/27/26 15:56, Felix Fietkau wrote:
>> On 16.05.26 16:49, David Bauer wrote:
>>> When performing a full system recovery of the MCU on a dual-phy
>>> platform, band 0 (usually 2.4GHz) stops reading correct noise floor
>>> data.
>>>
>>> This is due to noise floor reporting only being configured correctly
>>> for the second device PHY.
>>>
>>> Configure the respective registers correctly after restarting the MCU
>>> firmware to fix reported noise-floor values.
>>>
>>> Signed-off-by: David Bauer <mail@david-bauer.net>
>> Have you considered clearing MT76_STATE_RUNNING in mt7915_mac_restart instead?
>
> The call to mt7915_run is guarded by MT76_STATE_RUNNING being set per-phy.
>
> I think this is to not start the second PHY in case it was never started due to
> it not being present. We could in theory remove this check for the primary PHY
> and clear the flag prior calling mt7915_run.
>
> This seems a bit more hacky to me. Alternatively I can also refactor the entire
> mechanism to make it easier to understand and resolve this indirection in the
> process.
My suggestion would be to do this:
start_main = test_and_clear_bit(MT76_STATE_RUNNING, &dev->mphy.state);
start_ext = ext_phy &&
test_and_clear_bit(MT76_STATE_RUNNING, &ext_phy->state);
Then using those as conditions for calling mt7915_run in
mt7915_mac_restart.
That way the special case in mt7915_run disappears and the behavior
becomes easier to follow.
- Felix
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode
From: Rameshkumar Sundaram @ 2026-06-01 12:27 UTC (permalink / raw)
To: kwan1996, ath12k, linux-wireless
In-Reply-To: <20260507015336.14636-1-laicheehou9@gmail.com>
On 5/7/2026 7:23 AM, kwan1996 wrote:
> From: Kwan Lai Chee Hou <laicheehou9@gmail.com>
>
> In monitor mode, the driver incorrectly assigns the legacy rate
> to the rate_idx field of the radiotap header for HT/VHT/HE/EHT
> frames, ignoring the actual MCS value parsed from the hardware.
>
> This causes packet analyzers (like Wireshark) to display incorrect
> MCS values (e.g., legacy base rates instead of the true MCS).
>
> Fix this by assigning ppdu_info->mcs as the default rate_mcs
> in ath12k_dp_mon_fill_rx_rate(), and remove rate_idx assignments in
> ath12k_dp_mon_update_radiotap() to preserve
> the previously calculated MCS values (including the HT NSS offset).
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220864
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ
>
> Signed-off-by: Kwan Lai Chee Hou <laicheehou9@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/6] wifi: ath12k: Add driver support for WDS mode
From: Rameshkumar Sundaram @ 2026-06-01 12:40 UTC (permalink / raw)
To: Tamizh Chelvam Raja, ath12k; +Cc: linux-wireless
In-Reply-To: <20260525110942.2890212-1-tamizh.raja@oss.qualcomm.com>
On 5/25/2026 4:39 PM, Tamizh Chelvam Raja wrote:
> This patch series introduces support for WDS in the driver by adding
> below changes
>
> Handling of 4-address frame formats required for WDS operation.
> Proper setting of peer 4-address WMI param to ensure correct transmission
> and reception of multicast and unicast frames in WDS mode.
> Conversion of eth offload Rx frame to 802.11 frame for mac80211 to
> detect 4address frame and initiate AP_VLAN creation.
>
> Tamizh Chelvam Raja (6):
> wifi: ath12k: Set WDS vdev parameter for 4-address station interface
> wifi: ath12k: Add support for 4-address mode
> wifi: ath12k: Add 4-address mode support for eth offload
> wifi: ath12k: Add support for 4-address NULL frame handling
> wifi: ath12k: Add support for 4-address frame notification
> wifi: ath12k: Handle 4-address EAPOL frames from WBM error path
>
> drivers/net/wireless/ath/ath12k/core.h | 9 ++
> drivers/net/wireless/ath/ath12k/dp_peer.h | 2 +
> drivers/net/wireless/ath/ath12k/dp_rx.c | 10 +-
> drivers/net/wireless/ath/ath12k/dp_rx.h | 3 +-
> drivers/net/wireless/ath/ath12k/hal.h | 4 +-
> drivers/net/wireless/ath/ath12k/mac.c | 124 +++++++++++++++++-
> drivers/net/wireless/ath/ath12k/mac.h | 3 +
> drivers/net/wireless/ath/ath12k/peer.c | 11 +-
> drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c | 91 +++++++++++--
> drivers/net/wireless/ath/ath12k/wifi7/dp_tx.c | 41 +++++-
> drivers/net/wireless/ath/ath12k/wifi7/dp_tx.h | 4 +-
> .../wireless/ath/ath12k/wifi7/hal_qcc2072.c | 16 +++
> .../wireless/ath/ath12k/wifi7/hal_qcn9274.c | 16 +++
> .../net/wireless/ath/ath12k/wifi7/hal_tx.c | 4 +-
> .../net/wireless/ath/ath12k/wifi7/hal_tx.h | 1 +
> .../wireless/ath/ath12k/wifi7/hal_wcn7850.c | 16 +++
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 18 ++-
> drivers/net/wireless/ath/ath12k/wmi.c | 47 ++++++-
> drivers/net/wireless/ath/ath12k/wmi.h | 17 +++
> 19 files changed, 409 insertions(+), 28 deletions(-)
>
>
> base-commit: 30d516006fa1f72f957c18c6171f5680dcdebfb0
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: add hardware parameters for maximum supported clients
From: Rameshkumar Sundaram @ 2026-06-01 12:49 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260515030909.3312511-1-aaradhana.sahu@oss.qualcomm.com>
On 5/15/2026 8:39 AM, Aaradhana Sahu wrote:
> Currently, the driver uses memory profile parameters to determine the
> maximum number of supported clients, with a default limit of 512 for
> single-radio and 128 for DBS and DBS+SBS configurations. However,
> some devices have lower hardware limits depending on the radio
> configuration. Exceeding these hardware-specific limits can lead to
> firmware crashes.
>
> Add hardware parameters in ath12k_hw_params to define the maximum supported
> clients for each radio configuration. The driver uses the minimum of the
> memory profile limit and the hardware capability limit to prevent exceeding
> hardware constraints.
>
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath11k: dp rx sanity checks for invalid length in error paths
From: Rameshkumar Sundaram @ 2026-06-01 13:16 UTC (permalink / raw)
To: Miaoqing Pan, jjohnson; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260512022351.2033155-1-miaoqing.pan@oss.qualcomm.com>
On 5/12/2026 7:53 AM, Miaoqing Pan wrote:
> This patch series adds two defensive sanity checks in ath11k DP RX
> handling to prevent invalid memory access when hardware/descriptor
> contents are unexpected, especially in WBM error scenarios.
>
> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
> ---
> Miaoqing Pan (2):
> wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
> wifi: ath11k: add MSDU length validation for TKIP MIC error
>
> drivers/net/wireless/ath/ath11k/dp_rx.c | 59 +++++++++++++++++++++++--
> 1 file changed, 56 insertions(+), 3 deletions(-)
>
>
> base-commit: 7b25796f571fc09a7aa6fe7efb23edccd326917d
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* iwlwifi: 8086:7740 firmware crash – SYSTEM_STATISTICS_CMD timeout after roam
From: cam enih @ 2026-06-01 13:39 UTC (permalink / raw)
To: linuxwifi; +Cc: linux-wireless
Hello,
I'm seeing a reproducible firmware crash on an Intel Wi‑Fi 7 CNVi adapter
(8086:7740) on an Arrow Lake platform. The crash causes a full device
reset, briefly dropping connectivity.
Hardware: Intel Corporation Arrow Lake CNVi WiFi [8086:7740] (rev 04)
Driver: iwlwifi
Firmware version: 101.6e695a70.0 bz-b0-fm-c0-c101.ucode
Kernel: 7.0.10-2-cachyos
Distribution: Arch Linux
The crash occurs when the client roams from one BSSID to another
(c0:8b:05:b2:f3:b2 → c0:8b:05:b2:f3:c2). The event always happens about
15–20 minutes after connecting, immediately after a
SYSTEM_STATISTICS_CMD timeout:
[ +0.065429] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm ...
[Jun 1 21:24] iwlwifi 0000:00:14.3: Error sending
SYSTEM_STATISTICS_CMD: time out after 2000ms.
[ +0.000012] iwlwifi 0000:00:14.3: Current CMD queue read_ptr 5552
write_ptr 5553
[ +0.002087] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
...
[ +4.582072] iwlwifi 0000:00:14.3: HCMD_ACTIVE already clear for
command SYSTEM_STATISTICS_CMD
...
[ +0.554468] iwlwifi 0000:00:14.3: restart completed
Please let me know if you need any additional debug data or if there is
a firmware update / patch I should test. I'm happy to try experimental
builds.
Thank you,
Eric
^ permalink raw reply
* Re: [PATCH 2/7] wifi: ath11k: enable support for WCN6851
From: Jeff Johnson @ 2026-06-01 13:54 UTC (permalink / raw)
To: Dmitry Baryshkov, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-2-242917d88031@oss.qualcomm.com>
On 6/1/2026 2:46 AM, Dmitry Baryshkov wrote:
> The WCN6851, found e.g. on SM8350 platforms, is an earlier version of
> WCN6855 platform. It identifies itself as hw1.1. Copy WCN6855 hw 2.0
> configuration to support hw1.1 version.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath11k/core.c | 92 ++++++++++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath11k/core.h | 1 +
> drivers/net/wireless/ath/ath11k/mhi.c | 1 +
> drivers/net/wireless/ath/ath11k/pci.c | 9 ++++
> drivers/net/wireless/ath/ath11k/pcic.c | 11 ++++
> 5 files changed, 114 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index 3f6f4db5b7ee..7e997016cf6e 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -393,6 +393,98 @@ static const struct ath11k_hw_params ath11k_hw_params[] = {
> .cfr_num_stream_bufs = 0,
> .cfr_stream_buf_size = 0,
> },
> + {
> + .name = "wcn6855 hw1.1",
> + .hw_rev = ATH11K_HW_WCN6855_HW11,
> + .fw = {
> + .dir = "WCN6855/hw1.1",
> + .board_size = 256 * 1024,
> + .cal_offset = 128 * 1024,
> + },
...> + .num_vdevs = 2 + 1,
this value is being modified to 4 in:
https://msgid.link/20260525020711.2590815-1-wei.zhang@oss.qualcomm.com
It is merging into ath-next today and should reach linux-next very soon.
/jeff
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: Clear DMA descriptors without memset
From: Toke Høiland-Jørgensen @ 2026-06-01 15:10 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260517042716.2218386-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> Clear ath9k DMA descriptors with explicit status word stores instead of
> memset(). The descriptor rings are coherent DMA memory, which may be
> mapped uncached on 32-bit powerpc. The optimized memset() path can use
> dcbz there and trigger an alignment warning.
>
> Use WRITE_ONCE() for the descriptor status words so the compiler keeps
> the clears as ordinary stores instead of folding them back into bulk
> memset(). This covers AR9003 TX status descriptors as well as the RX
> status area cleared when setting up RX descriptors.
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: remove TX99 power array zero init
From: Toke Høiland-Jørgensen @ 2026-06-01 15:10 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260517222136.1660347-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> This array is fully initialized in the loop itself. No need to zero
> initialize and then overwrite.
>
> Remove static from the array. This was a holdover from when the array
> was a static global variable. It no longer confers any benefit.
>
> Also add a min() call to avoid the manual if/ternary operation.
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k: remove disabling of bands
From: Toke Høiland-Jørgensen @ 2026-06-01 15:11 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260521231806.261220-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> The old platform data code that used this is gone and this serves no
> purpose.
>
> The modern way to disable bands is ieee80211-freq-limit, which is
> already implemented.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath9k_htc: allocate tx_buf and buf together
From: Toke Høiland-Jørgensen @ 2026-06-01 15:12 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260521232020.261405-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> Use a flexible array member to combine allocations. No need to have them
> separate as they are always together.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath9k_htc: use module_usb_driver
From: Toke Høiland-Jørgensen @ 2026-06-01 15:09 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260506234848.189840-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> This follows the pattern with other USB Wifi drivers. There is nothing
> special being done in the _init and _exit functions here. Simplifies and
> saves some lines of code.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath11k: raise max vdevs to 4 on hardware with P2P and dual-station support
From: Rameshkumar Sundaram @ 2026-06-01 15:52 UTC (permalink / raw)
To: Wei Zhang, jeff.johnson; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260525020711.2590815-1-wei.zhang@oss.qualcomm.com>
On 5/25/2026 7:37 AM, Wei Zhang wrote:
> When P2P support is enabled, wpa_supplicant creates a p2p-device
> interface by default, which implicitly consumes one vdev. On systems
> managed by NetworkManager, this interface cannot be reliably disabled,
> leaving only two usable interfaces for user configurations.
>
> Increase num_vdevs to four for QCA6390 hw2.0, WCN6855 hw2.0/hw2.1,
> QCA2066 hw2.1, and QCA6698AQ hw2.1 to account for the implicit
> p2p-device and enable common concurrency scenarios such as AP + AP + STA.
>
> This change increases interface concurrency in the two-channel scenario
> by raising the maximum vdev limit, while keeping other combination rules
> unchanged.
>
> Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
> Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
> Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
>
> Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 1/2] wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
From: Jeff Johnson @ 2026-06-01 16:09 UTC (permalink / raw)
To: Baochen Qiang, Miaoqing Pan, jjohnson
Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <f89f90ea-a9f2-4f1c-b55f-2b77ddc505e1@oss.qualcomm.com>
On 5/31/2026 8:47 PM, Baochen Qiang wrote:
>
>
> On 5/12/2026 10:23 AM, Miaoqing Pan wrote:
>> In certain cases, hardware might provide packets with a
>> length greater than the maximum native Wi-Fi header length.
>> This can lead to accessing and modifying fields in the header
>> within the ath11k_dp_rx_h_undecap_nwifi() function for the
>> DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
>> potentially result in invalid data access and memory corruption.
>>
>> Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k]
>> Call trace:
>> ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k]
>> ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k]
>> ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k]
>> ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k]
>> ath11k_dp_service_srng+0x2e0/0x348 [ath11k]
>>
>> Add a sanity check before processing the SKB to prevent invalid
>> data access in the undecap native Wi-Fi function for the
>> DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.
>>
>> This adapted from the discussion/patch of the ath12k driver [1].
>>
>> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
>>
>> Link: https://lore.kernel.org/linux-wireless/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com/ # [1]
>> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/ath11k/dp_rx.c | 50 +++++++++++++++++++++++--
>> 1 file changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> index fe79109adc70..fbe2061a544d 100644
>> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
>> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> @@ -2502,6 +2502,29 @@ static void ath11k_dp_rx_deliver_msdu(struct ath11k *ar, struct napi_struct *nap
>> ieee80211_rx_napi(ar->hw, pubsta, msdu, napi);
>> }
>>
>> +static bool ath11k_dp_rx_check_nwifi_hdr_len_valid(struct ath11k_base *ab,
>> + struct hal_rx_desc *rx_desc,
>> + struct sk_buff *msdu)
>> +{
>> + struct ieee80211_hdr *hdr;
>> + u8 decap_type;
>> + u32 hdr_len;
>> +
>> + decap_type = ath11k_dp_rx_h_msdu_start_decap_type(ab, rx_desc);
>> + if (decap_type != DP_RX_DECAP_TYPE_NATIVE_WIFI)
>> + return true;
>> +
>> + hdr = (struct ieee80211_hdr *)msdu->data;
>> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
>> +
>> + if ((likely(hdr_len <= DP_MAX_NWIFI_HDR_LEN)))
>
> nit: Double parentheses on likely()
I've fixed this in the 'pending' branch:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=99f35f3f082fca14fc3324e48abd805871d39c69
^ permalink raw reply
* Re: net: wireless: ralink: RT2X00: regression, hostapd do not work anymore on 6.18.33 (work on 6.18.26)
From: Stanislaw Gruszka @ 2026-06-01 16:17 UTC (permalink / raw)
To: Corentin Labbe; +Cc: linux-wireless, linux-kernel
In-Reply-To: <ahxBexU0n_yb__EV@Red>
Hi,
On Sun, May 31, 2026 at 04:11:07PM +0200, Corentin Labbe wrote:
> Hello
>
> I have an hostapd setup with a
> 01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe
>
> The setup work fine on 6.18.26-gentoo
> It breaks on 6.18.33-gentoo
>
> I found an hint in dmesg:
> On 6.18.26-gentoo I see:
> May 31 15:48:45 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected
>
> On 6.18.33-gentoo I see:
> May 31 15:22:57 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0006 detected
>
> The RF chipset seems badly detected.
I do not see any rt2x00 related changes between upstream v6.18.26
and v6.18.33. Assuming gentoo does not provide own extra patches,
seems the issue be in some other subsystem, maybe PCI.
Then the best way get solution to the problem would be to find
offensive commit using git bisection:
https://docs.kernel.org/admin-guide/bug-bisect.html
You can also try if by a chance bug is not yet fixed in just
released v6.18.34
Regards
Stanislaw
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox