From jens.glathe at oldschoolsolutions.biz  Sun Dec  1 02:21:33 2024
From: jens.glathe at oldschoolsolutions.biz (Jens Glathe)
Date: Sun, 1 Dec 2024 11:21:33 +0100
Subject: =?UTF-8?Q?ath11k=3A_WCN6855_hw2=2E1=3A_board_file_for_Qualcomm?=
 =?UTF-8?Q?=C2=AE_FastConnect=E2=84=A2_6900_Wi-Fi_6E=2C_HP_Omnibook_X_14?=
Message-ID: <f6693075-60ea-4fed-8453-9e124e94203b@oldschoolsolutions.biz>

Hi there,

this is a board file submission for the WiFi / BT m.2? card I found in
my HP Omnibook? X14. There are no new calibration data, I re-used other
already present data after an educated guess. The fitting data were from
HP_G8_Lancia14. Also entered for the regdb, the board-2.json is attached
for reference. It works well.

* description for what hardware this is:

The card itself is a "Qualcomm? FastConnect? 6900 Wi-Fi 6E (2x2) Dual
Band Simultaneous (DBS) and Bluetooth? 5.3 Wireless-Card", based on the
WCN6855 SoC.

[??? 2.800166] ath11k_pci 0004:01:00.0: BAR 0 [mem 0x7c400000-0x7c5fffff
64bit]: assigned
[??? 2.800215] ath11k_pci 0004:01:00.0: enabling device (0000 -> 0002)
[??? 2.829651] ath11k_pci 0004:01:00.0: MSI vectors: 32
[??? 2.829672] ath11k_pci 0004:01:00.0: wcn6855 hw2.1


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

I used the /lib/firmware/ath11k/WCN6855/hw2.0/board-2.bin.zst available
in linux-firmware (20240318.git3b128b60-0ubuntu2.5), extracted it and
used the parts needed for this card.


* ids to be used with the board file (ATH11K_BD_IE_BOARD_NAME in ath11k)

"bus=pci,vendor=17cb,device=1103,subsystem-vendor=105b,subsystem-device=e108,qmi-chip-id=2,qmi-board-id=255"

sha256sum: ad4bcdbb5c0a4f87ad3a7796aa301bd41a0c224cf8bb067b17cc60a0f527f942

"bus=pci,vendor=17cb,device=1103,subsystem-vendor=105b,subsystem-device=e108,qmi-chip-id=18,qmi-board-id=255"

sha256sum: 07208286e6980a838e917933835fe93488a56c9ff43336b3f4d03b67d55fc850


* attach the actual board file (board.bin)

The name of the files are *not* equal to the id string in the
board-2.bin. The board-2.json file is also attached for reference. The
sha256sums are the ones of the actual files used.

board-2.bin sha256sum:
ded4d57897bff49de5af7434e66c294a456c06b2165c207331cab3e209f3ae9d

board-2.json sha256sum:
9517d39df64bdf8955a1ce1851145b7331d50f1d98ae7a5d6d873934153735d9


with best regards

Jens Glathe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: board-2.json
Type: application/json
Size: 1422 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241201/646a4295/attachment-0001.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: board-2.bin
Type: application/octet-stream
Size: 169252 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241201/646a4295/attachment-0001.bin>

From lujianhua000 at gmail.com  Sun Dec  1 05:57:14 2024
From: lujianhua000 at gmail.com (Jianhua Lu)
Date: Sun,  1 Dec 2024 21:57:14 +0800
Subject: [PATCH v4 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add qca6390-pmu node
Message-ID: <20241201135716.141691-1-lujianhua000@gmail.com>

Add qca6390-pmu node, which is used to manage power supply sequence for wifi and
bluetooth on sm8250 soc based devices.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Jianhua Lu <lujianhua000 at gmail.com>
---
No changes in v4.

No changes in v3.

changes in v2:
1. pick up Dmitry Baryshkov's Reviewed-by


 .../dts/qcom/sm8250-xiaomi-elish-common.dtsi  | 77 +++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 3596dd328c31..ebea283f56ea 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -97,6 +97,67 @@ key-vol-up {
 		};
 	};
 
+	qca6390-pmu {
+		compatible = "qcom,qca6390-pmu";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+		vddaon-supply = <&vreg_s6a_0p95>;
+		vddpmu-supply = <&vreg_s6a_0p95>;
+		vddrfa0p95-supply = <&vreg_s6a_0p95>;
+		vddrfa1p3-supply = <&vreg_s8c_1p35>;
+		vddrfa1p9-supply = <&vreg_s5a_1p9>;
+		vddpcie1p3-supply = <&vreg_s8c_1p35>;
+		vddpcie1p9-supply = <&vreg_s5a_1p9>;
+		vddio-supply = <&vreg_s4a_1p8>;
+
+		wlan-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+
+		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";
+			};
+		};
+	};
+
 	vph_pwr: vph-pwr-regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "vph_pwr";
@@ -701,6 +762,22 @@ &slpi {
 
 &tlmm {
 	gpio-reserved-ranges = <40 4>;
+
+	bt_en_state: bt-default-state {
+		pins = "gpio21";
+		function = "gpio";
+		drive-strength = <16>;
+		output-low;
+		bias-pull-up;
+	};
+
+	wlan_en_state: wlan-default-state {
+		pins = "gpio20";
+		function = "gpio";
+		drive-strength = <16>;
+		output-low;
+		bias-pull-up;
+	};
 };
 
 &usb_1 {
-- 
2.47.0



From lujianhua000 at gmail.com  Sun Dec  1 05:57:15 2024
From: lujianhua000 at gmail.com (Jianhua Lu)
Date: Sun,  1 Dec 2024 21:57:15 +0800
Subject: [PATCH v4 2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add wifi node
In-Reply-To: <20241201135716.141691-1-lujianhua000@gmail.com>
References: <20241201135716.141691-1-lujianhua000@gmail.com>
Message-ID: <20241201135716.141691-2-lujianhua000@gmail.com>

Add wifi node and this wifi module is connected to PCIe port.
The following is qca6390 probe message:
  ath11k_pci 0000:01:00.0: Adding to iommu group 12
  ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x604fffff 64bit]: assigned
  ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
  ath11k_pci 0000:01:00.0: MSI vectors: 32
  ath11k_pci 0000:01:00.0: qca6390 hw2.0
  ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
  ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Jianhua Lu <lujianhua000 at gmail.com>
---
changes in v4:
1. pick up Dmitry Baryshkov's Reviewed-by

changes in v3:
1. fix commit message typo (pice -> PCIe).

changes in v2:
1. add qcom,ath11k-calibration-variant property.

 .../dts/qcom/sm8250-xiaomi-elish-common.dtsi  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index ebea283f56ea..7a55e271c3ac 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -680,6 +680,25 @@ &pcie0_phy {
 	status = "okay";
 };
 
+&pcieport0 {
+	wifi at 0 {
+		compatible = "pci17cb,1101";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+
+		qcom,ath11k-calibration-variant = "Xiaomi_Pad_5Pro";
+	};
+};
+
 &pm8150_gpios {
 	vol_up_n: vol-up-n-state {
 		pins = "gpio6";
-- 
2.47.0



From lujianhua000 at gmail.com  Sun Dec  1 05:57:16 2024
From: lujianhua000 at gmail.com (Jianhua Lu)
Date: Sun,  1 Dec 2024 21:57:16 +0800
Subject: [PATCH v4 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add bluetooth node
In-Reply-To: <20241201135716.141691-1-lujianhua000@gmail.com>
References: <20241201135716.141691-1-lujianhua000@gmail.com>
Message-ID: <20241201135716.141691-3-lujianhua000@gmail.com>

Add bluetooth node and this bluetooth module is connected to uart.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
Signed-off-by: Jianhua Lu <lujianhua000 at gmail.com>
---
No changes in v4.

No changes in v3.

changes in v2:
1. pick up Dmitry Baryshkov's Reviewed-by

 .../dts/qcom/sm8250-xiaomi-elish-common.dtsi  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 7a55e271c3ac..100607da42ad 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -30,6 +30,10 @@ / {
 	qcom,msm-id = <QCOM_ID_SM8250 0x20001>; /* SM8250 v2.1 */
 	qcom,board-id = <0x10008 0>;
 
+	aliases {
+		serial0 = &uart6;
+	};
+
 	chosen {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -799,6 +803,21 @@ wlan_en_state: wlan-default-state {
 	};
 };
 
+&uart6 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,qca6390-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>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+	};
+};
+
 &usb_1 {
 	/* USB 2.0 only */
 	qcom,select-utmi-as-pipe-clk;
-- 
2.47.0



From jens.glathe at oldschoolsolutions.biz  Sun Dec  1 10:58:57 2024
From: jens.glathe at oldschoolsolutions.biz (Jens Glathe)
Date: Sun, 1 Dec 2024 19:58:57 +0100
Subject: ath11k: WCN6855 hw2.1: board file for WiFi on the Windows Dev Kit
 2023
Message-ID: <96a7e395-50e2-47f6-b0e4-5244460a8ef9@oldschoolsolutions.biz>

Hi there,

this is a board file submission for the WiFi / BT module found on the
Microsoft Windows Dev Kit 2023. (codename Blackrock, marketing name
"Project Volterra"). There are no new calibration data, I re-used other
already present data after an educated guess. The fitting data were from
LW_X13S.

* description for what hardware this is:

The module is described as generic "Qualcomm WCN65x We-Fi 6E Dual Band
Simultaneous (DBS) WiFiCx Network Adapter", the normal WCN6855 hw2.1.

Nov 15 07:20:58 volterra kernel: ath11k_pci 0006:01:00.0: BAR 0 [mem
0x30400000-0x305fffff 64bit]: assigned
Nov 15 07:20:58 volterra kernel: ath11k_pci 0006:01:00.0: enabling
device (0000 -> 0002)
Nov 15 07:20:58 volterra kernel: ath11k_pci 0006:01:00.0: MSI vectors: 32
Nov 15 07:20:58 volterra kernel: ath11k_pci 0006:01:00.0: wcn6855 hw2.1


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

I used the /lib/firmware/ath11k/WCN6855/hw2.0/board-2.bin.zst available
in linux-firmware (20240318.git3b128b60-0ubuntu2.5), extracted it and
used the parts needed for this card.


* ids to be used with the board file (ATH11K_BD_IE_BOARD_NAME in ath11k)

"bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=255,variant=MS_Volterra"

sha256sum: 3ee912c4bf015d314198c7c50829deb611b97e2499c13debd736485e72c67fa0

"bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=18,qmi-board-id=255,variant=MS_Volterra"

sha256sum: 77b1b9ef636ce8492723aa7c2ff2c42c2e5e81a43967d7f32bfdef93a31bf8c4


* attach the actual board file (board.bin)

The name of the files are *not* equal to the id string in the
board-2.bin. The board-2.json file is also attached for reference. The
sha256sums are the ones of the actual files used.

board-2.bin sha256sum:
928ec43c3de0a8fdbeaa95a61cda46e2de36d9ae0f533c2cf225924aba79367a

board-2.json sha256sum:
5f0acb38ce8a05a4f55b861b75d426cb5c781448b11b7878972fc6ea948214a1

with best regards

Jens Glathe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: board-2.bin
Type: application/octet-stream
Size: 144684 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241201/e4584c11/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: board-2.json
Type: application/json
Size: 974 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241201/e4584c11/attachment-0001.json>

From jtornosm at redhat.com  Mon Dec  2 01:18:30 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Mon,  2 Dec 2024 10:18:30 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
Message-ID: <20241202091858.200773-1-jtornosm@redhat.com>

Since commit f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces"),
if dual stations are supported for a device, we can not configure more that
one AP and/or DFS cannot be enabled.

Enable this by creating a new parameter (ignore_support_dual_stations) to
ignore this feature if it is convenient. Default behavior is to support
dual stations if possible.

Reported-by: Vladimir Benes <vbenes at redhat.com>
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm at redhat.com>
---
 drivers/net/wireless/ath/ath11k/core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index be67382c00f6..55c7a55d85ff 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -37,6 +37,12 @@ bool ath11k_ftm_mode;
 module_param_named(ftm_mode, ath11k_ftm_mode, bool, 0444);
 MODULE_PARM_DESC(ftm_mode, "Boots up in factory test mode");
 
+static bool ath11k_ignore_support_dual_stations;
+module_param_named(ignore_support_dual_stations,
+		   ath11k_ignore_support_dual_stations, bool, 0644);
+MODULE_PARM_DESC(ignore_support_dual_stations,
+		 "Ignore the support for dual stations to support other combinations");
+
 static const struct ath11k_hw_params ath11k_hw_params[] = {
 	{
 		.hw_rev = ATH11K_HW_IPQ8074,
@@ -2162,6 +2168,9 @@ static int ath11k_init_hw_params(struct ath11k_base *ab)
 	}
 
 	ab->hw_params = *hw_params;
+	if (ab->hw_params.support_dual_stations &&
+	    ath11k_ignore_support_dual_stations)
+		ab->hw_params.support_dual_stations  = false;
 
 	ath11k_info(ab, "%s\n", ab->hw_params.name);
 
-- 
2.47.0



From christian.gmeiner at gmail.com  Mon Dec  2 13:16:53 2024
From: christian.gmeiner at gmail.com (Christian Gmeiner)
Date: Mon, 2 Dec 2024 22:16:53 +0100
Subject: [PATCH v2 09/21] drm/etnaviv: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241115-converge-secs-to-jiffies-v2-9-911fb7595e79@linux.microsoft.com>
References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com>
 <20241115-converge-secs-to-jiffies-v2-9-911fb7595e79@linux.microsoft.com>
Message-ID: <CAH9NwWdjXKH-AcKa-prwdqj2JqWLYVp1qM+0kxtQYSwo1J1c7g@mail.gmail.com>

>
> Changes made with the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>

Reviewed-by: Christian Gmeiner <cgmeiner at igalia.com>

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 721d633aece9d4c81f0019e4c55884f26ee61c60..0f5a2c885d0ab7029c7248e15d6ea3c31823b782 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -100,7 +100,7 @@ int etnaviv_cmdbuf_init(struct etnaviv_cmdbuf_suballoc *suballoc,
>                 mutex_unlock(&suballoc->lock);
>                 ret = wait_event_interruptible_timeout(suballoc->free_event,
>                                                        suballoc->free_space,
> -                                                      msecs_to_jiffies(10 * 1000));
> +                                                      secs_to_jiffies(10));
>                 if (!ret) {
>                         dev_err(suballoc->dev,
>                                 "Timeout waiting for cmdbuf space\n");
>
> --
> 2.34.1
>


-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy


From quic_yuzha at quicinc.com  Mon Dec  2 17:54:43 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Tue, 3 Dec 2024 09:54:43 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241202091858.200773-1-jtornosm@redhat.com>
References: <20241202091858.200773-1-jtornosm@redhat.com>
Message-ID: <7ccd4b98-9557-4a8b-b493-e01b157c71e2@quicinc.com>



On 12/2/2024 5:18 PM, Jose Ignacio Tornos Martinez wrote:
> Since commit f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces"),
> if dual stations are supported for a device, we can not configure more that
> one AP and/or DFS cannot be enabled.
> 
Try 
https://lore.kernel.org/all/20241127022742.4016870-1-quic_yuzha at quicinc.com/
> Enable this by creating a new parameter (ignore_support_dual_stations) to
> ignore this feature if it is convenient. Default behavior is to support
> dual stations if possible.
> 
> Reported-by: Vladimir Benes <vbenes at redhat.com>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm at redhat.com>
> ---
>   drivers/net/wireless/ath/ath11k/core.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index be67382c00f6..55c7a55d85ff 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -37,6 +37,12 @@ bool ath11k_ftm_mode;
>   module_param_named(ftm_mode, ath11k_ftm_mode, bool, 0444);
>   MODULE_PARM_DESC(ftm_mode, "Boots up in factory test mode");
>   
> +static bool ath11k_ignore_support_dual_stations;
> +module_param_named(ignore_support_dual_stations,
> +		   ath11k_ignore_support_dual_stations, bool, 0644);
> +MODULE_PARM_DESC(ignore_support_dual_stations,
> +		 "Ignore the support for dual stations to support other combinations");
> +
>   static const struct ath11k_hw_params ath11k_hw_params[] = {
>   	{
>   		.hw_rev = ATH11K_HW_IPQ8074,
> @@ -2162,6 +2168,9 @@ static int ath11k_init_hw_params(struct ath11k_base *ab)
>   	}
>   
>   	ab->hw_params = *hw_params;
> +	if (ab->hw_params.support_dual_stations &&
> +	    ath11k_ignore_support_dual_stations)
> +		ab->hw_params.support_dual_stations  = false;
>   
>   	ath11k_info(ab, "%s\n", ab->hw_params.name);
>   



From quic_yuzha at quicinc.com  Mon Dec  2 22:03:18 2024
From: quic_yuzha at quicinc.com (Yu Zhang(Yuriy))
Date: Tue, 3 Dec 2024 14:03:18 +0800
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
Message-ID: <20241203060318.1750927-1-quic_yuzha@quicinc.com>

Add a node for the PMU module of the WCN6855 present on the qcs615
board. Assign its LDO power outputs to the existing WiFi/BT module.

This patch depends on below patch series:
- base
https://lore.kernel.org/all/20241104-add_initial_support_for_qcs615-v5-0-9dde8d7b80b0 at quicinc.com/
- pmic
https://lore.kernel.org/all/20241202-adds-spmi-pmic-peripherals-for-qcs615-v6-0-bdd306b4940d at quicinc.com/
- pci
https://lore.kernel.org/all/20241122023314.1616353-1-quic_ziyuzhan at quicinc.com/

Signed-off-by: Yu Zhang(Yuriy) <quic_yuzha at quicinc.com>

diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index 66f99cd860b9..80ae02ab2a9b 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -14,6 +14,7 @@ / {
 
 	aliases {
 		serial0 = &uart0;
+		serial1 = &uart7;
 	};
 
 	chosen {
@@ -33,6 +34,83 @@ xo_board_clk: xo-board-clk {
 			#clock-cells = <0>;
 		};
 	};
+
+	vreg_conn_1p8: vreg_conn_1p8 {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_conn_1p8";
+		startup-delay-us = <4000>;
+		enable-active-high;
+		gpio = <&pm8150_gpios 1 GPIO_ACTIVE_HIGH>;
+	};
+
+	vreg_conn_pa: vreg_conn_pa {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_conn_pa";
+		startup-delay-us = <4000>;
+		enable-active-high;
+		gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
+	};
+
+	wcn6855-pmu {
+		compatible = "qcom,wcn6855-pmu";
+
+		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+		pinctrl-names = "default";
+
+		vddio-supply = <&vreg_conn_pa>;
+		vddaon-supply = <&vreg_s5a>;
+		vddpmu-supply = <&vreg_conn_1p8>;
+		vddrfa0p95-supply = <&vreg_s5a>;
+		vddrfa1p3-supply = <&vreg_s6a>;
+		vddrfa1p9-supply = <&vreg_l15a>;
+		vddpcie1p3-supply = <&vreg_s6a>;
+		vddpcie1p9-supply = <&vreg_l15a>;
+
+		bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+		wlan-enable-gpios = <&tlmm 98 GPIO_ACTIVE_HIGH>;
+
+		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 {
@@ -231,10 +309,33 @@ &pcie_phy {
 	status = "okay";
 };
 
+&pcieport0 {
+	wifi at 0 {
+		compatible = "pci17cb,1103";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		qcom,ath11k-calibration-variant = "QC_QCS615_Ride";
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+	};
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };
 
+&qupv3_id_1 {
+	status = "okay";
+};
+
 &rpmhcc {
 	clocks = <&xo_board_clk>;
 };
@@ -262,12 +363,42 @@ wake-pins {
 			bias-pull-up;
 		};
 	};
+
+	wlan_en_state: wlan-en-state {
+		pins = "gpio98";
+		function = "gpio";
+		drive-strength = <16>;
+		output-high;
+		bias-pull-up;
+	};
+
+	bt_en_state: bt-en-state {
+		pins = "gpio85";
+		function = "gpio";
+		output-low;
+		bias-pull-down;
+	};
 };
 
 &uart0 {
 	status = "okay";
 };
 
+&uart7 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn6855-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>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+	};
+};
+
 &watchdog {
 	clocks = <&sleep_clk>;
 };
diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
index 808e42f799a6..8465e96e0e8e 100644
--- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
@@ -819,7 +819,7 @@ opp-8000000 {
 			};
 		};
 
-		pcie at 0 {
+		pcieport0: pcie at 0 {
 			device_type = "pci";
 			reg = <0x0 0x0 0x0 0x0 0x0>;
 			bus-range = <0x01 0xff>;
-- 
2.34.1



From jtornosm at redhat.com  Tue Dec  3 00:04:07 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Tue,  3 Dec 2024 09:04:07 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <7ccd4b98-9557-4a8b-b493-e01b157c71e2@quicinc.com>
References: <7ccd4b98-9557-4a8b-b493-e01b157c71e2@quicinc.com>
Message-ID: <20241203080407.100913-1-jtornosm@redhat.com>

Sorry, but your solution is not working for me.
We need to be able to setup 2 APs, as it was possible before, and with your
interface combinations it is not possible either.
I was trying to create a second interface combination to recover the old
scenario as well, but I couldn't, that is the reason why I have implemented
this parameter.

Thanks

Best regards
Jose Ignacio



From quic_yuzha at quicinc.com  Tue Dec  3 00:28:45 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Tue, 3 Dec 2024 16:28:45 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241203080407.100913-1-jtornosm@redhat.com>
References: <7ccd4b98-9557-4a8b-b493-e01b157c71e2@quicinc.com>
 <20241203080407.100913-1-jtornosm@redhat.com>
Message-ID: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>



On 12/3/2024 4:04 PM, Jose Ignacio Tornos Martinez wrote:
> Sorry, but your solution is not working for me.
> We need to be able to setup 2 APs, as it was possible before, and with your
> interface combinations it is not possible either.
> I was trying to create a second interface combination to recover the old
> scenario as well, but I couldn't, that is the reason why I have implemented
> this parameter.
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 
Which chip do you use?

I can't be sure about your scenario, but based on your description, I 
tried it on the 6855 and it works:
sh-5.1# iw dev
phy#0
         Interface wlan2
                 ifindex 6
                 wdev 0x3
                 addr 12:03:7f:21:84:11
                 ssid QSoftAP2
                 type AP
                 channel 149 (5745 MHz), width: 20 MHz, center1: 5745 MHz
                 txpower 18.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0
         Interface wlan1
                 ifindex 5
                 wdev 0x2
                 addr 02:03:7f:21:84:11
                 ssid QSoftAP1
                 type AP
                 channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
                 txpower 5.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0
         Interface wlan0
                 ifindex 4
                 wdev 0x1
                 addr 00:03:7f:21:84:11
                 type managed
                 txpower 18.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0


From jtornosm at redhat.com  Tue Dec  3 01:48:20 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Tue,  3 Dec 2024 10:48:20 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>
References: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>
Message-ID: <20241203094820.106225-1-jtornosm@redhat.com>

> Which chip do you use?
Since I am not totally sure about the useful information, let me show you
the kernel logs:
$ dmesg | grep ath11k 
[    3.659388] ath11k_pci 0000:01:00.0: BAR 0 [mem 0x84200000-0x843fffff 64bit]: assigned
[    3.659405] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[    3.659649] ath11k_pci 0000:01:00.0: MSI vectors: 32
[    3.659653] ath11k_pci 0000:01:00.0: wcn6855 hw2.1
[    4.871571] ath11k_pci 0000:01:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0210
[    4.871586] ath11k_pci 0000:01: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
[    5.241485] ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0

If I try to setup 2 APs with your interface combination I get this:
# iw list | grep -A6 "valid interface combinations:"
	valid interface combinations:
		 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

		 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
		   total <= 3, #channels <= 2, STA/AP BI must match
	HT Capability overrides:
# iw dev
phy#0
	Interface wlp1s0_1
		ifindex 6
		wdev 0x4
		addr a2:42:d2:1e:89:a3
		type managed
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0_0
		ifindex 5
		wdev 0x3
		addr 52:e9:be:33:6a:61
		ssid test-qe-wpa2-psk
		type AP
		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
		txpower 14.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0
		ifindex 3
		wdev 0x1
		addr c8:94:02:b5:fe:fb
		type managed
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
Or even this with no AP up:
# iw dev
phy#0
	Interface wlp1s0_1
		ifindex 6
		wdev 0x4
		addr ca:e5:84:22:10:ec
		type managed
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0_0
		ifindex 5
		wdev 0x3
		addr 9e:4e:c5:ea:4c:e9
		type AP
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0
		ifindex 3
		wdev 0x1
		addr c8:94:02:b5:fe:fb
		type managed
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

If I use the parameter to ignore the feature and configure the interface combination as before:
# iw list | grep -A4 "valid interface combinations:"
	valid interface combinations:
		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

	HT Capability overrides:
# iw dev
phy#1
	Interface wlp1s0_1
		ifindex 7
		wdev 0x100000004
		addr 82:90:89:90:c1:37
		ssid test-qe-wpa3-psk
		type AP
		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0_0
		ifindex 6
		wdev 0x100000003
		addr 6a:ef:d0:db:10:f0
		ssid test-qe-wpa2-psk
		type AP
		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0
	Interface wlp1s0
		ifindex 4
		wdev 0x100000001
		addr c8:94:02:b5:fe:fb
		type managed
		txpower 16.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

Thanks

Best regards
Jose Ignacio



From quic_yuzha at quicinc.com  Tue Dec  3 02:48:58 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Tue, 3 Dec 2024 18:48:58 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241203094820.106225-1-jtornosm@redhat.com>
References: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>
 <20241203094820.106225-1-jtornosm@redhat.com>
Message-ID: <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>



On 12/3/2024 5:48 PM, Jose Ignacio Tornos Martinez wrote:
>> Which chip do you use?
> Since I am not totally sure about the useful information, let me show you
> the kernel logs:
> $ dmesg | grep ath11k
> [    3.659388] ath11k_pci 0000:01:00.0: BAR 0 [mem 0x84200000-0x843fffff 64bit]: assigned
> [    3.659405] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
> [    3.659649] ath11k_pci 0000:01:00.0: MSI vectors: 32
> [    3.659653] ath11k_pci 0000:01:00.0: wcn6855 hw2.1
> [    4.871571] ath11k_pci 0000:01:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0210
> [    4.871586] ath11k_pci 0000:01: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
> [    5.241485] ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
> 
yes, you also use wcn6855 hw2.1.
> If I try to setup 2 APs with your interface combination I get this:
> # iw list | grep -A6 "valid interface combinations:"
> 	valid interface combinations:
> 		 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> 		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
> 
> 		 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> 		   total <= 3, #channels <= 2, STA/AP BI must match
> 	HT Capability overrides:
2 combinations are to support DBS and DFS.
Combinations is correct. channels=2, max interfaces=3.

And you want setup sta + sap + sap, right?
When up the second sap will meet error? Could you pls share the error logs?

I'm not very sure if you add all interface with managed type, and do 
"ifconfig xxx up" before running hostapd.

You can try add second and third interface with
"iw dev xx interface add xx type __ap".


> # iw dev
> phy#0
> 	Interface wlp1s0_1
> 		ifindex 6
> 		wdev 0x4
> 		addr a2:42:d2:1e:89:a3
> 		type managed
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0_0
> 		ifindex 5
> 		wdev 0x3
> 		addr 52:e9:be:33:6a:61
> 		ssid test-qe-wpa2-psk
> 		type AP
> 		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> 		txpower 14.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0
> 		ifindex 3
> 		wdev 0x1
> 		addr c8:94:02:b5:fe:fb
> 		type managed
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> Or even this with no AP up:
> # iw dev
> phy#0
> 	Interface wlp1s0_1
> 		ifindex 6
> 		wdev 0x4
> 		addr ca:e5:84:22:10:ec
> 		type managed
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0_0
> 		ifindex 5
> 		wdev 0x3
> 		addr 9e:4e:c5:ea:4c:e9
> 		type AP
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0
> 		ifindex 3
> 		wdev 0x1
> 		addr c8:94:02:b5:fe:fb
> 		type managed
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 
> If I use the parameter to ignore the feature and configure the interface combination as before:
> # iw list | grep -A4 "valid interface combinations:"
> 	valid interface combinations:
> 		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> 		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
> 
> 	HT Capability overrides:
> # iw dev
> phy#1
> 	Interface wlp1s0_1
> 		ifindex 7
> 		wdev 0x100000004
> 		addr 82:90:89:90:c1:37
> 		ssid test-qe-wpa3-psk
> 		type AP
> 		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0_0
> 		ifindex 6
> 		wdev 0x100000003
> 		addr 6a:ef:d0:db:10:f0
> 		ssid test-qe-wpa2-psk
> 		type AP
> 		channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 	Interface wlp1s0
> 		ifindex 4
> 		wdev 0x100000001
> 		addr c8:94:02:b5:fe:fb
> 		type managed
> 		txpower 16.00 dBm
> 		multicast TXQ:
> 			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
> 			0	0	0	0	0	0	0	0		0
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From dmitry.baryshkov at linaro.org  Tue Dec  3 05:08:53 2024
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Tue, 3 Dec 2024 15:08:53 +0200
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
In-Reply-To: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
References: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
Message-ID: <vpnvycgbjtksjbktiksaltb73w34ogdxt5satz7cpmel63j3mm@aqvih2idpdfw>

On Tue, Dec 03, 2024 at 02:03:18PM +0800, Yu Zhang(Yuriy) wrote:
> Add a node for the PMU module of the WCN6855 present on the qcs615
> board. Assign its LDO power outputs to the existing WiFi/BT module.
> 
> This patch depends on below patch series:
> - base
> https://lore.kernel.org/all/20241104-add_initial_support_for_qcs615-v5-0-9dde8d7b80b0 at quicinc.com/
> - pmic
> https://lore.kernel.org/all/20241202-adds-spmi-pmic-peripherals-for-qcs615-v6-0-bdd306b4940d at quicinc.com/
> - pci
> https://lore.kernel.org/all/20241122023314.1616353-1-quic_ziyuzhan at quicinc.com/

This doesn't belong to the commit message. The list of dependncies makes
no sense once they land upstream. Please switch to the b4 tool, use b4
prep --edit-cover to list such info (it will be automatically added to a
non-commit part of the email) and b4 prep --edit-deps to list
dependncies in a machine-readable format.

The patch itself looks good to me.

> 
> Signed-off-by: Yu Zhang(Yuriy) <quic_yuzha at quicinc.com>
> 
> 

-- 
With best wishes
Dmitry


From jtornosm at redhat.com  Tue Dec  3 08:33:59 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Tue,  3 Dec 2024 17:33:59 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
References: <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
Message-ID: <20241203163359.129185-1-jtornosm@redhat.com>

> And you want setup sta + sap + sap, right?
Your proposed interface combination fails as well for me if I am just
setting 2APs.
> When up the second sap will meet error? Could you pls share the error
> logs?
This is the log that is appearing:
[   61.909165] 8021q: 802.1Q VLAN Support v1.8
[   62.227530] ath11k_pci 0000:01:00.0: failed to create vdev 3, reached max vdev limit 3
It is appearing after configuring both APs when only one AP is up and when
both are down (see my previous 'iw dev' outputs).

> I'm not very sure if you add all interface with managed type, and do
> "ifconfig xxx up" before running hostapd.
Yes, I am setting the link up before running hostapd.
>You can try add second and third interface with
> "iw dev xx interface add xx type __ap".
And yes, I am doing like that for both APs.
Please, take into account that everything is working with the old interface
configuration and when it is set with the parameter (no error log), but it
is not working for me with your interface combination.
Have you tried with 2.4GHz band?

Thanks

Best regards
Jose Ignacio



From l.stach at pengutronix.de  Tue Dec  3 09:45:50 2024
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 03 Dec 2024 18:45:50 +0100
Subject: [PATCH 09/22] drm/etnaviv: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241115-converge-secs-to-jiffies-v1-9-19aadc34941b@linux.microsoft.com>
References: <20241115-converge-secs-to-jiffies-v1-0-19aadc34941b@linux.microsoft.com>
	 <20241115-converge-secs-to-jiffies-v1-9-19aadc34941b@linux.microsoft.com>
Message-ID: <fc624e3fd4a4a38dedf02e31be9e4f1c85fb40a0.camel@pengutronix.de>

Am Freitag, dem 15.11.2024 um 21:22 +0000 schrieb Easwar Hariharan:
> Changes made with the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
Thanks, applied to etnaviv/next.

Regards,
Lucas

> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 721d633aece9d4c81f0019e4c55884f26ee61c60..0f5a2c885d0ab7029c7248e15d6ea3c31823b782 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -100,7 +100,7 @@ int etnaviv_cmdbuf_init(struct etnaviv_cmdbuf_suballoc *suballoc,
>  		mutex_unlock(&suballoc->lock);
>  		ret = wait_event_interruptible_timeout(suballoc->free_event,
>  						       suballoc->free_space,
> -						       msecs_to_jiffies(10 * 1000));
> +						       secs_to_jiffies(10));
>  		if (!ret) {
>  			dev_err(suballoc->dev,
>  				"Timeout waiting for cmdbuf space\n");
> 



From quic_yuzha at quicinc.com  Tue Dec  3 19:21:25 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Wed, 4 Dec 2024 11:21:25 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241203163359.129185-1-jtornosm@redhat.com>
References: <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
 <20241203163359.129185-1-jtornosm@redhat.com>
Message-ID: <1b09c2c9-53bd-4960-b09c-7468f506b0a3@quicinc.com>



On 12/4/2024 12:33 AM, Jose Ignacio Tornos Martinez wrote:
>> And you want setup sta + sap + sap, right?
> Your proposed interface combination fails as well for me if I am just
> setting 2APs.
>> When up the second sap will meet error? Could you pls share the error
>> logs?
> This is the log that is appearing:
> [   61.909165] 8021q: 802.1Q VLAN Support v1.8
> [   62.227530] ath11k_pci 0000:01:00.0: failed to create vdev 3, reached max vdev limit 3
> It is appearing after configuring both APs when only one AP is up and when
> both are down (see my previous 'iw dev' outputs).
> 
>> I'm not very sure if you add all interface with managed type, and do
>> "ifconfig xxx up" before running hostapd.
> Yes, I am setting the link up before running hostapd.
>> You can try add second and third interface with
>> "iw dev xx interface add xx type __ap".
> And yes, I am doing like that for both APs.
Pls try add interface with type __ap or directly use hostapd up the ap 
interfaces that will re-type managed to ap.

> Please, take into account that everything is working with the old interface
> configuration and when it is set with the parameter (no error log), but it
> is not working for me with your interface combination.
f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces") update about 
interface combination limits.

If chip support DBS, station interfaces max is 2 that why you can't up 
the 3rd managed type interface. You better add interface with ap type.

> Have you tried with 2.4GHz band?
> 
2.4GHz works fine also.
sh-5.1# iw dev
phy#0
         Interface wlan2
                 ifindex 6
                 wdev 0x3
                 addr 12:03:7f:21:84:11
                 ssid QSoftAP2
                 type AP
                 channel 6 (2437 MHz), width: 20 MHz, center1: 2437 MHz
                 txpower 5.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0
         Interface wlan1
                 ifindex 5
                 wdev 0x2
                 addr 02:03:7f:21:84:11
                 ssid QSoftAP1
                 type AP
                 channel 6 (2437 MHz), width: 20 MHz, center1: 2437 MHz
                 txpower 18.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0
         Interface wlan0
                 ifindex 4
                 wdev 0x1
                 addr 00:03:7f:21:84:11
                 type managed
                 txpower 5.00 dBm
                 multicast TXQ:
                         qsz-byt qsz-pkt flows   drops   marks   overlmt 
hashcol tx-bytes        tx-packets
                         0       0       0       0       0       0 
0       0               0

> Thanks
> 
> Best regards
> Jose Ignacio
> 



From jtornosm at redhat.com  Tue Dec  3 23:51:28 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Wed,  4 Dec 2024 08:51:28 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <1b09c2c9-53bd-4960-b09c-7468f506b0a3@quicinc.com>
References: <1b09c2c9-53bd-4960-b09c-7468f506b0a3@quicinc.com>
Message-ID: <20241204075128.5547-1-jtornosm@redhat.com>

> Pls try add interface with type __ap or directly use hostapd up the ap 
> interfaces that will re-type managed to ap.
This is what I am doing.

> f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces") update about 
> interface combination limits.
My patch by means of a parameter allows to come back to the original
interface combination (before f019f4dff2e4 and not the current one that
you comment), so as I commented, this is the interface combination that 
I am finally using to setup the two APs:
# iw list | grep -A4 "valid interface combinations:"
 	valid interface combinations:
 		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
 		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
 
 	HT Capability overrides:
And I repeat that with that, my setup is working (no error log).

> If chip support DBS, station interfaces max is 2 that why you can't up 
> the 3rd managed type interface. You better add interface with ap type.
Ok, but as I commented this is what I am doing.
Just to clarify, only with your proposed interface combination I am getting
problems with a 3rd managed type interface.

> 2.4GHz works fine also.
That is great.

Ok, at this point, as I need my setup, in order to allow me to debug and
get the differences, could you share how you are configuring the two APs to
test and debug here?

Thanks

Best regards
Jose Ignacio



From jtornosm at redhat.com  Wed Dec  4 00:30:39 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Wed,  4 Dec 2024 09:30:39 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <20241204075128.5547-1-jtornosm@redhat.com>
References: <20241204075128.5547-1-jtornosm@redhat.com>
Message-ID: <20241204083039.7103-1-jtornosm@redhat.com>

I can share mine too if you want.

Thanks

Best regards
Jose Ignacio



From quic_yuzha at quicinc.com  Wed Dec  4 01:18:54 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Wed, 4 Dec 2024 17:18:54 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241204075128.5547-1-jtornosm@redhat.com>
References: <1b09c2c9-53bd-4960-b09c-7468f506b0a3@quicinc.com>
 <20241204075128.5547-1-jtornosm@redhat.com>
Message-ID: <f75a1655-fa5d-4675-85d0-b9b97dceba6f@quicinc.com>



On 12/4/2024 3:51 PM, Jose Ignacio Tornos Martinez wrote:
>> Pls try add interface with type __ap or directly use hostapd up the ap
>> interfaces that will re-type managed to ap.
> This is what I am doing.
But I see your interfaces all be added with managed? right?
> 
>> f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces") update about
>> interface combination limits.
> My patch by means of a parameter allows to come back to the original
> interface combination (before f019f4dff2e4 and not the current one that
> you comment), so as I commented, this is the interface combination that
> I am finally using to setup the two APs:
> # iw list | grep -A4 "valid interface combinations:"
>   	valid interface combinations:
>   		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
>   		   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
>   
>   	HT Capability overrides:
> And I repeat that with that, my setup is working (no error log).
> 
>> If chip support DBS, station interfaces max is 2 that why you can't up
>> the 3rd managed type interface. You better add interface with ap type.
> Ok, but as I commented this is what I am doing.
> Just to clarify, only with your proposed interface combination I am getting
> problems with a 3rd managed type interface.
> 
>> 2.4GHz works fine also.
> That is great.
> 
> Ok, at this point, as I need my setup, in order to allow me to debug and
> get the differences, could you share how you are configuring the two APs to
> test and debug here?
> 
sure.

apply f019f4dff2e4 ("wifi: ath11k: support 2 station interfaces")
apply 
https://lore.kernel.org/all/20241127022742.4016870-1-quic_yuzha at quicinc.com/

Test steps:
1. add interface
#iw dev wlan0 interface add wlan1 type __ap
#iw dev wlan0 interface add wlan2 type __ap

2.run hostapd
#hostapd hostapd1.conf &
#hostapd hostapd2.conf &

refer hostapd.conf:
---
interface=wlan1
driver=nl80211
ssid=QSoftAP1
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=12345678
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
rsn_pairwise=CCMP
---
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From prestwoj at gmail.com  Wed Dec  4 08:57:36 2024
From: prestwoj at gmail.com (James Prestwood)
Date: Wed, 4 Dec 2024 08:57:36 -0800
Subject: Connection timeouts (NL80211_TIMEOUT_UNSPECIFIED) after
 disconnect/association timeout
Message-ID: <441e9883-1efc-498b-ba33-6a4f12443f3b@gmail.com>

Hi,

I noticed this behavior where in some cases if the client gets 
disconnect or fails to roam due to an association timeout the next 
connection attempt will fail with a timeout of 
NL80211_TIMEOUT_UNSPECIFIED as the reason. Briefly looking at the kernel 
code in nl80211/sme.c:cfg80211_conn_do_work() this appears to be the 
default value passed in, so its hitting one of the cases that aren't 
auth/assoc related. There are no kernel logs when this happens. The 
supplicant fails multiple times continuing to iterate BSS's until it 
finally is able to connect a few seconds later. In some _very_ rare 
cases I have seen the client never able to reconnect to any BSS's, it 
just loops over all BSS with the same NL80211_TIMEOUT_UNSPECIFIED error 
indefinitely until a customer notices and reboots the client.

I see this behavior on kernel 6.2 and 6.8 (that's all our clients run at 
the moment) and on both ath10k and ath11k drivers. I'm not able to get 
this to happen with mac80211_hwsim fwiw. Prior to switching to 6.2 (and 
6.8) we were on 5.15 and I never saw this happen.

Below are some logs from the kernel and IWD. Lots of irrelevant lines 
have been removed to be more concise.

tl;dr

1. Got an association timeout attempting to roam, disconnected

2. Scanned (~1 second), plenty of available BSS's

3. Failed to connect to 4 different BSS's in a row with 
NL80211_TIMEOUT_UNSPECIFIED ("reason: 0")

4. Failed to connect to the next BSS with an auth timeout (no issue 
here, this just happens sometimes)

5. Finally able to connect to another BSS (oddly, the original BSS we 
were roaming away from)


Dec 04 11:42:34 iwd[391]: event: roam-info, bss: **:**:**:13:06:ea, 
signal: -87, load: 63/255
Dec 04 11:42:34 iwd[391]: event: state, old: connected, new: ft-roaming
Dec 04 11:42:34 kernel: wlan0: disconnect from AP **:**:**:13:07:b6 for 
new assoc to **:**:**:13:06:ea
Dec 04 11:42:34 kernel: wlan0: associate with **:**:**:13:06:ea (try 1/3)
Dec 04 11:42:34 kernel: wlan0: associate with **:**:**:13:06:ea (try 2/3)
Dec 04 11:42:34 kernel: wlan0: associate with **:**:**:13:06:ea (try 3/3)
Dec 04 11:42:34 kernel: wlan0: association with **:**:**:13:06:ea timed out
Dec 04 11:42:34 iwd[391]: src/netdev.c:netdev_associate_event()
Dec 04 11:42:34 iwd[391]: event: association-timeout,
Dec 04 11:42:34 iwd[391]: event: state, old: ft-roaming, new: disconnected
Dec 04 11:42:34 iwd[391]: event: state, old: disconnected, new: 
autoconnect_quick
Dec 04 11:42:34 iwd[391]: src/station.c:station_quick_scan_triggered() 
Quick scan triggered for wlan0
Dec 04 11:42:35 iwd[391]: src/scan.c:scan_notify() Scan notification New 
Scan Results(34)
Dec 04 11:42:35 iwd[391]: src/netdev.c:netdev_link_notify() event 16 on 
ifindex 5
Dec 04 11:42:35 iwd[391]: event: connect-info, ssid: <redacted>, bss: 
**:**:**:12:fc:f8, signal: -56, load: 65/255
Dec 04 11:42:35 iwd[391]: event: state, old: autoconnect_quick, new: 
connecting (auto)
Dec 04 11:42:35 iwd[391]: event: connect-timeout, reason: 0
Dec 04 11:42:35 iwd[391]: event: connect-info, ssid: <redacted>, bss: 
**:**:**:12:fd:56, signal: -62, load: 69/255
Dec 04 11:42:36 iwd[391]: event: connect-timeout, reason: 0
Dec 04 11:42:36 iwd[391]: event: connect-info, ssid: <redacted>, bss: 
**:**:**:13:08:33, signal: -60, load: 53/255
Dec 04 11:42:36 iwd[391]: event: connect-timeout, reason: 0
Dec 04 11:42:36 iwd[391]: event: connect-info, ssid: <redacted>, bss: 
**:**:**:12:fd:34, signal: -67, load: 43/255
Dec 04 11:42:36 iwd[391]: event: connect-timeout, reason: 0
Dec 04 11:42:36 kernel: wlan0: authenticate with **:**:**:13:07:b6
Dec 04 11:42:36 iwd[391]: event: connect-failed, status: 1
Dec 04 11:42:36 iwd[391]: event: connect-info, ssid: <redacted>, bss: 
**:**:**:13:07:b6, signal: -70, load: 28/255
Dec 04 11:42:36 iwd[391]: src/station.c:station_try_next_bss() 
Attempting to connect to next BSS **:**:**:13:07:b6
Dec 04 11:42:36 kernel: wlan0: send auth to **:**:**:13:07:b6 (try 1/3)
Dec 04 11:42:36 kernel: wlan0: send auth to **:**:**:13:07:b6 (try 2/3)
Dec 04 11:42:36 kernel: wlan0: authenticated
Dec 04 11:42:36 kernel: wlan0: associate with **:**:**:13:07:b6 (try 1/3)
Dec 04 11:42:36 kernel: wlan0: RX AssocResp from **:**:**:13:07:b6 
(capab=0x1511 status=0 aid=3)


While writing this email I also saw it happen live while I had a 
mac80211/cfg80211 trace running. In this recent case it failed on 12 
consecutive BSS's with the unspecified timeout. That trace log is 
attached, maybe could shed more light on this.

Thanks,

James
-------------- next part --------------
             iwd-391   [001] 443702.243059: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:13:08:28, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [001] 443702.243062: rdev_scan:            phy0
             iwd-391   [001] 443702.243066: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [001] 443702.244152: drv_return_int:       phy0 - 0
             iwd-391   [001] 443702.244155: rdev_return_int:      phy0, returned: 0
 locus_nodelet_m-3180  [002] 443702.396499: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [002] 443702.414460: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [002] 443702.414467: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:13:08:28, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [001] 443702.414655: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [001] 443702.414656: rdev_return_int:      phy0, returned: 0
             iwd-391   [001] 443702.414673: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:13:04:30, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [001] 443702.414675: rdev_scan:            phy0
             iwd-391   [001] 443702.414679: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [001] 443702.415075: drv_return_int:       phy0 - 0
             iwd-391   [001] 443702.415076: rdev_return_int:      phy0, returned: 0
           <...>-1581103 [001] 443702.449827: rdev_get_tx_power:    phy0, wdev(2)
           <...>-1581103 [001] 443702.449829: rdev_return_int_int:  phy0, function returns: 0, function filled: 21
          <idle>-0     [002] 443702.568112: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [001] 443702.586437: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [001] 443702.586445: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:13:04:30, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443702.586642: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [000] 443702.586644: rdev_return_int:      phy0, returned: 0
             iwd-391   [000] 443702.586661: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:12:fc:f8, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443702.586663: rdev_scan:            phy0
             iwd-391   [000] 443702.586668: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [000] 443702.587074: drv_return_int:       phy0 - 0
             iwd-391   [000] 443702.587076: rdev_return_int:      phy0, returned: 0
          <idle>-0     [002] 443702.740116: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [000] 443702.758447: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [000] 443702.758457: cfg80211_get_bss:     phy0, band: 1, freq: 5660.000, e6:55:b8:12:fc:f8, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443702.758813: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [000] 443702.758814: rdev_return_int:      phy0, returned: 0
             iwd-391   [000] 443702.758838: cfg80211_get_bss:     phy0, band: 1, freq: 5745.000, e6:55:b8:13:07:0c, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443702.758840: rdev_scan:            phy0
             iwd-391   [000] 443702.758846: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [000] 443702.759234: drv_return_int:       phy0 - 0
             iwd-391   [000] 443702.759236: rdev_return_int:      phy0, returned: 0
           <...>-1581096 [002] 443702.782533: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5745.000(scan_width: 0) signal: -8600, tsb:443710012133474, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
           <...>-1581096 [002] 443702.782542: cfg80211_return_bss:  e6:55:b8:13:08:2c, band: 1, freq: 5745.000
           <...>-1581096 [002] 443702.782552: cfg80211_rx_mgmt:     wdev(2), freq: 5745.000, sig dbm: -86
           <...>-1581096 [002] 443702.782553: cfg80211_return_bool: returned false
           <...>-1581096 [002] 443702.786359: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5745.000(scan_width: 0) signal: -8400, tsb:443710015959255, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
           <...>-1581096 [002] 443702.786363: cfg80211_return_bss:  e6:55:b8:13:08:2c, band: 1, freq: 5745.000
           <...>-1581096 [002] 443702.786371: cfg80211_rx_mgmt:     wdev(2), freq: 5745.000, sig dbm: -84
           <...>-1581096 [002] 443702.786372: cfg80211_return_bool: returned false
           <...>-1564434 [001] 443702.786380: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5745.000(scan_width: 0) signal: -8400, tsb:443710015959255, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [001] 443702.786383: cfg80211_return_bss:  e6:55:b8:13:08:2c, band: 1, freq: 5745.000
          <idle>-0     [002] 443702.885337: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5745.000(scan_width: 0) signal: -8600, tsb:443710114935282, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
          <idle>-0     [002] 443702.885342: cfg80211_return_bss:  e2:55:b8:13:08:2c, band: 1, freq: 5745.000
          <idle>-0     [002] 443702.885353: cfg80211_rx_mgmt:     wdev(2), freq: 5745.000, sig dbm: -86
          <idle>-0     [002] 443702.885354: cfg80211_return_bool: returned false
           <...>-3143  [002] 443702.912278: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [003] 443702.926446: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [003] 443702.926465: cfg80211_get_bss:     phy0, band: 1, freq: 5745.000, e6:55:b8:13:07:0c, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443702.926671: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [003] 443702.926673: rdev_return_int:      phy0, returned: 0
             iwd-391   [003] 443702.926692: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:13:08:03, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443702.926693: rdev_scan:            phy0
             iwd-391   [003] 443702.926697: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [002] 443702.938222: drv_return_int:       phy0 - 0
             iwd-391   [002] 443702.938224: rdev_return_int:      phy0, returned: 0
 locus_nodelet_m-486852 [002] 443703.080131: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [003] 443703.114439: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [003] 443703.114450: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:13:08:03, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443703.114669: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [000] 443703.114672: rdev_return_int:      phy0, returned: 0
             iwd-391   [000] 443703.114696: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:12:fd:59, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [000] 443703.114699: rdev_scan:            phy0
             iwd-391   [000] 443703.114704: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [002] 443703.115119: drv_return_int:       phy0 - 0
             iwd-391   [002] 443703.115121: rdev_return_int:      phy0, returned: 0
          <idle>-0     [002] 443703.268118: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [000] 443703.306413: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [000] 443703.306421: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:12:fd:59, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.306638: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [002] 443703.306640: rdev_return_int:      phy0, returned: 0
             iwd-391   [002] 443703.306661: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:12:fd:56, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.306664: rdev_scan:            phy0
             iwd-391   [002] 443703.306669: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [002] 443703.307173: drv_return_int:       phy0 - 0
             iwd-391   [002] 443703.307174: rdev_return_int:      phy0, returned: 0
           <...>-1581114 [001] 443703.449869: rdev_get_tx_power:    phy0, wdev(2)
           <...>-1581114 [001] 443703.449871: rdev_return_int_int:  phy0, function returns: 0, function filled: 21
          <idle>-0     [002] 443703.460100: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [000] 443703.475100: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [000] 443703.475111: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:12:fd:56, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.475319: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [002] 443703.475320: rdev_return_int:      phy0, returned: 0
             iwd-391   [002] 443703.475342: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:13:08:27, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.475344: rdev_scan:            phy0
             iwd-391   [002] 443703.475348: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [002] 443703.477060: drv_return_int:       phy0 - 0
             iwd-391   [002] 443703.477066: rdev_return_int:      phy0, returned: 0
          <idle>-0     [002] 443703.628767: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [000] 443703.646413: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [000] 443703.646425: cfg80211_get_bss:     phy0, band: 1, freq: 5580.000, e6:55:b8:13:08:27, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.646718: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [002] 443703.646720: rdev_return_int:      phy0, returned: 0
             iwd-391   [002] 443703.646744: cfg80211_get_bss:     phy0, band: 1, freq: 5680.000, e6:55:b8:13:03:f5, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.646746: rdev_scan:            phy0
             iwd-391   [002] 443703.646752: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [001] 443703.647626: drv_return_int:       phy0 - 0
             iwd-391   [001] 443703.647630: rdev_return_int:      phy0, returned: 0
          <idle>-0     [002] 443703.800194: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [003] 443703.814428: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [003] 443703.814436: cfg80211_get_bss:     phy0, band: 1, freq: 5680.000, e6:55:b8:13:03:f5, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.814714: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [002] 443703.814716: rdev_return_int:      phy0, returned: 0
             iwd-391   [002] 443703.814740: cfg80211_get_bss:     phy0, band: 1, freq: 5825.000, e6:55:b8:13:07:01, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [002] 443703.814742: rdev_scan:            phy0
             iwd-391   [002] 443703.814747: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [002] 443703.815269: drv_return_int:       phy0 - 0
             iwd-391   [002] 443703.815271: rdev_return_int:      phy0, returned: 0
           <...>-3692  [002] 443703.968177: api_scan_completed:   phy0 aborted:0
    kworker/u8:3-1546696 [003] 443703.986774: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
    kworker/u8:3-1546696 [003] 443703.986783: cfg80211_get_bss:     phy0, band: 1, freq: 5825.000, e6:55:b8:13:07:01, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443703.987012: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [003] 443703.987014: rdev_return_int:      phy0, returned: 0
             iwd-391   [003] 443703.987031: cfg80211_get_bss:     phy0, band: 1, freq: 5765.000, e6:55:b8:12:f9:01, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443703.987033: rdev_scan:            phy0
             iwd-391   [003] 443703.987037: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [001] 443703.987419: drv_return_int:       phy0 - 0
             iwd-391   [001] 443703.987421: rdev_return_int:      phy0, returned: 0
           <...>-3172  [002] 443704.140472: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [001] 443704.154412: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [001] 443704.154419: cfg80211_get_bss:     phy0, band: 1, freq: 5765.000, e6:55:b8:12:f9:01, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443704.154617: rdev_set_cqm_rssi_config: phy0, netdev:wlan0(5), rssi_thold: -70, rssi_hyst: 5
             iwd-391   [003] 443704.154618: rdev_return_int:      phy0, returned: 0
             iwd-391   [003] 443704.154640: cfg80211_get_bss:     phy0, band: 1, freq: 5240.000, e6:55:b8:13:07:e5, buf: 0x6c, bss_type: 0, privacy: 0
             iwd-391   [003] 443704.154643: rdev_scan:            phy0
             iwd-391   [003] 443704.154648: drv_hw_scan:          phy0 vif:wlan0(2)
             iwd-391   [003] 443704.155031: drv_return_int:       phy0 - 0
             iwd-391   [003] 443704.155033: rdev_return_int:      phy0, returned: 0
          <idle>-0     [002] 443704.188742: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5240.000(scan_width: 0) signal: -8500, tsb:443711418365070, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
          <idle>-0     [002] 443704.188748: cfg80211_return_bss:  e6:55:b8:13:07:e5, band: 1, freq: 5240.000
          <idle>-0     [002] 443704.188757: cfg80211_rx_mgmt:     wdev(2), freq: 5240.000, sig dbm: -85
          <idle>-0     [002] 443704.188757: cfg80211_return_bool: returned false
          <idle>-0     [002] 443704.189076: cfg80211_inform_bss_frame: phy0, band: 1, freq: 5240.000(scan_width: 0) signal: -8600, tsb:443711418702116, detect_tsf:0, tsf_bssid: 00:00:00:00:00:00
          <idle>-0     [002] 443704.189078: cfg80211_return_bss:  e2:55:b8:13:07:e5, band: 1, freq: 5240.000
          <idle>-0     [002] 443704.189082: cfg80211_rx_mgmt:     wdev(2), freq: 5240.000, sig dbm: -86
          <idle>-0     [002] 443704.189082: cfg80211_return_bool: returned false
          <idle>-0     [002] 443704.308082: api_scan_completed:   phy0 aborted:0
           <...>-1564434 [003] 443704.322461: cfg80211_scan_done:   aborted: false, scan start (TSF): 0, tsf_bssid: 00:00:00:00:00:00
           <...>-1564434 [003] 443704.322469: cfg80211_get_bss:     phy0, band: 1, freq: 5240.000, e6:55:b8:13:07:e5, buf: 0x6c, bss_type: 0, privacy: 0
           <...>-1564434 [003] 443704.322472: cfg80211_return_bss:  e6:55:b8:13:07:e5, band: 1, freq: 5240.000
           <...>-1542519 [003] 443704.322490: cfg80211_get_bss:     phy0, band: 1, freq: 5240.000, e6:55:b8:13:07:e5, buf: 0x6c, bss_type: 0, privacy: 2
           <...>-1542519 [003] 443704.322491: cfg80211_return_bss:  e6:55:b8:13:07:e5, band: 1, freq: 5240.000
           <...>-1542519 [003] 443704.322492: rdev_auth:            phy0, netdev:wlan0(5), auth type: 0, bssid: e6:55:b8:13:07:e5


From jtornosm at redhat.com  Thu Dec  5 03:07:02 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Thu,  5 Dec 2024 12:07:02 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <f75a1655-fa5d-4675-85d0-b9b97dceba6f@quicinc.com>
References: <f75a1655-fa5d-4675-85d0-b9b97dceba6f@quicinc.com>
Message-ID: <20241205110704.232725-1-jtornosm@redhat.com>

> But I see your interfaces all be added with managed? right?
Yes

> Test steps:
> ...
Ok, I am using a bridge with the AP interfaces in addition but it is
the same.
Indeed I have tested in the same way as you too (even using your
hostapd.conf with the suitable name for the interfaces).
So I have started to debug (current upstream linux +
https://lore.kernel.org/all/20241127022742.4016870-1-quic_yuzha at quicinc.com/ +
dump_stack() in ath11k_mac_op_add_interface, enabling ath11k_dbg),
let me show you this:
[    5.703295] ath11k_pci 0000:01:00.0: vdev a2:d8:da:c5:7b:79 created, vdev_id 0
[    5.703304] CPU: 4 UID: 0 PID: 945 Comm: NetworkManager Tainted: G        W          6.12.0+ #104
[    5.703315] Tainted: [W]=WARN
[    5.703317] Hardware name: ASUS System Product Name/PRIME B660-PLUS D4, BIOS 1620 08/12/2022
[    5.703320] Call Trace:
[    5.703325]  <TASK>
[    5.703330]  dump_stack_lvl+0x5d/0x80
[    5.703344]  ath11k_mac_op_add_interface.cold+0x4ed/0xa92 [ath11k]
[    5.703399]  drv_add_interface+0x4f/0x230 [mac80211]
[    5.703512]  ieee80211_do_open+0x4b3/0x770 [mac80211]
[    5.703669]  ieee80211_open+0x8a/0x90 [mac80211]
...
[    5.804755] ath11k_pci 0000:01:00.0: vdev c8:94:02:b5:fe:fb created, vdev_id 1
[    5.804759] CPU: 1 UID: 0 PID: 1011 Comm: wpa_supplicant Tainted: G        W          6.12.0+ #104
[    5.804763] Tainted: [W]=WARN
[    5.804765] Hardware name: ASUS System Product Name/PRIME B660-PLUS D4, BIOS 1620 08/12/2022
[    5.804766] Call Trace:
[    5.804770]  <TASK>
[    5.804773]  dump_stack_lvl+0x5d/0x80
[    5.804783]  ath11k_mac_op_add_interface.cold+0x4ed/0xa92 [ath11k]
[    5.804809]  drv_add_interface+0x4f/0x230 [mac80211]
[    5.804868]  ieee80211_do_open+0x4b3/0x770 [mac80211]
[    5.804934]  nl80211_start_p2p_device+0x8b/0x160 [cfg80211]
...
So, since the normal sta interface and p2p interface are initialized,
with your proposed interface combination, only one AP interface can be
added for me (vdev limit is 3).
I like your idea to have a common interface combination set for everything,
but I think it is not possible here.
My patch with the new parameter at least allow to select what to do, dual
stations support or APs support for all the cases.

Thanks

Best regards
Jose Ignacio



From konrad.dybcio at oss.qualcomm.com  Thu Dec  5 09:14:48 2024
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Thu, 5 Dec 2024 18:14:48 +0100
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
In-Reply-To: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
References: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
Message-ID: <1ca062dd-8910-4caf-a133-0e5717b43540@oss.qualcomm.com>

On 3.12.2024 7:03 AM, Yu Zhang(Yuriy) wrote:
> Add a node for the PMU module of the WCN6855 present on the qcs615
> board. Assign its LDO power outputs to the existing WiFi/BT module.
> 

subject:

arm64: dts: qcom: qcs615-ride: ....

[...]

> +
> +	vreg_conn_1p8: vreg_conn_1p8 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vreg_conn_1p8";
> +		startup-delay-us = <4000>;
> +		enable-active-high;
> +		gpio = <&pm8150_gpios 1 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	vreg_conn_pa: vreg_conn_pa {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vreg_conn_pa";
> +		startup-delay-us = <4000>;
> +		enable-active-high;
> +		gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
> +	};

Are any of these boot-on?

> +
> +	wcn6855-pmu {
> +		compatible = "qcom,wcn6855-pmu";
> +
> +		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
> +		pinctrl-names = "default";
> +
> +		vddio-supply = <&vreg_conn_pa>;
> +		vddaon-supply = <&vreg_s5a>;
> +		vddpmu-supply = <&vreg_conn_1p8>;
> +		vddrfa0p95-supply = <&vreg_s5a>;
> +		vddrfa1p3-supply = <&vreg_s6a>;
> +		vddrfa1p9-supply = <&vreg_l15a>;
> +		vddpcie1p3-supply = <&vreg_s6a>;
> +		vddpcie1p9-supply = <&vreg_l15a>;
> +
> +		bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
> +		wlan-enable-gpios = <&tlmm 98 GPIO_ACTIVE_HIGH>;

Please move these properties above supplies, to match the style in
other recent device trees

[...]

>  &rpmhcc {
>  	clocks = <&xo_board_clk>;
>  };
> @@ -262,12 +363,42 @@ wake-pins {
>  			bias-pull-up;
>  		};
>  	};
> +
> +	wlan_en_state: wlan-en-state {
> +		pins = "gpio98";
> +		function = "gpio";
> +		drive-strength = <16>;
> +		output-high;
> +		bias-pull-up;
> +	};
> +
> +	bt_en_state: bt-en-state {
> +		pins = "gpio85";
> +		function = "gpio";
> +		output-low;
> +		bias-pull-down;
> +	};

These should be sorted by gpio idx

Konrad


From quic_yuzha at quicinc.com  Thu Dec  5 18:24:32 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Fri, 6 Dec 2024 10:24:32 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241205110704.232725-1-jtornosm@redhat.com>
References: <f75a1655-fa5d-4675-85d0-b9b97dceba6f@quicinc.com>
 <20241205110704.232725-1-jtornosm@redhat.com>
Message-ID: <0f24e115-e76d-4c8a-8a1b-591a157ee78e@quicinc.com>



On 12/5/2024 7:07 PM, Jose Ignacio Tornos Martinez wrote:
>> But I see your interfaces all be added with managed? right?
> Yes
> 
My point is that you can try setup with ap type interface, now 
combination limits not allow up 3 inferfaces with managed interface.
>> Test steps:
>> ...
> Ok, I am using a bridge with the AP interfaces in addition but it is
> the same.
> Indeed I have tested in the same way as you too (even using your
> hostapd.conf with the suitable name for the interfaces).
> So I have started to debug (current upstream linux +
> https://lore.kernel.org/all/20241127022742.4016870-1-quic_yuzha at quicinc.com/ +
> dump_stack() in ath11k_mac_op_add_interface, enabling ath11k_dbg),
> let me show you this:
> [    5.703295] ath11k_pci 0000:01:00.0: vdev a2:d8:da:c5:7b:79 created, vdev_id 0
> [    5.703304] CPU: 4 UID: 0 PID: 945 Comm: NetworkManager Tainted: G        W          6.12.0+ #104
> [    5.703315] Tainted: [W]=WARN
> [    5.703317] Hardware name: ASUS System Product Name/PRIME B660-PLUS D4, BIOS 1620 08/12/2022
> [    5.703320] Call Trace:
> [    5.703325]  <TASK>
> [    5.703330]  dump_stack_lvl+0x5d/0x80
> [    5.703344]  ath11k_mac_op_add_interface.cold+0x4ed/0xa92 [ath11k]
> [    5.703399]  drv_add_interface+0x4f/0x230 [mac80211]
> [    5.703512]  ieee80211_do_open+0x4b3/0x770 [mac80211]
> [    5.703669]  ieee80211_open+0x8a/0x90 [mac80211]
> ...
> [    5.804755] ath11k_pci 0000:01:00.0: vdev c8:94:02:b5:fe:fb created, vdev_id 1
> [    5.804759] CPU: 1 UID: 0 PID: 1011 Comm: wpa_supplicant Tainted: G        W          6.12.0+ #104
> [    5.804763] Tainted: [W]=WARN
> [    5.804765] Hardware name: ASUS System Product Name/PRIME B660-PLUS D4, BIOS 1620 08/12/2022
> [    5.804766] Call Trace:
> [    5.804770]  <TASK>
> [    5.804773]  dump_stack_lvl+0x5d/0x80
> [    5.804783]  ath11k_mac_op_add_interface.cold+0x4ed/0xa92 [ath11k]
> [    5.804809]  drv_add_interface+0x4f/0x230 [mac80211]
> [    5.804868]  ieee80211_do_open+0x4b3/0x770 [mac80211]
> [    5.804934]  nl80211_start_p2p_device+0x8b/0x160 [cfg80211]
> ...
> So, since the normal sta interface and p2p interface are initialized,
> with your proposed interface combination, only one AP interface can be
> added for me (vdev limit is 3).
> I like your idea to have a common interface combination set for everything,
> but I think it is not possible here.
> My patch with the new parameter at least allow to select what to do, dual
> stations support or APs support for all the cases.
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From quic_yuzha at quicinc.com  Thu Dec  5 19:22:44 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Fri, 6 Dec 2024 11:22:44 +0800
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
In-Reply-To: <1ca062dd-8910-4caf-a133-0e5717b43540@oss.qualcomm.com>
References: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
 <1ca062dd-8910-4caf-a133-0e5717b43540@oss.qualcomm.com>
Message-ID: <649dc6c0-f0e1-4dca-8f93-d0f81803cd70@quicinc.com>



On 12/6/2024 1:14 AM, Konrad Dybcio wrote:
> On 3.12.2024 7:03 AM, Yu Zhang(Yuriy) wrote:
>> Add a node for the PMU module of the WCN6855 present on the qcs615
>> board. Assign its LDO power outputs to the existing WiFi/BT module.
>>
> 
> subject:
> 
> arm64: dts: qcom: qcs615-ride: ....
> 
> [...]
> 
>> +
>> +	vreg_conn_1p8: vreg_conn_1p8 {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vreg_conn_1p8";
>> +		startup-delay-us = <4000>;
>> +		enable-active-high;
>> +		gpio = <&pm8150_gpios 1 GPIO_ACTIVE_HIGH>;
>> +	};
>> +
>> +	vreg_conn_pa: vreg_conn_pa {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vreg_conn_pa";
>> +		startup-delay-us = <4000>;
>> +		enable-active-high;
>> +		gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
>> +	};
> 
> Are any of these boot-on?
> 
Yes, these are used wcn6855-pmu?
      vddio-supply = <&vreg_conn_pa>;
      vddpmu-supply = <&vreg_conn_1p8>;
>> +
>> +	wcn6855-pmu {
>> +		compatible = "qcom,wcn6855-pmu";
>> +
>> +		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
>> +		pinctrl-names = "default";
>> +
>> +		vddio-supply = <&vreg_conn_pa>;
>> +		vddaon-supply = <&vreg_s5a>;
>> +		vddpmu-supply = <&vreg_conn_1p8>;
>> +		vddrfa0p95-supply = <&vreg_s5a>;
>> +		vddrfa1p3-supply = <&vreg_s6a>;
>> +		vddrfa1p9-supply = <&vreg_l15a>;
>> +		vddpcie1p3-supply = <&vreg_s6a>;
>> +		vddpcie1p9-supply = <&vreg_l15a>;
>> +
>> +		bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
>> +		wlan-enable-gpios = <&tlmm 98 GPIO_ACTIVE_HIGH>;
> 
> Please move these properties above supplies, to match the style in
> other recent device trees
> 
> [...]
> 
>>   &rpmhcc {
>>   	clocks = <&xo_board_clk>;
>>   };
>> @@ -262,12 +363,42 @@ wake-pins {
>>   			bias-pull-up;
>>   		};
>>   	};
>> +
>> +	wlan_en_state: wlan-en-state {
>> +		pins = "gpio98";
>> +		function = "gpio";
>> +		drive-strength = <16>;
>> +		output-high;
>> +		bias-pull-up;
>> +	};
>> +
>> +	bt_en_state: bt-en-state {
>> +		pins = "gpio85";
>> +		function = "gpio";
>> +		output-low;
>> +		bias-pull-down;
>> +	};
> 
> These should be sorted by gpio idx
> 
> Konrad



From konrad.dybcio at oss.qualcomm.com  Fri Dec  6 04:16:13 2024
From: konrad.dybcio at oss.qualcomm.com (Konrad Dybcio)
Date: Fri, 6 Dec 2024 13:16:13 +0100
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
In-Reply-To: <649dc6c0-f0e1-4dca-8f93-d0f81803cd70@quicinc.com>
References: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
 <1ca062dd-8910-4caf-a133-0e5717b43540@oss.qualcomm.com>
 <649dc6c0-f0e1-4dca-8f93-d0f81803cd70@quicinc.com>
Message-ID: <7107275e-1ccf-4f09-ada3-e082833d9364@oss.qualcomm.com>

On 6.12.2024 4:22 AM, Yu Zhang (Yuriy) wrote:
> 
> 
> On 12/6/2024 1:14 AM, Konrad Dybcio wrote:
>> On 3.12.2024 7:03 AM, Yu Zhang(Yuriy) wrote:
>>> Add a node for the PMU module of the WCN6855 present on the qcs615
>>> board. Assign its LDO power outputs to the existing WiFi/BT module.
>>>
>>
>> subject:
>>
>> arm64: dts: qcom: qcs615-ride: ....
>>
>> [...]
>>
>>> +
>>> +??? vreg_conn_1p8: vreg_conn_1p8 {
>>> +??????? compatible = "regulator-fixed";
>>> +??????? regulator-name = "vreg_conn_1p8";
>>> +??????? startup-delay-us = <4000>;
>>> +??????? enable-active-high;
>>> +??????? gpio = <&pm8150_gpios 1 GPIO_ACTIVE_HIGH>;
>>> +??? };
>>> +
>>> +??? vreg_conn_pa: vreg_conn_pa {
>>> +??????? compatible = "regulator-fixed";
>>> +??????? regulator-name = "vreg_conn_pa";
>>> +??????? startup-delay-us = <4000>;
>>> +??????? enable-active-high;
>>> +??????? gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
>>> +??? };
>>
>> Are any of these boot-on?
>>
> Yes, these are used wcn6855-pmu?
> ???? vddio-supply = <&vreg_conn_pa>;
> ???? vddpmu-supply = <&vreg_conn_1p8>;

What i meant is, whether these regulators are enabled at boot
time (i.e. without software intervention). If that's the case,
`regulator-boot-on;` should be added

Konrad


From tharvey at gateworks.com  Fri Dec  6 09:07:02 2024
From: tharvey at gateworks.com (Tim Harvey)
Date: Fri, 6 Dec 2024 09:07:02 -0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
Message-ID: <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>

On Mon, Nov 25, 2024 at 6:47?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>
>
>
> On 11/26/2024 2:02 AM, Tim Harvey wrote:
> > On Sun, Nov 24, 2024 at 11:23?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
> >>
> >>
> >>
> >> On 11/23/2024 8:43 AM, Tim Harvey wrote:
> >>> On Thu, Nov 21, 2024 at 9:51?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 11/22/2024 5:50 AM, Tim Harvey wrote:
> >>>>> On Tue, Nov 19, 2024 at 6:32?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 11/20/2024 4:16 AM, Tim Harvey wrote:
> >>>>>>> Greetings,
> >>>>>>>
> >>>>>>> I've got an ath11k card that is failing to init on an IMX8MM system
> >>>>>>> with 4GB of DRAM:
> >>>>>>> [    7.551582] ath11k_pci 0000:01:00.0: BAR 0 [mem
> >>>>>>> 0x18000000-0x181fffff 64bit]: assigned
> >>>>>>> [    7.551713] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
> >>>>>>> [    7.552401] ath11k_pci 0000:01:00.0: MSI vectors: 16
> >>>>>>> [    7.552440] ath11k_pci 0000:01:00.0: qcn9074 hw1.0
> >>>>>>> [    7.887186] mhi mhi0: Loaded FW: ath11k/QCN9074/hw1.0/amss.bin,
> >>>>>>> sha256: 5ee1b7b204541b5f99984f21d694ececaec08fbce1b520ffe6fe740b02a4afd7
> >>>>>>> [    8.435964] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0x0
> >>>>>>> board_id 0xff soc_id 0xffffffff
> >>>>>>> [    8.435991] ath11k_pci 0000:01:00.0: fw_version 0x270206d0
> >>>>>>> fw_build_timestamp 2022-08-04 12:48 fw_build_id
> >>>>>>> WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
> >>>>>>> [    8.441700] ath11k_pci 0000:01:00.0: Loaded FW:
> >>>>>>> ath11k/QCN9074/hw1.0/board-2.bin, sha256:
> >>>>>>> dbf0ca14aa1229eccd48f26f1026901b9718b143bd30b51b8ea67c84ba6207f1
> >>>>>>> [    9.753764] ath11k_pci 0000:01:00.0: Loaded FW:
> >>>>>>> ath11k/QCN9074/hw1.0/m3.bin, sha256:
> >>>>>>> b6d957f335073a15a8de809398e1506f0200a08747eaf7189c843cf519ffc1de
> >>>>>>> [    9.789791] ath11k_pci 0000:01:00.0: swiotlb buffer is full (sz:
> >>>>>>> 1048583 bytes), total 32768 (slots), used 2528 (slots)
> >>>>>>> [    9.789853] ath11k_pci 0000:01:00.0: failed to set up tcl_comp ring (0) :-12
> >>>>>>> [    9.790238] ath11k_pci 0000:01:00.0: failed to init DP: -12
> >>>>>>> root at noble-venice:~# cat /proc/cmdline
> >>>>>>> console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200
> >>>>>>> root=PARTUUID=5cdde84f-01 rootwait net.ifnames=0 cma=196M
> >>>>>>>
> >>>>>>> The IMX8MM's DRAM base is at 1GB so anything above 3GB hits the 32bit
> >>>>>>> address boundary. If I pass in a mem=3096M the device registers just
> >>>>>>> fine.
> >>>>>> yeah ... that parameter makes kernel alloc memory below 32bit boundary, thus swiotlb is not necessary.
> >>>>>
> >>>>> Hi Baochen,
> >>>>>
> >>>>> Yes, that makes sense as I step through the code. On IMX8M with DRAM
> >>>>> 3GB or less dma_capable(...) is true so swiotlb bounce buffers are not
> >>>>> needed.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I found this to be the case with modern kernels however I found
> >>>>>>> differing behavior with older kernels:
> >>>>>>> - 6.6 and 6.1 the device registers with 4GB DRAM but crashes on client connect
> >>>>>>> - 5.15 devices registers with 4GB DRAM and appears to work just fine
> >>>>>> are you using Linus' tree or the stable tree?
> >>>>>>
> >>>>>
> >>>>> For 6.6 I tested stable.
> >>>> can you try Linus's tree ? as I know the stable tree is possible to miss some important fix.
> >>>>
> >>>>>
> >>>>> This likely has something to do with commit dbd73acb22d8 ("wifi:
> >>>>> ath11k: enable 36 bit mask for stream DMA") but it would seem to me
> >>>>> that patch was trying to avoid the entire 32bit DMA limitation. Maybe
> >>>>> that patch sets the ath11k device DMA mask to 36 bits but maybe the
> >>>>> IMX8M PCI DMA is only capable of 32bits?
> >>>> that patch is making situation better, not worse. that said, it helps to avoid swiotlb in
> >>>> ath11k DMA, rather than to get it involved.
> >>>>
> >>>
> >>> Yes, that patch would be an improvement on systems capable of
> >>> addressing 64bit memory but not on the IMX8M which is seemingly
> >>> capable of only 32bit DMA over PCI.
> >>>
> >>>>>
> >>>>>>>
> >>>>>>> Could anyone explain what is going on here? Obviously there have been
> >>>>>>> changes at some point to start using swiotlb which I believe was all
> >>>>>>> about avoiding 32bit DMA limitations but I'm not clear how I should be
> >>>>>>> configuring this for IMX8MM with 4GB DRAM. Maybe my kernel IOMMU
> >>>>>>> configuration is incorrect somehow?
> >>>>>> there are quite some options associated with IOMMU, not sure which one might be causing this. But basically you may check:
> >>>>>>
> >>>>>> CONFIG_IOMMU_IOVA
> >>>>>> CONFIG_IOMMU_API
> >>>>>> CONFIG_IOMMU_SUPPORT
> >>>>>> CONFIG_IOMMU_DMA=y
> >>>>>>
> >>>>>
> >>>>> These are enabled which I believe appropriate for IMX8M. If I want to
> >>>>> utilize the full 4GB DRAM on IMX then I must use IOMMU and swiotlb
> >>>>> which would mean a performance hit due to copying mem to/from bounce
> >>>>> buffers not to mention the fact that I can't figure out how to
> >>>>> configure the system to avoid the 'swiotlb swiotlb buffer is full'
> >>>>> issue.
> >>>
> >>> My statement regarding needing an IOMMU above is wrong; apparently the
> >>> IMX8M SoC's don't have an IOMMU but the fact I have it enabled in the
> >>> kernel should be a don't-care. If I understand swiotlb correctly, if I
> >>> did have an IOMMU then it would be used instead of swiotlb.
> >>>
> >>>>>
> >>>>> Enabling CONFIG_SWIOTLB_DYNAMIC does not help nor does increasing the
> >>>>> number of slots - it has something to do with the number/size of DMA
> >>>>> buffers that ath11k is asking for:
> >>>> yeah, ath11k asks for fixed size DMA buffer regardless of that config.
> >>>>
> >>>>> # dmesg | grep swiotlb_tbl_map_single
> >>>>> [    5.237731] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16384 (slots=32768/    32)
> >>>>> [    5.247519] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16416 (slots=32768/    64)
> >>>>> [    5.261794] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16448 (slots=32768/    96)
> >>>>> [    5.275114] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16480 (slots=32768/   128)
> >>>>> [    5.287757] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16512 (slots=32768/   160)
> >>>>> [    5.299688] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16544 (slots=32768/   192)
> >>>>> [    5.312482] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16576 (slots=32768/   224)
> >>>>> [    5.324493] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16608 (slots=32768/   256)
> >>>>> [    5.337001] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16640 (slots=32768/   288)
> >>>>> [    5.346754] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16672 (slots=32768/   320)
> >>>>> [    5.356571] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16704 (slots=32768/   352)
> >>>>> [    5.366372] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16736 (slots=32768/   384)
> >>>>> [    5.376164] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16768 (slots=32768/   416)
> >>>>> [    5.385944] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16800 (slots=32768/   448)
> >>>>> [    5.395712] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16832 (slots=32768/   480)
> >>>>> [    5.408270] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16864 (slots=32768/   512)
> >>>>> [    5.419768] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16896 (slots=32768/   544)
> >>>>> [    5.430966] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16928 (slots=32768/   576)
> >>>>> [    5.442368] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16960 (slots=32768/   608)
> >>>>> [    5.452422] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 16992 (slots=32768/   640)
> >>>>> [    5.463507] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17024 (slots=32768/   672)
> >>>>> [    5.473536] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17056 (slots=32768/   704)
> >>>>> [    5.485661] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17088 (slots=32768/   736)
> >>>>> [    5.495404] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17120 (slots=32768/   768)
> >>>>> [    5.509626] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17152 (slots=32768/   800)
> >>>>> [    5.519353] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17184 (slots=32768/   832)
> >>>>> [    5.529077] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17216 (slots=32768/   864)
> >>>>> [    5.538799] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17248 (slots=32768/   896)
> >>>>> [    5.548517] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17280 (slots=32768/   928)
> >>>>> [    5.558238] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17312 (slots=32768/   960)
> >>>>> [    5.567965] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index= 17344 (slots=32768/   992)
> >>>>> [    5.578943] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=     0 (slots=32768/   992)
> >>>>> [    5.578964] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8192 (slots=32768/   993)
> >>>>> [    5.599793] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=    32 (slots=32768/   992)
> >>>>> [    5.599861] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  68B index=  8193 (slots=32768/   993)
> >>>>> [    5.609589] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=    64 (slots=32768/   993)
> >>>>> [    5.628921] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=    96 (slots=32768/   992)
> >>>>> [    5.638703] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  68B index= 17376 (slots=32768/   993)
> >>>>> [    5.649602] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   128 (slots=32768/   992)
> >>>>> [    5.659389] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   160 (slots=32768/   992)
> >>>>> [    5.674038] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  96B index= 17377 (slots=32768/   993)
> >>>>> [    5.685016] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   192 (slots=32768/   992)
> >>>>> [    5.694819] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   224 (slots=32768/   992)
> >>>>> [    5.694831] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index= 17378 (slots=32768/   993)
> >>>>> [    5.714194] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  40B index= 17379 (slots=32768/   994)
> >>>>> [    5.725089] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   256 (slots=32768/   992)
> >>>>> [    5.753507] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17380 (slots=32768/   996)
> >>>>> [    5.764668] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   288 (slots=32768/   992)
> >>>>> [    5.774456] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   320 (slots=32768/   992)
> >>>>> [    5.774620] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17384 (slots=32768/   996)
> >>>>> [    5.795091] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   352 (slots=32768/   992)
> >>>>> [    5.795241] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17388 (slots=32768/   996)
> >>>>> [    5.815724] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   384 (slots=32768/   992)
> >>>>> [    5.815884] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17392 (slots=32768/   996)
> >>>>> [    5.836357] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   416 (slots=32768/   992)
> >>>>> [    5.836368] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8194 (slots=32768/   993)
> >>>>> [    5.855856] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17396 (slots=32768/   997)
> >>>>> [    5.866818] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   448 (slots=32768/   992)
> >>>>> [    5.866978] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17400 (slots=32768/   996)
> >>>>> [    5.887451] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   480 (slots=32768/   992)
> >>>>> [    5.897231] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   512 (slots=32768/   992)
> >>>>> [    5.897389] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17404 (slots=32768/   996)
> >>>>> [    5.917866] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   544 (slots=32768/   992)
> >>>>> [    5.918026] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17408 (slots=32768/   996)
> >>>>> [    5.938489] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   576 (slots=32768/   992)
> >>>>> [    5.938642] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17412 (slots=32768/   996)
> >>>>> [    5.959121] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   608 (slots=32768/   992)
> >>>>> [    5.959135] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8195 (slots=32768/   993)
> >>>>> [    5.978619] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17416 (slots=32768/   997)
> >>>>> [    5.989588] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   640 (slots=32768/   992)
> >>>>> [    5.989738] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17420 (slots=32768/   996)
> >>>>> [    6.010215] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   672 (slots=32768/   992)
> >>>>> [    6.020001] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   704 (slots=32768/   992)
> >>>>> [    6.020158] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17424 (slots=32768/   996)
> >>>>> [    6.040643] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   736 (slots=32768/   992)
> >>>>> [    6.040798] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17428 (slots=32768/   996)
> >>>>> [    6.061287] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   768 (slots=32768/   992)
> >>>>> [    6.061437] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17432 (slots=32768/   996)
> >>>>> [    6.081918] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   800 (slots=32768/   992)
> >>>>> [    6.081929] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8196 (slots=32768/   993)
> >>>>> [    6.101409] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17436 (slots=32768/   997)
> >>>>> [    6.112375] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   832 (slots=32768/   992)
> >>>>> [    6.112528] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17440 (slots=32768/   996)
> >>>>> [    6.133004] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   864 (slots=32768/   992)
> >>>>> [    6.142785] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   896 (slots=32768/   992)
> >>>>> [    6.142949] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17444 (slots=32768/   996)
> >>>>> [    6.163426] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   928 (slots=32768/   992)
> >>>>> [    6.163576] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17448 (slots=32768/   996)
> >>>>> [    6.184058] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   960 (slots=32768/   992)
> >>>>> [    6.184208] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17452 (slots=32768/   996)
> >>>>> [    6.204691] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=   992 (slots=32768/   992)
> >>>>> [    6.204704] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8197 (slots=32768/   993)
> >>>>> [    6.224183] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17456 (slots=32768/   997)
> >>>>> [    6.235148] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1024 (slots=32768/   992)
> >>>>> [    6.235308] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 6224B index= 17460 (slots=32768/   996)
> >>>>> [    6.255777] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1056 (slots=32768/   992)
> >>>>> [    6.265552] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1088 (slots=32768/   992)
> >>>>> [    6.265633] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 2128B index= 17464 (slots=32768/   994)
> >>>>> [    6.286142] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1120 (slots=32768/   992)
> >>>>> [    6.286182] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  72B index= 17466 (slots=32768/   993)
> >>>>> [    7.574489] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1152 (slots=32768/   992)
> >>>>> [    7.584645] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  60B index= 17467 (slots=32768/   993)
> >>>>> [    7.595593] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1184 (slots=32768/   992)
> >>>>> [    7.595608] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  8198 (slots=32768/   993)
> >>>>> [    7.605359] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1216 (slots=32768/   993)
> >>>>> [    7.624703] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 452B index=  1248 (slots=32768/   993)
> >>>>> [    7.635603] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1280 (slots=32768/   992)
> >>>>> [    7.645344] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>>  52B index=  1312 (slots=32768/   993)
> >>>>> [    7.656247] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1314 (slots=32768/   992)
> >>>>> [    7.683567] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
> >>>>> 65535B index=  1346 (slots=32768/   992)
> >>>>> [    7.696095] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single
> >>>>> size=1048583B index=    -1 (slots=32768/   992)
> >>>>>
> >>>>> I'm still trying to understand the swiotlb allocation to see if there
> >>>>> is some configuration change I should be making.
> >>>>
> >>>> I suspect you hit the same issue mentioned here:
> >>>>
> >>>> https://lore.kernel.org/all/CAOMZO5A7+nxACoBPY0k8cOpVQByZtEV_N1489MK5wETHF_RXWA at mail.gmail.com/
> >>>>
> >>>> so can you check if below commit present in your kernel, and if not could you pick it up
> >>>> and try again?
> >>>>
> >>>> commit 14cebf689a78 ("swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE")
> >> ignore this request since it should be no related to your issue :(
> >>
> >>>>
> >>>
> >>> I bisected the 'swiotlb buffer is full' issue back to commit
> >>> aaf244141ed7 ("wifi: ath11k: fix IOMMU errors on buffer rings") which
> >>> looks to me to be a legitimate fix and if I revert it swiotlb is now
> >>> happy and the driver registers but I get the crash on client connect
> >>> that I was seeing in 6.6 so that commit fixes an issue, but causes
> >>> swiotlb to not be fulfilled.
> >> not really ... that commit is not the cause to your issue. you don;t see the 'swiotlb
> >> full' error after revert it simply because dma_map_single() is NOT called then.
> >>
> >>
> >>>
> >>> The issue seems to be that the swiotlb memory buffer allocator is
> >>> getting too fragmented to be useful with what ath11k is now asking for
> >>> (a lot of 2K and 64K buffers and then finally a 1048583B buffer which
> >>> fails due to the fragmentation of the swiotlb buffer.
> >> no, the direct cause to 'swiotlb full' error is that kernel does not allow a swiotlb map
> >> request larger than 256kb [1]:
> >>
> >> 'A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE bytes, which
> >> is 256 KiB with current definitions'
> >>
> >> while here ath11k is requesting a buffer of 1048583 bytes.
> >>
> >>
> >> howevr the question is that why swiotlb is involved here: for streamed DMA operation
> >> ath11k is capable of addressing 64GB memory (with 36bit DMA mask), in your case this
> >> covers whole system memory. the most possible reason I can think of is that swiotlb is
> >> forcebly enabled in your kernel (with swiotlb=force?) such that each DMA buffer would be
> >> bounced by swiotlb regardless of its physical address.
> >>
> >
> > I do not have swiotlb forced explicitly. Again, this is because I'm on
> > a IMX8MM with 4GiB DRAM which has no IOMMU and a 32bit DMA where
> > peripherals can not access memory over 3GiB as its base DRAM starting
> > at 1GiB (so swiotlb is getting used with a DRAM size >3GiB).
> ah ... I get your point and agree. so the limitation doesn't come from the ath11k
> hardware, but comes from IMX8MM itself. I guess the direct cause for involving swiotlb is
> dma_capable() returns false due to dev->bus_dma_limit is ((1ULL << 32) - 1).
>
> >
> > Reverting commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE
> > ring from cacheable memory") indeed resolves this issue.
> correct. by reverting it ath11k uses dma_alloc_coherent() instead of dma_map_single(), so
> the issue is gone.
>
> >
> > I notice that ath12k has a similar architecture as ath11k where
> > ath12k_dp_srng_setup() looks like what ath11k_dp_srng_setup() before
> > the change to allocate its buffers from cacheable memory so it's
> > probably just a matter of time before the same changes are made to
> > ath12k which will break that for this platform/memory-size as well.
> thanks, will take care.
>
> >
> > So the way I see to resolve this either:
> > a) revert commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE
> > ring from cacheable memory") - to stop asking for buffers >256KiB
> > b) find some other use of that upper 1GiB so that it can't be
> > allocated by DMA and swiotlb isn't needed
> > c) tell my board users to use mem=3096M and lose that last 1GiB of DRAM
>
> while the first one seems best it impacts performance. so I get another proposal: in case
> IOMMU not present, check DMA adressing limitation before allocating the buffer. If it can
> not cover 36 bit memory space and the system is able to alloc buffers above 4Gb, pass
> GFP_DMA32 or GFP_DMA to kzalloc() such that we can get a buffer below 4GB/16MB.
>
> anyway, can u send a patch for that?
>

I could work up a patch if I understood the memory allocation better.
Do you know how to check for this situation?

Are you saying allow the current kzalloc and then check the address
given to see if it's dma-able (how?) then free it and realloc it with
GFP_DMA32 and skip the dma_map_single?

I've added the iommu folk to the thread to see if they have any input.
To recap, the issue here is that ath11k wants to allocate some large
(~1MiB) cacheable buffers and on an iommu-less system (IMX8M) with a
32bit DMA engine this will fail as it requires swiotlb and the buffer
size being too large results in a swiotlb buffer full error.

Best Regards,

Tim

> >
> >>
> >>
> >> [1] Documentation/core-api/swiotlb.rst
> >>
> >>>
> >>> I'm guessing that this has gone unnoticed for a while because there
> >>> are maybe not a lot of systems out there that require swiotlb with
> >>> ath11k (either no IOMMU or more memory than DMA can address) and my
> >>> guess is that if you test ath11k with swiotlb=force you will easily
> >>> see this 'swiotlb buffer is full' issue on other systems.
> >>>
> >>> I'm not that knowledgeable about ath11k but I do know that ath10 and
> >>> ath12k do not have this issue with swiotlb. Debugging a bit shows that
> >>> there are a lot of large DMA buffers being requested by ath11k and I'm
> >>> wondering if that could be reduced or optimized somehow.
> >>>
> >>>>
> >>>>>
> >>>>> To avoid using swiotlb is there some way to limit the memory region
> >>>>> used for DMA operations to below 32bit boundary yet still allow the
> >>>>> memory above 32bit to be useful in the system for userspace maybe?
> >>>> if you are using dma_alloc_coherent() I'm afraid there is no way for that. the API
> >>>> internally ignores any zone flags passed with the 'gfp' argument. see
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/dma/mapping.c#n615
> >>>>
> >>>
> >>> is DMA_RESTRICTED_POOL a solution for me?
> >> i don;t think this help since this is used in coherent DMA?
> >>
> >
> > While DMA_RESTRICTED_POOL does allow defining the area used by swiotlb
> > it doesn't change the way swiotlb allocates buffers or the fact that
> > swiotlb is used at all.
> >
> > Best Regards,
> >
> > Tim
> >
> >
> >>>
> >>> Best Regards,
> >>>
> >>> Tim
> >>>
> >>
>


From eahariha at linux.microsoft.com  Fri Dec  6 12:58:17 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Fri, 6 Dec 2024 12:58:17 -0800
Subject: [PATCH v2 00/21] Converge on using secs_to_jiffies()
In-Reply-To: <b9fcb12a-b7a4-4c33-836e-67109ce07deb@intel.com>
References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com>
 <b9fcb12a-b7a4-4c33-836e-67109ce07deb@intel.com>
Message-ID: <dab77729-682f-4182-9fb2-cd522ac29b5f@linux.microsoft.com>

On 11/29/2024 4:57 AM, Przemek Kitszel wrote:
> 
> [removed most non-list recipients, it's just too much]
> 
> On 11/15/24 10:26 PM, Easwar Hariharan wrote:
<snip>
>>
>> ---
>> Changes in v2:
>> - EDITME: describe what is new in this series revision.
>> - EDITME: use bulletpoints and terse descriptions.
>> - Link to v1: https://lore.kernel.org/r/20241115-converge-secs-to-
>> jiffies-v1-0-19aadc34941b at linux.microsoft.com
> 
> that is not a proper changelog, you were supposed to edit those
> placeholder entries; please look around for examples
> 
> There is also just too much recipients. Please split up your patches
> into smaller pieces. You will also learn the process on a smaller
> sample.
> 
> And definitively please wait for 48h before reposting such big series.

Yes, sorry, I sent out a v2 in a moment of panic on including the
already accepted patch in v1. I failed to edit the changelog in that
same panic. I'll try to not panic and do better in the future.

> 
> Regarding code - you could also convert msecs_to_jiffies(const * HZ),
> there are 10 that are greppable.
> 

Those seem to be mistakes. const*HZ is a seconds-denominated timeout,
being passed to msecs_to_jiffies() which will treat it as a
millisecond-denominated timeout resulting in an excessively long
timeout. I suppose that's better than a too-short timeout, and
apparently it's been working fine all along since hardware responds
before the too-long timeout expires. Half of them are in
drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been
there since 2010.

Thanks,
Easwar


From jtornosm at redhat.com  Sun Dec  8 04:13:21 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Sun,  8 Dec 2024 13:13:21 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <0f24e115-e76d-4c8a-8a1b-591a157ee78e@quicinc.com>
References: <0f24e115-e76d-4c8a-8a1b-591a157ee78e@quicinc.com>
Message-ID: <20241208121321.9760-1-jtornosm@redhat.com>

>My point is that you can try setup with ap type interface,
This is what I am doing!
> now combination limits not allow up 3 inferfaces with managed interface.
Why? The limits were bigger previously.
Why cannot allow the old configuration (previous to the commit f019f4dff2e4
("wifi: ath11k: support 2 station interfaces"a))?
In another way, your proposed configuration is limited for me.

Thanks

Best regards
Jose Ignacio



From quic_yuzha at quicinc.com  Sun Dec  8 18:29:03 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Mon, 9 Dec 2024 10:29:03 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241208121321.9760-1-jtornosm@redhat.com>
References: <0f24e115-e76d-4c8a-8a1b-591a157ee78e@quicinc.com>
 <20241208121321.9760-1-jtornosm@redhat.com>
Message-ID: <1123551c-1a6d-4d0d-b3c7-f65c15509280@quicinc.com>



On 12/8/2024 8:13 PM, Jose Ignacio Tornos Martinez wrote:
>> My point is that you can try setup with ap type interface,
> This is what I am doing!
So you can't up with ap type or can't up with managed interface?
>> now combination limits not allow up 3 inferfaces with managed interface.
> Why? The limits were bigger previously.
> Why cannot allow the old configuration (previous to the commit f019f4dff2e4
> ("wifi: ath11k: support 2 station interfaces"a))?
> In another way, your proposed configuration is limited for me.
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From quic_bqiang at quicinc.com  Sun Dec  8 22:39:49 2024
From: quic_bqiang at quicinc.com (Baochen Qiang)
Date: Mon, 9 Dec 2024 14:39:49 +0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com>
 <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
Message-ID: <76df542c-ee17-493a-9a1a-284b49b0dbc0@quicinc.com>



On 12/7/2024 1:07 AM, Tim Harvey wrote:
> On Mon, Nov 25, 2024 at 6:47?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>>
>>
>>
>> On 11/26/2024 2:02 AM, Tim Harvey wrote:
>>> On Sun, Nov 24, 2024 at 11:23?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 11/23/2024 8:43 AM, Tim Harvey wrote:
>>>>> On Thu, Nov 21, 2024 at 9:51?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/22/2024 5:50 AM, Tim Harvey wrote:
>>>>>>> On Tue, Nov 19, 2024 at 6:32?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/20/2024 4:16 AM, Tim Harvey wrote:
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> I've got an ath11k card that is failing to init on an IMX8MM system
>>>>>>>>> with 4GB of DRAM:
>>>>>>>>> [    7.551582] ath11k_pci 0000:01:00.0: BAR 0 [mem
>>>>>>>>> 0x18000000-0x181fffff 64bit]: assigned
>>>>>>>>> [    7.551713] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
>>>>>>>>> [    7.552401] ath11k_pci 0000:01:00.0: MSI vectors: 16
>>>>>>>>> [    7.552440] ath11k_pci 0000:01:00.0: qcn9074 hw1.0
>>>>>>>>> [    7.887186] mhi mhi0: Loaded FW: ath11k/QCN9074/hw1.0/amss.bin,
>>>>>>>>> sha256: 5ee1b7b204541b5f99984f21d694ececaec08fbce1b520ffe6fe740b02a4afd7
>>>>>>>>> [    8.435964] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0x0
>>>>>>>>> board_id 0xff soc_id 0xffffffff
>>>>>>>>> [    8.435991] ath11k_pci 0000:01:00.0: fw_version 0x270206d0
>>>>>>>>> fw_build_timestamp 2022-08-04 12:48 fw_build_id
>>>>>>>>> WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
>>>>>>>>> [    8.441700] ath11k_pci 0000:01:00.0: Loaded FW:
>>>>>>>>> ath11k/QCN9074/hw1.0/board-2.bin, sha256:
>>>>>>>>> dbf0ca14aa1229eccd48f26f1026901b9718b143bd30b51b8ea67c84ba6207f1
>>>>>>>>> [    9.753764] ath11k_pci 0000:01:00.0: Loaded FW:
>>>>>>>>> ath11k/QCN9074/hw1.0/m3.bin, sha256:
>>>>>>>>> b6d957f335073a15a8de809398e1506f0200a08747eaf7189c843cf519ffc1de
>>>>>>>>> [    9.789791] ath11k_pci 0000:01:00.0: swiotlb buffer is full (sz:
>>>>>>>>> 1048583 bytes), total 32768 (slots), used 2528 (slots)
>>>>>>>>> [    9.789853] ath11k_pci 0000:01:00.0: failed to set up tcl_comp ring (0) :-12
>>>>>>>>> [    9.790238] ath11k_pci 0000:01:00.0: failed to init DP: -12
>>>>>>>>> root at noble-venice:~# cat /proc/cmdline
>>>>>>>>> console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200
>>>>>>>>> root=PARTUUID=5cdde84f-01 rootwait net.ifnames=0 cma=196M
>>>>>>>>>
>>>>>>>>> The IMX8MM's DRAM base is at 1GB so anything above 3GB hits the 32bit
>>>>>>>>> address boundary. If I pass in a mem=3096M the device registers just
>>>>>>>>> fine.
>>>>>>>> yeah ... that parameter makes kernel alloc memory below 32bit boundary, thus swiotlb is not necessary.
>>>>>>>
>>>>>>> Hi Baochen,
>>>>>>>
>>>>>>> Yes, that makes sense as I step through the code. On IMX8M with DRAM
>>>>>>> 3GB or less dma_capable(...) is true so swiotlb bounce buffers are not
>>>>>>> needed.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I found this to be the case with modern kernels however I found
>>>>>>>>> differing behavior with older kernels:
>>>>>>>>> - 6.6 and 6.1 the device registers with 4GB DRAM but crashes on client connect
>>>>>>>>> - 5.15 devices registers with 4GB DRAM and appears to work just fine
>>>>>>>> are you using Linus' tree or the stable tree?
>>>>>>>>
>>>>>>>
>>>>>>> For 6.6 I tested stable.
>>>>>> can you try Linus's tree ? as I know the stable tree is possible to miss some important fix.
>>>>>>
>>>>>>>
>>>>>>> This likely has something to do with commit dbd73acb22d8 ("wifi:
>>>>>>> ath11k: enable 36 bit mask for stream DMA") but it would seem to me
>>>>>>> that patch was trying to avoid the entire 32bit DMA limitation. Maybe
>>>>>>> that patch sets the ath11k device DMA mask to 36 bits but maybe the
>>>>>>> IMX8M PCI DMA is only capable of 32bits?
>>>>>> that patch is making situation better, not worse. that said, it helps to avoid swiotlb in
>>>>>> ath11k DMA, rather than to get it involved.
>>>>>>
>>>>>
>>>>> Yes, that patch would be an improvement on systems capable of
>>>>> addressing 64bit memory but not on the IMX8M which is seemingly
>>>>> capable of only 32bit DMA over PCI.
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Could anyone explain what is going on here? Obviously there have been
>>>>>>>>> changes at some point to start using swiotlb which I believe was all
>>>>>>>>> about avoiding 32bit DMA limitations but I'm not clear how I should be
>>>>>>>>> configuring this for IMX8MM with 4GB DRAM. Maybe my kernel IOMMU
>>>>>>>>> configuration is incorrect somehow?
>>>>>>>> there are quite some options associated with IOMMU, not sure which one might be causing this. But basically you may check:
>>>>>>>>
>>>>>>>> CONFIG_IOMMU_IOVA
>>>>>>>> CONFIG_IOMMU_API
>>>>>>>> CONFIG_IOMMU_SUPPORT
>>>>>>>> CONFIG_IOMMU_DMA=y
>>>>>>>>
>>>>>>>
>>>>>>> These are enabled which I believe appropriate for IMX8M. If I want to
>>>>>>> utilize the full 4GB DRAM on IMX then I must use IOMMU and swiotlb
>>>>>>> which would mean a performance hit due to copying mem to/from bounce
>>>>>>> buffers not to mention the fact that I can't figure out how to
>>>>>>> configure the system to avoid the 'swiotlb swiotlb buffer is full'
>>>>>>> issue.
>>>>>
>>>>> My statement regarding needing an IOMMU above is wrong; apparently the
>>>>> IMX8M SoC's don't have an IOMMU but the fact I have it enabled in the
>>>>> kernel should be a don't-care. If I understand swiotlb correctly, if I
>>>>> did have an IOMMU then it would be used instead of swiotlb.
>>>>>
>>>>>>>
>>>>>>> Enabling CONFIG_SWIOTLB_DYNAMIC does not help nor does increasing the
>>>>>>> number of slots - it has something to do with the number/size of DMA
>>>>>>> buffers that ath11k is asking for:
>>>>>> yeah, ath11k asks for fixed size DMA buffer regardless of that config.
>>>>>>
>>>>>>> # dmesg | grep swiotlb_tbl_map_single
>>>>>>> [    5.237731] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16384 (slots=32768/    32)
>>>>>>> [    5.247519] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16416 (slots=32768/    64)
>>>>>>> [    5.261794] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16448 (slots=32768/    96)
>>>>>>> [    5.275114] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16480 (slots=32768/   128)
>>>>>>> [    5.287757] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16512 (slots=32768/   160)
>>>>>>> [    5.299688] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16544 (slots=32768/   192)
>>>>>>> [    5.312482] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16576 (slots=32768/   224)
>>>>>>> [    5.324493] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16608 (slots=32768/   256)
>>>>>>> [    5.337001] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16640 (slots=32768/   288)
>>>>>>> [    5.346754] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16672 (slots=32768/   320)
>>>>>>> [    5.356571] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16704 (slots=32768/   352)
>>>>>>> [    5.366372] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16736 (slots=32768/   384)
>>>>>>> [    5.376164] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16768 (slots=32768/   416)
>>>>>>> [    5.385944] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16800 (slots=32768/   448)
>>>>>>> [    5.395712] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16832 (slots=32768/   480)
>>>>>>> [    5.408270] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16864 (slots=32768/   512)
>>>>>>> [    5.419768] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16896 (slots=32768/   544)
>>>>>>> [    5.430966] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16928 (slots=32768/   576)
>>>>>>> [    5.442368] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16960 (slots=32768/   608)
>>>>>>> [    5.452422] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 16992 (slots=32768/   640)
>>>>>>> [    5.463507] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17024 (slots=32768/   672)
>>>>>>> [    5.473536] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17056 (slots=32768/   704)
>>>>>>> [    5.485661] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17088 (slots=32768/   736)
>>>>>>> [    5.495404] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17120 (slots=32768/   768)
>>>>>>> [    5.509626] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17152 (slots=32768/   800)
>>>>>>> [    5.519353] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17184 (slots=32768/   832)
>>>>>>> [    5.529077] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17216 (slots=32768/   864)
>>>>>>> [    5.538799] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17248 (slots=32768/   896)
>>>>>>> [    5.548517] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17280 (slots=32768/   928)
>>>>>>> [    5.558238] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17312 (slots=32768/   960)
>>>>>>> [    5.567965] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index= 17344 (slots=32768/   992)
>>>>>>> [    5.578943] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=     0 (slots=32768/   992)
>>>>>>> [    5.578964] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8192 (slots=32768/   993)
>>>>>>> [    5.599793] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=    32 (slots=32768/   992)
>>>>>>> [    5.599861] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  68B index=  8193 (slots=32768/   993)
>>>>>>> [    5.609589] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=    64 (slots=32768/   993)
>>>>>>> [    5.628921] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=    96 (slots=32768/   992)
>>>>>>> [    5.638703] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  68B index= 17376 (slots=32768/   993)
>>>>>>> [    5.649602] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   128 (slots=32768/   992)
>>>>>>> [    5.659389] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   160 (slots=32768/   992)
>>>>>>> [    5.674038] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  96B index= 17377 (slots=32768/   993)
>>>>>>> [    5.685016] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   192 (slots=32768/   992)
>>>>>>> [    5.694819] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   224 (slots=32768/   992)
>>>>>>> [    5.694831] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index= 17378 (slots=32768/   993)
>>>>>>> [    5.714194] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  40B index= 17379 (slots=32768/   994)
>>>>>>> [    5.725089] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   256 (slots=32768/   992)
>>>>>>> [    5.753507] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17380 (slots=32768/   996)
>>>>>>> [    5.764668] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   288 (slots=32768/   992)
>>>>>>> [    5.774456] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   320 (slots=32768/   992)
>>>>>>> [    5.774620] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17384 (slots=32768/   996)
>>>>>>> [    5.795091] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   352 (slots=32768/   992)
>>>>>>> [    5.795241] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17388 (slots=32768/   996)
>>>>>>> [    5.815724] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   384 (slots=32768/   992)
>>>>>>> [    5.815884] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17392 (slots=32768/   996)
>>>>>>> [    5.836357] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   416 (slots=32768/   992)
>>>>>>> [    5.836368] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8194 (slots=32768/   993)
>>>>>>> [    5.855856] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17396 (slots=32768/   997)
>>>>>>> [    5.866818] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   448 (slots=32768/   992)
>>>>>>> [    5.866978] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17400 (slots=32768/   996)
>>>>>>> [    5.887451] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   480 (slots=32768/   992)
>>>>>>> [    5.897231] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   512 (slots=32768/   992)
>>>>>>> [    5.897389] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17404 (slots=32768/   996)
>>>>>>> [    5.917866] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   544 (slots=32768/   992)
>>>>>>> [    5.918026] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17408 (slots=32768/   996)
>>>>>>> [    5.938489] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   576 (slots=32768/   992)
>>>>>>> [    5.938642] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17412 (slots=32768/   996)
>>>>>>> [    5.959121] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   608 (slots=32768/   992)
>>>>>>> [    5.959135] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8195 (slots=32768/   993)
>>>>>>> [    5.978619] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17416 (slots=32768/   997)
>>>>>>> [    5.989588] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   640 (slots=32768/   992)
>>>>>>> [    5.989738] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17420 (slots=32768/   996)
>>>>>>> [    6.010215] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   672 (slots=32768/   992)
>>>>>>> [    6.020001] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   704 (slots=32768/   992)
>>>>>>> [    6.020158] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17424 (slots=32768/   996)
>>>>>>> [    6.040643] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   736 (slots=32768/   992)
>>>>>>> [    6.040798] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17428 (slots=32768/   996)
>>>>>>> [    6.061287] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   768 (slots=32768/   992)
>>>>>>> [    6.061437] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17432 (slots=32768/   996)
>>>>>>> [    6.081918] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   800 (slots=32768/   992)
>>>>>>> [    6.081929] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8196 (slots=32768/   993)
>>>>>>> [    6.101409] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17436 (slots=32768/   997)
>>>>>>> [    6.112375] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   832 (slots=32768/   992)
>>>>>>> [    6.112528] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17440 (slots=32768/   996)
>>>>>>> [    6.133004] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   864 (slots=32768/   992)
>>>>>>> [    6.142785] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   896 (slots=32768/   992)
>>>>>>> [    6.142949] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17444 (slots=32768/   996)
>>>>>>> [    6.163426] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   928 (slots=32768/   992)
>>>>>>> [    6.163576] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17448 (slots=32768/   996)
>>>>>>> [    6.184058] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   960 (slots=32768/   992)
>>>>>>> [    6.184208] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17452 (slots=32768/   996)
>>>>>>> [    6.204691] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=   992 (slots=32768/   992)
>>>>>>> [    6.204704] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8197 (slots=32768/   993)
>>>>>>> [    6.224183] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17456 (slots=32768/   997)
>>>>>>> [    6.235148] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1024 (slots=32768/   992)
>>>>>>> [    6.235308] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 6224B index= 17460 (slots=32768/   996)
>>>>>>> [    6.255777] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1056 (slots=32768/   992)
>>>>>>> [    6.265552] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1088 (slots=32768/   992)
>>>>>>> [    6.265633] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 2128B index= 17464 (slots=32768/   994)
>>>>>>> [    6.286142] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1120 (slots=32768/   992)
>>>>>>> [    6.286182] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  72B index= 17466 (slots=32768/   993)
>>>>>>> [    7.574489] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1152 (slots=32768/   992)
>>>>>>> [    7.584645] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  60B index= 17467 (slots=32768/   993)
>>>>>>> [    7.595593] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1184 (slots=32768/   992)
>>>>>>> [    7.595608] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  8198 (slots=32768/   993)
>>>>>>> [    7.605359] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1216 (slots=32768/   993)
>>>>>>> [    7.624703] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 452B index=  1248 (slots=32768/   993)
>>>>>>> [    7.635603] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1280 (slots=32768/   992)
>>>>>>> [    7.645344] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>>  52B index=  1312 (slots=32768/   993)
>>>>>>> [    7.656247] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1314 (slots=32768/   992)
>>>>>>> [    7.683567] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single size=
>>>>>>> 65535B index=  1346 (slots=32768/   992)
>>>>>>> [    7.696095] ath11k_pci 0000:01:00.0: swiotlb_tbl_map_single
>>>>>>> size=1048583B index=    -1 (slots=32768/   992)
>>>>>>>
>>>>>>> I'm still trying to understand the swiotlb allocation to see if there
>>>>>>> is some configuration change I should be making.
>>>>>>
>>>>>> I suspect you hit the same issue mentioned here:
>>>>>>
>>>>>> https://lore.kernel.org/all/CAOMZO5A7+nxACoBPY0k8cOpVQByZtEV_N1489MK5wETHF_RXWA at mail.gmail.com/
>>>>>>
>>>>>> so can you check if below commit present in your kernel, and if not could you pick it up
>>>>>> and try again?
>>>>>>
>>>>>> commit 14cebf689a78 ("swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE")
>>>> ignore this request since it should be no related to your issue :(
>>>>
>>>>>>
>>>>>
>>>>> I bisected the 'swiotlb buffer is full' issue back to commit
>>>>> aaf244141ed7 ("wifi: ath11k: fix IOMMU errors on buffer rings") which
>>>>> looks to me to be a legitimate fix and if I revert it swiotlb is now
>>>>> happy and the driver registers but I get the crash on client connect
>>>>> that I was seeing in 6.6 so that commit fixes an issue, but causes
>>>>> swiotlb to not be fulfilled.
>>>> not really ... that commit is not the cause to your issue. you don;t see the 'swiotlb
>>>> full' error after revert it simply because dma_map_single() is NOT called then.
>>>>
>>>>
>>>>>
>>>>> The issue seems to be that the swiotlb memory buffer allocator is
>>>>> getting too fragmented to be useful with what ath11k is now asking for
>>>>> (a lot of 2K and 64K buffers and then finally a 1048583B buffer which
>>>>> fails due to the fragmentation of the swiotlb buffer.
>>>> no, the direct cause to 'swiotlb full' error is that kernel does not allow a swiotlb map
>>>> request larger than 256kb [1]:
>>>>
>>>> 'A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE bytes, which
>>>> is 256 KiB with current definitions'
>>>>
>>>> while here ath11k is requesting a buffer of 1048583 bytes.
>>>>
>>>>
>>>> howevr the question is that why swiotlb is involved here: for streamed DMA operation
>>>> ath11k is capable of addressing 64GB memory (with 36bit DMA mask), in your case this
>>>> covers whole system memory. the most possible reason I can think of is that swiotlb is
>>>> forcebly enabled in your kernel (with swiotlb=force?) such that each DMA buffer would be
>>>> bounced by swiotlb regardless of its physical address.
>>>>
>>>
>>> I do not have swiotlb forced explicitly. Again, this is because I'm on
>>> a IMX8MM with 4GiB DRAM which has no IOMMU and a 32bit DMA where
>>> peripherals can not access memory over 3GiB as its base DRAM starting
>>> at 1GiB (so swiotlb is getting used with a DRAM size >3GiB).
>> ah ... I get your point and agree. so the limitation doesn't come from the ath11k
>> hardware, but comes from IMX8MM itself. I guess the direct cause for involving swiotlb is
>> dma_capable() returns false due to dev->bus_dma_limit is ((1ULL << 32) - 1).
>>
>>>
>>> Reverting commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE
>>> ring from cacheable memory") indeed resolves this issue.
>> correct. by reverting it ath11k uses dma_alloc_coherent() instead of dma_map_single(), so
>> the issue is gone.
>>
>>>
>>> I notice that ath12k has a similar architecture as ath11k where
>>> ath12k_dp_srng_setup() looks like what ath11k_dp_srng_setup() before
>>> the change to allocate its buffers from cacheable memory so it's
>>> probably just a matter of time before the same changes are made to
>>> ath12k which will break that for this platform/memory-size as well.
>> thanks, will take care.
>>
>>>
>>> So the way I see to resolve this either:
>>> a) revert commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE
>>> ring from cacheable memory") - to stop asking for buffers >256KiB
>>> b) find some other use of that upper 1GiB so that it can't be
>>> allocated by DMA and swiotlb isn't needed
>>> c) tell my board users to use mem=3096M and lose that last 1GiB of DRAM
>>
>> while the first one seems best it impacts performance. so I get another proposal: in case
>> IOMMU not present, check DMA adressing limitation before allocating the buffer. If it can
>> not cover 36 bit memory space and the system is able to alloc buffers above 4Gb, pass
>> GFP_DMA32 or GFP_DMA to kzalloc() such that we can get a buffer below 4GB/16MB.
>>
>> anyway, can u send a patch for that?
>>
> 
> I could work up a patch if I understood the memory allocation better.
> Do you know how to check for this situation?
> 
> Are you saying allow the current kzalloc and then check the address
> given to see if it's dma-able (how?) then free it and realloc it with
> GFP_DMA32 and skip the dma_map_single?

yeah, somthing like that. But thinking it more I realize that it is not a general
sollution, even it can fix the issue in your case.

For a general sollution, what I can think of now is either of below:

1. revert commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE ring from cacheable
memory"). This way we can avoid the size limitaion on streaming DMA.

2. limit the allocation size to be less than 256KB.

However both of them may have impact on performance.

> 
> I've added the iommu folk to the thread to see if they have any input.
> To recap, the issue here is that ath11k wants to allocate some large
> (~1MiB) cacheable buffers and on an iommu-less system (IMX8M) with a
> 32bit DMA engine this will fail as it requires swiotlb and the buffer
> size being too large results in a swiotlb buffer full error.
> 
> Best Regards,
> 
> Tim
> 
>>>
>>>>
>>>>
>>>> [1] Documentation/core-api/swiotlb.rst
>>>>
>>>>>
>>>>> I'm guessing that this has gone unnoticed for a while because there
>>>>> are maybe not a lot of systems out there that require swiotlb with
>>>>> ath11k (either no IOMMU or more memory than DMA can address) and my
>>>>> guess is that if you test ath11k with swiotlb=force you will easily
>>>>> see this 'swiotlb buffer is full' issue on other systems.
>>>>>
>>>>> I'm not that knowledgeable about ath11k but I do know that ath10 and
>>>>> ath12k do not have this issue with swiotlb. Debugging a bit shows that
>>>>> there are a lot of large DMA buffers being requested by ath11k and I'm
>>>>> wondering if that could be reduced or optimized somehow.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> To avoid using swiotlb is there some way to limit the memory region
>>>>>>> used for DMA operations to below 32bit boundary yet still allow the
>>>>>>> memory above 32bit to be useful in the system for userspace maybe?
>>>>>> if you are using dma_alloc_coherent() I'm afraid there is no way for that. the API
>>>>>> internally ignores any zone flags passed with the 'gfp' argument. see
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/dma/mapping.c#n615
>>>>>>
>>>>>
>>>>> is DMA_RESTRICTED_POOL a solution for me?
>>>> i don;t think this help since this is used in coherent DMA?
>>>>
>>>
>>> While DMA_RESTRICTED_POOL does allow defining the area used by swiotlb
>>> it doesn't change the way swiotlb allocates buffers or the fact that
>>> swiotlb is used at all.
>>>
>>> Best Regards,
>>>
>>> Tim
>>>
>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Tim
>>>>>
>>>>
>>



From jtornosm at redhat.com  Mon Dec  9 00:03:34 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Mon,  9 Dec 2024 09:03:34 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <1123551c-1a6d-4d0d-b3c7-f65c15509280@quicinc.com>
References: <1123551c-1a6d-4d0d-b3c7-f65c15509280@quicinc.com>
Message-ID: <20241209080334.5989-1-jtornosm@redhat.com>

> So you can't up with ap type or can't up with managed interface?
Please, let's go to focus and not repeat the same, due to the reasons
that I commented before, I can't up my scenario with aps using your
proposed inteface configuration.
I am going to remark again, I can do it with the old configuration
previous to the commit f019f4dff2e4 ("wifi: ath11k: support 2 station
interfaces").
Thanks to my patch after 019f4dff2e4 ("wifi: ath11k: support 2 station
interfaces") by means of a parameter I can do it too.
And that's all.

Thanks

Best regards
Jose Ignacio



From hch at lst.de  Mon Dec  9 00:17:14 2024
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 9 Dec 2024 09:17:14 +0100
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com> <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com> <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
Message-ID: <20241209081714.GA25363@lst.de>

I scrolled three pages before giving up as it was just quotes over
quotas.  Can you please write an email that contains whatever you're
trying to tell instead of just quotes?  Same for the person replying.



From quic_yuzha at quicinc.com  Mon Dec  9 00:33:24 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Mon, 9 Dec 2024 16:33:24 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241209080334.5989-1-jtornosm@redhat.com>
References: <1123551c-1a6d-4d0d-b3c7-f65c15509280@quicinc.com>
 <20241209080334.5989-1-jtornosm@redhat.com>
Message-ID: <db61f998-2524-4623-8b0f-143661507e38@quicinc.com>



On 12/9/2024 4:03 PM, Jose Ignacio Tornos Martinez wrote:
>> So you can't up with ap type or can't up with managed interface?
> Please, let's go to focus and not repeat the same, due to the reasons
> that I commented before, I can't up my scenario with aps using your
> proposed inteface configuration.
Yes, Can you pls share the complete steps and commands?
> I am going to remark again, I can do it with the old configuration
> previous to the commit f019f4dff2e4 ("wifi: ath11k: support 2 station
> interfaces").
> Thanks to my patch after 019f4dff2e4 ("wifi: ath11k: support 2 station
> interfaces") by means of a parameter I can do it too.
> And that's all.
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From robin.murphy at arm.com  Mon Dec  9 02:49:49 2024
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 9 Dec 2024 10:49:49 +0000
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <20241209081714.GA25363@lst.de>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com>
 <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de>
Message-ID: <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>

On 09/12/2024 8:17 am, Christoph Hellwig wrote:
> I scrolled three pages before giving up as it was just quotes over
> quotas.  Can you please write an email that contains whatever you're
> trying to tell instead of just quotes?  Same for the person replying.

TBH I'm hesitant to look too closely since everything those Atheros WiFi 
drivers do with DMA tends to be sketchy, but from what I could make out 
from skimming until I also gave up, I think it might be an attempt to 
reinvent dma_alloc_pages(), or possibly dma_alloc_noncoherent().

Cheers,
Robin.


From janusz.dziedzic at gmail.com  Mon Dec  9 03:23:32 2024
From: janusz.dziedzic at gmail.com (Janusz Dziedzic)
Date: Mon, 9 Dec 2024 12:23:32 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
References: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>
 <20241203094820.106225-1-jtornosm@redhat.com> <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
Message-ID: <CAFED-jk--dXAoXJ9ijpnUDeD=WiW4ZeoLb45WXiVpzPvkgX12A@mail.gmail.com>

wt., 3 gru 2024 o 11:57 Yu Zhang (Yuriy) <quic_yuzha at quicinc.com> napisa?(a):
>
>
>
> On 12/3/2024 5:48 PM, Jose Ignacio Tornos Martinez wrote:
> >> Which chip do you use?
> > Since I am not totally sure about the useful information, let me show you
> > the kernel logs:
> > $ dmesg | grep ath11k
> > [    3.659388] ath11k_pci 0000:01:00.0: BAR 0 [mem 0x84200000-0x843fffff 64bit]: assigned
> > [    3.659405] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
> > [    3.659649] ath11k_pci 0000:01:00.0: MSI vectors: 32
> > [    3.659653] ath11k_pci 0000:01:00.0: wcn6855 hw2.1
> > [    4.871571] ath11k_pci 0000:01:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0210
> > [    4.871586] ath11k_pci 0000:01: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
> > [    5.241485] ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
> >
> yes, you also use wcn6855 hw2.1.
> > If I try to setup 2 APs with your interface combination I get this:
> > # iw list | grep -A6 "valid interface combinations:"
> >       valid interface combinations:
> >                * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> >                  total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
> >
> >                * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> >                  total <= 3, #channels <= 2, STA/AP BI must match
> >       HT Capability overrides:
> 2 combinations are to support DBS and DFS.
> Combinations is correct. channels=2, max interfaces=3.
>
Small question from my side. If phyX will support 3 bands (2.4/5/6)
what this channes<=2 limitation mean here for APs?
 a) can I setup APs on 2412 and 5180
 b) or even can setup APs on 2412 and 2462?
 c) or setup APs on 5180 and 6055?
How could I know a or b or c is allowed?

BTW, do you plan to share same firmware (with 2 possible APs) for
ath12k and WCN7850?

BR
Janusz

> And you want setup sta + sap + sap, right?
> When up the second sap will meet error? Could you pls share the error logs?
>
> I'm not very sure if you add all interface with managed type, and do
> "ifconfig xxx up" before running hostapd.
>
> You can try add second and third interface with
> "iw dev xx interface add xx type __ap".
>
>
> > # iw dev
> > phy#0
> >       Interface wlp1s0_1
> >               ifindex 6
> >               wdev 0x4
> >               addr a2:42:d2:1e:89:a3
> >               type managed
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0_0
> >               ifindex 5
> >               wdev 0x3
> >               addr 52:e9:be:33:6a:61
> >               ssid test-qe-wpa2-psk
> >               type AP
> >               channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> >               txpower 14.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0
> >               ifindex 3
> >               wdev 0x1
> >               addr c8:94:02:b5:fe:fb
> >               type managed
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> > Or even this with no AP up:
> > # iw dev
> > phy#0
> >       Interface wlp1s0_1
> >               ifindex 6
> >               wdev 0x4
> >               addr ca:e5:84:22:10:ec
> >               type managed
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0_0
> >               ifindex 5
> >               wdev 0x3
> >               addr 9e:4e:c5:ea:4c:e9
> >               type AP
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0
> >               ifindex 3
> >               wdev 0x1
> >               addr c8:94:02:b5:fe:fb
> >               type managed
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >
> > If I use the parameter to ignore the feature and configure the interface combination as before:
> > # iw list | grep -A4 "valid interface combinations:"
> >       valid interface combinations:
> >                * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
> >                  total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
> >
> >       HT Capability overrides:
> > # iw dev
> > phy#1
> >       Interface wlp1s0_1
> >               ifindex 7
> >               wdev 0x100000004
> >               addr 82:90:89:90:c1:37
> >               ssid test-qe-wpa3-psk
> >               type AP
> >               channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0_0
> >               ifindex 6
> >               wdev 0x100000003
> >               addr 6a:ef:d0:db:10:f0
> >               ssid test-qe-wpa2-psk
> >               type AP
> >               channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >       Interface wlp1s0
> >               ifindex 4
> >               wdev 0x100000001
> >               addr c8:94:02:b5:fe:fb
> >               type managed
> >               txpower 16.00 dBm
> >               multicast TXQ:
> >                       qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
> >                       0       0       0       0       0       0       0       0               0
> >
> > Thanks
> >
> > Best regards
> > Jose Ignacio
> >
>
>


-- 
Janusz Dziedzic


From przemyslaw.kitszel at intel.com  Mon Dec  9 04:01:42 2024
From: przemyslaw.kitszel at intel.com (Przemek Kitszel)
Date: Mon, 9 Dec 2024 13:01:42 +0100
Subject: [PATCH v2 00/21] Converge on using secs_to_jiffies()
In-Reply-To: <dab77729-682f-4182-9fb2-cd522ac29b5f@linux.microsoft.com>
References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com>
 <b9fcb12a-b7a4-4c33-836e-67109ce07deb@intel.com>
 <dab77729-682f-4182-9fb2-cd522ac29b5f@linux.microsoft.com>
Message-ID: <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com>

On 12/6/24 9:58 PM, Easwar Hariharan wrote:
> On 11/29/2024 4:57 AM, Przemek Kitszel wrote:
>>
>> [removed most non-list recipients, it's just too much]
>>
>> On 11/15/24 10:26 PM, Easwar Hariharan wrote:
> <snip>

>>
>> Regarding code - you could also convert msecs_to_jiffies(const * HZ),
>> there are 10 that are greppable.
>>
> 
> Those seem to be mistakes. const*HZ is a seconds-denominated timeout,
> being passed to msecs_to_jiffies() which will treat it as a
> millisecond-denominated timeout resulting in an excessively long
> timeout. I suppose that's better than a too-short timeout, and
> apparently it's been working fine all along since hardware responds
> before the too-long timeout expires. Half of them are in
> drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been
> there since 2010.

my point was that, the default value of HZ is 1000, and most of the code
that is just `$value*HZ` was meant as "$value seconds, in ms unit".

Same for HZ/const, HZ/2 being 500ms.

HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the
value in simple context.

If you happen to touch this, please do in a separate series, to get more
attention from drivers owners.

> 
> Thanks,
> Easwar



From francesco at dolcini.it  Mon Dec  9 04:05:18 2024
From: francesco at dolcini.it (Francesco Dolcini)
Date: Mon, 9 Dec 2024 13:05:18 +0100
Subject: ath11k-firmware: WCN6855 hw2.1: add Silex SX-PCEAX specific BDF
Message-ID: <Z1bc_jn-k-88Io3f@gaggiata.pivistrello.it>

Hi,

I'd like to ask for inclusion for the board file for Silex SX-PCEAX
radio module [1].

 * description for what hardware this is
  - SX-PCEAX is a tri-band IEEE 802.11 abgn/ac/ax WLAN module plus
    Bluetooth 5.2 BR/EDR/LE combo module based on Qualcomm?s QCA2066 SoC.
  - It is used, for example, on Toradex Aquila AM69 SoM,
    https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69

 * origin of the board file
  - it comes from the BSP package distributed by Toradex,
    https://docs.toradex.com/116005-sx-pceax-board-files_v1.0.zip

 * ids to be used with the board file
  - bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=18,qmi-board-id=255
    sha256sum: 6b83356883cdfd3f25cf1bcb3b4ccede3ec1ecf2dbcf61f844ce5901bdf161d7


Logs:

[    9.948171] ath11k_pci 0003:01:00.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
[    9.957083] ath11k_pci 0003:01: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
[    9.980693] ath11k_pci 0003:01:00.0: qmi SMBIOS bdf variant name not set.
[    9.988591] ath11k_pci 0003:01:00.0: qmi DT bdf variant name not set.
[    9.988599] ath11k_pci 0003:01:00.0: boot using board name 'bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=18,qmi-board-id=255'
[   10.023549] ath11k_pci 0003:01:00.0: boot firmware request ath11k/WCN6855/hw2.1/board-2.bin size 6489396

root at aquila-am69-25797013:~# lspci -s 0003:01:00.0 -v -nn
0003:01:00.0 Network controller [0280]: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] (rev 01)
        Subsystem: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:3374]
        Flags: bus master, fast devsel, latency 0, IRQ 657
        Memory at 4410200000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=32/32 Maskable+ 64bit-
        Capabilities: [70] Express Endpoint, IntMsgNum 0
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Secondary PCI Express
        Capabilities: [158] Transaction Processing Hints
        Capabilities: [1e4] Latency Tolerance Reporting
        Capabilities: [1ec] L1 PM Substates
        Kernel driver in use: ath11k_pci
        Kernel modules: ath11k_pci

root at aquila-am69-25797013:~# uname -a
Linux aquila-am69-25797013 6.6.58-01607-gd8fe9e598e20 #1 SMP PREEMPT Thu Dec  5 12:27:19 CET 2024 aarch64 GNU/Linux

[1] https://www.silextechnology.com/connectivity-solutions/embedded-wireless/sx-pceax

Francesco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=3374,qmi-chip-id=18,qmi-board-id=255.bin
Type: application/octet-stream
Size: 60024 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241209/3fe93f6b/attachment-0001.bin>

From christophe.leroy at csgroup.eu  Mon Dec  9 04:45:17 2024
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Mon, 9 Dec 2024 13:45:17 +0100
Subject: [PATCH v2 00/21] Converge on using secs_to_jiffies()
In-Reply-To: <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com>
References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com>
 <b9fcb12a-b7a4-4c33-836e-67109ce07deb@intel.com>
 <dab77729-682f-4182-9fb2-cd522ac29b5f@linux.microsoft.com>
 <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com>
Message-ID: <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu>



Le 09/12/2024 ? 13:01, Przemek Kitszel a ?crit?:
> On 12/6/24 9:58 PM, Easwar Hariharan wrote:
>> On 11/29/2024 4:57 AM, Przemek Kitszel wrote:
>>>
>>> [removed most non-list recipients, it's just too much]
>>>
>>> On 11/15/24 10:26 PM, Easwar Hariharan wrote:
>> <snip>
> 
>>>
>>> Regarding code - you could also convert msecs_to_jiffies(const * HZ),
>>> there are 10 that are greppable.
>>>
>>
>> Those seem to be mistakes. const*HZ is a seconds-denominated timeout,
>> being passed to msecs_to_jiffies() which will treat it as a
>> millisecond-denominated timeout resulting in an excessively long
>> timeout. I suppose that's better than a too-short timeout, and
>> apparently it's been working fine all along since hardware responds
>> before the too-long timeout expires. Half of them are in
>> drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been
>> there since 2010.
> 
> my point was that, the default value of HZ is 1000, and most of the code
> that is just `$value*HZ` was meant as "$value seconds, in ms unit".

I can't follow you here. The default value of HZ is 250 as far as I can see.

Regardless, HZ is the number of jiffies per second, nothing else.

> 
> Same for HZ/const, HZ/2 being 500ms.
> 
> HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the
> value in simple context.

Why is that awful ?

HZ is a nice macro that gives you the number of ticks per second, so 
that you are able to easily calculate the number of ticks for a given 
duration, regardless of the configured number of ticks per second.

Christophe


From przemyslaw.kitszel at intel.com  Mon Dec  9 07:03:31 2024
From: przemyslaw.kitszel at intel.com (Przemek Kitszel)
Date: Mon, 9 Dec 2024 16:03:31 +0100
Subject: [PATCH v2 00/21] Converge on using secs_to_jiffies()
In-Reply-To: <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu>
References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com>
 <b9fcb12a-b7a4-4c33-836e-67109ce07deb@intel.com>
 <dab77729-682f-4182-9fb2-cd522ac29b5f@linux.microsoft.com>
 <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com>
 <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu>
Message-ID: <3113d4f4-4f8b-41d6-af89-f82cbc89da75@intel.com>

On 12/9/24 1:45 PM, Christophe Leroy wrote:
> 
> 
> Le 09/12/2024 ? 13:01, Przemek Kitszel a ?crit?:
>> On 12/6/24 9:58 PM, Easwar Hariharan wrote:
>>> On 11/29/2024 4:57 AM, Przemek Kitszel wrote:
>>>>
>>>> [removed most non-list recipients, it's just too much]
>>>>
>>>> On 11/15/24 10:26 PM, Easwar Hariharan wrote:
>>> <snip>
>>
>>>>
>>>> Regarding code - you could also convert msecs_to_jiffies(const * HZ),
>>>> there are 10 that are greppable.

Thanks to Christope, I re-examined those ~10 cases, and that should be
refactored by just dropping msec_to_jiffies() part, not replacing
by sec_to_jiffies().

>>>>
>>>
>>> Those seem to be mistakes. const*HZ is a seconds-denominated timeout,
>>> being passed to msecs_to_jiffies() which will treat it as a
>>> millisecond-denominated timeout resulting in an excessively long
>>> timeout. I suppose that's better than a too-short timeout, and
>>> apparently it's been working fine all along since hardware responds
>>> before the too-long timeout expires. Half of them are in
>>> drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been
>>> there since 2010.
>>
>> my point was that, the default value of HZ is 1000, and most of the code
>> that is just `$value*HZ` was meant as "$value seconds, in ms unit".
> 
> I can't follow you here. The default value of HZ is 250 as far as I can 
> see.

as default I understand "the value that is effective for those that
don't tweak", not necessarily "the fallback that will be used when not
set by any other means". On my RedHat and Fedora boxes it's 1000.

> 
> Regardless, HZ is the number of jiffies per second, nothing else.

That is true. But the name is wrong.

> 
>>
>> Same for HZ/const, HZ/2 being 500ms.
>>
>> HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the
>> value in simple context.
> 
> Why is that awful ?

so, 1Hertz = 1/1s == once per second,
something happening twice per second, with freq of 2Hz, repeats
each HZ/2 jiffies
https://en.wikipedia.org/wiki/Hertz

the #define name should be really JHZ -> JIFFIES_PER_SECOND

> 
> HZ is a nice macro that gives you the number of ticks per second, so 
> that you are able to easily calculate the number of ticks for a given 
> duration, regardless of the configured number of ticks per second.

Again, technically true, but default being eq to number of msec in sec,
causes it to bite.



From jeff.johnson at oss.qualcomm.com  Mon Dec  9 08:59:19 2024
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Mon, 9 Dec 2024 08:59:19 -0800
Subject: pull-request: ath-next-20241209
Message-ID: <1bcdaf98-6078-4f79-a989-2e5db9400585@oss.qualcomm.com>

The following changes since commit 2b94751626a6d49bbe42a19cc1503bd391016bd5:

  wifi: cw1200: Fix potential NULL dereference (2024-10-31 16:20:02 +0200)

are available in the Git repository at:

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

for you to fetch changes up to da8656797ae10b524a7a0c3d5eeb6237fa3ddd70:

  wifi: ath12k: introduce mlo_capable flag for device group (2024-12-05 14:34:10 -0800)

----------------------------------------------------------------
ath.git patches for v6.14

This development cycle featured multiple patchsets to ath12k to
support the new 802.11be MLO feature, although the feature is still
incomplete. Also in ath12k, there were other feature patches.  In
ath11k, support was added for QCA6698AQ. And there was the usual set
of bug fixes and cleanups across most drivers, notable being the
addition of "noinline_for_stack" to some functions to avoid "stack
frame size" warnings when compiling with clang.

----------------------------------------------------------------
Aditya Kumar Singh (2):
      wifi: ath12k: ath12k_bss_assoc(): MLO support
      wifi: ath12k: rename mlo_capable_flags to single_chip_mlo_supp

Balaji Pothunoori (2):
      wifi: ath11k: Suspend hardware before firmware mode off for WCN6750
      wifi: ath11k: Fix unexpected return buffer manager error for WCN6750/WCN6855

Barnab?s Cz?m?n (1):
      wifi: wcn36xx: fix channel survey memory allocation size

Dinesh Karthikeyan (4):
      wifi: ath12k: Support Downlink Pager Stats
      wifi: ath12k: Support phy counter and TPC stats
      wifi: ath12k: Support SoC Common Stats
      wifi: ath12k: Support Transmit PER Rate Stats

Dmitry Antipov (5):
      wifi: ath9k: miscellaneous spelling fixes
      wifi: ath11k: cleanup struct ath11k_vif
      wifi: ath11k: cleanup struct ath11k_reg_tpc_power_info
      wifi: ath11k: cleanup struct ath11k_mon_data
      wifi: ath11k: miscellaneous spelling fixes

Jeff Johnson (4):
      wifi: ath12k: mark QMI driver event helpers as noinline
      wifi: ath11k: mark some QMI driver event helpers as noinline
      wifi: ath11k: mark ath11k_dp_rx_mon_mpdu_pop() as noinline
      wifi: ath11k: mark ath11k_wow_convert_8023_to_80211() as noinline

Kalle Valo (5):
      wifi: ath12k: ath12k_mac_vdev_create(): use goto for error handling
      wifi: ath12k: introduce ath12k_hw_warn()
      wifi: ath12k: convert struct ath12k::wmi_mgmt_tx_work to struct wiphy_work
      wifi: ath12k: ath12k_mac_op_set_key(): fix uninitialized symbol 'ret'
      wifi: ath12k: ath12k_mac_op_sta_rc_update(): use mac80211 provided link id

Karol Przybylski (1):
      wifi: ath12k: Fix for out-of bound access error

Karthikeyan Periyasamy (10):
      wifi: ath12k: Refactor core startup
      wifi: ath12k: add ath12k_ab_to_ah() and ath12k_ab_set_ah()
      wifi: ath12k: add ath12k_get_num_hw()
      wifi: ath12k: introduce QMI firmware ready flag
      wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()
      wifi: ath12k: introduce device group abstraction
      wifi: ath12k: refactor core start based on hardware group
      wifi: ath12k: move struct ath12k_hw from per device to group
      wifi: ath12k: send QMI host capability after device group is ready
      wifi: ath12k: introduce mlo_capable flag for device group

Miaoqing Pan (1):
      wifi: ath11k: add support for QCA6698AQ

P Praneesh (1):
      wifi: ath12k: Fix endianness issue in struct hal_tlv_64_hdr

Rameshkumar Sundaram (4):
      wifi: ath12k: add reo queue lookup table for ML peers
      wifi: ath12k: modify chanctx iterators for MLO
      wifi: ath12k: ath12k_mac_station_add(): fix potential rx_stats leak
      wifi: ath12k: defer vdev creation for MLO

Roopni Devanathan (1):
      wifi: ath12k: Fix inappropriate use of print_array_to_buf_index()

Sidhanta Sahu (1):
      wifi: ath12k: Support MBSSID Control Frame Stats

Sriram R (16):
      wifi: ath12k: MLO vdev bringup changes
      wifi: ath12k: Refactor sta state machine
      wifi: ath12k: Add helpers for multi link peer creation and deletion
      wifi: ath12k: add multi-link flag in peer create command
      wifi: ath12k: add helper to find multi-link station
      wifi: ath12k: Add MLO peer assoc command support
      wifi: ath12k: Add MLO station state change handling
      wifi: ath12k: support change_sta_links() mac80211 op
      wifi: ath12k: add primary link for data path operations
      wifi: ath12k: use arsta instead of sta
      wifi: ath12k: Use mac80211 vif's link_conf instead of bss_conf
      wifi: ath12k: Use mac80211 sta's link_sta instead of deflink
      wifi: ath12k: ath12k_mac_op_tx(): MLO support
      wifi: ath12k: ath12k_mac_op_flush(): MLO support
      wifi: ath12k: ath12k_mac_op_ampdu_action(): MLO support
      wifi: ath12k: do not return invalid link id for scan link

Toke H?iland-J?rgensen (1):
      wifi: ath9k: Add RX inactivity detection and reset chip when it occurs

 drivers/net/wireless/ath/ath11k/core.c             |  132 ++
 drivers/net/wireless/ath/ath11k/core.h             |    4 +-
 drivers/net/wireless/ath/ath11k/dp.h               |    1 -
 drivers/net/wireless/ath/ath11k/dp_rx.c            |   14 +-
 drivers/net/wireless/ath/ath11k/hal.h              |    6 +-
 drivers/net/wireless/ath/ath11k/hal_rx.c           |    3 +-
 drivers/net/wireless/ath/ath11k/hw.h               |    1 +
 drivers/net/wireless/ath/ath11k/mac.c              |    6 +-
 drivers/net/wireless/ath/ath11k/mhi.c              |    1 +
 drivers/net/wireless/ath/ath11k/pci.c              |    3 +
 drivers/net/wireless/ath/ath11k/pcic.c             |   13 +-
 drivers/net/wireless/ath/ath11k/qmi.c              |    8 +-
 drivers/net/wireless/ath/ath11k/wow.c              |    6 +-
 drivers/net/wireless/ath/ath12k/core.c             |  482 ++++-
 drivers/net/wireless/ath/ath12k/core.h             |  134 +-
 drivers/net/wireless/ath/ath12k/debug.c            |    6 +-
 drivers/net/wireless/ath/ath12k/debug.h            |    5 +-
 .../net/wireless/ath/ath12k/debugfs_htt_stats.c    |  681 ++++++-
 .../net/wireless/ath/ath12k/debugfs_htt_stats.h    |  218 ++-
 drivers/net/wireless/ath/ath12k/dp.c               |   70 +-
 drivers/net/wireless/ath/ath12k/dp.h               |    3 +-
 drivers/net/wireless/ath/ath12k/dp_rx.c            |   96 +-
 drivers/net/wireless/ath/ath12k/dp_rx.h            |    6 +-
 drivers/net/wireless/ath/ath12k/hal_desc.h         |    2 +-
 drivers/net/wireless/ath/ath12k/hal_rx.c           |   12 +-
 drivers/net/wireless/ath/ath12k/mac.c              | 2003 +++++++++++++++-----
 drivers/net/wireless/ath/ath12k/mac.h              |   16 +-
 drivers/net/wireless/ath/ath12k/pci.c              |   10 +
 drivers/net/wireless/ath/ath12k/peer.c             |  223 ++-
 drivers/net/wireless/ath/ath12k/peer.h             |   23 +-
 drivers/net/wireless/ath/ath12k/qmi.c              |  167 +-
 drivers/net/wireless/ath/ath12k/qmi.h              |   20 +
 drivers/net/wireless/ath/ath12k/wmi.c              |  207 +-
 drivers/net/wireless/ath/ath12k/wmi.h              |  115 ++
 drivers/net/wireless/ath/ath9k/antenna.c           |    2 +-
 drivers/net/wireless/ath/ath9k/ar9002_hw.c         |    2 +-
 drivers/net/wireless/ath/ath9k/ar9003_hw.c         |    2 +-
 drivers/net/wireless/ath/ath9k/ar9003_mci.c        |    4 +-
 drivers/net/wireless/ath/ath9k/ar9003_phy.h        |    2 +-
 drivers/net/wireless/ath/ath9k/ath9k.h             |    2 +
 drivers/net/wireless/ath/ath9k/channel.c           |    2 +-
 drivers/net/wireless/ath/ath9k/common-spectral.c   |    2 +-
 drivers/net/wireless/ath/ath9k/debug.c             |    1 +
 drivers/net/wireless/ath/ath9k/debug.h             |    1 +
 drivers/net/wireless/ath/ath9k/dfs.c               |    2 +-
 drivers/net/wireless/ath/ath9k/hif_usb.c           |    2 +-
 drivers/net/wireless/ath/ath9k/hw.c                |    4 +-
 drivers/net/wireless/ath/ath9k/hw.h                |    2 +-
 drivers/net/wireless/ath/ath9k/link.c              |   33 +-
 drivers/net/wireless/ath/ath9k/mac.h               |    2 +-
 drivers/net/wireless/ath/ath9k/main.c              |    3 +-
 drivers/net/wireless/ath/ath9k/wow.c               |    6 +-
 drivers/net/wireless/ath/ath9k/xmit.c              |    2 +-
 drivers/net/wireless/ath/wcn36xx/main.c            |    5 +-
 54 files changed, 4042 insertions(+), 736 deletions(-)


From kvalo at kernel.org  Mon Dec  9 10:42:20 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Mon,  9 Dec 2024 18:42:20 +0000 (UTC)
Subject: pull-request: ath-next-20241209
In-Reply-To: <1bcdaf98-6078-4f79-a989-2e5db9400585@oss.qualcomm.com>
References: <1bcdaf98-6078-4f79-a989-2e5db9400585@oss.qualcomm.com>
Message-ID: <173376973868.347288.14583872593159043067.kvalo@kernel.org>

Jeff Johnson <jeff.johnson at oss.qualcomm.com> wrote:

> The following changes since commit 2b94751626a6d49bbe42a19cc1503bd391016bd5:
> 
>   wifi: cw1200: Fix potential NULL dereference (2024-10-31 16:20:02 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20241209
> 
> for you to fetch changes up to da8656797ae10b524a7a0c3d5eeb6237fa3ddd70:
> 
>   wifi: ath12k: introduce mlo_capable flag for device group (2024-12-05 14:34:10 -0800)
> 
> ----------------------------------------------------------------
> ath.git patches for v6.14
> 
> This development cycle featured multiple patchsets to ath12k to
> support the new 802.11be MLO feature, although the feature is still
> incomplete. Also in ath12k, there were other feature patches.  In
> ath11k, support was added for QCA6698AQ. And there was the usual set
> of bug fixes and cleanups across most drivers, notable being the
> addition of "noinline_for_stack" to some functions to avoid "stack
> frame size" warnings when compiling with clang.
> 
> ----------------------------------------------------------------
> Aditya Kumar Singh (2):
>       wifi: ath12k: ath12k_bss_assoc(): MLO support
>       wifi: ath12k: rename mlo_capable_flags to single_chip_mlo_supp
> 
> Balaji Pothunoori (2):
>       wifi: ath11k: Suspend hardware before firmware mode off for WCN6750
>       wifi: ath11k: Fix unexpected return buffer manager error for WCN6750/WCN6855
> 
> Barnab?s Cz?m?n (1):
>       wifi: wcn36xx: fix channel survey memory allocation size
> 
> Dinesh Karthikeyan (4):
>       wifi: ath12k: Support Downlink Pager Stats
>       wifi: ath12k: Support phy counter and TPC stats
>       wifi: ath12k: Support SoC Common Stats
>       wifi: ath12k: Support Transmit PER Rate Stats
> 
> Dmitry Antipov (5):
>       wifi: ath9k: miscellaneous spelling fixes
>       wifi: ath11k: cleanup struct ath11k_vif
>       wifi: ath11k: cleanup struct ath11k_reg_tpc_power_info
>       wifi: ath11k: cleanup struct ath11k_mon_data
>       wifi: ath11k: miscellaneous spelling fixes
> 
> Jeff Johnson (4):
>       wifi: ath12k: mark QMI driver event helpers as noinline
>       wifi: ath11k: mark some QMI driver event helpers as noinline
>       wifi: ath11k: mark ath11k_dp_rx_mon_mpdu_pop() as noinline
>       wifi: ath11k: mark ath11k_wow_convert_8023_to_80211() as noinline
> 
> Kalle Valo (5):
>       wifi: ath12k: ath12k_mac_vdev_create(): use goto for error handling
>       wifi: ath12k: introduce ath12k_hw_warn()
>       wifi: ath12k: convert struct ath12k::wmi_mgmt_tx_work to struct wiphy_work
>       wifi: ath12k: ath12k_mac_op_set_key(): fix uninitialized symbol 'ret'
>       wifi: ath12k: ath12k_mac_op_sta_rc_update(): use mac80211 provided link id
> 
> Karol Przybylski (1):
>       wifi: ath12k: Fix for out-of bound access error
> 
> Karthikeyan Periyasamy (10):
>       wifi: ath12k: Refactor core startup
>       wifi: ath12k: add ath12k_ab_to_ah() and ath12k_ab_set_ah()
>       wifi: ath12k: add ath12k_get_num_hw()
>       wifi: ath12k: introduce QMI firmware ready flag
>       wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()
>       wifi: ath12k: introduce device group abstraction
>       wifi: ath12k: refactor core start based on hardware group
>       wifi: ath12k: move struct ath12k_hw from per device to group
>       wifi: ath12k: send QMI host capability after device group is ready
>       wifi: ath12k: introduce mlo_capable flag for device group
> 
> Miaoqing Pan (1):
>       wifi: ath11k: add support for QCA6698AQ
> 
> P Praneesh (1):
>       wifi: ath12k: Fix endianness issue in struct hal_tlv_64_hdr
> 
> Rameshkumar Sundaram (4):
>       wifi: ath12k: add reo queue lookup table for ML peers
>       wifi: ath12k: modify chanctx iterators for MLO
>       wifi: ath12k: ath12k_mac_station_add(): fix potential rx_stats leak
>       wifi: ath12k: defer vdev creation for MLO
> 
> Roopni Devanathan (1):
>       wifi: ath12k: Fix inappropriate use of print_array_to_buf_index()
> 
> Sidhanta Sahu (1):
>       wifi: ath12k: Support MBSSID Control Frame Stats
> 
> Sriram R (16):
>       wifi: ath12k: MLO vdev bringup changes
>       wifi: ath12k: Refactor sta state machine
>       wifi: ath12k: Add helpers for multi link peer creation and deletion
>       wifi: ath12k: add multi-link flag in peer create command
>       wifi: ath12k: add helper to find multi-link station
>       wifi: ath12k: Add MLO peer assoc command support
>       wifi: ath12k: Add MLO station state change handling
>       wifi: ath12k: support change_sta_links() mac80211 op
>       wifi: ath12k: add primary link for data path operations
>       wifi: ath12k: use arsta instead of sta
>       wifi: ath12k: Use mac80211 vif's link_conf instead of bss_conf
>       wifi: ath12k: Use mac80211 sta's link_sta instead of deflink
>       wifi: ath12k: ath12k_mac_op_tx(): MLO support
>       wifi: ath12k: ath12k_mac_op_flush(): MLO support
>       wifi: ath12k: ath12k_mac_op_ampdu_action(): MLO support
>       wifi: ath12k: do not return invalid link id for scan link
> 
> Toke H?iland-J?rgensen (1):
>       wifi: ath9k: Add RX inactivity detection and reset chip when it occurs
> 
>  drivers/net/wireless/ath/ath11k/core.c             |  132 ++
>  drivers/net/wireless/ath/ath11k/core.h             |    4 +-
>  drivers/net/wireless/ath/ath11k/dp.h               |    1 -
>  drivers/net/wireless/ath/ath11k/dp_rx.c            |   14 +-
>  drivers/net/wireless/ath/ath11k/hal.h              |    6 +-
>  drivers/net/wireless/ath/ath11k/hal_rx.c           |    3 +-
>  drivers/net/wireless/ath/ath11k/hw.h               |    1 +
>  drivers/net/wireless/ath/ath11k/mac.c              |    6 +-
>  drivers/net/wireless/ath/ath11k/mhi.c              |    1 +
>  drivers/net/wireless/ath/ath11k/pci.c              |    3 +
>  drivers/net/wireless/ath/ath11k/pcic.c             |   13 +-
>  drivers/net/wireless/ath/ath11k/qmi.c              |    8 +-
>  drivers/net/wireless/ath/ath11k/wow.c              |    6 +-
>  drivers/net/wireless/ath/ath12k/core.c             |  482 ++++-
>  drivers/net/wireless/ath/ath12k/core.h             |  134 +-
>  drivers/net/wireless/ath/ath12k/debug.c            |    6 +-
>  drivers/net/wireless/ath/ath12k/debug.h            |    5 +-
>  .../net/wireless/ath/ath12k/debugfs_htt_stats.c    |  681 ++++++-
>  .../net/wireless/ath/ath12k/debugfs_htt_stats.h    |  218 ++-
>  drivers/net/wireless/ath/ath12k/dp.c               |   70 +-
>  drivers/net/wireless/ath/ath12k/dp.h               |    3 +-
>  drivers/net/wireless/ath/ath12k/dp_rx.c            |   96 +-
>  drivers/net/wireless/ath/ath12k/dp_rx.h            |    6 +-
>  drivers/net/wireless/ath/ath12k/hal_desc.h         |    2 +-
>  drivers/net/wireless/ath/ath12k/hal_rx.c           |   12 +-
>  drivers/net/wireless/ath/ath12k/mac.c              | 2003 +++++++++++++++-----
>  drivers/net/wireless/ath/ath12k/mac.h              |   16 +-
>  drivers/net/wireless/ath/ath12k/pci.c              |   10 +
>  drivers/net/wireless/ath/ath12k/peer.c             |  223 ++-
>  drivers/net/wireless/ath/ath12k/peer.h             |   23 +-
>  drivers/net/wireless/ath/ath12k/qmi.c              |  167 +-
>  drivers/net/wireless/ath/ath12k/qmi.h              |   20 +
>  drivers/net/wireless/ath/ath12k/wmi.c              |  207 +-
>  drivers/net/wireless/ath/ath12k/wmi.h              |  115 ++
>  drivers/net/wireless/ath/ath9k/antenna.c           |    2 +-
>  drivers/net/wireless/ath/ath9k/ar9002_hw.c         |    2 +-
>  drivers/net/wireless/ath/ath9k/ar9003_hw.c         |    2 +-
>  drivers/net/wireless/ath/ath9k/ar9003_mci.c        |    4 +-
>  drivers/net/wireless/ath/ath9k/ar9003_phy.h        |    2 +-
>  drivers/net/wireless/ath/ath9k/ath9k.h             |    2 +
>  drivers/net/wireless/ath/ath9k/channel.c           |    2 +-
>  drivers/net/wireless/ath/ath9k/common-spectral.c   |    2 +-
>  drivers/net/wireless/ath/ath9k/debug.c             |    1 +
>  drivers/net/wireless/ath/ath9k/debug.h             |    1 +
>  drivers/net/wireless/ath/ath9k/dfs.c               |    2 +-
>  drivers/net/wireless/ath/ath9k/hif_usb.c           |    2 +-
>  drivers/net/wireless/ath/ath9k/hw.c                |    4 +-
>  drivers/net/wireless/ath/ath9k/hw.h                |    2 +-
>  drivers/net/wireless/ath/ath9k/link.c              |   33 +-
>  drivers/net/wireless/ath/ath9k/mac.h               |    2 +-
>  drivers/net/wireless/ath/ath9k/main.c              |    3 +-
>  drivers/net/wireless/ath/ath9k/wow.c               |    6 +-
>  drivers/net/wireless/ath/ath9k/xmit.c              |    2 +-
>  drivers/net/wireless/ath/wcn36xx/main.c            |    5 +-
>  54 files changed, 4042 insertions(+), 736 deletions(-)

Pulled, thanks.

b20821248e26 Merge tag 'ath-next-20241209' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1bcdaf98-6078-4f79-a989-2e5db9400585 at oss.qualcomm.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From tharvey at gateworks.com  Mon Dec  9 11:15:02 2024
From: tharvey at gateworks.com (Tim Harvey)
Date: Mon, 9 Dec 2024 11:15:02 -0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de> <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
Message-ID: <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>

On Mon, Dec 9, 2024 at 2:49?AM Robin Murphy <robin.murphy at arm.com> wrote:
>
> On 09/12/2024 8:17 am, Christoph Hellwig wrote:
> > I scrolled three pages before giving up as it was just quotes over
> > quotas.  Can you please write an email that contains whatever you're
> > trying to tell instead of just quotes?  Same for the person replying.
>

Christoph,

Understood; there was a lot of back and forth and likely some
misinformation from my early replies. Let me recap here.

The issue I run into is that with Linux 6.9 and beyond on an IMX8M
Mini SoC (no IMOMMU) with >3GiB DRAM (which requires more than 32 bits
of address due to IMX8M's DRAM base being at 0x40000000) the ath11k
driver will fail to register a netdev and errors out with 'ath11k
swiotlb buffer is full':
[    8.057077] ath11k_pci 0000:04:00.0: BAR 0 [mem
0x18200000-0x183fffff 64bit]: assigned
[    8.057151] ath11k_pci 0000:04:00.0: enabling device (0000 -> 0002)
[    8.091920] ath11k_pci 0000:04:00.0: MSI vectors: 16
[    8.091960] ath11k_pci 0000:04:00.0: qcn9074 hw1.0
[    8.832924] ath11k_pci 0000:04:00.0: chip_id 0x0 chip_family 0x0
board_id 0xff soc_id 0xffffffff
[    8.832951] ath11k_pci 0000:04:00.0: fw_version 0x270206d0
fw_build_timestamp 2022-08-04 12:48 fw_build_id
WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
[   10.194343] ath11k_pci 0000:04:00.0: swiotlb buffer is full (sz:
1048583 bytes), total 32768 (slots), used 2529 (slots)
[   10.194406] ath11k_pci 0000:04:00.0: failed to set up tcl_comp ring (0) :-12
[   10.194781] ath11k_pci 0000:04:00.0: failed to init DP: -12

After a lot of back and forth and investigation this is due to the
IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
is requesting some buffers that are too large for swiotlb to provide.
There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
to cacheable memory that could be reverted to fix this but the concern
was that it would impact performance moving those buffers to
non-cacheable memory (there are three ~1MiB buffers being allocated):
commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
cacheable memory").

> TBH I'm hesitant to look too closely since everything those Atheros WiFi
> drivers do with DMA tends to be sketchy, but from what I could make out
> from skimming until I also gave up, I think it might be an attempt to
> reinvent dma_alloc_pages(), or possibly dma_alloc_noncoherent().

Robin,

Agreed - I'm not sure how much attention, review, or testing these
ath11k patches originally got due to the fact that there appears to be
breakage for a couple of years here.

The chain of events as best I can tell are:

commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
cacheable memory")
- Nov 12 2021 (made it into Linux 5.17)
- changes allocation of reo_dst rings to cacheable memory to allow
cached descriptor access to optimize CPU usage
- this is flawed because it uses virt_to_phys() to allocate cacheable
memory which does not work on systems with an IOMMU enabled or using
software IOMMU (swiotlb); this causes a kernel crash on client
association

commit d0e2523bfa9c ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
cacheable memory)
- Nov 12 2021 (made it into Linux Linux 5.17)
- furthers the previous patch by also including the WBM2SW buffers in
cacheable memory which are about 1MiB in size

commit aaf244141ed7 ("wifi: ath11k: fix IOMMU errors on buffer rings")
- Dec 20 2023 (made it into Linux 6.9)
- resolves the issue from commit 6452f0a3d565 (but missing a Fixes
tag) by changing the virt_to_phys calls to dma_map_single() but on
systems that need software IOMMUC (IMX8MM > 3GiB) this exposes the
'swiotlb buffer is full' limitation due to commit d0e2523bfa9c which
allocates buffers exceeding the 256KiB limit imposed by swiotlb

Therefore in the case of an IOMMU'less system with DMA address
limitations of 32bit and >3GiB DRAM (as many IMX8M boards have) the
ath11k driver has been broken since 5.17.

Best Regards,

Tim


From quic_yuzha at quicinc.com  Mon Dec  9 18:32:31 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Tue, 10 Dec 2024 10:32:31 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <CAFED-jk--dXAoXJ9ijpnUDeD=WiW4ZeoLb45WXiVpzPvkgX12A@mail.gmail.com>
References: <20bf2693-ce53-48e9-8b54-7e3273815033@quicinc.com>
 <20241203094820.106225-1-jtornosm@redhat.com>
 <99359cc4-2279-4a8a-80a1-d5475fd5208d@quicinc.com>
 <CAFED-jk--dXAoXJ9ijpnUDeD=WiW4ZeoLb45WXiVpzPvkgX12A@mail.gmail.com>
Message-ID: <1848f4fa-bc38-44b3-a6c2-8c97a765bfb1@quicinc.com>



On 12/9/2024 7:23 PM, Janusz Dziedzic wrote:
> wt., 3 gru 2024 o 11:57 Yu Zhang (Yuriy) <quic_yuzha at quicinc.com> napisa?(a):
>>
>>
>>
>> On 12/3/2024 5:48 PM, Jose Ignacio Tornos Martinez wrote:
>>>> Which chip do you use?
>>> Since I am not totally sure about the useful information, let me show you
>>> the kernel logs:
>>> $ dmesg | grep ath11k
>>> [    3.659388] ath11k_pci 0000:01:00.0: BAR 0 [mem 0x84200000-0x843fffff 64bit]: assigned
>>> [    3.659405] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
>>> [    3.659649] ath11k_pci 0000:01:00.0: MSI vectors: 32
>>> [    3.659653] ath11k_pci 0000:01:00.0: wcn6855 hw2.1
>>> [    4.871571] ath11k_pci 0000:01:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0210
>>> [    4.871586] ath11k_pci 0000:01: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
>>> [    5.241485] ath11k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
>>>
>> yes, you also use wcn6855 hw2.1.
>>> If I try to setup 2 APs with your interface combination I get this:
>>> # iw list | grep -A6 "valid interface combinations:"
>>>        valid interface combinations:
>>>                 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
>>>                   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
>>>
>>>                 * #{ managed } <= 2, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
>>>                   total <= 3, #channels <= 2, STA/AP BI must match
>>>        HT Capability overrides:
>> 2 combinations are to support DBS and DFS.
>> Combinations is correct. channels=2, max interfaces=3.
>>
> Small question from my side. If phyX will support 3 bands (2.4/5/6)
> what this channes<=2 limitation mean here for APs?
>   a) can I setup APs on 2412 and 5180
>   b) or even can setup APs on 2412 and 2462?
>   c) or setup APs on 5180 and 6055?
> How could I know a or b or c is allowed?
> 
all allowed, but recommend more 2.4g + 5g and 2.4g + 6g.
> BTW, do you plan to share same firmware (with 2 possible APs) for
> ath12k and WCN7850?
> 
WCN7850 use different firmware, when ath11k done will plan about ath12k 
about it.

And by the way, if you try in ath11k with 2 aps?
> BR
> Janusz
> 
>> And you want setup sta + sap + sap, right?
>> When up the second sap will meet error? Could you pls share the error logs?
>>
>> I'm not very sure if you add all interface with managed type, and do
>> "ifconfig xxx up" before running hostapd.
>>
>> You can try add second and third interface with
>> "iw dev xx interface add xx type __ap".
>>
>>
>>> # iw dev
>>> phy#0
>>>        Interface wlp1s0_1
>>>                ifindex 6
>>>                wdev 0x4
>>>                addr a2:42:d2:1e:89:a3
>>>                type managed
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0_0
>>>                ifindex 5
>>>                wdev 0x3
>>>                addr 52:e9:be:33:6a:61
>>>                ssid test-qe-wpa2-psk
>>>                type AP
>>>                channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
>>>                txpower 14.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0
>>>                ifindex 3
>>>                wdev 0x1
>>>                addr c8:94:02:b5:fe:fb
>>>                type managed
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>> Or even this with no AP up:
>>> # iw dev
>>> phy#0
>>>        Interface wlp1s0_1
>>>                ifindex 6
>>>                wdev 0x4
>>>                addr ca:e5:84:22:10:ec
>>>                type managed
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0_0
>>>                ifindex 5
>>>                wdev 0x3
>>>                addr 9e:4e:c5:ea:4c:e9
>>>                type AP
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0
>>>                ifindex 3
>>>                wdev 0x1
>>>                addr c8:94:02:b5:fe:fb
>>>                type managed
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>
>>> If I use the parameter to ignore the feature and configure the interface combination as before:
>>> # iw list | grep -A4 "valid interface combinations:"
>>>        valid interface combinations:
>>>                 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 16, #{ P2P-device } <= 1,
>>>                   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
>>>
>>>        HT Capability overrides:
>>> # iw dev
>>> phy#1
>>>        Interface wlp1s0_1
>>>                ifindex 7
>>>                wdev 0x100000004
>>>                addr 82:90:89:90:c1:37
>>>                ssid test-qe-wpa3-psk
>>>                type AP
>>>                channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0_0
>>>                ifindex 6
>>>                wdev 0x100000003
>>>                addr 6a:ef:d0:db:10:f0
>>>                ssid test-qe-wpa2-psk
>>>                type AP
>>>                channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>        Interface wlp1s0
>>>                ifindex 4
>>>                wdev 0x100000001
>>>                addr c8:94:02:b5:fe:fb
>>>                type managed
>>>                txpower 16.00 dBm
>>>                multicast TXQ:
>>>                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
>>>                        0       0       0       0       0       0       0       0               0
>>>
>>> Thanks
>>>
>>> Best regards
>>> Jose Ignacio
>>>
>>
>>
> 
> 



From quic_yuzha at quicinc.com  Mon Dec  9 18:37:44 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Tue, 10 Dec 2024 10:37:44 +0800
Subject: [PATCH v3] arm64: dts: qcom: qcs615: add WiFi/BT nodes
In-Reply-To: <7107275e-1ccf-4f09-ada3-e082833d9364@oss.qualcomm.com>
References: <20241203060318.1750927-1-quic_yuzha@quicinc.com>
 <1ca062dd-8910-4caf-a133-0e5717b43540@oss.qualcomm.com>
 <649dc6c0-f0e1-4dca-8f93-d0f81803cd70@quicinc.com>
 <7107275e-1ccf-4f09-ada3-e082833d9364@oss.qualcomm.com>
Message-ID: <fd8dd19a-a15b-48a3-ab14-9c63e617ed10@quicinc.com>



On 12/6/2024 8:16 PM, Konrad Dybcio wrote:
> On 6.12.2024 4:22 AM, Yu Zhang (Yuriy) wrote:
>>
>>
>> On 12/6/2024 1:14 AM, Konrad Dybcio wrote:
>>> On 3.12.2024 7:03 AM, Yu Zhang(Yuriy) wrote:
>>>> Add a node for the PMU module of the WCN6855 present on the qcs615
>>>> board. Assign its LDO power outputs to the existing WiFi/BT module.
>>>>
>>>
>>> subject:
>>>
>>> arm64: dts: qcom: qcs615-ride: ....
>>>
>>> [...]
>>>
>>>> +
>>>> +??? vreg_conn_1p8: vreg_conn_1p8 {
>>>> +??????? compatible = "regulator-fixed";
>>>> +??????? regulator-name = "vreg_conn_1p8";
>>>> +??????? startup-delay-us = <4000>;
>>>> +??????? enable-active-high;
>>>> +??????? gpio = <&pm8150_gpios 1 GPIO_ACTIVE_HIGH>;
>>>> +??? };
>>>> +
>>>> +??? vreg_conn_pa: vreg_conn_pa {
>>>> +??????? compatible = "regulator-fixed";
>>>> +??????? regulator-name = "vreg_conn_pa";
>>>> +??????? startup-delay-us = <4000>;
>>>> +??????? enable-active-high;
>>>> +??????? gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
>>>> +??? };
>>>
>>> Are any of these boot-on?
>>>
>> Yes, these are used wcn6855-pmu?
>>  ???? vddio-supply = <&vreg_conn_pa>;
>>  ???? vddpmu-supply = <&vreg_conn_1p8>;
> 
> What i meant is, whether these regulators are enabled at boot
> time (i.e. without software intervention). If that's the case,
> `regulator-boot-on;` should be added
> 
No need regulator-boot-on, it was triggered by the 
software(pci_pwrctl_pwrseq_driver).
> Konrad
Yu


From hch at lst.de  Mon Dec  9 20:11:33 2024
From: hch at lst.de (Christoph Hellwig)
Date: Tue, 10 Dec 2024 05:11:33 +0100
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com> <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com> <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com> <20241209081714.GA25363@lst.de> <593c0d63-d8fd-4439-a57a-97340212c197@arm.com> <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
Message-ID: <20241210041133.GA17116@lst.de>

On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
> After a lot of back and forth and investigation this is due to the
> IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
> is requesting some buffers that are too large for swiotlb to provide.
> There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
> to cacheable memory that could be reverted to fix this but the concern
> was that it would impact performance moving those buffers to
> non-cacheable memory (there are three ~1MiB buffers being allocated):
> commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
> cacheable memory").

The combination of "buffers" and "swiotlb" sounds like Robin was right
below. 

> The chain of events as best I can tell are:
> 
> commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
> cacheable memory")
> - Nov 12 2021 (made it into Linux 5.17)
> - changes allocation of reo_dst rings to cacheable memory to allow
> cached descriptor access to optimize CPU usage
> - this is flawed because it uses virt_to_phys() to allocate cacheable
> memory which does not work on systems with an IOMMU enabled or using
> software IOMMU (swiotlb); this causes a kernel crash on client
> association

And this is where it started to take a wrong turn, that everyhing
later basically made worse.  If you have long living and potentially
large DMA allocations, you need to use dma_alloc_* interfaces.

5.17 already had dma_alloc_pages for quite a while which was and still is
the proper interface to use.  For much older kernel you'd be stuck
with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
but even that would have been much better.


From jtornosm at redhat.com  Tue Dec 10 00:44:19 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Tue, 10 Dec 2024 09:44:19 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <db61f998-2524-4623-8b0f-143661507e38@quicinc.com>
References: <db61f998-2524-4623-8b0f-143661507e38@quicinc.com>
Message-ID: <20241210084419.126723-1-jtornosm@redhat.com>

> Yes, Can you pls share the complete steps and commands?
Sure, I offered it before.

You need NetworkManager and of course NetworkManager-wifi packages installed
and working.
We are using Fedora/rhel with the default configuration and you can configure,
before the next steps, the wifi interface as sta from NetworkManager or not
(with no wifi configuration the same result happens) because it is going to
be unmanaged.

After booting (wlp1s0 is the wifi interface for ath11k and there are no other
wifi cards in the system), here the necessary steps with our network
configuration:
# nmcli  device set wlp1s0 managed off
# ip link set wlp1s0 up
# ip link add name wifi_br0 type bridge
# ip addr add 192.168.254.1/24 dev wifi_br0
# ip link set wifi_br0 up
# iw dev wlp1s0 interface add wlp1s0_0 type __ap
# iw dev wlp1s0 interface add wlp1s0_1 type __ap
# systemd-run --unit hostapd1 hostapd -dd /tmp/hostapd1.conf
# systemd-run --unit hostapd2 hostapd -dd /tmp/hostapd2.conf
# dnsmasq \
    --pid-file=/tmp/dnsmasq_wireless.pid \
    --port=63 \
    --no-hosts \
    --interface=wifi_br0 \
    --bind-interfaces \
    --dhcp-range=192.168.254.2,192.168.254.205,60m \
    --dhcp-option=option:router,192.168.254.1 \
    --dhcp-leasefile=/var/lib/dnsmasq/hostapd.leases \
    --dhcp-lease-max=200

After booting I get the same issue just doing:
# nmcli  device set wlp1s0 managed off
# ip link set wlp1s0 up
And the step that you commented in a previous answer:
# iw dev wlp1s0 interface add wlp1s0_0 type __ap
# iw dev wlp1s0 interface add wlp1s0_1 type __ap
# hostapd hostapd1.conf &
# hostapd hostapd2.conf &

You can use whatever hostapd configuration (with the suitable interface name).

Thanks

Best regards
Jose Ignacio



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:33 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:33 +0000
Subject: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>

This script finds and suggests conversions of timeout patterns that
result in seconds-denominated timeouts to use the new secs_to_jiffies()
API in include/linux/jiffies.h for better readability.

Suggested-by: Anna-Maria Behnsen <anna-maria at linutronix.de>
Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
new file mode 100644
index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
--- /dev/null
+++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Find usages of:
+/// - msecs_to_jiffies(value*1000)
+/// - msecs_to_jiffies(value*MSEC_PER_SEC)
+///
+// Confidence: High
+// Copyright: (C) 2024 Easwar Hariharan, Microsoft
+// Keywords: secs, seconds, jiffies
+//
+
+virtual patch
+
+ at depends on patch@ constant C; @@
+
+- msecs_to_jiffies(C * 1000)
++ secs_to_jiffies(C)
+
+ at depends on patch@ constant C; @@
+
+- msecs_to_jiffies(C * MSEC_PER_SEC)
++ secs_to_jiffies(C)

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:31 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:31 +0000
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-ID: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>

This is a series that follows up on my previous series to introduce
secs_to_jiffies() and convert a few initial users.[1] In the review for
that series, Anna-Maria requested converting other users with
Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
that use the multiply pattern of either of:
- msecs_to_jiffies(N*1000), or
- msecs_to_jiffies(N*MSEC_PER_SEC)

where N is a constant, to avoid the multiplication.

The entire conversion is made with Coccinelle in the script added in
patch 2. Some changes suggested by Coccinelle have been deferred to
later parts that will address other possible variant patterns.

CC: Anna-Maria Behnsen <anna-maria at linutronix.de>
Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>

[1] https://lore.kernel.org/all/20241030-open-coded-timeouts-v3-0-9ba123facf88 at linux.microsoft.com/
[2] https://lore.kernel.org/all/8734kngfni.fsf at somnus/

---
Changes in v3:
- Rebase on next-20241210
- Fix typo'ed timeout in net/netfilter/nf_conntrack_proto_sctp.c (Stephen Rothwell)
- Use Coccinelle operation modes for Coccinelle script (Markus Elfring)
- Remove redundant comments in arch/arm/mach-pxa/sharpsl_pm.c
  (Christophe Leroy)
- Remove excess line breaks (Heiko Carstens, Christophe Leroy)
- Add more detail into the commit messages throughout (Christophe Leroy)
- Pick up Reviewed-by Thomas Hellstr?m for drm/xe
- Drop drm/etnaviv patch already queued into etnaviv/next
- Replace call to [m]secs_to_jiffies(0) with just 0 for livepatch (Dan
  Carpenter, Christophe Leroy)
- Split out nfp patch to send to net-next (Christophe Leroy)
- Pick up Acked-by from Jeff Johnson for ath11k
- Link to v2: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v2-0-911fb7595e79 at linux.microsoft.com
Changes in v2:
- Exclude already accepted patch adding secs_to_jiffies() https://git.kernel.org/tip/b35108a51cf7bab58d7eace1267d7965978bcdb8
- Link to v1: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v1-0-19aadc34941b at linux.microsoft.com

---
Easwar Hariharan (19):
      netfilter: conntrack: Cleanup timeout definitions
      coccinelle: misc: Add secs_to_jiffies script
      arm: pxa: Convert timeouts to use secs_to_jiffies()
      s390: kernel: Convert timeouts to use secs_to_jiffies()
      powerpc/papr_scm: Convert timeouts to secs_to_jiffies()
      mm: kmemleak: Convert timeouts to secs_to_jiffies()
      accel/habanalabs: Convert timeouts to secs_to_jiffies()
      drm/xe: Convert timeout to secs_to_jiffies()
      scsi: lpfc: Convert timeouts to secs_to_jiffies()
      scsi: arcmsr: Convert timeouts to secs_to_jiffies()
      scsi: pm8001: Convert timeouts to secs_to_jiffies()
      xen/blkback: Convert timeouts to secs_to_jiffies()
      gve: Convert timeouts to secs_to_jiffies()
      wifi: ath11k: Convert timeouts to secs_to_jiffies()
      Bluetooth: MGMT: Convert timeouts to secs_to_jiffies()
      staging: vc04_services: Convert timeouts to secs_to_jiffies()
      ceph: Convert timeouts to secs_to_jiffies()
      livepatch: Convert timeouts to secs_to_jiffies()
      ALSA: line6: Convert timeouts to secs_to_jiffies()

 arch/arm/mach-pxa/sharpsl_pm.c                     |  8 ++++----
 arch/powerpc/platforms/pseries/papr_scm.c          |  2 +-
 arch/s390/kernel/lgr.c                             |  2 +-
 arch/s390/kernel/time.c                            |  4 ++--
 arch/s390/kernel/topology.c                        |  2 +-
 drivers/accel/habanalabs/common/device.c           |  2 +-
 drivers/accel/habanalabs/common/habanalabs_drv.c   |  3 +--
 drivers/block/xen-blkback/blkback.c                |  2 +-
 drivers/gpu/drm/xe/xe_device.c                     |  2 +-
 drivers/net/ethernet/google/gve/gve_tx_dqo.c       |  6 ++----
 drivers/net/wireless/ath/ath11k/debugfs.c          |  2 +-
 drivers/scsi/arcmsr/arcmsr_hba.c                   |  2 +-
 drivers/scsi/lpfc/lpfc_init.c                      | 18 +++++++++---------
 drivers/scsi/lpfc/lpfc_nportdisc.c                 |  8 ++++----
 drivers/scsi/lpfc/lpfc_nvme.c                      |  2 +-
 drivers/scsi/lpfc/lpfc_sli.c                       |  4 ++--
 drivers/scsi/lpfc/lpfc_vmid.c                      |  2 +-
 drivers/scsi/pm8001/pm8001_init.c                  |  2 +-
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c    |  2 +-
 fs/ceph/quota.c                                    |  2 +-
 mm/kmemleak.c                                      |  4 ++--
 net/bluetooth/mgmt.c                               |  2 +-
 net/netfilter/nf_conntrack_proto_sctp.c            | 21 ++++++++-------------
 samples/livepatch/livepatch-callbacks-busymod.c    |  3 +--
 samples/livepatch/livepatch-shadow-fix1.c          |  3 +--
 samples/livepatch/livepatch-shadow-mod.c           | 15 +++++----------
 scripts/coccinelle/misc/secs_to_jiffies.cocci      | 22 ++++++++++++++++++++++
 sound/usb/line6/toneport.c                         |  2 +-
 28 files changed, 78 insertions(+), 71 deletions(-)
---
base-commit: 1b2ab8149928c1cea2d7eca30cd35bb7fe014053
change-id: 20241112-converge-secs-to-jiffies-d99d1016bd11

Best regards,
-- 
Easwar Hariharan <eahariha at linux.microsoft.com>



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:34 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:34 +0000
Subject: [PATCH v3 03/19] arm: pxa: Convert timeouts to use
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-3-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 arch/arm/mach-pxa/sharpsl_pm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 0c8d9000df5a6384d615cf231ff986c0c6b71681..dd930e3a61a493293597815782d2ffd36605a700 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -31,10 +31,10 @@
 /*
  * Constants
  */
-#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
-#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
-#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
-#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
+#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (secs_to_jiffies(60))
+#define SHARPSL_CHARGE_FINISH_TIME             (secs_to_jiffies(10*60))
+#define SHARPSL_BATCHK_TIME                    (secs_to_jiffies(15))
+#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10) /* 10 min */
 
 #define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
 #define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:32 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:32 +0000
Subject: [PATCH v3 01/19] netfilter: conntrack: Cleanup timeout definitions
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-1-ddfefd7e9f2a@linux.microsoft.com>

None of the higher order definitions are used anymore, so remove
definitions for minutes, hours, and days timeouts. Convert the seconds
denominated timeouts to secs_to_jiffies()

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 net/netfilter/nf_conntrack_proto_sctp.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
index 4cc97f971264ed779434ab4597dd0162586b3736..7c6f7c9f73320dd208bd0940f539bd9e662e62d0 100644
--- a/net/netfilter/nf_conntrack_proto_sctp.c
+++ b/net/netfilter/nf_conntrack_proto_sctp.c
@@ -39,20 +39,15 @@ static const char *const sctp_conntrack_names[] = {
 	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= "HEARTBEAT_SENT",
 };
 
-#define SECS  * HZ
-#define MINS  * 60 SECS
-#define HOURS * 60 MINS
-#define DAYS  * 24 HOURS
-
 static const unsigned int sctp_timeouts[SCTP_CONNTRACK_MAX] = {
-	[SCTP_CONNTRACK_CLOSED]			= 10 SECS,
-	[SCTP_CONNTRACK_COOKIE_WAIT]		= 3 SECS,
-	[SCTP_CONNTRACK_COOKIE_ECHOED]		= 3 SECS,
-	[SCTP_CONNTRACK_ESTABLISHED]		= 210 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= 3 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= 3 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT]	= 3 SECS,
-	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= 30 SECS,
+	[SCTP_CONNTRACK_CLOSED]			= secs_to_jiffies(10),
+	[SCTP_CONNTRACK_COOKIE_WAIT]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_COOKIE_ECHOED]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_ESTABLISHED]		= secs_to_jiffies(210),
+	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT]	= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= secs_to_jiffies(30),
 };
 
 #define	SCTP_FLAG_HEARTBEAT_VTAG_FAILED	1

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:35 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:35 +0000
Subject: [PATCH v3 04/19] s390: kernel: Convert timeouts to use
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the values here are a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 arch/s390/kernel/lgr.c      | 2 +-
 arch/s390/kernel/time.c     | 4 ++--
 arch/s390/kernel/topology.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/s390/kernel/lgr.c b/arch/s390/kernel/lgr.c
index 6652e54cf3db9fbdd8cfb06f8a0dc1d4c05ae7d7..6d1ffca5f798086160112990cb947ec8deed0659 100644
--- a/arch/s390/kernel/lgr.c
+++ b/arch/s390/kernel/lgr.c
@@ -166,7 +166,7 @@ static struct timer_list lgr_timer;
  */
 static void lgr_timer_set(void)
 {
-	mod_timer(&lgr_timer, jiffies + msecs_to_jiffies(LGR_TIMER_INTERVAL_SECS * MSEC_PER_SEC));
+	mod_timer(&lgr_timer, jiffies + secs_to_jiffies(LGR_TIMER_INTERVAL_SECS));
 }
 
 /*
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 34a65c141ea076ba97b3238f1f36f077b15961df..e9f47c3a61978a45c72aee23bc44dcb128113c8c 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -662,12 +662,12 @@ static void stp_check_leap(void)
 		if (ret < 0)
 			pr_err("failed to set leap second flags\n");
 		/* arm Timer to clear leap second flags */
-		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(14400 * MSEC_PER_SEC));
+		mod_timer(&stp_timer, jiffies + secs_to_jiffies(14400));
 	} else {
 		/* The day the leap second is scheduled for hasn't been reached. Retry
 		 * in one hour.
 		 */
-		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(3600 * MSEC_PER_SEC));
+		mod_timer(&stp_timer, jiffies + secs_to_jiffies(3600));
 	}
 }
 
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4f9c301a705b63f8dd0e7bc33e7206ad1222e7a7..0fd56a1cadbd4f41a9876a3a3fec7f5dc08ac2db 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -371,7 +371,7 @@ static void set_topology_timer(void)
 	if (atomic_add_unless(&topology_poll, -1, 0))
 		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(100));
 	else
-		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(60 * MSEC_PER_SEC));
+		mod_timer(&topology_timer, jiffies + secs_to_jiffies(60));
 }
 
 void topology_expect_change(void)

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:37 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:37 +0000
Subject: [PATCH v3 06/19] mm: kmemleak: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-6-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 mm/kmemleak.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2a945c07ae99525815c8fb733e8eb1b4da60668e..a2ded75cc0c03838bc048c82990c8524f25549b6 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1855,7 +1855,7 @@ static int kmemleak_scan_thread(void *arg)
 	 * Wait before the first scan to allow the system to fully initialize.
 	 */
 	if (first_run) {
-		signed long timeout = msecs_to_jiffies(SECS_FIRST_SCAN * 1000);
+		signed long timeout = secs_to_jiffies(SECS_FIRST_SCAN);
 		first_run = 0;
 		while (timeout && !kthread_should_stop())
 			timeout = schedule_timeout_interruptible(timeout);
@@ -2241,7 +2241,7 @@ void __init kmemleak_init(void)
 		return;
 
 	jiffies_min_age = msecs_to_jiffies(MSECS_MIN_AGE);
-	jiffies_scan_wait = msecs_to_jiffies(SECS_SCAN_WAIT * 1000);
+	jiffies_scan_wait = secs_to_jiffies(SECS_SCAN_WAIT);
 
 	object_cache = KMEM_CACHE(kmemleak_object, SLAB_NOLEAKTRACE);
 	scan_area_cache = KMEM_CACHE(kmemleak_scan_area, SLAB_NOLEAKTRACE);

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:36 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:36 +0000
Subject: [PATCH v3 05/19] powerpc/papr_scm: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f84ac9fbe203c111046464b9100866dddae687bb..f7c9271bda58433f395648063e60409a8d3c11d9 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -544,7 +544,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
 
 	/* Jiffies offset for which the health data is assumed to be same */
 	cache_timeout = p->lasthealth_jiffies +
-		msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
+		secs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL);
 
 	/* Fetch new health info is its older than MIN_HEALTH_QUERY_INTERVAL */
 	if (time_after(jiffies, cache_timeout))

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:38 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:38 +0000
Subject: [PATCH v3 07/19] accel/habanalabs: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-7-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/accel/habanalabs/common/device.c         | 2 +-
 drivers/accel/habanalabs/common/habanalabs_drv.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/habanalabs/common/device.c b/drivers/accel/habanalabs/common/device.c
index e0cf3b4343bb081638430f2552ed27431b488ff9..30277ae410d4b742ffb7bddc35498564ff96fe62 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -817,7 +817,7 @@ static void device_hard_reset_pending(struct work_struct *work)
 		}
 
 		queue_delayed_work(hdev->reset_wq, &device_reset_work->reset_work,
-					msecs_to_jiffies(HL_PENDING_RESET_PER_SEC * 1000));
+					secs_to_jiffies(HL_PENDING_RESET_PER_SEC));
 	}
 }
 
diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c b/drivers/accel/habanalabs/common/habanalabs_drv.c
index 5409b2c656c803f6d172dd882711357061f30022..596c52e8aa266bf48e2be45e719adb202604577b 100644
--- a/drivers/accel/habanalabs/common/habanalabs_drv.c
+++ b/drivers/accel/habanalabs/common/habanalabs_drv.c
@@ -361,8 +361,7 @@ static void fixup_device_params_per_asic(struct hl_device *hdev, int timeout)
 		 * a different default timeout for Gaudi
 		 */
 		if (timeout == HL_DEFAULT_TIMEOUT_LOCKED)
-			hdev->timeout_jiffies = msecs_to_jiffies(GAUDI_DEFAULT_TIMEOUT_LOCKED *
-										MSEC_PER_SEC);
+			hdev->timeout_jiffies = secs_to_jiffies(GAUDI_DEFAULT_TIMEOUT_LOCKED);
 
 		hdev->reset_upon_device_release = 0;
 		break;

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:39 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:39 +0000
Subject: [PATCH v3 08/19] drm/xe: Convert timeout to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-8-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Reviewed-by: Thomas Hellstr?m <thomas.hellstrom at linux.intel.com>
Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/gpu/drm/xe/xe_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 56d4ffb650dade8622cc25026a96155fa5572434..9093469a275f46f7bf58ff1049c1c9cc712cdd33 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -519,7 +519,7 @@ static int wait_for_lmem_ready(struct xe_device *xe)
 	drm_dbg(&xe->drm, "Waiting for lmem initialization\n");
 
 	start = jiffies;
-	timeout = start + msecs_to_jiffies(60 * 1000); /* 60 sec! */
+	timeout = start + secs_to_jiffies(60); /* 60 sec! */
 
 	do {
 		if (signal_pending(current))

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:41 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:41 +0000
Subject: [PATCH v3 10/19] scsi: arcmsr: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-10-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/scsi/arcmsr/arcmsr_hba.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 6a32e3e0d516881fd87a56a394607930582644ee..fe7de7705b7e2c84324f1a493f7825343d6476c6 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1045,7 +1045,7 @@ static void arcmsr_init_get_devmap_timer(struct AdapterControlBlock *pacb)
 static void arcmsr_init_set_datetime_timer(struct AdapterControlBlock *pacb)
 {
 	timer_setup(&pacb->refresh_timer, arcmsr_set_iop_datetime, 0);
-	pacb->refresh_timer.expires = jiffies + msecs_to_jiffies(60 * 1000);
+	pacb->refresh_timer.expires = jiffies + secs_to_jiffies(60);
 	add_timer(&pacb->refresh_timer);
 }
 

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:42 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:42 +0000
Subject: [PATCH v3 11/19] scsi: pm8001: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-11-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/scsi/pm8001/pm8001_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
index f8c81e53e93f7849bbe7fe9cbc861f22b964bc39..22e0e79e88ab0a60965ff3809de116eb4a6851e2 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -736,7 +736,7 @@ static int pm8001_init_sas_add(struct pm8001_hba_info *pm8001_ha)
 		return -EIO;
 	}
 	time_remaining = wait_for_completion_timeout(&completion,
-				msecs_to_jiffies(60*1000)); // 1 min
+				secs_to_jiffies(60)); // 1 min
 	if (!time_remaining) {
 		kfree(payload.func_specific);
 		pm8001_dbg(pm8001_ha, FAIL, "get_nvmd_req timeout\n");

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:40 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:40 +0000
Subject: [PATCH v3 09/19] scsi: lpfc: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-9-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/scsi/lpfc/lpfc_init.c      | 18 +++++++++---------
 drivers/scsi/lpfc/lpfc_nportdisc.c |  8 ++++----
 drivers/scsi/lpfc/lpfc_nvme.c      |  2 +-
 drivers/scsi/lpfc/lpfc_sli.c       |  4 ++--
 drivers/scsi/lpfc/lpfc_vmid.c      |  2 +-
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7f57397d91a90d8fea689a6d095c30c974fd63f6..4fed2e1243e05896c7e67902b6a9924bed1a5ea9 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -598,7 +598,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 		  jiffies + msecs_to_jiffies(1000 * timeout));
 	/* Set up heart beat (HB) timer */
 	mod_timer(&phba->hb_tmofunc,
-		  jiffies + msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+		  jiffies + secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	clear_bit(HBA_HBEAT_INP, &phba->hba_flag);
 	clear_bit(HBA_HBEAT_TMO, &phba->hba_flag);
 	phba->last_completion_time = jiffies;
@@ -1267,7 +1267,7 @@ lpfc_hb_mbox_cmpl(struct lpfc_hba * phba, LPFC_MBOXQ_t * pmboxq)
 	    !test_bit(FC_UNLOADING, &phba->pport->load_flag))
 		mod_timer(&phba->hb_tmofunc,
 			  jiffies +
-			  msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+			  secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	return;
 }
 
@@ -1555,7 +1555,7 @@ lpfc_hb_timeout_handler(struct lpfc_hba *phba)
 		/* If IOs are completing, no need to issue a MBX_HEARTBEAT */
 		spin_lock_irq(&phba->pport->work_port_lock);
 		if (time_after(phba->last_completion_time +
-				msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL),
+				secs_to_jiffies(LPFC_HB_MBOX_INTERVAL),
 				jiffies)) {
 			spin_unlock_irq(&phba->pport->work_port_lock);
 			if (test_bit(HBA_HBEAT_INP, &phba->hba_flag))
@@ -3354,7 +3354,7 @@ lpfc_block_mgmt_io(struct lpfc_hba *phba, int mbx_action)
 	spin_unlock_irqrestore(&phba->hbalock, iflag);
 	if (mbx_action == LPFC_MBX_NO_WAIT)
 		return;
-	timeout = msecs_to_jiffies(LPFC_MBOX_TMO * 1000) + jiffies;
+	timeout = secs_to_jiffies(LPFC_MBOX_TMO) + jiffies;
 	spin_lock_irqsave(&phba->hbalock, iflag);
 	if (phba->sli.mbox_active) {
 		actcmd = phba->sli.mbox_active->u.mb.mbxCommand;
@@ -4924,14 +4924,14 @@ int lpfc_scan_finished(struct Scsi_Host *shost, unsigned long time)
 		stat = 1;
 		goto finished;
 	}
-	if (time >= msecs_to_jiffies(30 * 1000)) {
+	if (time >= secs_to_jiffies(30)) {
 		lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 				"0461 Scanning longer than 30 "
 				"seconds.  Continuing initialization\n");
 		stat = 1;
 		goto finished;
 	}
-	if (time >= msecs_to_jiffies(15 * 1000) &&
+	if (time >= secs_to_jiffies(15) &&
 	    phba->link_state <= LPFC_LINK_DOWN) {
 		lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 				"0465 Link down longer than 15 "
@@ -4945,7 +4945,7 @@ int lpfc_scan_finished(struct Scsi_Host *shost, unsigned long time)
 	if (vport->num_disc_nodes || vport->fc_prli_sent)
 		goto finished;
 	if (!atomic_read(&vport->fc_map_cnt) &&
-	    time < msecs_to_jiffies(2 * 1000))
+	    time < secs_to_jiffies(2))
 		goto finished;
 	if ((phba->sli.sli_flag & LPFC_SLI_MBOX_ACTIVE) != 0)
 		goto finished;
@@ -5179,8 +5179,8 @@ lpfc_vmid_poll(struct timer_list *t)
 		lpfc_worker_wake_up(phba);
 
 	/* restart the timer for the next iteration */
-	mod_timer(&phba->inactive_vmid_poll, jiffies + msecs_to_jiffies(1000 *
-							LPFC_VMID_TIMER));
+	mod_timer(&phba->inactive_vmid_poll,
+		  jiffies + secs_to_jiffies(LPFC_VMID_TIMER));
 }
 
 /**
diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c
index 4d88cfe71caed398d376030c9ae06d3aad6ae00c..08a7f5c6157ff984d6e37751ca5398adbf80b607 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -906,7 +906,7 @@ lpfc_rcv_logo(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 		    (ndlp->nlp_state >= NLP_STE_ADISC_ISSUE ||
 		     ndlp->nlp_state <= NLP_STE_PRLI_ISSUE)) {
 			mod_timer(&ndlp->nlp_delayfunc,
-				  jiffies + msecs_to_jiffies(1000 * 1));
+				  jiffies + secs_to_jiffies(1));
 			set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 			ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 			lpfc_printf_vlog(vport, KERN_INFO,
@@ -1332,7 +1332,7 @@ lpfc_rcv_els_plogi_issue(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 	}
 
 	/* Put ndlp in npr state set plogi timer for 1 sec */
-	mod_timer(&ndlp->nlp_delayfunc, jiffies + msecs_to_jiffies(1000 * 1));
+	mod_timer(&ndlp->nlp_delayfunc, jiffies + secs_to_jiffies(1));
 	set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 	ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 	ndlp->nlp_prev_state = NLP_STE_PLOGI_ISSUE;
@@ -1936,7 +1936,7 @@ lpfc_cmpl_reglogin_reglogin_issue(struct lpfc_vport *vport,
 
 		/* Put ndlp in npr state set plogi timer for 1 sec */
 		mod_timer(&ndlp->nlp_delayfunc,
-			  jiffies + msecs_to_jiffies(1000 * 1));
+			  jiffies + secs_to_jiffies(1));
 		set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 		ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 
@@ -2743,7 +2743,7 @@ lpfc_rcv_prlo_npr_node(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 
 	if (!test_bit(NLP_DELAY_TMO, &ndlp->nlp_flag)) {
 		mod_timer(&ndlp->nlp_delayfunc,
-			  jiffies + msecs_to_jiffies(1000 * 1));
+			  jiffies + secs_to_jiffies(1));
 		set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 		clear_bit(NLP_NPR_ADISC, &ndlp->nlp_flag);
 		ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 43dc1da4a1567c05d6ac5f8bda19032737998e64..b1adb9f59097d083a3ae24f4ddf6413350a0368d 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2237,7 +2237,7 @@ lpfc_nvme_lport_unreg_wait(struct lpfc_vport *vport,
 	 * wait. Print a message if a 10 second wait expires and renew the
 	 * wait. This is unexpected.
 	 */
-	wait_tmo = msecs_to_jiffies(LPFC_NVME_WAIT_TMO * 1000);
+	wait_tmo = secs_to_jiffies(LPFC_NVME_WAIT_TMO);
 	while (true) {
 		ret = wait_for_completion_timeout(lport_unreg_cmp, wait_tmo);
 		if (unlikely(!ret)) {
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 874644b31a3ebd815d5bf55bc4b3464c94d9cfa6..3fd9723cd271c8a024b6f34e583668e973404e6f 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -9012,7 +9012,7 @@ lpfc_sli4_hba_setup(struct lpfc_hba *phba)
 
 	/* Start heart beat timer */
 	mod_timer(&phba->hb_tmofunc,
-		  jiffies + msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+		  jiffies + secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	clear_bit(HBA_HBEAT_INP, &phba->hba_flag);
 	clear_bit(HBA_HBEAT_TMO, &phba->hba_flag);
 	phba->last_completion_time = jiffies;
@@ -13323,7 +13323,7 @@ lpfc_sli_mbox_sys_shutdown(struct lpfc_hba *phba, int mbx_action)
 		lpfc_sli_mbox_sys_flush(phba);
 		return;
 	}
-	timeout = msecs_to_jiffies(LPFC_MBOX_TMO * 1000) + jiffies;
+	timeout = secs_to_jiffies(LPFC_MBOX_TMO) + jiffies;
 
 	/* Disable softirqs, including timers from obtaining phba->hbalock */
 	local_bh_disable();
diff --git a/drivers/scsi/lpfc/lpfc_vmid.c b/drivers/scsi/lpfc/lpfc_vmid.c
index cc3e4736f2fe29e1fd4afe221c9c7c40ecf382d4..14dbfe954e423acc47d1b1c80160ff193783f500 100644
--- a/drivers/scsi/lpfc/lpfc_vmid.c
+++ b/drivers/scsi/lpfc/lpfc_vmid.c
@@ -278,7 +278,7 @@ int lpfc_vmid_get_appid(struct lpfc_vport *vport, char *uuid,
 		if (!(vport->phba->pport->vmid_flag & LPFC_VMID_TIMER_ENBLD)) {
 			mod_timer(&vport->phba->inactive_vmid_poll,
 				  jiffies +
-				  msecs_to_jiffies(1000 * LPFC_VMID_TIMER));
+				  secs_to_jiffies(LPFC_VMID_TIMER));
 			vport->phba->pport->vmid_flag |= LPFC_VMID_TIMER_ENBLD;
 		}
 	}

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:43 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:43 +0000
Subject: [PATCH v3 12/19] xen/blkback: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-12-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/block/xen-blkback/blkback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 838064593f62b75f3d937c0c041ea78dedbbaf84..a7c2b04ab943de9cbd69b596aad177a0534f7762 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -544,7 +544,7 @@ static void print_stats(struct xen_blkif_ring *ring)
 		 ring->st_rd_req, ring->st_wr_req,
 		 ring->st_f_req, ring->st_ds_req,
 		 ring->persistent_gnt_c, max_pgrants);
-	ring->st_print = jiffies + msecs_to_jiffies(10 * 1000);
+	ring->st_print = jiffies + secs_to_jiffies(10);
 	ring->st_rd_req = 0;
 	ring->st_wr_req = 0;
 	ring->st_oo_req = 0;

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:44 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:44 +0000
Subject: [PATCH v3 13/19] gve: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-13-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/net/ethernet/google/gve/gve_tx_dqo.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
index f879426cb5523a7e150f363b5e57b9d472b5817c..394debc62268aadf2579f9b516e045cb48287e7c 100644
--- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
@@ -1146,8 +1146,7 @@ static void gve_handle_miss_completion(struct gve_priv *priv,
 	/* jiffies can wraparound but time comparisons can handle overflows. */
 	pending_packet->timeout_jiffies =
 			jiffies +
-			msecs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT *
-					 MSEC_PER_SEC);
+			secs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT);
 	add_to_list(tx, &tx->dqo_compl.miss_completions, pending_packet);
 
 	*bytes += pending_packet->skb->len;
@@ -1191,8 +1190,7 @@ static void remove_miss_completions(struct gve_priv *priv,
 		pending_packet->state = GVE_PACKET_STATE_TIMED_OUT_COMPL;
 		pending_packet->timeout_jiffies =
 				jiffies +
-				msecs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT *
-						 MSEC_PER_SEC);
+				secs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT);
 		/* Maintain pending packet in another list so the packet can be
 		 * unallocated at a later time.
 		 */

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:45 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:45 +0000
Subject: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Acked-by: Jeff Johnson <quic_jjohnson at quicinc.com>
Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/debugfs.c b/drivers/net/wireless/ath/ath11k/debugfs.c
index 57281a135dd7fa6b8610636f47873c8bba21053c..bf192529e3fe26a91e72105a77b4c6f849b905ec 100644
--- a/drivers/net/wireless/ath/ath11k/debugfs.c
+++ b/drivers/net/wireless/ath/ath11k/debugfs.c
@@ -178,7 +178,7 @@ static int ath11k_debugfs_fw_stats_request(struct ath11k *ar,
 	 * received 'update stats' event, we keep a 3 seconds timeout in case,
 	 * fw_stats_done is not marked yet
 	 */
-	timeout = jiffies + msecs_to_jiffies(3 * 1000);
+	timeout = jiffies + secs_to_jiffies(3);
 
 	ath11k_debugfs_fw_stats_reset(ar);
 

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:46 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:46 +0000
Subject: [PATCH v3 15/19] Bluetooth: MGMT: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-15-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 net/bluetooth/mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index b31192d473d09b663dc7babd107b4894088ebf6d..8c993763ee0f0360e0d92705f9035f47754b793b 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -210,7 +210,7 @@ static const u16 mgmt_untrusted_events[] = {
 	MGMT_EV_EXP_FEATURE_CHANGED,
 };
 
-#define CACHE_TIMEOUT	msecs_to_jiffies(2 * 1000)
+#define CACHE_TIMEOUT	secs_to_jiffies(2)
 
 #define ZERO_KEY "\x00\x00\x00\x00\x00\x00\x00\x00" \
 		 "\x00\x00\x00\x00\x00\x00\x00\x00"

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:47 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:47 +0000
Subject: [PATCH v3 16/19] staging: vc04_services: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index dc0d715ed97078ad0f0a41db78428db4f4135a76..0dbe76ee557032d7861acfc002cc203ff2e6971d 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -59,7 +59,7 @@ static int bcm2835_audio_send_msg_locked(struct bcm2835_audio_instance *instance
 
 	if (wait) {
 		if (!wait_for_completion_timeout(&instance->msg_avail_comp,
-						 msecs_to_jiffies(10 * 1000))) {
+						 secs_to_jiffies(10))) {
 			dev_err(instance->dev,
 				"vchi message timeout, msg=%d\n", m->type);
 			return -ETIMEDOUT;

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:48 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:48 +0000
Subject: [PATCH v3 17/19] ceph: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-17-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 fs/ceph/quota.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ceph/quota.c b/fs/ceph/quota.c
index 06ee397e0c3a6172592e62dba95cd267cfff0db1..d90eda19bcc4618f98bfed833c10a6071cf2e2ac 100644
--- a/fs/ceph/quota.c
+++ b/fs/ceph/quota.c
@@ -166,7 +166,7 @@ static struct inode *lookup_quotarealm_inode(struct ceph_mds_client *mdsc,
 	if (IS_ERR(in)) {
 		doutc(cl, "Can't lookup inode %llx (err: %ld)\n", realm->ino,
 		      PTR_ERR(in));
-		qri->timeout = jiffies + msecs_to_jiffies(60 * 1000); /* XXX */
+		qri->timeout = jiffies + secs_to_jiffies(60); /* XXX */
 	} else {
 		qri->timeout = 0;
 		qri->inode = in;

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:49 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:49 +0000
Subject: [PATCH v3 18/19] livepatch: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 samples/livepatch/livepatch-callbacks-busymod.c |  3 +--
 samples/livepatch/livepatch-shadow-fix1.c       |  3 +--
 samples/livepatch/livepatch-shadow-mod.c        | 15 +++++----------
 3 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/samples/livepatch/livepatch-callbacks-busymod.c b/samples/livepatch/livepatch-callbacks-busymod.c
index 378e2d40271a9717d09eff51d3d3612c679736fc..69105596e72e6826aa2815cb2599eea56a0055ba 100644
--- a/samples/livepatch/livepatch-callbacks-busymod.c
+++ b/samples/livepatch/livepatch-callbacks-busymod.c
@@ -44,8 +44,7 @@ static void busymod_work_func(struct work_struct *work)
 static int livepatch_callbacks_mod_init(void)
 {
 	pr_info("%s\n", __func__);
-	schedule_delayed_work(&work,
-		msecs_to_jiffies(1000 * 0));
+	schedule_delayed_work(&work, 0);
 	return 0;
 }
 
diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
index 6701641bf12d454a770e49abeeb0dea92560e55e..f3f153895d6ce751fc91ae1224d91b220cba3e37 100644
--- a/samples/livepatch/livepatch-shadow-fix1.c
+++ b/samples/livepatch/livepatch-shadow-fix1.c
@@ -72,8 +72,7 @@ static struct dummy *livepatch_fix1_dummy_alloc(void)
 	if (!d)
 		return NULL;
 
-	d->jiffies_expire = jiffies +
-		msecs_to_jiffies(1000 * EXPIRE_PERIOD);
+	d->jiffies_expire = jiffies + secs_to_jiffies(EXPIRE_PERIOD);
 
 	/*
 	 * Patch: save the extra memory location into a SV_LEAK shadow
diff --git a/samples/livepatch/livepatch-shadow-mod.c b/samples/livepatch/livepatch-shadow-mod.c
index 7e753b0d2fa611524c9e2adbe02c8fa3e9b6015e..5d83ad5a8118dbbac897dfcbb92e6d5f399d1dc3 100644
--- a/samples/livepatch/livepatch-shadow-mod.c
+++ b/samples/livepatch/livepatch-shadow-mod.c
@@ -101,8 +101,7 @@ static __used noinline struct dummy *dummy_alloc(void)
 	if (!d)
 		return NULL;
 
-	d->jiffies_expire = jiffies +
-		msecs_to_jiffies(1000 * EXPIRE_PERIOD);
+	d->jiffies_expire = jiffies + secs_to_jiffies(EXPIRE_PERIOD);
 
 	/* Oops, forgot to save leak! */
 	leak = kzalloc(sizeof(*leak), GFP_KERNEL);
@@ -152,8 +151,7 @@ static void alloc_work_func(struct work_struct *work)
 	list_add(&d->list, &dummy_list);
 	mutex_unlock(&dummy_list_mutex);
 
-	schedule_delayed_work(&alloc_dwork,
-		msecs_to_jiffies(1000 * ALLOC_PERIOD));
+	schedule_delayed_work(&alloc_dwork, secs_to_jiffies(ALLOC_PERIOD));
 }
 
 /*
@@ -184,16 +182,13 @@ static void cleanup_work_func(struct work_struct *work)
 	}
 	mutex_unlock(&dummy_list_mutex);
 
-	schedule_delayed_work(&cleanup_dwork,
-		msecs_to_jiffies(1000 * CLEANUP_PERIOD));
+	schedule_delayed_work(&cleanup_dwork, secs_to_jiffies(CLEANUP_PERIOD));
 }
 
 static int livepatch_shadow_mod_init(void)
 {
-	schedule_delayed_work(&alloc_dwork,
-		msecs_to_jiffies(1000 * ALLOC_PERIOD));
-	schedule_delayed_work(&cleanup_dwork,
-		msecs_to_jiffies(1000 * CLEANUP_PERIOD));
+	schedule_delayed_work(&alloc_dwork, secs_to_jiffies(ALLOC_PERIOD));
+	schedule_delayed_work(&cleanup_dwork, secs_to_jiffies(CLEANUP_PERIOD));
 
 	return 0;
 }

-- 
2.43.0



From eahariha at linux.microsoft.com  Tue Dec 10 14:02:50 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 22:02:50 +0000
Subject: [PATCH v3 19/19] ALSA: line6: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210-converge-secs-to-jiffies-v3-19-ddfefd7e9f2a@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 sound/usb/line6/toneport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
index ca2c6f5de407ece21ab69a39ed603e3f10069039..c073b38cd6738176fc6a276d05ed553526573341 100644
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -386,7 +386,7 @@ static int toneport_setup(struct usb_line6_toneport *toneport)
 		toneport_update_led(toneport);
 
 	schedule_delayed_work(&toneport->line6.startup_work,
-			      msecs_to_jiffies(TONEPORT_PCM_DELAY * 1000));
+			      secs_to_jiffies(TONEPORT_PCM_DELAY));
 	return 0;
 }
 

-- 
2.43.0



From tharvey at gateworks.com  Tue Dec 10 15:06:31 2024
From: tharvey at gateworks.com (Tim Harvey)
Date: Tue, 10 Dec 2024 15:06:31 -0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <20241210041133.GA17116@lst.de>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de> <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com> <20241210041133.GA17116@lst.de>
Message-ID: <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>

On Mon, Dec 9, 2024 at 8:11?PM Christoph Hellwig <hch at lst.de> wrote:
>
> On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
> > After a lot of back and forth and investigation this is due to the
> > IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
> > is requesting some buffers that are too large for swiotlb to provide.
> > There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
> > to cacheable memory that could be reverted to fix this but the concern
> > was that it would impact performance moving those buffers to
> > non-cacheable memory (there are three ~1MiB buffers being allocated):
> > commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
> > cacheable memory").
>
> The combination of "buffers" and "swiotlb" sounds like Robin was right
> below.
>
> > The chain of events as best I can tell are:
> >
> > commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
> > cacheable memory")
> > - Nov 12 2021 (made it into Linux 5.17)
> > - changes allocation of reo_dst rings to cacheable memory to allow
> > cached descriptor access to optimize CPU usage
> > - this is flawed because it uses virt_to_phys() to allocate cacheable
> > memory which does not work on systems with an IOMMU enabled or using
> > software IOMMU (swiotlb); this causes a kernel crash on client
> > association
>
> And this is where it started to take a wrong turn, that everyhing
> later basically made worse.  If you have long living and potentially
> large DMA allocations, you need to use dma_alloc_* interfaces.
>
> 5.17 already had dma_alloc_pages for quite a while which was and still is
> the proper interface to use.  For much older kernel you'd be stuck
> with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
> but even that would have been much better.

Christoph,

I'm not clear what you are suggesting be done here. Are you suggesting
that ath11k has been using the wrong mechanism by calling
dma_map_single for cached DMA buffers? I'm not all that familiar with
ath11k so I can't tell what buffers are considered long living.

Best Regards,

Tim


From jeff.johnson at oss.qualcomm.com  Tue Dec 10 15:14:22 2024
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Tue, 10 Dec 2024 15:14:22 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>

On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.[1] In the review for
> that series, Anna-Maria requested converting other users with
> Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
> that use the multiply pattern of either of:
> - msecs_to_jiffies(N*1000), or
> - msecs_to_jiffies(N*MSEC_PER_SEC)
> 
> where N is a constant, to avoid the multiplication.
> 
> The entire conversion is made with Coccinelle in the script added in
> patch 2. Some changes suggested by Coccinelle have been deferred to
> later parts that will address other possible variant patterns.
> 
> CC: Anna-Maria Behnsen <anna-maria at linutronix.de>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>

I have the same question as before: How do you expect these to land?
Do you now have a maintainer who will take all of them?
Or do you want individual maintainers to take the ones applicable to them?

/jeff


From akpm at linux-foundation.org  Tue Dec 10 15:36:04 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 10 Dec 2024 15:36:04 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
Message-ID: <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>

On Tue, 10 Dec 2024 15:14:22 -0800 Jeff Johnson <jeff.johnson at oss.qualcomm.com> wrote:

> On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> > This is a series that follows up on my previous series to introduce
> > secs_to_jiffies() and convert a few initial users.[1] In the review for
> > that series, Anna-Maria requested converting other users with
> > Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
> > that use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1000), or
> > - msecs_to_jiffies(N*MSEC_PER_SEC)
> > 
> > where N is a constant, to avoid the multiplication.
> > 
> > The entire conversion is made with Coccinelle in the script added in
> > patch 2. Some changes suggested by Coccinelle have been deferred to
> > later parts that will address other possible variant patterns.
> > 
> > CC: Anna-Maria Behnsen <anna-maria at linutronix.de>
> > Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> 
> I have the same question as before: How do you expect these to land?
> Do you now have a maintainer who will take all of them?
> Or do you want individual maintainers to take the ones applicable to them?

I'll just grab everything and see if anyone complains ;)


From akpm at linux-foundation.org  Tue Dec 10 16:35:20 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 10 Dec 2024 16:35:20 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>

On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan <eahariha at linux.microsoft.com> wrote:

> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.

Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
emails because soooo many cc's!

I'd ask relevant maintainers to send in any acks and I'll paste them
into the relevant changelogs.



From eahariha at linux.microsoft.com  Tue Dec 10 17:00:21 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 17:00:21 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
Message-ID: <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>

On 12/10/2024 4:35 PM, Andrew Morton wrote:
> On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan <eahariha at linux.microsoft.com> wrote:
> 
>> This is a series that follows up on my previous series to introduce
>> secs_to_jiffies() and convert a few initial users.
> 
> Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
> emails because soooo many cc's!
> 
> I'd ask relevant maintainers to send in any acks and I'll paste them
> into the relevant changelogs.

Thank you, Andrew!

- Easwar


From kuba at kernel.org  Tue Dec 10 17:35:48 2024
From: kuba at kernel.org (Jakub Kicinski)
Date: Tue, 10 Dec 2024 17:35:48 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
Message-ID: <20241210173548.5d32efe0@kernel.org>

On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > I have the same question as before: How do you expect these to land?
> > Do you now have a maintainer who will take all of them?
> > Or do you want individual maintainers to take the ones applicable to them?  
> 
> I'll just grab everything and see if anyone complains ;)

I may, if this leads to a conflict :(

Easwar, please break this up per subsystem.


From quic_yuzha at quicinc.com  Tue Dec 10 18:10:23 2024
From: quic_yuzha at quicinc.com (Yu Zhang (Yuriy))
Date: Wed, 11 Dec 2024 10:10:23 +0800
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations
 are supported
In-Reply-To: <20241210084419.126723-1-jtornosm@redhat.com>
References: <db61f998-2524-4623-8b0f-143661507e38@quicinc.com>
 <20241210084419.126723-1-jtornosm@redhat.com>
Message-ID: <d8705140-e335-47e0-ac70-47d8592fb18c@quicinc.com>



On 12/10/2024 4:44 PM, Jose Ignacio Tornos Martinez wrote:
>> Yes, Can you pls share the complete steps and commands?
> Sure, I offered it before.
> 
> You need NetworkManager and of course NetworkManager-wifi packages installed
> and working.
> We are using Fedora/rhel with the default configuration and you can configure,
> before the next steps, the wifi interface as sta from NetworkManager or not
> (with no wifi configuration the same result happens) because it is going to
> be unmanaged.
> 
> After booting (wlp1s0 is the wifi interface for ath11k and there are no other
> wifi cards in the system), here the necessary steps with our network
> configuration:
> # nmcli  device set wlp1s0 managed off
> # ip link set wlp1s0 up
> # ip link add name wifi_br0 type bridge
> # ip addr add 192.168.254.1/24 dev wifi_br0
> # ip link set wifi_br0 up
> # iw dev wlp1s0 interface add wlp1s0_0 type __ap
> # iw dev wlp1s0 interface add wlp1s0_1 type __ap
> # systemd-run --unit hostapd1 hostapd -dd /tmp/hostapd1.conf
> # systemd-run --unit hostapd2 hostapd -dd /tmp/hostapd2.conf
> # dnsmasq \
>      --pid-file=/tmp/dnsmasq_wireless.pid \
>      --port=63 \
>      --no-hosts \
>      --interface=wifi_br0 \
>      --bind-interfaces \
>      --dhcp-range=192.168.254.2,192.168.254.205,60m \
>      --dhcp-option=option:router,192.168.254.1 \
>      --dhcp-leasefile=/var/lib/dnsmasq/hostapd.leases \
>      --dhcp-lease-max=200
> 
> After booting I get the same issue just doing:
> # nmcli  device set wlp1s0 managed off
> # ip link set wlp1s0 up
> And the step that you commented in a previous answer:
> # iw dev wlp1s0 interface add wlp1s0_0 type __ap
> # iw dev wlp1s0 interface add wlp1s0_1 type __ap
> # hostapd hostapd1.conf &
> # hostapd hostapd2.conf &
> 
Got it, you use Networkmanager, so that the add interface type will 
always be managed. But it's still work fine in my device that I use 
"hostapd hostapd2.conf" to up the second ap.

So could you share your log about it? Enable debug and tracer about 
ath11k and mac80211, and share the the recorded trace?

> You can use whatever hostapd configuration (with the suitable interface name).
> 
> Thanks
> 
> Best regards
> Jose Ignacio
> 



From quic_bqiang at quicinc.com  Tue Dec 10 18:31:25 2024
From: quic_bqiang at quicinc.com (Baochen Qiang)
Date: Wed, 11 Dec 2024 10:31:25 +0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com>
 <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de>
 <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
 <20241210041133.GA17116@lst.de>
 <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
Message-ID: <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com>



On 12/11/2024 7:06 AM, Tim Harvey wrote:
> On Mon, Dec 9, 2024 at 8:11?PM Christoph Hellwig <hch at lst.de> wrote:
>>
>> On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
>>> After a lot of back and forth and investigation this is due to the
>>> IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
>>> is requesting some buffers that are too large for swiotlb to provide.
>>> There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
>>> to cacheable memory that could be reverted to fix this but the concern
>>> was that it would impact performance moving those buffers to
>>> non-cacheable memory (there are three ~1MiB buffers being allocated):
>>> commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
>>> cacheable memory").
>>
>> The combination of "buffers" and "swiotlb" sounds like Robin was right
>> below.
>>
>>> The chain of events as best I can tell are:
>>>
>>> commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
>>> cacheable memory")
>>> - Nov 12 2021 (made it into Linux 5.17)
>>> - changes allocation of reo_dst rings to cacheable memory to allow
>>> cached descriptor access to optimize CPU usage
>>> - this is flawed because it uses virt_to_phys() to allocate cacheable
>>> memory which does not work on systems with an IOMMU enabled or using
>>> software IOMMU (swiotlb); this causes a kernel crash on client
>>> association
>>
>> And this is where it started to take a wrong turn, that everyhing
>> later basically made worse.  If you have long living and potentially
>> large DMA allocations, you need to use dma_alloc_* interfaces.
>>
>> 5.17 already had dma_alloc_pages for quite a while which was and still is
>> the proper interface to use.  For much older kernel you'd be stuck
>> with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
>> but even that would have been much better.
> 
> Christoph,
> 
> I'm not clear what you are suggesting be done here. Are you suggesting
> that ath11k has been using the wrong mechanism by calling
> dma_map_single for cached DMA buffers? I'm not all that familiar with
> ath11k so I can't tell what buffers are considered long living.

those buffers are allocated when driver load and freed when driver unload, so IMO they are
long living.

> 
> Best Regards,
> 
> Tim



From akpm at linux-foundation.org  Tue Dec 10 18:31:30 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 10 Dec 2024 18:31:30 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210173548.5d32efe0@kernel.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
Message-ID: <20241210183130.81111d05148c41278a299aad@linux-foundation.org>

On Tue, 10 Dec 2024 17:35:48 -0800 Jakub Kicinski <kuba at kernel.org> wrote:

> On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > > I have the same question as before: How do you expect these to land?
> > > Do you now have a maintainer who will take all of them?
> > > Or do you want individual maintainers to take the ones applicable to them?  
> > 
> > I'll just grab everything and see if anyone complains ;)
> 
> I may, if this leads to a conflict :(

Very unlikely, and any such conflict will be trivial.

> Easwar, please break this up per subsystem.

The series is already one-patch-per-changed-file.


From kuba at kernel.org  Tue Dec 10 18:41:29 2024
From: kuba at kernel.org (Jakub Kicinski)
Date: Tue, 10 Dec 2024 18:41:29 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210183130.81111d05148c41278a299aad@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
Message-ID: <20241210184129.41aaf371@kernel.org>

On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > I'll just grab everything and see if anyone complains ;)  
> > 
> > I may, if this leads to a conflict :(  
> 
> Very unlikely, and any such conflict will be trivial.

Agreed, mainly I don't understand why we'd make an exception
and take the patchset via a special tree.

> > Easwar, please break this up per subsystem.  
> 
> The series is already one-patch-per-changed-file.

More confusingly still, they did send one standalone patch for 
an Ethernet driver:
https://lore.kernel.org/all/20241210-converge-secs-to-jiffies-v3-20-59479891e658 at linux.microsoft.com/
And yet another Ethernet driver (drivers/net/ethernet/google/gve/) 
is converted in this series.


From akpm at linux-foundation.org  Tue Dec 10 18:50:40 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 10 Dec 2024 18:50:40 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210184129.41aaf371@kernel.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
	<20241210184129.41aaf371@kernel.org>
Message-ID: <20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>

On Tue, 10 Dec 2024 18:41:29 -0800 Jakub Kicinski <kuba at kernel.org> wrote:

> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > > I'll just grab everything and see if anyone complains ;)  
> > > 
> > > I may, if this leads to a conflict :(  
> > 
> > Very unlikely, and any such conflict will be trivial.
> 
> Agreed, mainly I don't understand why we'd make an exception
> and take the patchset via a special tree.

It saves work for everyone?

The patches are super-simple.  If a maintainer chooses to merge one of
them, Stephen tells us and I drop the mm.git copy.  It's all so easy.



From kuba at kernel.org  Tue Dec 10 19:01:33 2024
From: kuba at kernel.org (Jakub Kicinski)
Date: Tue, 10 Dec 2024 19:01:33 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
	<20241210184129.41aaf371@kernel.org>
	<20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>
Message-ID: <20241210190133.44818a76@kernel.org>

On Tue, 10 Dec 2024 18:50:40 -0800 Andrew Morton wrote:
> > > Very unlikely, and any such conflict will be trivial.  
> > 
> > Agreed, mainly I don't understand why we'd make an exception
> > and take the patchset via a special tree.  
> 
> It saves work for everyone?
> 
> The patches are super-simple.  If a maintainer chooses to merge one of
> them, Stephen tells us and I drop the mm.git copy.  It's all so easy.

If it's just to save work - we're fine.
Please don't apply the networking changes.


From eahariha at linux.microsoft.com  Tue Dec 10 20:34:43 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 10 Dec 2024 20:34:43 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <20241210184129.41aaf371@kernel.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
 <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
 <20241210173548.5d32efe0@kernel.org>
 <20241210183130.81111d05148c41278a299aad@linux-foundation.org>
 <20241210184129.41aaf371@kernel.org>
Message-ID: <d93e388c-ed18-400c-b6cf-ec00a5979457@linux.microsoft.com>

On 12/10/2024 6:41 PM, Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
>>>> I'll just grab everything and see if anyone complains ;)  
>>>
>>> I may, if this leads to a conflict :(  
>>
>> Very unlikely, and any such conflict will be trivial.
> 
> Agreed, mainly I don't understand why we'd make an exception
> and take the patchset via a special tree.
> 
>>> Easwar, please break this up per subsystem.  
>>
>> The series is already one-patch-per-changed-file.
> 
> More confusingly still, they did send one standalone patch for 
> an Ethernet driver:
> https://lore.kernel.org/all/20241210-converge-secs-to-jiffies-v3-20-59479891e658 at linux.microsoft.com/
> And yet another Ethernet driver (drivers/net/ethernet/google/gve/) 
> is converted in this series.

Sorry about the confusion, I missed pulling the gve patch from this
series. I'll send that (and ath11k) separately as well. I'll pull all
these together into a series so you can merge them together if you prefer.

Thanks,
Easwar


From christophe.leroy at csgroup.eu  Tue Dec 10 23:00:02 2024
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 11 Dec 2024 08:00:02 +0100
Subject: [PATCH v3 18/19] livepatch: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <07784753-6874-4dda-a080-2d2812f4a10a@csgroup.eu>



Le 10/12/2024 ? 23:02, Easwar Hariharan a ?crit?:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> ---
>   samples/livepatch/livepatch-callbacks-busymod.c |  3 +--
>   samples/livepatch/livepatch-shadow-fix1.c       |  3 +--
>   samples/livepatch/livepatch-shadow-mod.c        | 15 +++++----------
>   3 files changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/samples/livepatch/livepatch-callbacks-busymod.c b/samples/livepatch/livepatch-callbacks-busymod.c
> index 378e2d40271a9717d09eff51d3d3612c679736fc..69105596e72e6826aa2815cb2599eea56a0055ba 100644
> --- a/samples/livepatch/livepatch-callbacks-busymod.c
> +++ b/samples/livepatch/livepatch-callbacks-busymod.c
> @@ -44,8 +44,7 @@ static void busymod_work_func(struct work_struct *work)
>   static int livepatch_callbacks_mod_init(void)
>   {
>   	pr_info("%s\n", __func__);
> -	schedule_delayed_work(&work,
> -		msecs_to_jiffies(1000 * 0));
> +	schedule_delayed_work(&work, 0);

This hunk is not in line with the patch description.

This is probably OK to have in this patch, but you should add additional 
description to mention that special case with a 0 delay.

Allthough you should probably change it to schedule_work() instead of 
using a 0 delay.

Christophe


From christophe.leroy at csgroup.eu  Tue Dec 10 23:02:39 2024
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 11 Dec 2024 08:02:39 +0100
Subject: [PATCH v3 05/19] powerpc/papr_scm: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <427e840b-d4f5-4554-b798-c70a5b67040e@csgroup.eu>



Le 10/12/2024 ? 23:02, Easwar Hariharan a ?crit?:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>

Reviewed-by: Christophe Leroy <christophe.leroy at csgroup.eu>

> ---
>   arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index f84ac9fbe203c111046464b9100866dddae687bb..f7c9271bda58433f395648063e60409a8d3c11d9 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -544,7 +544,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
>   
>   	/* Jiffies offset for which the health data is assumed to be same */
>   	cache_timeout = p->lasthealth_jiffies +
> -		msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
> +		secs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL);
>   
>   	/* Fetch new health info is its older than MIN_HEALTH_QUERY_INTERVAL */
>   	if (time_after(jiffies, cache_timeout))
> 



From kvalo at kernel.org  Tue Dec 10 23:42:11 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Wed, 11 Dec 2024 09:42:11 +0200
Subject: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
	(Easwar Hariharan's message of "Tue, 10 Dec 2024 22:02:45 +0000")
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <87sequr7ho.fsf@kernel.org>

Easwar Hariharan <eahariha at linux.microsoft.com> writes:

> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Acked-by: Jeff Johnson <quic_jjohnson at quicinc.com>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> ---
>  drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I assume we can take this to our ath.git tree, please let us know if
that's not the case.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Tue Dec 10 23:45:24 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Wed, 11 Dec 2024 09:45:24 +0200
Subject: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <87sequr7ho.fsf@kernel.org> (Kalle Valo's message of "Wed, 11 Dec
	2024 09:42:11 +0200")
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
	<87sequr7ho.fsf@kernel.org>
Message-ID: <87o71ir7cb.fsf@kernel.org>

Kalle Valo <kvalo at kernel.org> writes:

> Easwar Hariharan <eahariha at linux.microsoft.com> writes:
>
>> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
>> secs_to_jiffies(). As the value here is a multiple of 1000, use
>> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>>
>> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
>> the following Coccinelle rules:
>>
>> @@ constant C; @@
>>
>> - msecs_to_jiffies(C * 1000)
>> + secs_to_jiffies(C)
>>
>> @@ constant C; @@
>>
>> - msecs_to_jiffies(C * MSEC_PER_SEC)
>> + secs_to_jiffies(C)
>>
>> Acked-by: Jeff Johnson <quic_jjohnson at quicinc.com>
>> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
>> ---
>>  drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I assume we can take this to our ath.git tree, please let us know if
> that's not the case.

Nevermind, I now saw the discussion in the cover letter and assume that
this patch will be sent separately.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From robin.murphy at arm.com  Wed Dec 11 05:44:53 2024
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 11 Dec 2024 13:44:53 +0000
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com>
 <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de>
 <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
 <20241210041133.GA17116@lst.de>
 <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
 <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com>
Message-ID: <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com>

On 2024-12-11 2:31 am, Baochen Qiang wrote:
> 
> 
> On 12/11/2024 7:06 AM, Tim Harvey wrote:
>> On Mon, Dec 9, 2024 at 8:11?PM Christoph Hellwig <hch at lst.de> wrote:
>>>
>>> On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
>>>> After a lot of back and forth and investigation this is due to the
>>>> IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
>>>> is requesting some buffers that are too large for swiotlb to provide.
>>>> There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
>>>> to cacheable memory that could be reverted to fix this but the concern
>>>> was that it would impact performance moving those buffers to
>>>> non-cacheable memory (there are three ~1MiB buffers being allocated):
>>>> commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
>>>> cacheable memory").
>>>
>>> The combination of "buffers" and "swiotlb" sounds like Robin was right
>>> below.
>>>
>>>> The chain of events as best I can tell are:
>>>>
>>>> commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
>>>> cacheable memory")
>>>> - Nov 12 2021 (made it into Linux 5.17)
>>>> - changes allocation of reo_dst rings to cacheable memory to allow
>>>> cached descriptor access to optimize CPU usage
>>>> - this is flawed because it uses virt_to_phys() to allocate cacheable
>>>> memory which does not work on systems with an IOMMU enabled or using
>>>> software IOMMU (swiotlb); this causes a kernel crash on client
>>>> association
>>>
>>> And this is where it started to take a wrong turn, that everyhing
>>> later basically made worse.  If you have long living and potentially
>>> large DMA allocations, you need to use dma_alloc_* interfaces.
>>>
>>> 5.17 already had dma_alloc_pages for quite a while which was and still is
>>> the proper interface to use.  For much older kernel you'd be stuck
>>> with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
>>> but even that would have been much better.
>>
>> Christoph,
>>
>> I'm not clear what you are suggesting be done here. Are you suggesting
>> that ath11k has been using the wrong mechanism by calling
>> dma_map_single for cached DMA buffers? I'm not all that familiar with
>> ath11k so I can't tell what buffers are considered long living.
> 
> those buffers are allocated when driver load and freed when driver unload, so IMO they are
> long living.

The point is that if this driver wants a notion of "cached DMA buffers", 
then it should allocate such buffers the proper way, not try to reinvent 
it badly. That means using dma_alloc_pages(), or modern 
dma_alloc_noncoherent() which is essentially the same thing but with the 
dma_map_page() call automatically done for you as well.

Thanks,
Robin.


From jtornosm at redhat.com  Wed Dec 11 09:41:55 2024
From: jtornosm at redhat.com (Jose Ignacio Tornos Martinez)
Date: Wed, 11 Dec 2024 18:41:55 +0100
Subject: [PATCH] wifi: ath11k: allow APs combination when dual stations are supported
In-Reply-To: <d8705140-e335-47e0-ac70-47d8592fb18c@quicinc.com>
References: <d8705140-e335-47e0-ac70-47d8592fb18c@quicinc.com>
Message-ID: <20241211174155.30782-1-jtornosm@redhat.com>

> Got it, you use Networkmanager, so that the add interface type will
> always be managed. But it's still work fine in my device that I use
> "hostapd hostapd2.conf" to up the second ap.
Yes, it works for you because you don't have a manager and/or your initial
situation was clean and/or without other needs/services.

For us it was enough to be able to come back to the initial interface
combination, but it seems that you prefer to have a common configuration
for everything.
So, since I think it is your final intention, please, go ahead with your
proposed interface combination and then I will debug myself to try complete
and/or reuse in some way.

Thanks

Best regards
Jose Ignacio



From dave.stevenson at raspberrypi.com  Wed Dec 11 09:46:32 2024
From: dave.stevenson at raspberrypi.com (Dave Stevenson)
Date: Wed, 11 Dec 2024 17:46:32 +0000
Subject: [PATCH v3 16/19] staging: vc04_services: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <CAPY8ntDHcGpsaNytY2up_54e03twqZ2fj1=JTnb8x7LLo3uGDQ@mail.gmail.com>

On Tue, 10 Dec 2024 at 22:02, Easwar Hariharan
<eahariha at linux.microsoft.com> wrote:
>
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>

Reviewed-by: Dave Stevenson <dave.stevenson at raspberrypi.com>

> ---
>  drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> index dc0d715ed97078ad0f0a41db78428db4f4135a76..0dbe76ee557032d7861acfc002cc203ff2e6971d 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> @@ -59,7 +59,7 @@ static int bcm2835_audio_send_msg_locked(struct bcm2835_audio_instance *instance
>
>         if (wait) {
>                 if (!wait_for_completion_timeout(&instance->msg_avail_comp,
> -                                                msecs_to_jiffies(10 * 1000))) {
> +                                                secs_to_jiffies(10))) {
>                         dev_err(instance->dev,
>                                 "vchi message timeout, msg=%d\n", m->type);
>                         return -ETIMEDOUT;
>
> --
> 2.43.0
>


From ultwcz1997 at outlook.com  Wed Dec 11 19:51:03 2024
From: ultwcz1997 at outlook.com (wang chaozheng)
Date: Thu, 12 Dec 2024 03:51:03 +0000
Subject: ath11k for QCA6391
Message-ID: <12ce6ea00fd34e919527021ab17da92cOSZPR01MB6597F2FD7B51B0E5E8BEA5DBD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>

Hello,

I have recently purchased some QCA6391 cards and I am going to try to
get them working with Linux.

When I installed driver ath11k_pci.ko, it shows following, but not show wireless network cards,
such as wlan0.

$ dmesg | grep ath11k
[ ? 10.376207] ath11k_pci 0004:01:00.0: Adding to iommu group 7
[ ? 10.376639] ath11k_pci 0004:01:00.0: WARNING: ath11k PCI support is experimental!
[ ? 10.377478] ath11k_pci 0004:01:00.0: BAR 0: assigned [mem 0x1740000000-0x1740ffffff 64bit]
[ ? 10.377593] ath11k_pci 0004:01:00.0: enabling device (0000 -> 0002)

Does anyone know?

Thanks

BTW, other information
$ uname -r
5.10.104

$ lcpci -mnn
0004:01:00.0 "Unassigned class [ff00]" "Qualcomm [17cb]" "Device [1101]" "Qualcomm [17cb]" "Device [0108]"

$ find /lib/firmware/ath11k/QCA6390 -type f | xargs md5sum
fd4aa4a58f33854a751ec7d14d77ce91 ?/lib/firmware/ath11k/QCA6390/hw2.0/m3.bin
682f7ca2e0b3ea16644c3585772a2cba ?/lib/firmware/ath11k/QCA6390/hw2.0/amss.bin
39ab8341a089836d244b77be3e98ee1e ?/lib/firmware/ath11k/QCA6390/hw2.0/board-2.bin
fafd08643ce688612c1af3590e309f3e ?/lib/firmware/ath11k/QCA6390/hw2.0/board-2.bin_ath11k

--?
ath11k mailing list
ath11k at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k


From quic_bqiang at quicinc.com  Wed Dec 11 21:24:45 2024
From: quic_bqiang at quicinc.com (Baochen Qiang)
Date: Thu, 12 Dec 2024 13:24:45 +0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com>
 <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de>
 <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
 <20241210041133.GA17116@lst.de>
 <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
 <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com>
 <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com>
Message-ID: <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>



On 12/11/2024 9:44 PM, Robin Murphy wrote:
> On 2024-12-11 2:31 am, Baochen Qiang wrote:
>>
>>
>> On 12/11/2024 7:06 AM, Tim Harvey wrote:
>>> On Mon, Dec 9, 2024 at 8:11?PM Christoph Hellwig <hch at lst.de> wrote:
>>>>
>>>> On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
>>>>> After a lot of back and forth and investigation this is due to the
>>>>> IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
>>>>> is requesting some buffers that are too large for swiotlb to provide.
>>>>> There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
>>>>> to cacheable memory that could be reverted to fix this but the concern
>>>>> was that it would impact performance moving those buffers to
>>>>> non-cacheable memory (there are three ~1MiB buffers being allocated):
>>>>> commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
>>>>> cacheable memory").
>>>>
>>>> The combination of "buffers" and "swiotlb" sounds like Robin was right
>>>> below.
>>>>
>>>>> The chain of events as best I can tell are:
>>>>>
>>>>> commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
>>>>> cacheable memory")
>>>>> - Nov 12 2021 (made it into Linux 5.17)
>>>>> - changes allocation of reo_dst rings to cacheable memory to allow
>>>>> cached descriptor access to optimize CPU usage
>>>>> - this is flawed because it uses virt_to_phys() to allocate cacheable
>>>>> memory which does not work on systems with an IOMMU enabled or using
>>>>> software IOMMU (swiotlb); this causes a kernel crash on client
>>>>> association
>>>>
>>>> And this is where it started to take a wrong turn, that everyhing
>>>> later basically made worse.? If you have long living and potentially
>>>> large DMA allocations, you need to use dma_alloc_* interfaces.
>>>>
>>>> 5.17 already had dma_alloc_pages for quite a while which was and still is
>>>> the proper interface to use.? For much older kernel you'd be stuck
>>>> with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
>>>> but even that would have been much better.
>>>
>>> Christoph,
>>>
>>> I'm not clear what you are suggesting be done here. Are you suggesting
>>> that ath11k has been using the wrong mechanism by calling
>>> dma_map_single for cached DMA buffers? I'm not all that familiar with
>>> ath11k so I can't tell what buffers are considered long living.
>>
>> those buffers are allocated when driver load and freed when driver unload, so IMO they are
>> long living.
> 
> The point is that if this driver wants a notion of "cached DMA buffers", then it should
> allocate such buffers the proper way, not try to reinvent it badly. That means using
> dma_alloc_pages(), or modern dma_alloc_noncoherent() which is essentially the same thing
> but with the dma_map_page() call automatically done for you as well.

yeah, you are right, Robin. didn't know there are convenient interfaces like these already.

Tim, can you work out a patch then?

> 
> Thanks,
> Robin.



From ionic at ionic.de  Wed Dec 11 22:35:07 2024
From: ionic at ionic.de (Mihai Moldovan)
Date: Thu, 12 Dec 2024 07:35:07 +0100
Subject: ath11k for QCA6391
In-Reply-To: <12ce6ea00fd34e919527021ab17da92cOSZPR01MB6597F2FD7B51B0E5E8BEA5DBD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>
References: <12ce6ea00fd34e919527021ab17da92cOSZPR01MB6597F2FD7B51B0E5E8BEA5DBD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>
Message-ID: <c0fc2c17-2836-43c1-b888-459b8e71b6c0@ionic.de>

* On 12/12/24 04:51, wang chaozheng wrote:
> BTW, other information
> $ uname -r
> 5.10.104

Your kernel is very old. While being LTS and shipping a lot of backports, that 
typically is not the case for new features. Additionally, even for LTS 
standards, this version is antique (c.f.: current version of the 5.10 line is 
5.10.230).

QCA6391 support really came with 5.15 or something along those lines.


Do yourself a favor and retest with the mainline kernel version, please.



Mihai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241212/8d9e898c/attachment-0001.sig>

From hch at lst.de  Wed Dec 11 23:18:48 2024
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 12 Dec 2024 08:18:48 +0100
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>
References: <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com> <20241209081714.GA25363@lst.de> <593c0d63-d8fd-4439-a57a-97340212c197@arm.com> <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com> <20241210041133.GA17116@lst.de> <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com> <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com> <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com> <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>
Message-ID: <20241212071848.GB6638@lst.de>

On Thu, Dec 12, 2024 at 01:24:45PM +0800, Baochen Qiang wrote:
> yeah, you are right, Robin. didn't know there are convenient interfaces
> like these already.

FYI, the DMA-API documentation says pretty straight forward to not
use the streaming API and documents these interfaces.  But maybe it's
not clear enough, so I'm open to suggestions on how to make it more
obvious.



From ultwcz1997 at outlook.com  Wed Dec 11 23:42:31 2024
From: ultwcz1997 at outlook.com (wang chaozheng)
Date: Thu, 12 Dec 2024 07:42:31 +0000
Subject: ath11k for QCA6391
Message-ID: <OSZPR01MB659723077AA21A568465CDEDD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>

* On 12/12/24 06:35, Mihai Moldovan wrote:
> Your kernel is very old. While being LTS and shipping a lot of backports, that
> typically is not the case for new features. Additionally, even for LTS
> standards, this version is antique (c.f.: current version of the 5.10 line is
5.10.230).

I known it, thank you. 

> Do yourself a favor and retest with the mainline kernel version, please.

I Will test for newer kernel.

Best regards.
Wang

From kvalo at kernel.org  Thu Dec 12 02:55:51 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Thu, 12 Dec 2024 12:55:51 +0200
Subject: ath11k for QCA6391
In-Reply-To: <OSZPR01MB659723077AA21A568465CDEDD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>
	(wang chaozheng's message of "Thu, 12 Dec 2024 07:42:31 +0000")
References: <OSZPR01MB659723077AA21A568465CDEDD93F2@OSZPR01MB6597.jpnprd01.prod.outlook.com>
Message-ID: <87zfl1rwzs.fsf@kernel.org>

wang chaozheng <ultwcz1997 at outlook.com> writes:

> * On 12/12/24 06:35, Mihai Moldovan wrote:
>
>> Your kernel is very old. While being LTS and shipping a lot of backports, that
>> typically is not the case for new features. Additionally, even for LTS
>> standards, this version is antique (c.f.: current version of the 5.10 line is
>> 5.10.230).
>
> I known it, thank you.

ath11k even tries to warn:

[ ? 10.376639] ath11k_pci 0004:01:00.0: WARNING: ath11k PCI support is experimental!

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Thu Dec 12 06:02:08 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Thu, 12 Dec 2024 16:02:08 +0200
Subject: [PATCH v3 1/2] wifi: ath11k: move update channel list from
 update reg worker to reg notifier
In-Reply-To: <20241129070714.226-2-quic_kangyang@quicinc.com> (Kang Yang's
	message of "Fri, 29 Nov 2024 15:07:13 +0800")
References: <20241129070714.226-1-quic_kangyang@quicinc.com>
	<20241129070714.226-2-quic_kangyang@quicinc.com>
Message-ID: <8734itov8f.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

> From: Wen Gong <quic_wgong at quicinc.com>
>
> Currently ath11k call regulatory_set_wiphy_regd() in ath11k_regd_update()
> to notify the reg domain change to cfg80211 and update channel list by
> reg_work, then ath11k immediately update channel list to firmware by
> ath11k_reg_update_chan_list().
>
> callstack:
> ath11k_regd_update
> ->regulatory_set_wiphy_regd
>            -> schedule_work(&reg_work)
> -> ath11k_reg_update_chan_list
>
> They are running in two threads, it leads the channel list data out of
> sync caused by muti-threads without synchronization. At this time,
> ath11k may update wrong channel list to firmware because the reg_work
> still running or even hasn't started yet. In this case, if the
> ath11k_reg_update_chan_list accesses an improperly updated channel list
> before reg_work is completed, it may result in out of bounds write
> errors, as shown in the KASAN report:
>
> BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list
> Call Trace:
>     ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]
>     kfree+0x109/0x3a0
>     ath11k_regd_update+0x1cf/0x350 [ath11k]
>     ath11k_regd_update_work+0x14/0x20 [ath11k]
>     process_one_work+0xe35/0x14c0
>
> The correct flow is after reg_work update the channel list according to
> new reg domain, ath11k call ath11k_reg_update_chan_list() and update the
> new channel list to firmware.
>
> reg_call_notifier()(finally it will call ath11k_reg_notifier()) will be
> called to by reg_work to notify ath11k when it finishes the channel
> list update. So at this time, call ath11k_reg_update_chan_list() in
> reg_call_notifier() with initiator type NL80211_REGDOM_SET_BY_DRIVER.
> Then ath11k_reg_update_chan_list() will use the correct channel list.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>
> Fixes: f45cb6b29cd3 ("wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()")
> Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>

The commit message would need significant work to make it more
understandable, I feel that it's just explaining call flows. But clearly
describing the problem and the design how it's solved would be a lot
more helpful.

Jeff had good guidance how to write a good commit message but I don't
have a link at hand right now.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Thu Dec 12 06:07:30 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Thu, 12 Dec 2024 16:07:30 +0200
Subject: [PATCH v3 2/2] wifi: ath11k: move update channel list to worker
 for wait flag
In-Reply-To: <20241129070714.226-3-quic_kangyang@quicinc.com> (Kang Yang's
	message of "Fri, 29 Nov 2024 15:07:14 +0800")
References: <20241129070714.226-1-quic_kangyang@quicinc.com>
	<20241129070714.226-3-quic_kangyang@quicinc.com>
Message-ID: <87y10lngf1.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

> From: Wen Gong <quic_wgong at quicinc.com>
>
> When wait flag is set for ath11k_reg_update_chan_list(), it will wait
> the completion of 11d/hw scan if 11d/hw scan is running.
>
> With the previous patch "wifi: ath11k: move update channel list from
> update reg worker to reg notifier", ath11k_reg_update_chan_list() will
> be called when reg_work is running. The global lock rtnl_lock will be
> held by reg_work in the meantime. If the wait_for_completion_timeout()
> is called due to 11d/hw scan is running, the occupation time of
> rtnl_lock will increase. This will increase blocking time for other
> threads if they want to use rtnl_lock.
>
> Move update channel list operation in ath11k_reg_update_chan_list() to
> a new worker, then the wait of completion of 11d/hw scan will not
> happen in reg_work and not increase the occupation time of the rtnl_lock.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>
> Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
> Co-developed-by: Kang Yang <quic_kangyang at quicinc.com>
> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>

Same here, I think the commit message should be more or less rewritten.

> --- a/drivers/net/wireless/ath/ath11k/core.h
> +++ b/drivers/net/wireless/ath/ath11k/core.h
> @@ -743,6 +743,10 @@ struct ath11k {
>  	struct completion bss_survey_done;
>  
>  	struct work_struct regd_update_work;
> +	struct work_struct channel_update_work;
> +	struct list_head channel_update_queue;
> +	/* protects channel_update_queue data */
> +	spinlock_t channel_update_lock;

Do you really need a new lock? Why not use data_lock?

> @@ -6318,6 +6320,15 @@ static void ath11k_mac_op_stop(struct ieee80211_hw *hw, bool suspend)
>  	}
>  	spin_unlock_bh(&ar->data_lock);
>  
> +	spin_lock_bh(&ar->channel_update_lock);

Empty line here, please.

> +	while ((params = list_first_entry_or_null(&ar->channel_update_queue,
> +						  struct scan_chan_list_params,
> +						  list))) {
> +		list_del(&params->list);
> +		kfree(params);
> +	}

Here also empty line.

> +	spin_unlock_bh(&ar->channel_update_lock);
> +
>  	rcu_assign_pointer(ar->ab->pdevs_active[ar->pdev_idx], NULL);
>  
>  	synchronize_rcu();

[...]

> +void ath11k_regd_update_chan_list_work(struct work_struct *work)
> +{
> +	struct ath11k *ar = container_of(work, struct ath11k,
> +					 channel_update_work);
> +	struct scan_chan_list_params *params;
> +	struct list_head local_update_list;
> +	int left;
> +
> +	INIT_LIST_HEAD(&local_update_list);
> +
> +	spin_lock_bh(&ar->channel_update_lock);
> +	while ((params = list_first_entry_or_null(&ar->channel_update_queue,
> +						  struct scan_chan_list_params,
> +						  list))) {
> +		list_del(&params->list);
> +		list_add_tail(&params->list, &local_update_list);
> +	}
> +	spin_unlock_bh(&ar->channel_update_lock);

What about list_splice_tail_init() or similar?

> +
> +	while ((params = list_first_entry_or_null(&local_update_list,
> +						  struct scan_chan_list_params,
> +						  list))) {
> +		if (ar->state_11d != ATH11K_11D_IDLE) {
> +			left = wait_for_completion_timeout(&ar->completed_11d_scan,
> +							   ATH11K_SCAN_TIMEOUT_HZ);
> +			if (!left) {
> +				ath11k_dbg(ar->ab, ATH11K_DBG_REG,
> +					   "failed to receive 11d scan complete: timed out\n");
> +				ar->state_11d = ATH11K_11D_IDLE;
> +			}

Empty line here.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Thu Dec 12 06:41:43 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Thu, 12 Dec 2024 14:41:43 +0000 (UTC)
Subject: [PATCH v3 1/2] wifi: ath11k: fix RCU stall while reaping monitor
 destination ring
In-Reply-To: <20241008053744.1070-2-quic_kangyang@quicinc.com>
References: <20241008053744.1070-2-quic_kangyang@quicinc.com>
Message-ID: <173401450207.833118.1446184244363325456.kvalo@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> wrote:

> From: P Praneesh <quic_ppranees at quicinc.com>
> 
> While processing the monitor destination ring, MSDUs are reaped from the
> link descriptor based on the corresponding buf_id.
> 
> However, sometimes the driver cannot obtain a valid buffer corresponding
> to the buf_id received from the hardware. This causes an infinite loop
> in the destination processing, resulting in a kernel crash.
> 
> kernel log:
> ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
> ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
> ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
> ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
> 
> Fix this by skipping the problematic buf_id and reaping the next entry,
> replacing the break with the next MSDU processing.
> 
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: P Praneesh <quic_ppranees at quicinc.com>
> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
> Acked-by: Jeff Johnson <quic_jjohnson at quicinc.com>

Acked-by: Kalle Valo <kvalo at kernel.org>

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20241008053744.1070-2-quic_kangyang at quicinc.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
https://docs.kernel.org/process/submitting-patches.html



From kvalo at kernel.org  Thu Dec 12 06:53:37 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Thu, 12 Dec 2024 16:53:37 +0200
Subject: [PATCH v3 2/2] wifi: ath11k: add srng->lock for
 ath11k_hal_srng_* in monitor mode
In-Reply-To: <20241008053744.1070-3-quic_kangyang@quicinc.com> (Kang Yang's
	message of "Tue, 8 Oct 2024 13:37:44 +0800")
References: <20241008053744.1070-1-quic_kangyang@quicinc.com>
	<20241008053744.1070-3-quic_kangyang@quicinc.com>
Message-ID: <87ttb9nea6.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

> ath11k_hal_srng_* should be used with srng->lock to protect srng data.
>
> For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
> they use ath11k_hal_srng_* for many times but never call srng->lock.
>
> So when running (full) monitor mode, warning will occur:
> RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
> Call Trace:
>  ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
>  ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
>  ? idr_alloc_u32+0x97/0xd0
>  ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
>  ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
>  ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
>  __napi_poll+0x30/0x1f0
>  net_rx_action+0x198/0x320
>  __do_softirq+0xdd/0x319
>
> So add srng->lock for them to avoid such warnings.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>

[...]

> @@ -5607,7 +5609,7 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
>  	struct hal_sw_mon_ring_entries *sw_mon_entries;
>  	struct ath11k_pdev_mon_stats *rx_mon_stats;
>  	struct sk_buff *head_msdu, *tail_msdu;
> -	void *mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
> +	struct hal_srng *mon_dst_srng;
>  	void *ring_entry;
>  	u32 rx_bufs_used = 0, mpdu_rx_bufs_used;
>  	int quota = 0, ret;
> @@ -5623,6 +5625,9 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
>  		goto reap_status_ring;
>  	}
>  
> +	mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
> +	spin_lock_bh(&mon_dst_srng->lock);

Why initialise mon_dst_srng differently? The commit message mentions
nothing about this change.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From eahariha at linux.microsoft.com  Thu Dec 12 09:33:02 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Thu, 12 Dec 2024 17:33:02 +0000
Subject: [PATCH net-next v4 2/2] wifi: ath11k: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
Message-ID: <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Acked-by: Jeff Johnson <quic_jjohnson at quicinc.com>
Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/debugfs.c b/drivers/net/wireless/ath/ath11k/debugfs.c
index 57281a135dd7fa6b8610636f47873c8bba21053c..bf192529e3fe26a91e72105a77b4c6f849b905ec 100644
--- a/drivers/net/wireless/ath/ath11k/debugfs.c
+++ b/drivers/net/wireless/ath/ath11k/debugfs.c
@@ -178,7 +178,7 @@ static int ath11k_debugfs_fw_stats_request(struct ath11k *ar,
 	 * received 'update stats' event, we keep a 3 seconds timeout in case,
 	 * fw_stats_done is not marked yet
 	 */
-	timeout = jiffies + msecs_to_jiffies(3 * 1000);
+	timeout = jiffies + secs_to_jiffies(3);
 
 	ath11k_debugfs_fw_stats_reset(ar);
 

-- 
2.43.0



From eahariha at linux.microsoft.com  Thu Dec 12 09:33:00 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Thu, 12 Dec 2024 17:33:00 +0000
Subject: [PATCH net-next v4 0/2] Converge on using secs_to_jiffies() in netdev
Message-ID: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>

These patches are pulled out from v2 [1] and v3 [2] of my series to be sent
through netdev. The series converts users of msecs_to_jiffies() that need
seconds-denominated timeouts to the new secs_to_jiffies() API in
include/linux/jiffies.h to avoid the multiplication with 1000 or MSEC_PER_SEC.

[1]: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v2-0-911fb7595e79 at linux.microsoft.com
[2]: https://lore.kernel.org/r/20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a at linux.microsoft.com

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
Easwar Hariharan (2):
      gve: Convert timeouts to secs_to_jiffies()
      wifi: ath11k: Convert timeouts to secs_to_jiffies()

 drivers/net/ethernet/google/gve/gve_tx_dqo.c | 6 ++----
 drivers/net/wireless/ath/ath11k/debugfs.c    | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)
---
base-commit: 91e71d606356e50f238d7a87aacdee4abc427f07
change-id: 20241211-netdev-converge-secs-to-jiffies-f18b18c775c1

Best regards,
-- 
Easwar Hariharan <eahariha at linux.microsoft.com>



From eahariha at linux.microsoft.com  Thu Dec 12 09:33:01 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Thu, 12 Dec 2024 17:33:01 +0000
Subject: [PATCH net-next v4 1/2] gve: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
Message-ID: <20241212-netdev-converge-secs-to-jiffies-v4-1-6dac97a6d6ab@linux.microsoft.com>

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
---
 drivers/net/ethernet/google/gve/gve_tx_dqo.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
index f879426cb5523a7e150f363b5e57b9d472b5817c..394debc62268aadf2579f9b516e045cb48287e7c 100644
--- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
@@ -1146,8 +1146,7 @@ static void gve_handle_miss_completion(struct gve_priv *priv,
 	/* jiffies can wraparound but time comparisons can handle overflows. */
 	pending_packet->timeout_jiffies =
 			jiffies +
-			msecs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT *
-					 MSEC_PER_SEC);
+			secs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT);
 	add_to_list(tx, &tx->dqo_compl.miss_completions, pending_packet);
 
 	*bytes += pending_packet->skb->len;
@@ -1191,8 +1190,7 @@ static void remove_miss_completions(struct gve_priv *priv,
 		pending_packet->state = GVE_PACKET_STATE_TIMED_OUT_COMPL;
 		pending_packet->timeout_jiffies =
 				jiffies +
-				msecs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT *
-						 MSEC_PER_SEC);
+				secs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT);
 		/* Maintain pending packet in another list so the packet can be
 		 * unallocated at a later time.
 		 */

-- 
2.43.0



From pkaligineedi at google.com  Thu Dec 12 09:38:03 2024
From: pkaligineedi at google.com (Praveen Kaligineedi)
Date: Thu, 12 Dec 2024 09:38:03 -0800
Subject: [PATCH net-next v4 1/2] gve: Convert timeouts to secs_to_jiffies()
In-Reply-To: <20241212-netdev-converge-secs-to-jiffies-v4-1-6dac97a6d6ab@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
 <20241212-netdev-converge-secs-to-jiffies-v4-1-6dac97a6d6ab@linux.microsoft.com>
Message-ID: <CA+f9V1OK39b5hNoVZqu6AfPJqGsB4_5iyAK24Oit-tjmxrk7jA@mail.gmail.com>

On Thu, Dec 12, 2024 at 9:33?AM Easwar Hariharan
<eahariha at linux.microsoft.com> wrote:
>
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
Reviewed-by: Praveen Kaligineedi <pkaligineedi at google.com>


From jeff.johnson at oss.qualcomm.com  Thu Dec 12 09:51:06 2024
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 12 Dec 2024 09:51:06 -0800
Subject: [PATCH net-next v4 2/2] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
 <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>
Message-ID: <27cc63e7-1a63-4ba5-8c7a-12a78ad6d9fa@oss.qualcomm.com>

On 12/12/2024 9:33 AM, Easwar Hariharan wrote:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> 
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> 
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> 
> 

something is wrong with your patch since it introduces a blank line after each
line.

Also if you want the ath11k patch to be taken separately, it goes through the
ath tree, not the net tree.

/jeff




From quic_jjohnson at quicinc.com  Thu Dec 12 10:08:10 2024
From: quic_jjohnson at quicinc.com (Jeff Johnson)
Date: Thu, 12 Dec 2024 10:08:10 -0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <20241212071848.GB6638@lst.de>
References: <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com>
 <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de>
 <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
 <20241210041133.GA17116@lst.de>
 <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
 <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com>
 <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com>
 <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>
 <20241212071848.GB6638@lst.de>
Message-ID: <ecbd70dd-9274-42b6-9673-9c6d82c4e763@quicinc.com>

On 12/11/2024 11:18 PM, Christoph Hellwig wrote:
> On Thu, Dec 12, 2024 at 01:24:45PM +0800, Baochen Qiang wrote:
>> yeah, you are right, Robin. didn't know there are convenient interfaces
>> like these already.
> 
> FYI, the DMA-API documentation says pretty straight forward to not
> use the streaming API and documents these interfaces.  But maybe it's
> not clear enough, so I'm open to suggestions on how to make it more
> obvious.

This is probably less of a documentation issue and more of an issue with the
fact that each instance of the ath driver is based upon the prior instance,
and hence it inherits any usage of legacy APIs. So unless someone notices
there is a better API, or proactively adds the usage of the new API for us,
the ath drivers will continue to use legacy APIs.

So it is appreciated that light has been shed on this issue.

/jeff



From eahariha at linux.microsoft.com  Thu Dec 12 11:17:10 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Thu, 12 Dec 2024 11:17:10 -0800
Subject: [PATCH net-next v4 2/2] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <27cc63e7-1a63-4ba5-8c7a-12a78ad6d9fa@oss.qualcomm.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
 <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>
 <27cc63e7-1a63-4ba5-8c7a-12a78ad6d9fa@oss.qualcomm.com>
Message-ID: <cc1d5e08-92e0-46d8-badb-2a61482200cf@linux.microsoft.com>

On 12/12/2024 9:51 AM, Jeff Johnson wrote:
> On 12/12/2024 9:33 AM, Easwar Hariharan wrote:
>> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
>>
>> secs_to_jiffies(). As the value here is a multiple of 1000, use
>>
>> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>>
>>
>>
> 
> something is wrong with your patch since it introduces a blank line after each
> line.
>

This is some sort of weird interaction between b4 and git send-email. I
used git send-email to send the patches after writing them out with b4
send so as to edit "net-next" into the subject line. It's good to know
to not mix the tools in the future.

I can resend from the branch with git send-email directly to avoid this
if preferred.

> Also if you want the ath11k patch to be taken separately, it goes through the
> ath tree, not the net tree.
> 
> /jeff
> 

I don't have a preference on being taken separately, whatever approach
works best is good with me.

Thanks,
Easwar


From jeff.johnson at oss.qualcomm.com  Thu Dec 12 11:48:09 2024
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 12 Dec 2024 11:48:09 -0800
Subject: [PATCH net-next v4 2/2] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <cc1d5e08-92e0-46d8-badb-2a61482200cf@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
 <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>
 <27cc63e7-1a63-4ba5-8c7a-12a78ad6d9fa@oss.qualcomm.com>
 <cc1d5e08-92e0-46d8-badb-2a61482200cf@linux.microsoft.com>
Message-ID: <a6d2bfba-c3a8-4cf4-9276-7f7e39671a15@oss.qualcomm.com>

On 12/12/2024 11:17 AM, Easwar Hariharan wrote:
> On 12/12/2024 9:51 AM, Jeff Johnson wrote:
>> On 12/12/2024 9:33 AM, Easwar Hariharan wrote:
>>> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
>>>
>>> secs_to_jiffies(). As the value here is a multiple of 1000, use
>>>
>>> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>>>
>>>
>>>
>>
>> something is wrong with your patch since it introduces a blank line after each
>> line.
>>
> 
> This is some sort of weird interaction between b4 and git send-email. I
> used git send-email to send the patches after writing them out with b4
> send so as to edit "net-next" into the subject line. It's good to know
> to not mix the tools in the future.
> 
> I can resend from the branch with git send-email directly to avoid this
> if preferred.
> 
>> Also if you want the ath11k patch to be taken separately, it goes through the
>> ath tree, not the net tree.
>>
>> /jeff
>>
> 
> I don't have a preference on being taken separately, whatever approach
> works best is good with me.

Andrew has this in his mm tree, so let's just have it come from there:
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=b3b550379dd1f0b65fac207c9c4d0eb5ed84775e



From tharvey at gateworks.com  Thu Dec 12 11:57:57 2024
From: tharvey at gateworks.com (Tim Harvey)
Date: Thu, 12 Dec 2024 11:57:57 -0800
Subject: ath11k swiotlb buffer is full (on IMX8M with 4GiB DRAM)
In-Reply-To: <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>
References: <CAJ+vNU0EL3T+GyNAbVbGqYYQ5NM3h7cgAwqxxBMuZjh+-YQ3bA@mail.gmail.com>
 <1b2ea8b2-6fbe-4118-b6c6-742c8f0be476@quicinc.com> <CAJ+vNU1-OZ3y4p2L+zf64AiVtUv70yZNqkT20jTxyE0_gJb6Jg@mail.gmail.com>
 <0282be95-9094-4d49-b79e-4f7c976dad00@quicinc.com> <CAJ+vNU32EMHjtchJRb1sODBrUKG2vZW4ZEu1_F0+dCCEjCn7Dg@mail.gmail.com>
 <20241209081714.GA25363@lst.de> <593c0d63-d8fd-4439-a57a-97340212c197@arm.com>
 <CAJ+vNU2ypE_Mn_6iKCmf5LYk9Sth=ryWXyewc5MhOKK8VoAKCA@mail.gmail.com>
 <20241210041133.GA17116@lst.de> <CAJ+vNU03Cqsc+O5anwmvJW8Wfd-06LbDMVHjxVFdixf01ZLczQ@mail.gmail.com>
 <5fe372df-ae51-4a8b-9fa3-a4a0ea2d33e3@quicinc.com> <9b2e8ffa-ba2c-46da-a478-eb1fb44b693e@arm.com>
 <80992ae5-e329-4a34-94c8-9345b2e8a9a0@quicinc.com>
Message-ID: <CAJ+vNU1v6JMTcnKhJAPtRu2A-rVjNNUd3MrqAP64EWMiNVuC4g@mail.gmail.com>

On Wed, Dec 11, 2024 at 9:24?PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>
>
>
> On 12/11/2024 9:44 PM, Robin Murphy wrote:
> > On 2024-12-11 2:31 am, Baochen Qiang wrote:
> >>
> >>
> >> On 12/11/2024 7:06 AM, Tim Harvey wrote:
> >>> On Mon, Dec 9, 2024 at 8:11?PM Christoph Hellwig <hch at lst.de> wrote:
> >>>>
> >>>> On Mon, Dec 09, 2024 at 11:15:02AM -0800, Tim Harvey wrote:
> >>>>> After a lot of back and forth and investigation this is due to the
> >>>>> IMX8M SoC's not having an IOMMU thus swiotlb is being used and ath11k
> >>>>> is requesting some buffers that are too large for swiotlb to provide.
> >>>>> There is a specific patch which added the HAL_WBM2SW_RELEASE buffers
> >>>>> to cacheable memory that could be reverted to fix this but the concern
> >>>>> was that it would impact performance moving those buffers to
> >>>>> non-cacheable memory (there are three ~1MiB buffers being allocated):
> >>>>> commit d0e2523bfa9cb ("ath11k: allocate HAL_WBM2SW_RELEASE ring from
> >>>>> cacheable memory").
> >>>>
> >>>> The combination of "buffers" and "swiotlb" sounds like Robin was right
> >>>> below.
> >>>>
> >>>>> The chain of events as best I can tell are:
> >>>>>
> >>>>> commit 6452f0a3d565 ("ath11k: allocate dst ring descriptors from
> >>>>> cacheable memory")
> >>>>> - Nov 12 2021 (made it into Linux 5.17)
> >>>>> - changes allocation of reo_dst rings to cacheable memory to allow
> >>>>> cached descriptor access to optimize CPU usage
> >>>>> - this is flawed because it uses virt_to_phys() to allocate cacheable
> >>>>> memory which does not work on systems with an IOMMU enabled or using
> >>>>> software IOMMU (swiotlb); this causes a kernel crash on client
> >>>>> association
> >>>>
> >>>> And this is where it started to take a wrong turn, that everyhing
> >>>> later basically made worse.  If you have long living and potentially
> >>>> large DMA allocations, you need to use dma_alloc_* interfaces.
> >>>>
> >>>> 5.17 already had dma_alloc_pages for quite a while which was and still is
> >>>> the proper interface to use.  For much older kernel you'd be stuck
> >>>> with dma_alloc_noncoherent or dma_alloc_attrs with the right flag,
> >>>> but even that would have been much better.
> >>>
> >>> Christoph,
> >>>
> >>> I'm not clear what you are suggesting be done here. Are you suggesting
> >>> that ath11k has been using the wrong mechanism by calling
> >>> dma_map_single for cached DMA buffers? I'm not all that familiar with
> >>> ath11k so I can't tell what buffers are considered long living.
> >>
> >> those buffers are allocated when driver load and freed when driver unload, so IMO they are
> >> long living.
> >
> > The point is that if this driver wants a notion of "cached DMA buffers", then it should
> > allocate such buffers the proper way, not try to reinvent it badly. That means using
> > dma_alloc_pages(), or modern dma_alloc_noncoherent() which is essentially the same thing
> > but with the dma_map_page() call automatically done for you as well.
>
> yeah, you are right, Robin. didn't know there are convenient interfaces like these already.
>
> Tim, can you work out a patch then?
>

How about:

diff --git a/drivers/net/wireless/ath/ath11k/dp.c
b/drivers/net/wireless/ath/ath11k/dp.c
index fbf666d0ecf1..557e06187e95 100644
--- a/drivers/net/wireless/ath/ath11k/dp.c
+++ b/drivers/net/wireless/ath/ath11k/dp.c
@@ -105,9 +105,8 @@ void ath11k_dp_srng_cleanup(struct ath11k_base
*ab, struct dp_srng *ring)
                return;

        if (ring->cached) {
-               dma_unmap_single(ab->dev, ring->paddr_unaligned, ring->size,
-                                DMA_FROM_DEVICE);
-               kfree(ring->vaddr_unaligned);
+               dma_free_noncoherent(ab->dev, ring->size, ring->vaddr_unaligned,
+                                    ring->paddr_unaligned, DMA_FROM_DEVICE);
        } else {
                dma_free_coherent(ab->dev, ring->size, ring->vaddr_unaligned,
                                  ring->paddr_unaligned);
@@ -249,28 +248,18 @@ int ath11k_dp_srng_setup(struct ath11k_base *ab,
struct dp_srng *ring,
                default:
                        cached = false;
                }
-
-               if (cached) {
-                       ring->vaddr_unaligned = kzalloc(ring->size, GFP_KERNEL);
-                       if (!ring->vaddr_unaligned)
-                               return -ENOMEM;
-
-                       ring->paddr_unaligned = dma_map_single(ab->dev,
-
ring->vaddr_unaligned,
-                                                              ring->size,
-                                                              DMA_FROM_DEVICE);
-                       if (dma_mapping_error(ab->dev, ring->paddr_unaligned)) {
-                               kfree(ring->vaddr_unaligned);
-                               ring->vaddr_unaligned = NULL;
-                               return -ENOMEM;
-                       }
-               }
        }

-       if (!cached)
+       if (cached) {
+               ring->vaddr_unaligned = dma_alloc_noncoherent(ab->dev,
ring->size,
+
&ring->paddr_unaligned,
+                                                             DMA_FROM_DEVICE,
+                                                             GFP_KERNEL);
+       } else {
                ring->vaddr_unaligned = dma_alloc_coherent(ab->dev, ring->size,

&ring->paddr_unaligned,
                                                           GFP_KERNEL);
+       }

        if (!ring->vaddr_unaligned)
                return -ENOMEM;

If this is what we are talking about here I can submit that with a
proper commit log. Note there are a lot of other calls to
dma_map_single in the ath drivers and my understanding is those may be
just fine for small short-lived buffers but I'm not clear if that is
what they are always used for.

Best Regards,

Tim

> >
> > Thanks,
> > Robin.
>


From jeff.johnson at oss.qualcomm.com  Thu Dec 12 12:12:04 2024
From: jeff.johnson at oss.qualcomm.com (Jeff Johnson)
Date: Thu, 12 Dec 2024 12:12:04 -0800
Subject: [PATCH net-next v4 2/2] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
In-Reply-To: <cc1d5e08-92e0-46d8-badb-2a61482200cf@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
 <20241212-netdev-converge-secs-to-jiffies-v4-2-6dac97a6d6ab@linux.microsoft.com>
 <27cc63e7-1a63-4ba5-8c7a-12a78ad6d9fa@oss.qualcomm.com>
 <cc1d5e08-92e0-46d8-badb-2a61482200cf@linux.microsoft.com>
Message-ID: <e9552968-64c2-4e98-bbcd-37a7498422ab@oss.qualcomm.com>

On 12/12/2024 11:17 AM, Easwar Hariharan wrote:
> This is some sort of weird interaction between b4 and git send-email. I
> used git send-email to send the patches after writing them out with b4
> send so as to edit "net-next" into the subject line. It's good to know
> to not mix the tools in the future.
> 
> I can resend from the branch with git send-email directly to avoid this
> if preferred.
Note that if you have a recent version, b4 prep --set-prefixes can add the
tags to the subject (and keep track of them in the cover letter metadata)



From quic_kangyang at quicinc.com  Thu Dec 12 22:17:44 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 14:17:44 +0800
Subject: [PATCH v3 2/2] wifi: ath11k: add srng->lock for ath11k_hal_srng_*
 in monitor mode
In-Reply-To: <87ttb9nea6.fsf@kernel.org>
References: <20241008053744.1070-1-quic_kangyang@quicinc.com>
 <20241008053744.1070-3-quic_kangyang@quicinc.com> <87ttb9nea6.fsf@kernel.org>
Message-ID: <79910df2-a7fd-4880-bd32-4f2927341654@quicinc.com>



On 12/12/2024 10:53 PM, Kalle Valo wrote:
> Kang Yang <quic_kangyang at quicinc.com> writes:
> 
>> ath11k_hal_srng_* should be used with srng->lock to protect srng data.
>>
>> For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
>> they use ath11k_hal_srng_* for many times but never call srng->lock.
>>
>> So when running (full) monitor mode, warning will occur:
>> RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
>> Call Trace:
>>   ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
>>   ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
>>   ? idr_alloc_u32+0x97/0xd0
>>   ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
>>   ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
>>   ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
>>   __napi_poll+0x30/0x1f0
>>   net_rx_action+0x198/0x320
>>   __do_softirq+0xdd/0x319
>>
>> So add srng->lock for them to avoid such warnings.
>>
>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
>> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
>>
>> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
>> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
> 
> [...]
> 
>> @@ -5607,7 +5609,7 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
>>   	struct hal_sw_mon_ring_entries *sw_mon_entries;
>>   	struct ath11k_pdev_mon_stats *rx_mon_stats;
>>   	struct sk_buff *head_msdu, *tail_msdu;
>> -	void *mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
>> +	struct hal_srng *mon_dst_srng;
>>   	void *ring_entry;
>>   	u32 rx_bufs_used = 0, mpdu_rx_bufs_used;
>>   	int quota = 0, ret;
>> @@ -5623,6 +5625,9 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
>>   		goto reap_status_ring;
>>   	}
>>   
>> +	mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
>> +	spin_lock_bh(&mon_dst_srng->lock);
> 
> Why initialise mon_dst_srng differently? The commit message mentions
> nothing about this change.


Because need to fetch spin lock inside 'struct hal_srng'. If still use 
'void *mon_dst_srng', need to perform a variable type cast.

Bur 'struct hal_srng' will make this line too long:
'struct hal_srng *mon_dst_srng = 
&ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];'
So I separated the definition and initialization.

ath11k_dp_rx_reap_mon_status_ring()/ath11k_dp_process_rx and others ring 
process function is the same.



> 



From quic_kangyang at quicinc.com  Thu Dec 12 22:46:10 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 14:46:10 +0800
Subject: [PATCH v3 2/2] wifi: ath11k: move update channel list to worker
 for wait flag
In-Reply-To: <87y10lngf1.fsf@kernel.org>
References: <20241129070714.226-1-quic_kangyang@quicinc.com>
 <20241129070714.226-3-quic_kangyang@quicinc.com> <87y10lngf1.fsf@kernel.org>
Message-ID: <07734404-b737-4a8c-ae24-f8b0b8c16e58@quicinc.com>



On 12/12/2024 10:07 PM, Kalle Valo wrote:
> Kang Yang <quic_kangyang at quicinc.com> writes:
> 
>> From: Wen Gong <quic_wgong at quicinc.com>
>>
>> When wait flag is set for ath11k_reg_update_chan_list(), it will wait
>> the completion of 11d/hw scan if 11d/hw scan is running.
>>
>> With the previous patch "wifi: ath11k: move update channel list from
>> update reg worker to reg notifier", ath11k_reg_update_chan_list() will
>> be called when reg_work is running. The global lock rtnl_lock will be
>> held by reg_work in the meantime. If the wait_for_completion_timeout()
>> is called due to 11d/hw scan is running, the occupation time of
>> rtnl_lock will increase. This will increase blocking time for other
>> threads if they want to use rtnl_lock.
>>
>> Move update channel list operation in ath11k_reg_update_chan_list() to
>> a new worker, then the wait of completion of 11d/hw scan will not
>> happen in reg_work and not increase the occupation time of the rtnl_lock.
>>
>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>>
>> Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
>> Co-developed-by: Kang Yang <quic_kangyang at quicinc.com>
>> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
> 
> Same here, I think the commit message should be more or less rewritten.
> 
>> --- a/drivers/net/wireless/ath/ath11k/core.h
>> +++ b/drivers/net/wireless/ath/ath11k/core.h
>> @@ -743,6 +743,10 @@ struct ath11k {
>>   	struct completion bss_survey_done;
>>   
>>   	struct work_struct regd_update_work;
>> +	struct work_struct channel_update_work;
>> +	struct list_head channel_update_queue;
>> +	/* protects channel_update_queue data */
>> +	spinlock_t channel_update_lock;
> 
> Do you really need a new lock? Why not use data_lock?

Seems data_lock is OK, will change in next version.

> 
>> @@ -6318,6 +6320,15 @@ static void ath11k_mac_op_stop(struct ieee80211_hw *hw, bool suspend)
>>   	}
>>   	spin_unlock_bh(&ar->data_lock);
>>   
>> +	spin_lock_bh(&ar->channel_update_lock);
> 
> Empty line here, please.
> 
>> +	while ((params = list_first_entry_or_null(&ar->channel_update_queue,
>> +						  struct scan_chan_list_params,
>> +						  list))) {
>> +		list_del(&params->list);
>> +		kfree(params);
>> +	}
> 
> Here also empty line.
> 
>> +	spin_unlock_bh(&ar->channel_update_lock);
>> +
>>   	rcu_assign_pointer(ar->ab->pdevs_active[ar->pdev_idx], NULL);
>>   
>>   	synchronize_rcu();
> 
> [...]
> 
>> +void ath11k_regd_update_chan_list_work(struct work_struct *work)
>> +{
>> +	struct ath11k *ar = container_of(work, struct ath11k,
>> +					 channel_update_work);
>> +	struct scan_chan_list_params *params;
>> +	struct list_head local_update_list;
>> +	int left;
>> +
>> +	INIT_LIST_HEAD(&local_update_list);
>> +
>> +	spin_lock_bh(&ar->channel_update_lock);
>> +	while ((params = list_first_entry_or_null(&ar->channel_update_queue,
>> +						  struct scan_chan_list_params,
>> +						  list))) {
>> +		list_del(&params->list);
>> +		list_add_tail(&params->list, &local_update_list);
>> +	}
>> +	spin_unlock_bh(&ar->channel_update_lock);
> 
> What about list_splice_tail_init() or similar?

Seems list_splice_tail_init() is better. The time complexity is O(1).?

> 
>> +
>> +	while ((params = list_first_entry_or_null(&local_update_list,
>> +						  struct scan_chan_list_params,
>> +						  list))) {
>> +		if (ar->state_11d != ATH11K_11D_IDLE) {
>> +			left = wait_for_completion_timeout(&ar->completed_11d_scan,
>> +							   ATH11K_SCAN_TIMEOUT_HZ);
>> +			if (!left) {
>> +				ath11k_dbg(ar->ab, ATH11K_DBG_REG,
>> +					   "failed to receive 11d scan complete: timed out\n");
>> +				ar->state_11d = ATH11K_11D_IDLE;
>> +			}
> 
> Empty line here.
> 



From dwmw2 at infradead.org  Fri Dec 13 01:10:30 2024
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 13 Dec 2024 09:10:30 +0000
Subject: [PATCH RFC/RFT] vfio/pci: Create feature to disable MSI
 virtualization
In-Reply-To: <87r0aspby6.ffs@tglx>
References: <adcb785e-4dc7-4c4a-b341-d53b72e13467@gmail.com>
	 <20240812170014.1583783-1-alex.williamson@redhat.com>
	 <20240813163053.GK1985367@ziepe.ca> <87r0aspby6.ffs@tglx>
Message-ID: <03fdfde8dc05ecce1f1edececf0800d8cb919ac1.camel@infradead.org>

On Tue, 2024-08-13 at 19:30 +0200, Thomas Gleixner wrote:
> On Tue, Aug 13 2024 at 13:30, Jason Gunthorpe wrote:
> > On Mon, Aug 12, 2024 at 10:59:12AM -0600, Alex Williamson wrote:
> > > vfio-pci has always virtualized the MSI address and data registers as
> > > MSI programming is performed through the SET_IRQS ioctl.? Often this
> > > virtualization is not used, and in specific cases can be unhelpful.
> > > 
> > > One such case where the virtualization is a hinderance is when the
> > > device contains an onboard interrupt controller programmed by the guest
> > > driver.? Userspace VMMs have a chance to quirk this programming,
> > > injecting the host physical MSI information, but only if the userspace
> > > driver can get access to the host physical address and data registers.
> > > 
> > > This introduces a device feature which allows the userspace driver to
> > > disable virtualization of the MSI capability address and data registers
> > > in order to provide read-only access the the physical values.
> > 
> > Personally, I very much dislike this. Encouraging such hacky driver
> > use of the interrupt subsystem is not a good direction. Enabling this
> > in VMs will further complicate fixing the IRQ usages in these drivers
> > over the long run.
> > 
> > If the device has it's own interrupt sources then the device needs to
> > create an irq_chip and related and hook them up properly. Not hackily
> > read the MSI-X registers and write them someplace else.
> > 
> > Thomas Gleixner has done alot of great work recently to clean this up.
> > 
> > So if you imagine the driver is fixed, then this is not necessary.
> 
> Yes. I looked at the at11k driver when I was reworking the PCI/MSI
> subsystem and that's a perfect candidate for a proper device specific
> interrupt domain to replace the horrible MSI hackery it has.

The ath11k hacks may be awful, but in their defence, that's because the
whole way the hardware works is awful.

Q: With PCI passthrough to a guest, how does the guest OS tell the
device where to do DMA?

A: The guest OS just hands the device a guest physical address and the
IOMMU does the rest. Nothing 'intercedes' between the guest and the
device to mess with that address.

Q: MSIs are just DMA. So with PCI passthrough to a guest, how does the
guest OS configure the device's MSIs? 

<fantasy>
A: The guest OS just hands the device a standard MSI message encoding
the target guest APIC ID and vector (etc.), and the IOMMU does the
rest. Nothing 'intercedes' between the guest and the device to mess
with that MSI message.

And thus ath11k didn't need to do *any* hacks to work around a stupid
hardware design with the VMM snooping on stuff it ideally shouldn't
have had any business touching in the first place.

Posted interrupts are almost the *default* because the IOMMU receives a
<source-id, vCPU APIC ID, vector> tuple on the bus. If receiving an
interrupt for a vCPU which isn't currently running, that's when the
IOMMU sets a bit in a table somewhere and notifies the host OS.

All that special case MSI handling and routing code that I had
nightmares about because it fell through a wormhole from a parallel
universe, doesn't exist.

And look, DPDK drivers which run in polling mode and 'abuse' MSIs by
using real memory addresses and asking the device to "write <these> 32
bits to <this> structure if you want attention" just work nicely in
virtual machines too, just as they do on real hardware.
</fantasy>

/me wakes up...

Shit.

And we have to enable this Interrupt Remapping crap even to address
more than 255 CPUs *without* virtualization? Even a *guest* has to see
a virtual IOMMU and enable Interrupt Remapping to be able to use more
than 255 vCPUs? Even though there were a metric shitload of spare bits
in the MSI message we could have used?.

Wait, so that means we have to offer an IOMMU with *DMA* remapping to
guests, which means 2-stage translations and/or massive overhead, just
for that guest to be able to use >255 vCPUs?

Screw you all, I'm going back to bed.



? And *should* use, if we ever do something similar like, say, expand
  the vector# space past 8 bits. Intel and AMD take note. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath11k/attachments/20241213/b50e36ba/attachment-0001.p7s>

From dominik.strzelczyk at firmator24.pl  Fri Dec 13 01:15:57 2024
From: dominik.strzelczyk at firmator24.pl (Dominik Strzelczyk)
Date: Fri, 13 Dec 2024 09:15:57 GMT
Subject: =?UTF-8?Q?Pytanie_o_ofert=C4=99?=
Message-ID: <20241213084500-0.1.hw.11zm6.0.9vo21omlf6@firmator24.pl>

Dzie? dobry,

Czy potrzebuj? Pa?stwo aktualnie nowych klient?w ?

Skutecznie pomagamy rozpoczyna? rozmowy handlowe z klientami zainteresowanymi Pa?stwa ofert?.

Zapraszam do kontaktu zwrotnego.


Pozdrawiam serdecznie
Dominik Strzelczyk


From quic_kangyang at quicinc.com  Fri Dec 13 01:39:07 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 17:39:07 +0800
Subject: [PATCH v4 0/2] wifi: ath11k: fix data out of sync for channel list for reg update
Message-ID: <20241213093909.629-1-quic_kangyang@quicinc.com>

Currently there are two threads to updating/fetch data of channel
list, and there are no synchronization for the data, it leads data out
of sync for channel list when doing reg update.

So change the call flow to make sure the fetch data running after the
update data finished, then data of channel list become synchronization.

Note: This patch-set is an old patch-set in public review written by
Wen Gong. Just continue sending it for him.
Link: https://lore.kernel.org/linux-wireless/20230329091235.19500-1-quic_wgong at quicinc.com/

v4:
    1. rewrite commit message in patch#1, #2.
    2. use list_splice_tail_init() to move list entry.
    3. use data_lock instead of adding a new lock.
v3:
    1. rebase on tag ath-202411251703.
    2. add KASAN BUG report in patch #1.
v2:
    1. rewrite commit message for patch #1 and #2.
    2. use a local list without the spinlock held for patch #2.

Wen Gong (2):
  wifi: ath11k: move update channel list from update reg worker to reg
    notifier
  wifi: ath11k: move update channel list to worker when wait flag is set

 drivers/net/wireless/ath/ath11k/core.c |   1 +
 drivers/net/wireless/ath/ath11k/core.h |   4 +-
 drivers/net/wireless/ath/ath11k/mac.c  |  14 ++++
 drivers/net/wireless/ath/ath11k/reg.c  | 107 +++++++++++++++++--------
 drivers/net/wireless/ath/ath11k/reg.h  |   1 +
 drivers/net/wireless/ath/ath11k/wmi.h  |   1 +
 6 files changed, 93 insertions(+), 35 deletions(-)


base-commit: 175616a7658cd5d53389d1f9c1ce22debd4595a5
-- 
2.34.1



From quic_kangyang at quicinc.com  Fri Dec 13 01:39:08 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 17:39:08 +0800
Subject: [PATCH v4 1/2] wifi: ath11k: move update channel list from update reg worker to reg notifier
In-Reply-To: <20241213093909.629-1-quic_kangyang@quicinc.com>
References: <20241213093909.629-1-quic_kangyang@quicinc.com>
Message-ID: <20241213093909.629-2-quic_kangyang@quicinc.com>

From: Wen Gong <quic_wgong at quicinc.com>

Currently when ath11k gets new channel list, it will mainly do two things
in ath11k_regd_update():
1. update channel list to cfg80211 by reg_work.
2. update cfg80211's channel list to firmware by
ath11k_reg_update_chan_list().

Flow:
ath11k_regd_update
->regulatory_set_wiphy_regd
        -> schedule_work(&reg_work)
                ->reg_work->reg_process_self_managed_hint
                        ->handle_band_custom(update to cfg80211)
-> ath11k_reg_update_chan_list(update to firmware)

But ath11k_reg_update_chan_list() is immediately called after reg_work
is queued. They are running in different threads. At this time,
ath11k_reg_update_chan_list() may use a wrong channel list because
handle_band_custom() may not be finished.
This may result in out-of-bounds write errors:
BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list
Call Trace:
    ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]
    kfree+0x109/0x3a0
    ath11k_regd_update+0x1cf/0x350 [ath11k]
    ath11k_regd_update_work+0x14/0x20 [ath11k]
    process_one_work+0xe35/0x14c0

So should make sure ath11k_reg_update_chan_list() is called after
handle_band_custom() is finished.

reg_process_self_managed_hint() will call reg_call_notifier() after
handle_band_custom(). This function will call ath11k_reg_notifier(), so
move ath11k_reg_update_chan_list() to ath11k_reg_notifier(). Then
ath11k can update correct channel list to firmware.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

Fixes: f45cb6b29cd3 ("wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()")
Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
---
 drivers/net/wireless/ath/ath11k/reg.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index b0f289784dd3..cb2cf9b63d18 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -55,6 +55,19 @@ ath11k_reg_notifier(struct wiphy *wiphy, struct regulatory_request *request)
 	ath11k_dbg(ar->ab, ATH11K_DBG_REG,
 		   "Regulatory Notification received for %s\n", wiphy_name(wiphy));
 
+	if (request->initiator == NL80211_REGDOM_SET_BY_DRIVER) {
+		ath11k_dbg(ar->ab, ATH11K_DBG_REG,
+			   "driver initiated regd update\n");
+		if (ar->state != ATH11K_STATE_ON)
+			return;
+
+		ret = ath11k_reg_update_chan_list(ar, true);
+		if (ret)
+			ath11k_warn(ar->ab, "failed to update channel list: %d\n", ret);
+
+		return;
+	}
+
 	/* Currently supporting only General User Hints. Cell base user
 	 * hints to be handled later.
 	 * Hints from other sources like Core, Beacons are not expected for
@@ -293,12 +306,6 @@ int ath11k_regd_update(struct ath11k *ar)
 	if (ret)
 		goto err;
 
-	if (ar->state == ATH11K_STATE_ON) {
-		ret = ath11k_reg_update_chan_list(ar, true);
-		if (ret)
-			goto err;
-	}
-
 	return 0;
 err:
 	ath11k_warn(ab, "failed to perform regd update : %d\n", ret);
@@ -977,6 +984,7 @@ void ath11k_regd_update_work(struct work_struct *work)
 void ath11k_reg_init(struct ath11k *ar)
 {
 	ar->hw->wiphy->regulatory_flags = REGULATORY_WIPHY_SELF_MANAGED;
+	ar->hw->wiphy->flags |= WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER;
 	ar->hw->wiphy->reg_notifier = ath11k_reg_notifier;
 }
 
-- 
2.34.1



From quic_kangyang at quicinc.com  Fri Dec 13 01:39:09 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 17:39:09 +0800
Subject: [PATCH v4 2/2] wifi: ath11k: move update channel list to worker when wait flag is set
In-Reply-To: <20241213093909.629-1-quic_kangyang@quicinc.com>
References: <20241213093909.629-1-quic_kangyang@quicinc.com>
Message-ID: <20241213093909.629-3-quic_kangyang@quicinc.com>

From: Wen Gong <quic_wgong at quicinc.com>

With previous patch "wifi: ath11k: move update channel list from update
reg worker to reg notifier", ath11k_reg_update_chan_list() will be
called during reg_process_self_managed_hint().

reg_process_self_managed_hint() will hold rtnl_lock all the time.
But ath11k_reg_update_chan_list() may increase the occupation time of
rtnl_lock, because wait flag is set and wait_for_completion_timeout()
will be called when 11d/hw scan is running.

Should minimize the occupation time of rtnl_lock as much as possible.

Move update channel list operation to a new worker, so that
wait_for_completion_timeout() won't be called and will not increase the
occupation time of rtnl_lock.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
Co-developed-by: Kang Yang <quic_kangyang at quicinc.com>
Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
---
 drivers/net/wireless/ath/ath11k/core.c |  1 +
 drivers/net/wireless/ath/ath11k/core.h |  4 +-
 drivers/net/wireless/ath/ath11k/mac.c  | 14 +++++
 drivers/net/wireless/ath/ath11k/reg.c  | 87 +++++++++++++++++---------
 drivers/net/wireless/ath/ath11k/reg.h  |  1 +
 drivers/net/wireless/ath/ath11k/wmi.h  |  1 +
 6 files changed, 79 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index c576bbba52bf..e4db3cdecf29 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -2056,6 +2056,7 @@ void ath11k_core_halt(struct ath11k *ar)
 	ath11k_mac_scan_finish(ar);
 	ath11k_mac_peer_cleanup_all(ar);
 	cancel_delayed_work_sync(&ar->scan.timeout);
+	cancel_work_sync(&ar->channel_update_work);
 	cancel_work_sync(&ar->regd_update_work);
 	cancel_work_sync(&ab->update_11d_work);
 
diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
index a9dc7fe7765a..49c02cca501d 100644
--- a/drivers/net/wireless/ath/ath11k/core.h
+++ b/drivers/net/wireless/ath/ath11k/core.h
@@ -685,7 +685,7 @@ struct ath11k {
 	struct mutex conf_mutex;
 	/* protects the radio specific data like debug stats, ppdu_stats_info stats,
 	 * vdev_stop_status info, scan data, ath11k_sta info, ath11k_vif info,
-	 * channel context data, survey info, test mode data.
+	 * channel context data, survey info, test mode data, channel_update_queue.
 	 */
 	spinlock_t data_lock;
 
@@ -743,6 +743,8 @@ struct ath11k {
 	struct completion bss_survey_done;
 
 	struct work_struct regd_update_work;
+	struct work_struct channel_update_work;
+	struct list_head channel_update_queue;
 
 	struct work_struct wmi_mgmt_tx_work;
 	struct sk_buff_head wmi_mgmt_tx_queue;
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 31ae9b384a29..ec59ac829f79 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -6288,6 +6288,7 @@ static void ath11k_mac_op_stop(struct ieee80211_hw *hw, bool suspend)
 {
 	struct ath11k *ar = hw->priv;
 	struct htt_ppdu_stats_info *ppdu_stats, *tmp;
+	struct scan_chan_list_params *params;
 	int ret;
 
 	ath11k_mac_drain_tx(ar);
@@ -6303,6 +6304,7 @@ static void ath11k_mac_op_stop(struct ieee80211_hw *hw, bool suspend)
 	mutex_unlock(&ar->conf_mutex);
 
 	cancel_delayed_work_sync(&ar->scan.timeout);
+	cancel_work_sync(&ar->channel_update_work);
 	cancel_work_sync(&ar->regd_update_work);
 	cancel_work_sync(&ar->ab->update_11d_work);
 
@@ -6312,10 +6314,19 @@ static void ath11k_mac_op_stop(struct ieee80211_hw *hw, bool suspend)
 	}
 
 	spin_lock_bh(&ar->data_lock);
+
 	list_for_each_entry_safe(ppdu_stats, tmp, &ar->ppdu_stats_info, list) {
 		list_del(&ppdu_stats->list);
 		kfree(ppdu_stats);
 	}
+
+	while ((params = list_first_entry_or_null(&ar->channel_update_queue,
+						  struct scan_chan_list_params,
+						  list))) {
+		list_del(&params->list);
+		kfree(params);
+	}
+
 	spin_unlock_bh(&ar->data_lock);
 
 	rcu_assign_pointer(ar->ab->pdevs_active[ar->pdev_idx], NULL);
@@ -10018,6 +10029,7 @@ static const struct wiphy_iftype_ext_capab ath11k_iftypes_ext_capa[] = {
 
 static void __ath11k_mac_unregister(struct ath11k *ar)
 {
+	cancel_work_sync(&ar->channel_update_work);
 	cancel_work_sync(&ar->regd_update_work);
 
 	ieee80211_unregister_hw(ar->hw);
@@ -10417,6 +10429,8 @@ int ath11k_mac_allocate(struct ath11k_base *ab)
 		init_completion(&ar->thermal.wmi_sync);
 
 		INIT_DELAYED_WORK(&ar->scan.timeout, ath11k_scan_timeout_work);
+		INIT_WORK(&ar->channel_update_work, ath11k_regd_update_chan_list_work);
+		INIT_LIST_HEAD(&ar->channel_update_queue);
 		INIT_WORK(&ar->regd_update_work, ath11k_regd_update_work);
 
 		INIT_WORK(&ar->wmi_mgmt_tx_work, ath11k_mgmt_over_wmi_tx_work);
diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/ath/ath11k/reg.c
index cb2cf9b63d18..9f27860fd93e 100644
--- a/drivers/net/wireless/ath/ath11k/reg.c
+++ b/drivers/net/wireless/ath/ath11k/reg.c
@@ -124,32 +124,7 @@ int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait)
 	struct channel_param *ch;
 	enum nl80211_band band;
 	int num_channels = 0;
-	int i, ret, left;
-
-	if (wait && ar->state_11d != ATH11K_11D_IDLE) {
-		left = wait_for_completion_timeout(&ar->completed_11d_scan,
-						   ATH11K_SCAN_TIMEOUT_HZ);
-		if (!left) {
-			ath11k_dbg(ar->ab, ATH11K_DBG_REG,
-				   "failed to receive 11d scan complete: timed out\n");
-			ar->state_11d = ATH11K_11D_IDLE;
-		}
-		ath11k_dbg(ar->ab, ATH11K_DBG_REG,
-			   "11d scan wait left time %d\n", left);
-	}
-
-	if (wait &&
-	    (ar->scan.state == ATH11K_SCAN_STARTING ||
-	    ar->scan.state == ATH11K_SCAN_RUNNING)) {
-		left = wait_for_completion_timeout(&ar->scan.completed,
-						   ATH11K_SCAN_TIMEOUT_HZ);
-		if (!left)
-			ath11k_dbg(ar->ab, ATH11K_DBG_REG,
-				   "failed to receive hw scan complete: timed out\n");
-
-		ath11k_dbg(ar->ab, ATH11K_DBG_REG,
-			   "hw scan wait left time %d\n", left);
-	}
+	int i, ret = 0;
 
 	if (ar->state == ATH11K_STATE_RESTARTING)
 		return 0;
@@ -231,8 +206,16 @@ int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait)
 		}
 	}
 
-	ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
-	kfree(params);
+	if (wait) {
+		spin_lock_bh(&ar->data_lock);
+		list_add_tail(&params->list, &ar->channel_update_queue);
+		spin_unlock_bh(&ar->data_lock);
+
+		queue_work(ar->ab->workqueue, &ar->channel_update_work);
+	} else {
+		ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
+		kfree(params);
+	}
 
 	return ret;
 }
@@ -811,6 +794,54 @@ ath11k_reg_build_regd(struct ath11k_base *ab,
 	return new_regd;
 }
 
+void ath11k_regd_update_chan_list_work(struct work_struct *work)
+{
+	struct ath11k *ar = container_of(work, struct ath11k,
+					 channel_update_work);
+	struct scan_chan_list_params *params;
+	struct list_head local_update_list;
+	int left;
+
+	INIT_LIST_HEAD(&local_update_list);
+
+	spin_lock_bh(&ar->data_lock);
+	list_splice_tail_init(&ar->channel_update_queue, &local_update_list);
+	spin_unlock_bh(&ar->data_lock);
+
+	while ((params = list_first_entry_or_null(&local_update_list,
+						  struct scan_chan_list_params,
+						  list))) {
+		if (ar->state_11d != ATH11K_11D_IDLE) {
+			left = wait_for_completion_timeout(&ar->completed_11d_scan,
+							   ATH11K_SCAN_TIMEOUT_HZ);
+			if (!left) {
+				ath11k_dbg(ar->ab, ATH11K_DBG_REG,
+					   "failed to receive 11d scan complete: timed out\n");
+				ar->state_11d = ATH11K_11D_IDLE;
+			}
+
+			ath11k_dbg(ar->ab, ATH11K_DBG_REG,
+				   "reg 11d scan wait left time %d\n", left);
+		}
+
+		if ((ar->scan.state == ATH11K_SCAN_STARTING ||
+		     ar->scan.state == ATH11K_SCAN_RUNNING)) {
+			left = wait_for_completion_timeout(&ar->scan.completed,
+							   ATH11K_SCAN_TIMEOUT_HZ);
+			if (!left)
+				ath11k_dbg(ar->ab, ATH11K_DBG_REG,
+					   "failed to receive hw scan complete: timed out\n");
+
+			ath11k_dbg(ar->ab, ATH11K_DBG_REG,
+				   "reg hw scan wait left time %d\n", left);
+		}
+
+		ath11k_wmi_send_scan_chan_list_cmd(ar, params);
+		list_del(&params->list);
+		kfree(params);
+	}
+}
+
 static bool ath11k_reg_is_world_alpha(char *alpha)
 {
 	if (alpha[0] == '0' && alpha[1] == '0')
diff --git a/drivers/net/wireless/ath/ath11k/reg.h b/drivers/net/wireless/ath/ath11k/reg.h
index 263ea9061948..0d5e10bb5730 100644
--- a/drivers/net/wireless/ath/ath11k/reg.h
+++ b/drivers/net/wireless/ath/ath11k/reg.h
@@ -33,6 +33,7 @@ void ath11k_reg_init(struct ath11k *ar);
 void ath11k_reg_reset_info(struct cur_regulatory_info *reg_info);
 void ath11k_reg_free(struct ath11k_base *ab);
 void ath11k_regd_update_work(struct work_struct *work);
+void ath11k_regd_update_chan_list_work(struct work_struct *work);
 struct ieee80211_regdomain *
 ath11k_reg_build_regd(struct ath11k_base *ab,
 		      struct cur_regulatory_info *reg_info, bool intersect,
diff --git a/drivers/net/wireless/ath/ath11k/wmi.h b/drivers/net/wireless/ath/ath11k/wmi.h
index 8982b909c821..30b4b0c17682 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.h
+++ b/drivers/net/wireless/ath/ath11k/wmi.h
@@ -3817,6 +3817,7 @@ struct wmi_stop_scan_cmd {
 };
 
 struct scan_chan_list_params {
+	struct list_head list;
 	u32 pdev_id;
 	u16 nallchans;
 	struct channel_param ch_param[];
-- 
2.34.1



From quic_kangyang at quicinc.com  Fri Dec 13 01:41:41 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Fri, 13 Dec 2024 17:41:41 +0800
Subject: [PATCH v3 2/2] wifi: ath11k: add srng->lock for ath11k_hal_srng_*
 in monitor mode
In-Reply-To: <79910df2-a7fd-4880-bd32-4f2927341654@quicinc.com>
References: <20241008053744.1070-1-quic_kangyang@quicinc.com>
 <20241008053744.1070-3-quic_kangyang@quicinc.com> <87ttb9nea6.fsf@kernel.org>
 <79910df2-a7fd-4880-bd32-4f2927341654@quicinc.com>
Message-ID: <e0d2d1ce-0443-4eea-b3c3-ed7423875d11@quicinc.com>



On 12/13/2024 2:17 PM, Kang Yang wrote:
> 
> 
> On 12/12/2024 10:53 PM, Kalle Valo wrote:
>> Kang Yang <quic_kangyang at quicinc.com> writes:
>>
>>> ath11k_hal_srng_* should be used with srng->lock to protect srng data.
>>>
>>> For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
>>> they use ath11k_hal_srng_* for many times but never call srng->lock.
>>>
>>> So when running (full) monitor mode, warning will occur:
>>> RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
>>> Call Trace:
>>> ? ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
>>> ? ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
>>> ? ? idr_alloc_u32+0x97/0xd0
>>> ? ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
>>> ? ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
>>> ? ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
>>> ? __napi_poll+0x30/0x1f0
>>> ? net_rx_action+0x198/0x320
>>> ? __do_softirq+0xdd/0x319
>>>
>>> So add srng->lock for them to avoid such warnings.
>>>
>>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125- 
>>> QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
>>> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
>>>
>>> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax 
>>> devices")
>>> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
>>
>> [...]
>>
>>> @@ -5607,7 +5609,7 @@ static int ath11k_dp_full_mon_process_rx(struct 
>>> ath11k_base *ab, int mac_id,
>>> ????? struct hal_sw_mon_ring_entries *sw_mon_entries;
>>> ????? struct ath11k_pdev_mon_stats *rx_mon_stats;
>>> ????? struct sk_buff *head_msdu, *tail_msdu;
>>> -??? void *mon_dst_srng = &ar->ab->hal.srng_list[dp- 
>>> >rxdma_mon_dst_ring.ring_id];
>>> +??? struct hal_srng *mon_dst_srng;
>>> ????? void *ring_entry;
>>> ????? u32 rx_bufs_used = 0, mpdu_rx_bufs_used;
>>> ????? int quota = 0, ret;
>>> @@ -5623,6 +5625,9 @@ static int ath11k_dp_full_mon_process_rx(struct 
>>> ath11k_base *ab, int mac_id,
>>> ????????? goto reap_status_ring;
>>> ????? }
>>> +??? mon_dst_srng = &ar->ab->hal.srng_list[dp- 
>>> >rxdma_mon_dst_ring.ring_id];
>>> +??? spin_lock_bh(&mon_dst_srng->lock);
>>
>> Why initialise mon_dst_srng differently? The commit message mentions
>> nothing about this change.
> 
> 
> Because need to fetch spin lock inside 'struct hal_srng'. If still use 
> 'void *mon_dst_srng', need to perform a variable type cast.
> 
> Bur 'struct hal_srng' will make this line too long:
> 'struct hal_srng *mon_dst_srng = &ar->ab->hal.srng_list[dp- 
>  >rxdma_mon_dst_ring.ring_id];'
> So I separated the definition and initialization.
> 
> ath11k_dp_rx_reap_mon_status_ring()/ath11k_dp_process_rx and others ring 
> process function is the same.
> 

Do i need to send a new version for this?

> 
> 
>>
> 
> 



From patchwork-bot+netdevbpf at kernel.org  Sun Dec 15 14:20:27 2024
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Sun, 15 Dec 2024 22:20:27 +0000
Subject: [PATCH net-next v4 0/2] Converge on using secs_to_jiffies() in netdev
In-Reply-To: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
References: <20241212-netdev-converge-secs-to-jiffies-v4-0-6dac97a6d6ab@linux.microsoft.com>
Message-ID: <173430122779.3593151.18169196230893738996.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba at kernel.org>:

On Thu, 12 Dec 2024 17:33:00 +0000 you wrote:
> These patches are pulled out from v2 [1] and v3 [2] of my series to be sent
> through netdev. The series converts users of msecs_to_jiffies() that need
> seconds-denominated timeouts to the new secs_to_jiffies() API in
> include/linux/jiffies.h to avoid the multiplication with 1000 or MSEC_PER_SEC.
> 
> [1]: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v2-0-911fb7595e79 at linux.microsoft.com
> [2]: https://lore.kernel.org/r/20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a at linux.microsoft.com
> 
> [...]

Here is the summary with links:
  - [net-next,v4,1/2] gve: Convert timeouts to secs_to_jiffies()
    https://git.kernel.org/netdev/net-next/c/734ff310d38c
  - [net-next,v4,2/2] wifi: ath11k: Convert timeouts to secs_to_jiffies()
    (no matching commit)

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




From Frank.Lindner at ghmt.de  Tue Dec 17 04:48:48 2024
From: Frank.Lindner at ghmt.de (Lindner, Frank)
Date: Tue, 17 Dec 2024 12:48:48 +0000
Subject: How to use multiple QCN9074?
Message-ID: <FRYP281MB01600E9F9FCC94C621530791EB042@FRYP281MB0160.DEUP281.PROD.OUTLOOK.COM>

Hi folks,

i'm trying to get up 2 devices with QCN9074.
With a single card connected, this one device gets up and is running, but with 2 cards connected, none is shown as wifi adapter.
My drivers are build from ath-next tree.

Dmesg:
[Tue Dec 17 12:40:58 2024] pcieport 0000:0a:00.0: enabling device (0006 -> 0007)
[Tue Dec 17 12:40:58 2024] pcieport 0000:0b:04.0: enabling device (0006 -> 0007)
[Tue Dec 17 12:40:58 2024] ath11k_pci 0000:0d:00.0: BAR 0 [mem 0xac000000-0xac1fffff 64bit]: assigned
[Tue Dec 17 12:40:58 2024] ath11k_pci 0000:0d:00.0: MSI vectors: 16
[Tue Dec 17 12:40:58 2024] ath11k_pci 0000:0d:00.0: qcn9074 hw1.0
[Tue Dec 17 12:40:58 2024] mhi mhi0: Requested to power ON
[Tue Dec 17 12:40:58 2024] mhi mhi0: Power on setup success
[Tue Dec 17 12:40:59 2024] mhi mhi0: Wait for device to enter SBL or Mission mode
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: BAR 0 [mem 0xac400000-0xac5fffff 64bit]: assigned
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: MSI vectors: 16
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: qcn9074 hw1.0
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: host capability request failed: 1 90
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: failed to send qmi host cap: -22
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[Tue Dec 17 12:40:59 2024] ath11k_pci 0000:0f:00.0: fw_version 0x290b8862 fw_build_timestamp 2024-09-23 10:51 fw_build_id
[Tue Dec 17 12:40:59 2024] mhi mhi1: Requested to power ON
[Tue Dec 17 12:40:59 2024] mhi mhi1: Power on setup success
[Tue Dec 17 12:40:59 2024] mhi mhi1: Wait for device to enter SBL or Mission mode
[Tue Dec 17 12:41:00 2024] ath11k_pci 0000:0d:00.0: host capability request failed: 1 90
[Tue Dec 17 12:41:00 2024] ath11k_pci 0000:0d:00.0: failed to send qmi host cap: -22
[Tue Dec 17 12:41:00 2024] ath11k_pci 0000:0f:00.0: host capability request failed: 1 90
[Tue Dec 17 12:41:00 2024] ath11k_pci 0000:0f:00.0: failed to send qmi host cap: -22

Uname:
Linux nuc 6.12.3-061203-generic #202412060638 SMP PREEMPT_DYNAMIC Fri Dec  6 07:08:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
(Ubuntu 24.04)

Modinfo ath11k_pci:
filename:       /lib/modules/6.12.3-061203-generic/kernel/drivers/net/wireless/ath/ath11k/ath11k_pci.ko.zst
firmware:       ath11k/WCN6855/hw2.1/*
firmware:       ath11k/WCN6855/hw2.0/*
firmware:       ath11k/QCN9074/hw1.0/*
firmware:       ath11k/QCA6390/hw2.0/*
license:        Dual BSD/GPL
description:    Driver support for Qualcomm Technologies PCIe 802.11ax WLAN devices
srcversion:     6E2D53252E37DF43248F551
alias:          pci:v000017CBd00001104sv*sd*bc*sc*i*
alias:          pci:v000017CBd00001103sv*sd*bc*sc*i*
alias:          pci:v000017CBd00001101sv*sd*bc*sc*i*
depends:        ath11k,mhi
intree:         Y
name:           ath11k_pci
retpoline:      Y
vermagic:       6.12.3-061203-generic SMP preempt mod_unload modversions
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        10:57:55:01:8C:2D:86:E0:7B:95:74:DC:B7:D0:38:47:F1:CC:B6:58
sig_hashalgo:   sha512
signature:      49:17:62:BC:39:9D:E3:0C:A2:3B:4F:A6:C3:C4:6B:E9:9A:C1:09:6B:
                59:9F:AD:0B:BC:43:B0:A3:13:CA:03:DC:D9:64:76:F8:F0:C2:BE:2D:
                2A:C0:9B:F5:2D:B1:62:51:1E:C3:14:AF:94:66:FB:6B:50:C4:64:BB:
                4E:D6:BE:07:23:8C:62:8E:53:C1:56:E0:43:5E:F8:B0:63:D0:AD:B1:
                F2:42:A4:BC:E2:61:11:C0:0B:A2:81:B8:AE:A5:CB:B0:39:AE:14:8E:
                D0:97:0C:AB:6D:81:64:0E:C6:3E:99:FA:39:62:E4:11:8C:E0:29:F5:
                72:CF:CC:18:FF:84:07:38:3A:2F:66:61:E9:81:EC:C9:00:2D:42:AF:
                C4:E0:86:3F:DE:22:B5:99:72:36:55:45:98:0A:64:C5:EA:C4:1F:AD:
                40:1D:21:35:FA:2A:8A:9F:C7:3E:31:D0:E7:C8:C4:3C:6A:0F:B3:86:
                0C:77:EB:4F:DC:E5:64:FC:A1:F2:01:CB:53:59:E7:A5:23:7E:44:B9:
                DA:10:7B:38:D1:1F:19:26:04:39:6D:55:2D:5C:70:C3:60:01:BC:36:
                BC:E7:13:B9:27:0F:68:7A:95:4B:4E:AA:FE:1D:71:E3:87:C6:01:CE:
                87:28:B7:24:64:B7:E5:09:A1:09:47:C2:E9:95:B8:64:3A:71:65:3C:
                66:64:CC:7F:46:2D:06:32:6C:19:46:5D:F5:D5:F3:53:0D:91:99:C4:
                41:79:C9:AE:7B:17:08:DA:FE:E7:0F:5E:19:B4:3E:5F:A2:1D:C3:B4:
                E9:64:44:91:B6:8D:51:53:93:49:A3:39:F6:3D:9E:3F:1F:1A:C5:B7:
                25:21:E2:33:2B:81:E9:6A:DB:F8:C3:2E:41:FF:81:A2:58:47:E6:49:
                18:EA:4F:3C:06:1B:04:11:95:23:49:45:5E:89:5E:FB:B3:D6:88:B2:
                C0:B3:19:4F:C5:EE:BE:B0:3B:B9:30:83:B9:8D:DC:BF:55:19:73:AC:
                1E:CA:35:C7:B3:96:24:19:54:AC:FD:FA:CD:8F:49:4C:21:B1:53:C9:
                0E:A4:B4:0D:59:7A:DC:5B:6B:92:DC:B4:1F:B5:3E:A6:8E:90:D0:42:
                E0:E3:90:A2:36:E5:0D:D8:56:BB:5C:D6:20:DA:E5:4B:6B:C7:8B:8A:
                3C:A4:A3:8F:C3:70:94:BE:2F:E5:E8:3D:41:A1:42:A4:90:9C:AB:49:
                EC:BD:81:82:2B:9B:47:42:50:9C:25:2A:DE:90:3A:E2:79:A2:66:90:
                BA:E3:22:B7:B1:63:D9:6F:5C:84:C2:65:3F:37:C4:91:B3:B6:0B:02:
                A4:1C:1E:76:3D:72:85:93:27:9B:B2:8B

Modinfo ath11k:
filename:       /lib/modules/6.12.3-061203-generic/kernel/drivers/net/wireless/ath/ath11k/ath11k.ko.zst
license:        Dual BSD/GPL
description:    Core module for Qualcomm Atheros 802.11ax wireless LAN cards.
srcversion:     A5E23FEC04DDEFB64F17AB0
depends:        mac80211,cfg80211,qmi_helpers
intree:         Y
name:           ath11k
retpoline:      Y
vermagic:       6.12.3-061203-generic SMP preempt mod_unload modversions
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        10:57:55:01:8C:2D:86:E0:7B:95:74:DC:B7:D0:38:47:F1:CC:B6:58
sig_hashalgo:   sha512
signature:      86:2A:52:02:9B:C8:FE:ED:F1:E2:58:9C:A3:F1:92:A0:D4:75:4F:1C:
                3C:D5:D7:CF:41:A6:70:00:98:DB:4A:75:79:46:CE:C6:44:7A:65:82:
                40:DC:01:FF:28:E3:98:98:7C:67:01:31:B2:DD:06:07:76:0E:B5:17:
                6F:27:E2:B2:95:AF:A6:0E:68:CE:BB:18:D1:F7:F6:AA:48:E2:ED:86:
                74:F1:A8:3E:A3:95:96:D7:08:9C:87:C7:C6:A0:60:13:BA:F9:D9:C4:
                3F:37:99:59:A1:C1:B5:F0:C3:39:09:75:91:D6:7A:C5:CC:7C:98:AE:
                00:D3:28:48:3B:55:3C:F6:CF:FE:1E:AF:1E:4D:F8:35:53:80:C8:0D:
                D4:B6:C0:42:0E:0C:9C:7E:E2:BF:8D:49:8D:9E:F5:37:EA:2B:29:67:
                F1:1F:DB:56:C2:39:99:F1:F1:60:90:3C:32:7D:C7:87:E4:AE:99:22:
                9B:B1:2D:1B:9B:22:2B:D8:68:0A:4F:C0:A8:0F:41:58:66:65:25:55:
                D6:8B:FA:8C:CF:C7:2B:4D:92:3B:1D:6F:19:F8:52:A5:4C:1D:25:B6:
                EA:D6:A5:23:A3:B5:77:15:3D:D2:B1:EF:FB:12:B8:B7:C9:9F:D2:29:
                47:A0:64:7E:03:E6:F2:BE:11:0A:F3:72:27:36:AF:2E:64:F9:1A:B4:
                46:BD:14:B7:33:43:13:5B:55:A9:A3:06:DE:1F:4D:E7:A0:54:C7:8B:
                71:6D:35:62:2A:07:4C:4F:FD:FA:E7:77:1B:AF:6F:49:3E:01:11:D6:
                A7:4A:6E:B6:7E:DA:D8:DA:5E:51:63:45:86:D5:12:ED:96:EB:06:0A:
                EA:59:42:52:F5:74:33:2E:DA:1F:3D:C0:68:4E:15:FB:CE:F9:C7:79:
                41:D5:B7:ED:AC:76:42:4B:78:90:62:E5:57:5B:84:3F:9F:17:59:90:
                C7:C6:7D:DC:50:C3:29:32:00:C3:5B:24:9E:A5:81:53:9D:6B:BE:EF:
                50:E7:D9:E5:91:64:DC:E8:8B:17:E5:A7:3F:D3:28:39:A8:F2:49:32:
                5E:D9:CC:1E:86:13:81:9B:6F:C0:6B:AF:74:0F:07:6E:D9:BF:71:4A:
                FA:84:02:3F:A8:9D:37:D1:7F:50:51:3A:1A:C4:1B:4E:BB:77:89:D0:
                79:96:1F:E5:2B:13:C4:7E:20:7E:80:21:D9:B0:D8:08:8D:6B:56:AB:
                DD:EC:C0:B8:17:A2:58:F1:75:2B:84:A2:AD:ED:76:CE:58:EF:6C:B0:
                DB:5C:39:27:23:82:E1:9D:D1:42:5E:2F:82:64:97:5A:CA:5D:6D:7B:
                B0:B8:C3:AF:E2:3A:77:CC:06:EB:97:2D
parm:           cold_boot_cal:Decrease the channel switch time but increase the driver load time (Default: true) (bool)
parm:           debug_mask:Debugging mask (uint)
parm:           crypto_mode:crypto mode: 0-hardware, 1-software (uint)
parm:           frame_mode:Datapath frame mode (0: raw, 1: native wifi (default), 2: ethernet) (uint)
parm:           ftm_mode:Boots up in factory test mode (bool)

TIA
BR Frank


Vorstand: Dirk Wilhelm (V), Wulf Jannsen
Aufsichtsrat: Ron Scheepers (V)
Handelsregister: HRB Saarbr?cken Nr. 13201
Ust.ID Nr.: DE 153807627

From kvalo at kernel.org  Tue Dec 17 05:50:24 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Tue, 17 Dec 2024 15:50:24 +0200
Subject: [PATCH v3 2/2] wifi: ath11k: add srng->lock for
 ath11k_hal_srng_* in monitor mode
In-Reply-To: <e0d2d1ce-0443-4eea-b3c3-ed7423875d11@quicinc.com> (Kang Yang's
	message of "Fri, 13 Dec 2024 17:41:41 +0800")
References: <20241008053744.1070-1-quic_kangyang@quicinc.com>
	<20241008053744.1070-3-quic_kangyang@quicinc.com>
	<87ttb9nea6.fsf@kernel.org>
	<79910df2-a7fd-4880-bd32-4f2927341654@quicinc.com>
	<e0d2d1ce-0443-4eea-b3c3-ed7423875d11@quicinc.com>
Message-ID: <87a5cus9jz.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

>>>> @@ -5623,6 +5625,9 @@ static int
>>>> ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
>>>> ????????? goto reap_status_ring;
>>>> ????? }
>>>> +??? mon_dst_srng = &ar->ab->hal.srng_list[dp-
>>>> >rxdma_mon_dst_ring.ring_id];
>>>> +??? spin_lock_bh(&mon_dst_srng->lock);
>>>
>>> Why initialise mon_dst_srng differently? The commit message mentions
>>> nothing about this change.
>> Because need to fetch spin lock inside 'struct hal_srng'. If still
>> use 'void *mon_dst_srng', need to perform a variable type cast.
>> Bur 'struct hal_srng' will make this line too long:
>> 'struct hal_srng *mon_dst_srng = &ar->ab->hal.srng_list[dp-
>> >rxdma_mon_dst_ring.ring_id];'
>> So I separated the definition and initialization.
>> ath11k_dp_rx_reap_mon_status_ring()/ath11k_dp_process_rx and others
>> ring process function is the same.
>> 
>
> Do i need to send a new version for this?

Yeah, please mention in the commit message why you mon_dst_srng
initialisation.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Tue Dec 17 06:46:00 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Tue, 17 Dec 2024 16:46:00 +0200
Subject: [PATCH v4 1/2] wifi: ath11k: move update channel list from
 update reg worker to reg notifier
In-Reply-To: <20241213093909.629-2-quic_kangyang@quicinc.com> (Kang Yang's
	message of "Fri, 13 Dec 2024 17:39:08 +0800")
References: <20241213093909.629-1-quic_kangyang@quicinc.com>
	<20241213093909.629-2-quic_kangyang@quicinc.com>
Message-ID: <87frmmmkpj.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

> From: Wen Gong <quic_wgong at quicinc.com>
>
> Currently when ath11k gets new channel list, it will mainly do two things
> in ath11k_regd_update():
> 1. update channel list to cfg80211 by reg_work.
> 2. update cfg80211's channel list to firmware by
> ath11k_reg_update_chan_list().
>
> Flow:
> ath11k_regd_update
> ->regulatory_set_wiphy_regd
>         -> schedule_work(&reg_work)
>                 ->reg_work->reg_process_self_managed_hint
>                         ->handle_band_custom(update to cfg80211)
> -> ath11k_reg_update_chan_list(update to firmware)
>
> But ath11k_reg_update_chan_list() is immediately called after reg_work
> is queued. They are running in different threads. At this time,
> ath11k_reg_update_chan_list() may use a wrong channel list because
> handle_band_custom() may not be finished.
> This may result in out-of-bounds write errors:
> BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list
> Call Trace:
>     ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]
>     kfree+0x109/0x3a0
>     ath11k_regd_update+0x1cf/0x350 [ath11k]
>     ath11k_regd_update_work+0x14/0x20 [ath11k]
>     process_one_work+0xe35/0x14c0
>
> So should make sure ath11k_reg_update_chan_list() is called after
> handle_band_custom() is finished.
>
> reg_process_self_managed_hint() will call reg_call_notifier() after
> handle_band_custom(). This function will call ath11k_reg_notifier(), so
> move ath11k_reg_update_chan_list() to ath11k_reg_notifier(). Then
> ath11k can update correct channel list to firmware.
>
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
>
> Fixes: f45cb6b29cd3 ("wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()")
> Signed-off-by: Wen Gong <quic_wgong at quicinc.com>
> Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>

I think the commit message should be completely rewritten, the idea here
is not to list functions and their call orders.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at kernel.org  Tue Dec 17 06:53:11 2024
From: kvalo at kernel.org (Kalle Valo)
Date: Tue, 17 Dec 2024 16:53:11 +0200
Subject: [PATCH v4 2/2] wifi: ath11k: move update channel list to worker
 when wait flag is set
In-Reply-To: <20241213093909.629-3-quic_kangyang@quicinc.com> (Kang Yang's
	message of "Fri, 13 Dec 2024 17:39:09 +0800")
References: <20241213093909.629-1-quic_kangyang@quicinc.com>
	<20241213093909.629-3-quic_kangyang@quicinc.com>
Message-ID: <87bjxamkdk.fsf@kernel.org>

Kang Yang <quic_kangyang at quicinc.com> writes:

> From: Wen Gong <quic_wgong at quicinc.com>
>
> With previous patch "wifi: ath11k: move update channel list from update
> reg worker to reg notifier", ath11k_reg_update_chan_list() will be
> called during reg_process_self_managed_hint().
>
> reg_process_self_managed_hint() will hold rtnl_lock all the time.
> But ath11k_reg_update_chan_list() may increase the occupation time of
> rtnl_lock, because wait flag is set and wait_for_completion_timeout()
> will be called when 11d/hw scan is running.
>
> Should minimize the occupation time of rtnl_lock as much as possible.
>
> Move update channel list operation to a new worker, so that
> wait_for_completion_timeout() won't be called and will not increase the
> occupation time of rtnl_lock.

Maybe the last two paragraphs could be merged (and edited) like this:

We should minimize the occupation time of rtnl_lock as much as possible
to avoid interfering with rest of the system. So move the update channel
list operation to a new worker, so that wait_for_completion_timeout()
won't be called and will not increase the occupation time of rtnl_lock.

> --- a/drivers/net/wireless/ath/ath11k/core.h
> +++ b/drivers/net/wireless/ath/ath11k/core.h
> @@ -685,7 +685,7 @@ struct ath11k {
>  	struct mutex conf_mutex;
>  	/* protects the radio specific data like debug stats, ppdu_stats_info stats,
>  	 * vdev_stop_status info, scan data, ath11k_sta info, ath11k_vif info,
> -	 * channel context data, survey info, test mode data.
> +	 * channel context data, survey info, test mode data, channel_update_queue.
>  	 */
>  	spinlock_t data_lock;

Usually is best to add a comment the data you are protecting, in this
case the new fields in struct ath11k.

> @@ -743,6 +743,8 @@ struct ath11k {
>  	struct completion bss_survey_done;
>  
>  	struct work_struct regd_update_work;
> +	struct work_struct channel_update_work;
> +	struct list_head channel_update_queue;

So here add '/* protected with data_lock */' or similar before channel_update_queue.

> @@ -231,8 +206,16 @@ int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait)
>  		}
>  	}
>  
> -	ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
> -	kfree(params);
> +	if (wait) {
> +		spin_lock_bh(&ar->data_lock);
> +		list_add_tail(&params->list, &ar->channel_update_queue);
> +		spin_unlock_bh(&ar->data_lock);
> +
> +		queue_work(ar->ab->workqueue, &ar->channel_update_work);
> +	} else {
> +		ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
> +		kfree(params);
> +	}

You can avoid the else branch like this:

if (wait) {
	spin_lock_bh(&ar->data_lock);
	list_add_tail(&params->list, &ar->channel_update_queue);
	spin_unlock_bh(&ar->data_lock);

	queue_work(ar->ab->workqueue, &ar->channel_update_work);

        return 0;
}

ret = ath11k_wmi_send_scan_chan_list_cmd(ar, params);
kfree(params);

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From agordeev at linux.ibm.com  Tue Dec 17 09:28:57 2024
From: agordeev at linux.ibm.com (Alexander Gordeev)
Date: Tue, 17 Dec 2024 18:28:57 +0100
Subject: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <Z2G02RN7VelcrjNT@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>

On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:

Hi Easwar,

> This script finds and suggests conversions of timeout patterns that
> result in seconds-denominated timeouts to use the new secs_to_jiffies()
> API in include/linux/jiffies.h for better readability.
> 
> Suggested-by: Anna-Maria Behnsen <anna-maria at linutronix.de>
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> ---
>  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> new file mode 100644
> index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
> --- /dev/null
> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +///
> +/// Find usages of:
> +/// - msecs_to_jiffies(value*1000)
> +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
> +///
> +// Confidence: High
> +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
> +// Keywords: secs, seconds, jiffies
> +//
> +
> +virtual patch
> +
> + at depends on patch@ constant C; @@
> +
> +- msecs_to_jiffies(C * 1000)
> ++ secs_to_jiffies(C)
> +
> + at depends on patch@ constant C; @@
> +
> +- msecs_to_jiffies(C * MSEC_PER_SEC)
> ++ secs_to_jiffies(C)

If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207

	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));

Thanks!


From agordeev at linux.ibm.com  Tue Dec 17 09:31:16 2024
From: agordeev at linux.ibm.com (Alexander Gordeev)
Date: Tue, 17 Dec 2024 18:31:16 +0100
Subject: [PATCH v3 04/19] s390: kernel: Convert timeouts to use
 secs_to_jiffies()
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>
Message-ID: <Z2G1ZPL2cAlQOYlF@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>

On Tue, Dec 10, 2024 at 10:02:35PM +0000, Easwar Hariharan wrote:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the values here are a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> ---
>  arch/s390/kernel/lgr.c      | 2 +-
>  arch/s390/kernel/time.c     | 4 ++--
>  arch/s390/kernel/topology.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/s390/kernel/lgr.c b/arch/s390/kernel/lgr.c
> index 6652e54cf3db9fbdd8cfb06f8a0dc1d4c05ae7d7..6d1ffca5f798086160112990cb947ec8deed0659 100644
> --- a/arch/s390/kernel/lgr.c
> +++ b/arch/s390/kernel/lgr.c
> @@ -166,7 +166,7 @@ static struct timer_list lgr_timer;
>   */
>  static void lgr_timer_set(void)
>  {
> -	mod_timer(&lgr_timer, jiffies + msecs_to_jiffies(LGR_TIMER_INTERVAL_SECS * MSEC_PER_SEC));
> +	mod_timer(&lgr_timer, jiffies + secs_to_jiffies(LGR_TIMER_INTERVAL_SECS));
>  }
>  
>  /*
> diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
> index 34a65c141ea076ba97b3238f1f36f077b15961df..e9f47c3a61978a45c72aee23bc44dcb128113c8c 100644
> --- a/arch/s390/kernel/time.c
> +++ b/arch/s390/kernel/time.c
> @@ -662,12 +662,12 @@ static void stp_check_leap(void)
>  		if (ret < 0)
>  			pr_err("failed to set leap second flags\n");
>  		/* arm Timer to clear leap second flags */
> -		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(14400 * MSEC_PER_SEC));
> +		mod_timer(&stp_timer, jiffies + secs_to_jiffies(14400));
>  	} else {
>  		/* The day the leap second is scheduled for hasn't been reached. Retry
>  		 * in one hour.
>  		 */
> -		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(3600 * MSEC_PER_SEC));
> +		mod_timer(&stp_timer, jiffies + secs_to_jiffies(3600));
>  	}
>  }
>  
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 4f9c301a705b63f8dd0e7bc33e7206ad1222e7a7..0fd56a1cadbd4f41a9876a3a3fec7f5dc08ac2db 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -371,7 +371,7 @@ static void set_topology_timer(void)
>  	if (atomic_add_unless(&topology_poll, -1, 0))
>  		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(100));
>  	else
> -		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(60 * MSEC_PER_SEC));
> +		mod_timer(&topology_timer, jiffies + secs_to_jiffies(60));
>  }
>  
>  void topology_expect_change(void)

With this chunk added to the patch:

diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index d01724a715d0..7bf0f691827b 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -204,7 +204,7 @@ static void cmm_set_timer(void)
 			del_timer(&cmm_timer);
 		return;
 	}
-	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));
+	mod_timer(&cmm_timer, jiffies + secs_to_jiffies(cmm_timeout_seconds));
 }
 
 static void cmm_timer_fn(struct timer_list *unused)


Acked-by: Alexander Gordeev <agordeev at linux.ibm.com>


From julia.lawall at inria.fr  Tue Dec 17 09:33:18 2024
From: julia.lawall at inria.fr (Julia Lawall)
Date: Tue, 17 Dec 2024 18:33:18 +0100 (CET)
Subject: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
In-Reply-To: <Z2G02RN7VelcrjNT@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com> <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com> <Z2G02RN7VelcrjNT@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
Message-ID: <alpine.DEB.2.22.394.2412171831300.3566@hadrien>



On Tue, 17 Dec 2024, Alexander Gordeev wrote:

> On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:
>
> Hi Easwar,
>
> > This script finds and suggests conversions of timeout patterns that
> > result in seconds-denominated timeouts to use the new secs_to_jiffies()
> > API in include/linux/jiffies.h for better readability.
> >
> > Suggested-by: Anna-Maria Behnsen <anna-maria at linutronix.de>
> > Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
> > ---
> >  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
> > --- /dev/null
> > +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> > @@ -0,0 +1,22 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +///
> > +/// Find usages of:
> > +/// - msecs_to_jiffies(value*1000)
> > +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
> > +///
> > +// Confidence: High
> > +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
> > +// Keywords: secs, seconds, jiffies
> > +//
> > +
> > +virtual patch
> > +
> > + at depends on patch@ constant C; @@
> > +
> > +- msecs_to_jiffies(C * 1000)
> > ++ secs_to_jiffies(C)
> > +
> > + at depends on patch@ constant C; @@
> > +
> > +- msecs_to_jiffies(C * MSEC_PER_SEC)
> > ++ secs_to_jiffies(C)
>
> If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207
>
> 	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));

There is the requirement that C is a constant, and cmm_timeout_seconds is
not considered to be a constant, ie it is not all capital letters.
Indeed, it doesn't seem to be a constant at all.  I don't know if the
requirement of being a comstant is really necessary.

julia

>
> Thanks!
>


From eahariha at linux.microsoft.com  Tue Dec 17 09:43:31 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 17 Dec 2024 09:43:31 -0800
Subject: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
In-Reply-To: <alpine.DEB.2.22.394.2412171831300.3566@hadrien>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
 <Z2G02RN7VelcrjNT@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
 <alpine.DEB.2.22.394.2412171831300.3566@hadrien>
Message-ID: <f3f9a686-8be3-49f0-bcfb-10b864fa5a11@linux.microsoft.com>

On 12/17/2024 9:33 AM, Julia Lawall wrote:
> 
> 
> On Tue, 17 Dec 2024, Alexander Gordeev wrote:
> 
>> On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:
>>
>> Hi Easwar,
>>
>>> This script finds and suggests conversions of timeout patterns that
>>> result in seconds-denominated timeouts to use the new secs_to_jiffies()
>>> API in include/linux/jiffies.h for better readability.
>>>
>>> Suggested-by: Anna-Maria Behnsen <anna-maria at linutronix.de>
>>> Signed-off-by: Easwar Hariharan <eahariha at linux.microsoft.com>
>>> ---
>>>  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>
>>> diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>>> @@ -0,0 +1,22 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +///
>>> +/// Find usages of:
>>> +/// - msecs_to_jiffies(value*1000)
>>> +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
>>> +///
>>> +// Confidence: High
>>> +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
>>> +// Keywords: secs, seconds, jiffies
>>> +//
>>> +
>>> +virtual patch
>>> +
>>> + at depends on patch@ constant C; @@
>>> +
>>> +- msecs_to_jiffies(C * 1000)
>>> ++ secs_to_jiffies(C)
>>> +
>>> + at depends on patch@ constant C; @@
>>> +
>>> +- msecs_to_jiffies(C * MSEC_PER_SEC)
>>> ++ secs_to_jiffies(C)
>>
>> If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207
>>
>> 	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));
> 
> There is the requirement that C is a constant, and cmm_timeout_seconds is
> not considered to be a constant, ie it is not all capital letters.
> Indeed, it doesn't seem to be a constant at all.  I don't know if the
> requirement of being a comstant is really necessary.
> 
> julia
> 
>>
>> Thanks!
>>

As the cover letter says, this is part 1. I intend to do further parts
that address the cases where the multiplicand is an expression, as well
as the cases where the timeout provided to msecs_to_jiffies() is
denominated in seconds (i.e. ends in 000)

Thanks,
Easwar


From eahariha at linux.microsoft.com  Tue Dec 17 12:53:22 2024
From: eahariha at linux.microsoft.com (Easwar Hariharan)
Date: Tue, 17 Dec 2024 12:53:22 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
 <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
Message-ID: <14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>

On 12/10/2024 5:00 PM, Easwar Hariharan wrote:
> On 12/10/2024 4:35 PM, Andrew Morton wrote:
>> On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan <eahariha at linux.microsoft.com> wrote:
>>
>>> This is a series that follows up on my previous series to introduce
>>> secs_to_jiffies() and convert a few initial users.
>>
>> Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
>> emails because soooo many cc's!
>>
>> I'd ask relevant maintainers to send in any acks and I'll paste them
>> into the relevant changelogs.
> 
> Thank you, Andrew!
> 
> - Easwar

Hi Andrew,

There have been a couple of comments[1][2] that came in after you queued
the series to mm. Would you rather I send individual patches addressing
these, or just send a v4 of the entire series (-netdev of course) so you
can replace it wholesale?

Thanks,
Easwar

[1]
https://lore.kernel.org/all/07784753-6874-4dda-a080-2d2812f4a10a at csgroup.eu/
[2]
https://lore.kernel.org/all/Z2G1ZPL2cAlQOYlF at li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com/


From akpm at linux-foundation.org  Tue Dec 17 13:12:21 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 17 Dec 2024 13:12:21 -0800
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
In-Reply-To: <14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
	<422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
	<14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>
Message-ID: <20241217131221.e1b1262f97dc6a5d616ca8e7@linux-foundation.org>

On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan <eahariha at linux.microsoft.com> wrote:

> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace it wholesale?

Individual small fixes would be preferable please.  Mainly to
preserve the validity of current review efforts.


From quic_kangyang at quicinc.com  Thu Dec 19 03:05:29 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Thu, 19 Dec 2024 19:05:29 +0800
Subject: [PATCH v4 0/2] wifi: ath11k: fix full monitor mode for QCN9074
Message-ID: <20241219110531.2096-1-quic_kangyang@quicinc.com>

Fix a warning and a bug for full monitor mode. With these two fixes,
full monitor mode can work properly to capture packets on QCN9074.

v4: explain why change the srng definition and initialization.
v3:
    1. add fix tag for all patches.
    2. typo error: occurr/occur.
    3. delete unnecessary Unicode characters in patch #1.
v2:
    1. delete duplicate commit message in patch #1.
    2. explain this fix is for QCN9074.

Kang Yang (1):
  wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode

P Praneesh (1):
  wifi: ath11k: fix RCU stall while reaping monitor destination ring

 drivers/net/wireless/ath/ath11k/dp_rx.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)


base-commit: 27909c77d085d32db141cbb32b2cc9fbef874197
-- 
2.34.1



From quic_kangyang at quicinc.com  Thu Dec 19 03:05:30 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Thu, 19 Dec 2024 19:05:30 +0800
Subject: [PATCH v4 1/2] wifi: ath11k: fix RCU stall while reaping monitor destination ring
In-Reply-To: <20241219110531.2096-1-quic_kangyang@quicinc.com>
References: <20241219110531.2096-1-quic_kangyang@quicinc.com>
Message-ID: <20241219110531.2096-2-quic_kangyang@quicinc.com>

From: P Praneesh <quic_ppranees at quicinc.com>

While processing the monitor destination ring, MSDUs are reaped from the
link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding
to the buf_id received from the hardware. This causes an infinite loop
in the destination processing, resulting in a kernel crash.

kernel log:
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed

Fix this by skipping the problematic buf_id and reaping the next entry,
replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: P Praneesh <quic_ppranees at quicinc.com>
Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 029ecf51c9ef..07cd336ee01b 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -4783,7 +4783,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
 			if (!msdu) {
 				ath11k_dbg(ar->ab, ATH11K_DBG_DATA,
 					   "msdu_pop: invalid buf_id %d\n", buf_id);
-				break;
+				goto next_msdu;
 			}
 			rxcb = ATH11K_SKB_RXCB(msdu);
 			if (!rxcb->unmapped) {
@@ -5410,7 +5410,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
 					   "full mon msdu_pop: invalid buf_id %d\n",
 					    buf_id);
 				spin_unlock_bh(&rx_ring->idr_lock);
-				break;
+				goto next_msdu;
 			}
 			idr_remove(&rx_ring->bufs_idr, buf_id);
 			spin_unlock_bh(&rx_ring->idr_lock);
-- 
2.34.1



From quic_kangyang at quicinc.com  Thu Dec 19 03:05:31 2024
From: quic_kangyang at quicinc.com (Kang Yang)
Date: Thu, 19 Dec 2024 19:05:31 +0800
Subject: [PATCH v4 2/2] wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
In-Reply-To: <20241219110531.2096-1-quic_kangyang@quicinc.com>
References: <20241219110531.2096-1-quic_kangyang@quicinc.com>
Message-ID: <20241219110531.2096-3-quic_kangyang@quicinc.com>

ath11k_hal_srng_* should be used with srng->lock to protect srng data.

For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
they use ath11k_hal_srng_* for many times but never call srng->lock.

So when running (full) monitor mode, warning will occur:
RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace:
 ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
 ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
 ? idr_alloc_u32+0x97/0xd0
 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
 ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
 ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
 __napi_poll+0x30/0x1f0
 net_rx_action+0x198/0x320
 __do_softirq+0xdd/0x319

So add srng->lock for them to avoid such warnings.

Inorder to fetch the srng->lock, should change srng's definition from
'void' to 'struct hal_srng'. And initialize them elsewhere to prevent
one line of code from being too long. This is consistent with other ring
process functions, such as ath11k_dp_process_rx().

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Kang Yang <quic_kangyang at quicinc.com>
---
 drivers/net/wireless/ath/ath11k/dp_rx.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 07cd336ee01b..b8b3dce9cdb5 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -5148,7 +5148,7 @@ static void ath11k_dp_rx_mon_dest_process(struct ath11k *ar, int mac_id,
 	struct ath11k_mon_data *pmon = (struct ath11k_mon_data *)&dp->mon_data;
 	const struct ath11k_hw_hal_params *hal_params;
 	void *ring_entry;
-	void *mon_dst_srng;
+	struct hal_srng *mon_dst_srng;
 	u32 ppdu_id;
 	u32 rx_bufs_used;
 	u32 ring_id;
@@ -5165,6 +5165,7 @@ static void ath11k_dp_rx_mon_dest_process(struct ath11k *ar, int mac_id,
 
 	spin_lock_bh(&pmon->mon_lock);
 
+	spin_lock_bh(&mon_dst_srng->lock);
 	ath11k_hal_srng_access_begin(ar->ab, mon_dst_srng);
 
 	ppdu_id = pmon->mon_ppdu_info.ppdu_id;
@@ -5223,6 +5224,7 @@ static void ath11k_dp_rx_mon_dest_process(struct ath11k *ar, int mac_id,
 								mon_dst_srng);
 	}
 	ath11k_hal_srng_access_end(ar->ab, mon_dst_srng);
+	spin_unlock_bh(&mon_dst_srng->lock);
 
 	spin_unlock_bh(&pmon->mon_lock);
 
@@ -5612,7 +5614,7 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
 	struct hal_sw_mon_ring_entries *sw_mon_entries;
 	struct ath11k_pdev_mon_stats *rx_mon_stats;
 	struct sk_buff *head_msdu, *tail_msdu;
-	void *mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
+	struct hal_srng *mon_dst_srng;
 	void *ring_entry;
 	u32 rx_bufs_used = 0, mpdu_rx_bufs_used;
 	int quota = 0, ret;
@@ -5628,6 +5630,9 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
 		goto reap_status_ring;
 	}
 
+	mon_dst_srng = &ar->ab->hal.srng_list[dp->rxdma_mon_dst_ring.ring_id];
+	spin_lock_bh(&mon_dst_srng->lock);
+
 	ath11k_hal_srng_access_begin(ar->ab, mon_dst_srng);
 	while ((ring_entry = ath11k_hal_srng_dst_peek(ar->ab, mon_dst_srng))) {
 		head_msdu = NULL;
@@ -5671,6 +5676,7 @@ static int ath11k_dp_full_mon_process_rx(struct ath11k_base *ab, int mac_id,
 	}
 
 	ath11k_hal_srng_access_end(ar->ab, mon_dst_srng);
+	spin_unlock_bh(&mon_dst_srng->lock);
 	spin_unlock_bh(&pmon->mon_lock);
 
 	if (rx_bufs_used) {
-- 
2.34.1



From repk at triplefau.lt  Thu Dec 19 07:35:24 2024
From: repk at triplefau.lt (Remi Pommarel)
Date: Thu, 19 Dec 2024 16:35:24 +0100
Subject: Potential Broadcast Issues After GTK Key Exchange on ath11k with
 IPQ8072A (QCN5024/QCN5054)
In-Reply-To: <c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de>
References: <c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de>
Message-ID: <Z2Q9POuV-6MIdzRf@pilgrim>

Hi Steffen.

On Thu, Dec 19, 2024 at 04:02:30PM +0100, Steffen Moser wrote:
> Hello everyone,
> 
> I've encountered a possible issue in a DD-WRT [1] setup where broadcast
> packets stop being delivered after a GTK (Group Temporal Key) exchange. This
> issue occurs on a system with the following hardware:
> 
> ??? Access Point Hardware: DynaLink DL-WRX36
> ??? Router Software: DD-WRT v3.0-r58819 std (12/13/24)
> ??? CPU: Qualcomm IPQ8072A
> ??? WiFi Chips: Qualcomm QCN5024 and Qualcomm QCN5054
> ??? WiFi Driver: ath11k
> ??? Firmware: WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
> ??? NSS FW version: NSS.FW.12.5-210-HK.R
> ??? Kernel: Linux WL-AP-EG 6.6.64-rt29 #1791 SMP Thu Dec 12 16:41:51 +07
> 2024 aarch64 DD-WRT
> 
> The behavior is such that after a GTK exchange, the AP can get into a "weird
> state". When being there, broadcast frames like ARP or mDNS are no longer
> reliably delivered to connected clients while unicasts come still through.
> In this "weird state", the channel quality (active time vs. busy time) goes
> down and latencies to the still reachable WIFI clients rise.

This looks a lot like an issue we hit a while back. There is this patch
[0] from Qualcomm's wlan-open repository. It is a revert of [1]. Using
that the issue was never reproduced. Maybe this can help.

Also adding ath11k list.

Regards.

-- 
Remi

[0]: https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.3.0.r24/patches/ath11k/350-ath11k-Revert-clear-the-keys-properly-when-DISABLE_K.patch
[1]: commit 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY")

> 
> I've come across a related bug report on GitHub that describes a similar
> issue:
> https://github.com/openwrt/openwrt/issues/9555#issuecomment-2433857175
> 
> Unfortunately, the GitHub discussion drifted towards various other possible
> bugs.
> 
> In the meantime, I have a done a lot of additional debugging, but I am
> coming to a dead end due to limited knowledge of the ath11k driver and
> firmware internals. Interestingly, the AP can get back from "weird state" to
> "normal state" after another GTK rekey event. I've seen this behavior only
> in the 5 GHz band, yet (using non-DFS-channels).
> 
> My questions to the Linux wireless experts and developers in this community:
> 
> ?? Is such a behavior known with ath11k on IPQ8072A or on the mentioned WiFi
> chips (QCN5024/QCN5054)?
> 
> ?? Could this be a driver or firmware issue that specifically arises after a
> GTK or even GMK exchange?
> 
> ?? What can I do to debug it further? I've switched on debugging in
> "hostapd" in order to see the keying events. Are there more lower-level logs
> I can get from the WiFi chip and match to the latency and key exchange
> observations?
> 
> ?? Are there any additional information I can/should deliver to give the
> devs more insight about this issue?
> 
> When exchanging the DynaLink DL-WRX36 AP by a Netgear R7800 AP (CPU: QCA
> IPQ8065), its predecessor, the problem is gone without touching any of the
> clients.
> 
> Thank you in advance for any insights or experiences regarding this issue.
> 
> Best regards,
> Steffen
> 
> [1] https://dd-wrt.com/
> 
> 
> -- 
> ?-----------------------------------------------------------------------
> Dipl.-Inf. Steffen Moser                  Tel (Office): +49.731.50.32407
> School of Advanced Professional Studies       Ulm University, Room: 1013
> https://wissenschaftliche-weiterbildung.org/    Oberberghof 7, 89081 Ulm
> https://saps.uni-ulm.de/                                         Germany
> 


From s.gottschall at dd-wrt.com  Fri Dec 20 08:52:56 2024
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 20 Dec 2024 17:52:56 +0100
Subject: Potential Broadcast Issues After GTK Key Exchange on ath11k with
 IPQ8072A (QCN5024/QCN5054)
In-Reply-To: <Z2Q9POuV-6MIdzRf@pilgrim>
References: <c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de>
 <Z2Q9POuV-6MIdzRf@pilgrim>
Message-ID: <12798910-71aa-46da-b7b4-139669abfdb0@dd-wrt.com>

Hi Remi

Am 19.12.2024 um 16:35 schrieb Remi Pommarel:
> Hi Steffen.
>
> On Thu, Dec 19, 2024 at 04:02:30PM +0100, Steffen Moser wrote:
>> Hello everyone,
>>
>> I've encountered a possible issue in a DD-WRT [1] setup where broadcast
>> packets stop being delivered after a GTK (Group Temporal Key) exchange. This
>> issue occurs on a system with the following hardware:
>>
>>  ??? Access Point Hardware: DynaLink DL-WRX36
>>  ??? Router Software: DD-WRT v3.0-r58819 std (12/13/24)
>>  ??? CPU: Qualcomm IPQ8072A
>>  ??? WiFi Chips: Qualcomm QCN5024 and Qualcomm QCN5054
>>  ??? WiFi Driver: ath11k
>>  ??? Firmware: WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>>  ??? NSS FW version: NSS.FW.12.5-210-HK.R
>>  ??? Kernel: Linux WL-AP-EG 6.6.64-rt29 #1791 SMP Thu Dec 12 16:41:51 +07
>> 2024 aarch64 DD-WRT
>>
>> The behavior is such that after a GTK exchange, the AP can get into a "weird
>> state". When being there, broadcast frames like ARP or mDNS are no longer
>> reliably delivered to connected clients while unicasts come still through.
>> In this "weird state", the channel quality (active time vs. busy time) goes
>> down and latencies to the still reachable WIFI clients rise.
> This looks a lot like an issue we hit a while back. There is this patch
> [0] from Qualcomm's wlan-open repository. It is a revert of [1]. Using
> that the issue was never reproduced. Maybe this can help.
>
> Also adding ath11k list.
>
> Regards.

thank you for that hint. i? will integrate it into dd-wrt asap

Sebastian

>


From andersson at kernel.org  Thu Dec 26 10:26:47 2024
From: andersson at kernel.org (Bjorn Andersson)
Date: Thu, 26 Dec 2024 12:26:47 -0600
Subject: (subset) [PATCH v4 1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add qca6390-pmu node
In-Reply-To: <20241201135716.141691-1-lujianhua000@gmail.com>
References: <20241201135716.141691-1-lujianhua000@gmail.com>
Message-ID: <173523761395.1412574.10662186854294667989.b4-ty@kernel.org>


On Sun, 01 Dec 2024 21:57:14 +0800, Jianhua Lu wrote:
> Add qca6390-pmu node, which is used to manage power supply sequence for wifi and
> bluetooth on sm8250 soc based devices.
> 
> 

Applied, thanks!

[1/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add qca6390-pmu node
      commit: 6e4ec5f6940d8ae38ffe23c7f2f7da9de57d0cc1
[2/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add wifi node
      commit: 1993f0255347c98b133d90e4150a4ce5f32646c4
[3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add bluetooth node
      commit: 8b14c0648673439fb736b68096804314b934653b

Best regards,
-- 
Bjorn Andersson <andersson at kernel.org>


From lists at steffen-moser.de  Sat Dec 28 02:13:50 2024
From: lists at steffen-moser.de (Steffen Moser)
Date: Sat, 28 Dec 2024 11:13:50 +0100
Subject: Potential Broadcast Issues After GTK Key Exchange on ath11k with
 IPQ8072A (QCN5024/QCN5054)
In-Reply-To: <Z2Q9POuV-6MIdzRf@pilgrim>
References: <c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de>
 <Z2Q9POuV-6MIdzRf@pilgrim>
Message-ID: <b18ede18-0c33-4d14-a7c5-0066cbec39c9@steffen-moser.de>

Dear Remi,

thank you very much for the pointer to the patch. Sebastian integrated 
it into DD-WRT. Now the DynaLink DL-WRX36 runs absolutely smoothly, the 
WLAN links are stable, the packet loss is gone. No weird states anymore, 
independent from the group key exchange interval:

https://data.saps.uni-ulm.de/index.php/s/NLNpWqjc8iGsaEM

So your idea was a direct hit! Thank you very, very much. Several months 
of debugging have come to an end...

Thank you very much and all the best for 2025!

Kind regards,
Steffen

On 19.12.24 4:35 PM, Remi Pommarel wrote:
> Hi Steffen.
> 
> On Thu, Dec 19, 2024 at 04:02:30PM +0100, Steffen Moser wrote:
>> Hello everyone,
>> 
>> I've encountered a possible issue in a DD-WRT [1] setup where broadcast
>> packets stop being delivered after a GTK (Group Temporal Key) exchange. This
>> issue occurs on a system with the following hardware:
>> 
>> ??? Access Point Hardware: DynaLink DL-WRX36
>> ??? Router Software: DD-WRT v3.0-r58819 std (12/13/24)
>> ??? CPU: Qualcomm IPQ8072A
>> ??? WiFi Chips: Qualcomm QCN5024 and Qualcomm QCN5054
>> ??? WiFi Driver: ath11k
>> ??? Firmware: WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>> ??? NSS FW version: NSS.FW.12.5-210-HK.R
>> ??? Kernel: Linux WL-AP-EG 6.6.64-rt29 #1791 SMP Thu Dec 12 16:41:51 +07
>> 2024 aarch64 DD-WRT
>> 
>> The behavior is such that after a GTK exchange, the AP can get into a "weird
>> state". When being there, broadcast frames like ARP or mDNS are no longer
>> reliably delivered to connected clients while unicasts come still through.
>> In this "weird state", the channel quality (active time vs. busy time) goes
>> down and latencies to the still reachable WIFI clients rise.
> 
> This looks a lot like an issue we hit a while back. There is this patch
> [0] from Qualcomm's wlan-open repository. It is a revert of [1]. Using
> that the issue was never reproduced. Maybe this can help.
> 
> Also adding ath11k list.
> 
> Regards.
> 



