* [PATCH v2 16/37] arm64: dts: qcom: sa8540p-ride: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
index 44177e9b64b5..702ae4cd3d0c 100644
--- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
@@ -367,7 +367,7 @@ &pcie2a {
<0x03000000 0x5 0x00000000 0x5 0x00000000 0x1 0x00000000>;
perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 145 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie2a_default>;
@@ -388,7 +388,7 @@ &pcie3a {
<0x03000000 0x6 0x00000000 0x6 0x00000000 0x2 0x00000000>;
perst-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 56 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie3a_default>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 15/37] arm64: dts: qcom: lemans: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 4 ++--
arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index c665db6a4595..fe9a2cd325d4 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -703,7 +703,7 @@ &mdss0_dp1_phy {
&pcie0 {
perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
pinctrl-names = "default";
@@ -720,7 +720,7 @@ &pcie0_phy {
&pcie1 {
perst-gpios = <&tlmm 4 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 5 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 5 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi b/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
index 31bd00546d55..3a6d73b485a9 100644
--- a/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi
@@ -854,7 +854,7 @@ wake-pins {
&pcie0 {
perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie0_default_state>;
@@ -864,7 +864,7 @@ &pcie0 {
&pcie1 {
perst-gpios = <&tlmm 4 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 5 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 5 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie1_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 14/37] arm64: dts: qcom: monaco: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/monaco-evk.dts | 4 ++--
arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index 9d17ef7d2caf..b30fc7ecdf32 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -643,12 +643,12 @@ &pcie1_phy {
&pcieport0 {
reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_LOW>;
};
&pcieport1 {
reset-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
};
&pmm8620au_0_gpios {
diff --git a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
index e9a8553a8d82..f9891fbcca90 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
@@ -615,7 +615,7 @@ &pcie0 {
&pcieport0 {
reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_LOW>;
wifi@0 {
compatible = "pci17cb,1103";
@@ -651,7 +651,7 @@ &pcie1 {
&pcieport1 {
reset-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
};
&pcie1_phy {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 13/37] arm64: dts: qcom: sar2130p: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts b/arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts
index 74778a5b19ba..71a09e76b359 100644
--- a/arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts
+++ b/arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts
@@ -358,7 +358,7 @@ &i2c10 {
&pcie0 {
perst-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 57 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 12/37] arm64: dts: qcom: kaanapali: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 07247dc98b70..dc773da863c0 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -933,7 +933,7 @@ &pcie0_phy {
};
&pcie_port0 {
- wake-gpios = <&tlmm 104 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 104 GPIO_ACTIVE_LOW>;
reset-gpios = <&tlmm 102 GPIO_ACTIVE_LOW>;
wifi@0 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 11/37] arm64: dts: qcom: sm8750: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
index 3837f6785320..2c2753683c69 100644
--- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
@@ -1119,7 +1119,7 @@ &pcie0_phy {
};
&pcieport0 {
- wake-gpios = <&tlmm 104 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 104 GPIO_ACTIVE_LOW>;
reset-gpios = <&tlmm 102 GPIO_ACTIVE_LOW>;
wifi@0 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 10/37] arm64: dts: qcom: sm8650: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8650-mtp.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
index 0dc994f4e48d..2123312d88f6 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
@@ -1074,7 +1074,7 @@ &mdss_dp0_out {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
@@ -1108,7 +1108,7 @@ &pcie0_phy {
};
&pcie1 {
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
diff --git a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
index eabc828c05b4..775ce9f2dba0 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
@@ -942,7 +942,7 @@ &mdss_dp0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
@@ -976,7 +976,7 @@ &pcie0_phy {
};
&pcie1 {
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
diff --git a/arch/arm64/boot/dts/qcom/sm8650-mtp.dts b/arch/arm64/boot/dts/qcom/sm8650-mtp.dts
index dd6e33d2dc5d..8cc0d2cb3515 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-mtp.dts
@@ -642,7 +642,7 @@ &mdss_dsi0_phy {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
@@ -659,7 +659,7 @@ &pcie0_phy {
};
&pcie1 {
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index a3982ae22929..c302996a7857 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -936,7 +936,7 @@ &mdss_dp0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 09/37] arm64: dts: qcom: sm8550: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 2 +-
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 2 +-
arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi b/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
index e6ebb643203b..5eb4626c6129 100644
--- a/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi
@@ -336,7 +336,7 @@ &mdss_dsi0_phy {
&pcie0 {
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
pinctrl-names = "default";
@@ -349,7 +349,7 @@ &pcie0_phy {
&pcie1 {
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index ee13e6136a82..4709eb34521d 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -1003,7 +1003,7 @@ &mdss_dp0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
@@ -1037,7 +1037,7 @@ &pcie0_phy {
};
&pcie1 {
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie1_default_state>;
diff --git a/arch/arm64/boot/dts/qcom/sm8550-mtp.dts b/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
index 5769be83cfbd..7703ebfc1b67 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-mtp.dts
@@ -739,7 +739,7 @@ &mdss_dp0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -756,7 +756,7 @@ &pcie0_phy {
};
&pcie1 {
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 2fb2e0be5e4c..5ce81ac3ab4c 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -903,7 +903,7 @@ &mdss_dp0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
diff --git a/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts b/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts
index 81c02ee27fe9..cf4e4e9d9e26 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts
@@ -510,7 +510,7 @@ &i2c_master_hub_0 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts b/arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts
index 0e6ed6fce614..d23fe714bd27 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts
@@ -584,7 +584,7 @@ cirrus,gpio-ctrl2 {
};
&pcie0 {
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie0_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 08/37] arm64: dts: qcom: sm8450: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 03bf30b53f28..acb36aaaf20b 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2035,7 +2035,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
phy-names = "pciephy";
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie0_default_state>;
@@ -2200,7 +2200,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
phy-names = "pciephy";
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie1_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 07/37] arm64: dts: qcom: sm8350: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index 5f975d009465..0897ed1bbc6f 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -494,7 +494,7 @@ &pcie0 {
pinctrl-0 = <&pcie0_default_state>;
perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -508,7 +508,7 @@ &pcie0_phy {
&pcie1 {
perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie1_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 06/37] arm64: dts: qcom: sm8250: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 7076720413ab..eca66d1c1c5b 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2202,7 +2202,7 @@ pcie0: pcie@1c00000 {
phy-names = "pciephy";
perst-gpios = <&tlmm 79 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 81 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie0_default_state>;
@@ -2329,7 +2329,7 @@ pcie1: pcie@1c08000 {
phy-names = "pciephy";
perst-gpios = <&tlmm 82 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 84 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 84 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie1_default_state>;
@@ -2456,7 +2456,7 @@ pcie2: pcie@1c10000 {
phy-names = "pciephy";
perst-gpios = <&tlmm 85 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 87 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie2_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 05/37] arm64: dts: qcom: sm8150: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 0e101096209a..8da494de4308 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -1905,7 +1905,7 @@ pcie0: pcie@1c00000 {
phy-names = "pciephy";
perst-gpios = <&tlmm 35 GPIO_ACTIVE_HIGH>;
- wake-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie0_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 04/37] arm64: dts: qcom: sc8180x: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 2 +-
arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
index d86a31ddede2..44bf3db01d3a 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts
@@ -458,7 +458,7 @@ &mdss_edp_out {
&pcie3 {
perst-gpios = <&tlmm 178 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 180 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 180 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie3_default_state>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
index aff398390eba..a4644ecca536 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
+++ b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
@@ -559,7 +559,7 @@ &mdss_edp_out {
&pcie1 {
perst-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 177 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 177 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pcie2_default_state>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 03/37] arm64: dts: qcom: sdm845: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index 02416812b6a7..24c0e97bb122 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -619,7 +619,7 @@ &mss_pil {
&pcie0 {
status = "okay";
perst-gpios = <&tlmm 35 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 134 GPIO_ACTIVE_LOW>;
vddpe-3v3-supply = <&pcie0_3p3v_dual>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 02/37] arm64: dts: qcom: msm8996: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi b/arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi
index d55e4075040f..5b42c266557a 100644
--- a/arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi
@@ -192,7 +192,7 @@ &mmcc {
&pcie0 {
perst-gpios = <&tlmm 35 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
vddpe-3v3-supply = <&wlan_en>;
vdda-supply = <&pm8994_l28>;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi b/arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi
index 77ad613590a3..2abcc733dad8 100644
--- a/arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi
@@ -280,7 +280,7 @@ &pcie0 {
vdda-supply = <&vreg_l28a_0p925>;
perst-gpios = <&tlmm 35 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
};
&pcie_phy {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 01/37] ARM: dts: qcom: sdx55: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260611-wake-v2-0-2744251b1181@oss.qualcomm.com>
The PCIe WAKE# signal is active-low as defined in the PCIe Base
Specification. Fix the wake-gpios polarity by using GPIO_ACTIVE_LOW
instead of GPIO_ACTIVE_HIGH.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts b/arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts
index 082f7ed1a01f..302c88c47960 100644
--- a/arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts
+++ b/arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts
@@ -251,7 +251,7 @@ &pcie_phy {
&pcie_rc {
perst-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 53 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pcie_default>;
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 00/37] arm64: dts: qcom: Fix PCIe wake GPIO polarity
From: Krishna Chaitanya Chundru @ 2026-06-11 4:58 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
cros-qcom-dts-watchers, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru, Konrad Dybcio, Manivannan Sadhasivam,
Krishna Chaitanya Chundru
PCIe wake is active low signal as per the PCIe base spec, Several Qualcomm
platform devicetrees incorrectly describe wake-gpios as GPIO_ACTIVE_HIGH.
The PCIe PHY references and PERST/WAKE GPIO properties are defined on a
per-root-port basis and do not belong to the PCIe controller (RC)
node. Keeping these properties at the controller level makes the
description less accurate and prevents clean per-port customization.
This series moves the PHY references (phys, phy-names) from the PCIe
controller node to the corresponding root port nodes (pcie@0), namely
pcie0_port0, pcie1_port0, and pcie2_port0. Labels are added to these
port nodes to enable board-level overrides where required.
Additionally, the PERST and WAKE GPIO properties are relocated from
controller-level board overrides to their respective root port nodes
in the board DTS files. As part of this change, 'perst-gpios' is renamed
to 'reset-gpios' to align with the binding used in the PCIe root port
context.
This restructuring improves DT correctness by properly associating
resources with their respective hardware blocks and aligns with the
expectations defined in the PCIe binding.
Tested on Talos Ride & lemans evk platform.
No Fixes tag is added as no functional issue has been observed.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v2:
- Move phy, perst & wake properties to the root port node.
- Rebased the code
- Link to v1: https://patch.msgid.link/20260521-wake-v1-0-d822567be258@oss.qualcomm.com
---
Krishna Chaitanya Chundru (37):
ARM: dts: qcom: sdx55: Fix PCIe wake GPIO polarity
arm64: dts: qcom: msm8996: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sdm845: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sc8180x: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8150: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8250: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8350: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8450: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8550: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8650: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sm8750: Fix PCIe wake GPIO polarity
arm64: dts: qcom: kaanapali: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sar2130p: Fix PCIe wake GPIO polarity
arm64: dts: qcom: monaco: Fix PCIe wake GPIO polarity
arm64: dts: qcom: lemans: Fix PCIe wake GPIO polarity
arm64: dts: qcom: sa8540p-ride: Fix PCIe wake GPIO polarity
arm64: dts: qcom: kodiak: Fix PCIe wake GPIO polarity
arm64: dts: qcom: talos: Fix PCIe wake GPIO polarity
arm64: dts: qcom: lemans: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: msm8998: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: qcs404: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: qcs8550: Move PCIe GPIOs to root port node
arm64: dts: qcom: sa8295p: Move PCIe GPIOs to root port node
arm64: dts: qcom: sa8540p: Move PCIe GPIOs to root port node
arm64: dts: qcom: sar2130p: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sc8180x: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sc8280xp: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sdm845: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8150: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8250: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8350: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8450: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8550: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: talos: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: sm8650: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: kodiak: Move PCIe phy and GPIOs to root port node
arm64: dts: qcom: msm8996: Move PCIe phy and GPIOs to root port node
arch/arm/boot/dts/qcom/qcom-sdx55-t55.dts | 2 +-
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 15 ++++++++--
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 2 +-
arch/arm64/boot/dts/qcom/kodiak.dtsi | 10 +++----
arch/arm64/boot/dts/qcom/lemans-evk.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 16 ++++++----
arch/arm64/boot/dts/qcom/lemans.dtsi | 12 ++++----
arch/arm64/boot/dts/qcom/monaco-evk.dts | 4 +--
.../boot/dts/qcom/msm8996-oneplus-common.dtsi | 5 +++-
.../boot/dts/qcom/msm8996-sony-xperia-tone.dtsi | 7 +++--
.../arm64/boot/dts/qcom/msm8996-xiaomi-common.dtsi | 6 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 21 ++++++-------
arch/arm64/boot/dts/qcom/msm8998.dtsi | 8 ++---
.../boot/dts/qcom/qcm6490-particle-tachyon.dts | 15 ++++++----
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 6 ++--
arch/arm64/boot/dts/qcom/qcs404.dtsi | 7 ++---
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 8 +++--
.../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 16 ++++++----
.../qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso | 4 +--
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 +--
.../dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts | 14 +++++----
.../boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 4 +--
arch/arm64/boot/dts/qcom/qcs8550-aim300.dtsi | 16 ++++++----
arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 32 ++++++++++++--------
arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/sar2130p-qar2130p.dts | 6 ++--
arch/arm64/boot/dts/qcom/sar2130p.dtsi | 12 ++++----
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 5 +++-
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 5 +++-
.../arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 7 +++--
arch/arm64/boot/dts/qcom/sc8180x-primus.dts | 7 +++--
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 24 +++++++--------
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 24 +++++++++------
.../boot/dts/qcom/sc8280xp-huawei-gaokun3.dts | 14 +++++----
.../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 22 ++++++++------
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 22 ++++++++------
.../boot/dts/qcom/sc8280xp-microsoft-blackrock.dts | 14 +++++----
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 25 +++++++---------
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 13 ++++++---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 12 +++++---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++++-----
arch/arm64/boot/dts/qcom/sm8150.dtsi | 21 ++++++-------
arch/arm64/boot/dts/qcom/sm8250.dtsi | 34 +++++++++-------------
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/sm8350.dtsi | 14 ++++-----
arch/arm64/boot/dts/qcom/sm8450.dtsi | 22 ++++++--------
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 14 +++++----
arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 6 ++--
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 7 +++--
.../dts/qcom/sm8550-sony-xperia-yodo-pdx234.dts | 8 +++--
arch/arm64/boot/dts/qcom/sm8550.dtsi | 12 ++++----
.../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 14 +++++----
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 14 +++++----
arch/arm64/boot/dts/qcom/sm8650-mtp.dts | 16 ++++++----
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 6 ++--
arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 +++----
arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
arch/arm64/boot/dts/qcom/talos-evk-som.dtsi | 8 +++--
arch/arm64/boot/dts/qcom/talos.dtsi | 5 ++--
61 files changed, 420 insertions(+), 333 deletions(-)
---
base-commit: 9716c086c8e8b141d35aa61f2e96a2e83de212a7
change-id: 20260514-wake-1dfbdedcd173
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v18 6/7] coresight: ctcu: enable byte-cntr for TMC ETR devices
From: Jie Gan @ 2026-06-11 4:57 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Bjorn Andersson, Konrad Dybcio
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree
In-Reply-To: <20260507-enable-byte-cntr-for-ctcu-v18-6-2b2d590463a3@oss.qualcomm.com>
On 5/7/2026 10:12 PM, Jie Gan wrote:
> The byte-cntr function provided by the CTCU device is used to transfer data
> from the ETR buffer to the userspace. An interrupt is triggered if the data
> size exceeds the threshold set in the BYTECNTRVAL register. The interrupt
> handler counts the number of triggered interruptions and the read function
> will read the data from the synced ETR buffer.
>
> Switching the sysfs_buf when current buffer is full or the timeout is
> triggered and resets rrp and rwp registers after switched the buffer.
> The synced buffer will become available for reading after the switch.
>
> Byte-cntr workflow:
> start -> ctcu_enable(ctcu_byte_cntr_start) -> tmc_enable_etr_sink ->
> tmc_read_prepare_etr(jump to tmc_read_prepare_byte_cntr) ->
> tmc_etr_get_sysfs_trace(jump to tmc_byte_cntr_get_data) ->
> tmc_disable_etr_sink -> ctcu_disable(ctcu_byte_cntr_stop) ->
> tmc_read_unprepare_etr(jump to tmc_read_unprepare_byte_cntr) -> finish
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
> drivers/hwtracing/coresight/Makefile | 2 +-
> .../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 304 +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 127 ++++++++-
> drivers/hwtracing/coresight/coresight-ctcu.h | 79 +++++-
> drivers/hwtracing/coresight/coresight-tmc-core.c | 3 +-
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 114 +++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 9 +
> 8 files changed, 622 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-ctcu b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ctcu
> new file mode 100644
> index 000000000000..6e53a5197e53
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ctcu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/coresight/devices/<ctcu-name>/irq_enabled[0:1]
> +Date: May 2026
> +KernelVersion: 7.2
> +Contact: Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>; Jinlong Mao <jinlong.mao@oss.qualcomm.com>; Jie Gan <jie.gan@oss.qualcomm.com>
> +Description:
> + (RW) Configure the flag to enable interrupt to count data during CTCU enablement.
> + An interrupt is generated when the data size exceeds the value set in the IRQ register.
> + 0 : disable
> + 1 : enable
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index ab16d06783a5..821a1b06b20c 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -55,5 +55,5 @@ coresight-cti-y := coresight-cti-core.o coresight-cti-platform.o \
> obj-$(CONFIG_ULTRASOC_SMB) += ultrasoc-smb.o
> obj-$(CONFIG_CORESIGHT_DUMMY) += coresight-dummy.o
> obj-$(CONFIG_CORESIGHT_CTCU) += coresight-ctcu.o
> -coresight-ctcu-y := coresight-ctcu-core.o
> +coresight-ctcu-y := coresight-ctcu-core.o coresight-ctcu-byte-cntr.o
> obj-$(CONFIG_CORESIGHT_KUNIT_TESTS) += coresight-kunit-tests.o
> diff --git a/drivers/hwtracing/coresight/coresight-ctcu-byte-cntr.c b/drivers/hwtracing/coresight/coresight-ctcu-byte-cntr.c
> new file mode 100644
> index 000000000000..268194f35fd3
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-ctcu-byte-cntr.c
> @@ -0,0 +1,304 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/coresight.h>
> +#include <linux/device.h>
> +#include <linux/fs.h>
> +#include <linux/interrupt.h>
> +#include <linux/of_irq.h>
> +#include <linux/uaccess.h>
> +
> +#include "coresight-ctcu.h"
> +#include "coresight-priv.h"
> +#include "coresight-tmc.h"
> +
> +static irqreturn_t byte_cntr_handler(int irq, void *data)
> +{
> + struct ctcu_byte_cntr *byte_cntr_data = data;
> +
> + atomic_inc(&byte_cntr_data->irq_cnt);
> + wake_up(&byte_cntr_data->wq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void ctcu_cfg_byte_cntr_reg(struct ctcu_drvdata *drvdata, u32 val,
> + u32 offset)
> +{
> + /* A one value for IRQCTRL register represents 8 bytes */
> + ctcu_program_register(drvdata, val / 8, offset);
> +}
> +
> +static struct ctcu_byte_cntr *ctcu_get_byte_cntr(struct coresight_device *ctcu,
> + struct coresight_device *etr)
> +{
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(ctcu->dev.parent);
> + int port;
> +
> + port = coresight_get_in_port(etr, ctcu);
> + if (port < 0 || port > 1)
> + return NULL;
> +
> + return &drvdata->byte_cntr_data[port];
> +}
> +
> +static bool ctcu_byte_cntr_switch_buffer(struct tmc_drvdata *etr_drvdata,
> + struct ctcu_byte_cntr *byte_cntr_data)
> +{
> + struct etr_buf_node *nd, *next, *curr_node = NULL, *picked_node = NULL;
> + struct etr_buf *curr_buf = etr_drvdata->sysfs_buf;
> + bool found_free_buf = false;
> +
> + if (WARN_ON(!etr_drvdata || !byte_cntr_data))
> + return false;
> +
> + /* Stop the ETR before initiating the switch */
> + if (coresight_get_mode(etr_drvdata->csdev) != CS_MODE_DISABLED)
> + tmc_etr_enable_disable_hw(etr_drvdata, false);
> +
> + list_for_each_entry_safe(nd, next, &etr_drvdata->etr_buf_list, link) {
> + /* curr_buf is free for next round */
> + if (nd->sysfs_buf == curr_buf) {
> + nd->is_free = true;
> + curr_node = nd;
> + } else if (!found_free_buf && nd->is_free) {
> + picked_node = nd;
> + found_free_buf = true;
> + }
> + }
> +
> + if (found_free_buf) {
> + curr_node->pos = 0;
> + curr_node->reading = true;
> + byte_cntr_data->buf_node = curr_node;
> + etr_drvdata->sysfs_buf = picked_node->sysfs_buf;
> + etr_drvdata->etr_buf = picked_node->sysfs_buf;
> + picked_node->is_free = false;
> + /* Reset irq_cnt for next etr_buf */
> + atomic_set(&byte_cntr_data->irq_cnt, 0);
> + /* Restart the ETR once a free buffer is available */
> + if (coresight_get_mode(etr_drvdata->csdev) != CS_MODE_DISABLED)
> + tmc_etr_enable_disable_hw(etr_drvdata, true);
> + }
> +
> + return found_free_buf;
> +}
> +
> +/*
> + * ctcu_byte_cntr_get_data() - reads data from the deactivated and filled buffer.
> + * The byte-cntr reading work reads data from the deactivated and filled buffer.
> + * The read operation waits for a buffer to become available, either filled or
> + * upon timeout, and then reads trace data from the synced buffer.
> + */
> +static ssize_t tmc_byte_cntr_get_data(struct tmc_drvdata *etr_drvdata, loff_t pos,
> + size_t len, char **bufpp)
> +{
> + struct coresight_device *ctcu = tmc_etr_get_ctcu_device(etr_drvdata);
> + struct device *dev = &etr_drvdata->csdev->dev;
> + struct ctcu_byte_cntr *byte_cntr_data;
> + struct etr_buf *sysfs_buf;
> + atomic_t *irq_cnt;
> + ssize_t actual;
> + int ret;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(ctcu, etr_drvdata->csdev);
> + if (!byte_cntr_data || !byte_cntr_data->irq_enabled)
> + return -EINVAL;
> +
> + irq_cnt = &byte_cntr_data->irq_cnt;
> +
> +wait_buffer:
> + if (!byte_cntr_data->buf_node) {
> + ret = wait_event_interruptible_timeout(byte_cntr_data->wq,
> + (atomic_read(irq_cnt) >= MAX_IRQ_CNT - 1) ||
> + !byte_cntr_data->enable,
> + BYTE_CNTR_TIMEOUT);
> + if (ret < 0)
> + return ret;
> + /*
> + * The current etr_buf is almost full or timeout is triggered,
> + * so switch the buffer and mark the switched buffer as reading.
> + */
> + if (byte_cntr_data->enable) {
> + if (!ctcu_byte_cntr_switch_buffer(etr_drvdata, byte_cntr_data)) {
> + dev_err(dev, "Switch buffer failed for the byte-cntr\n");
> + return -ENOMEM;
> + }
> + } else {
> + /* Exit byte-cntr reading */
> + return 0;
> + }
> + }
> +
> + /* Check the status of current etr_buf */
> + if (atomic_read(irq_cnt) >= MAX_IRQ_CNT)
> + dev_warn(dev, "Data overwrite happened\n");
> +
> + pos = byte_cntr_data->buf_node->pos;
> + sysfs_buf = byte_cntr_data->buf_node->sysfs_buf;
> + actual = tmc_etr_read_sysfs_buf(sysfs_buf, pos, len, bufpp);
> + if (actual <= 0) {
> + /* Reset buf_node upon reading is finished or failed */
> + byte_cntr_data->buf_node->reading = false;
> + byte_cntr_data->buf_node = NULL;
> +
> + /*
> + * Nothing in the buffer, waiting for the next buffer
> + * to be filled.
> + */
> + if (actual == 0)
> + goto wait_buffer;
> + }
> +
> + return actual;
> +}
> +
> +static int tmc_read_prepare_byte_cntr(struct tmc_drvdata *etr_drvdata)
> +{
> + struct coresight_device *ctcu = tmc_etr_get_ctcu_device(etr_drvdata);
> + struct ctcu_byte_cntr *byte_cntr_data;
> + unsigned long flags;
> + int ret = 0;
> +
> + /* byte-cntr is operating with SYSFS mode being enabled only */
> + if (coresight_get_mode(etr_drvdata->csdev) != CS_MODE_SYSFS)
> + return -EINVAL;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(ctcu, etr_drvdata->csdev);
> + if (!byte_cntr_data || !byte_cntr_data->irq_enabled)
> + return -EINVAL;
> +
> + raw_spin_lock_irqsave(&byte_cntr_data->spin_lock, flags);
> + if (byte_cntr_data->reading) {
> + raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
> + return -EBUSY;
> + }
> +
> + /* byte_cntr_data->enable may race with ctcu_platform_remove() */
> + if (!byte_cntr_data->enable) {
> + raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
> + return -ENODEV;
> + }
> +
> + byte_cntr_data->reading = true;
> + raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
> + /* Setup an available etr_buf_list for byte-cntr */
> + ret = tmc_create_etr_buf_list(etr_drvdata, 2);
> + if (ret) {
> + byte_cntr_data->reading = false;
> + return ret;
> + }
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + atomic_set(&byte_cntr_data->irq_cnt, 0);
> + /*
> + * Configure the byte-cntr register to enable IRQ. The configured
> + * size is 5% of the buffer_size.
> + */
> + ctcu_cfg_byte_cntr_reg(byte_cntr_data->ctcu_drvdata,
> + etr_drvdata->size / MAX_IRQ_CNT,
> + byte_cntr_data->irq_ctrl_offset);
> + enable_irq_wake(byte_cntr_data->irq);
> + byte_cntr_data->buf_node = NULL;
> +
> + return 0;
> +}
> +
> +static int tmc_read_unprepare_byte_cntr(struct tmc_drvdata *etr_drvdata)
> +{
> + struct coresight_device *ctcu = tmc_etr_get_ctcu_device(etr_drvdata);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(ctcu, etr_drvdata->csdev);
> + if (!byte_cntr_data || !byte_cntr_data->irq_enabled)
Found an issue here. Need add one more condition to address the issue:
if (!byte_cntr_data || !byte_cntr_data->irq_enabled ||
!byte_cntr_data->reading)
In tmc_read_prepare_etr(), when byte_cntr_sysfs_ops is set but
tmc_read_prepare_byte_cntr() returns an error, the code falls through
to the normal prepare path and sets drvdata->reading = true. In the
paired tmc_read_unprepare_etr(), if byte_cntr_ops is still set and
tmc_read_unprepare_byte_cntr() returns 0 (because irq_enabled=true, even
though byte_cntr_data->reading was never set), the function returns
early without clearing drvdata->reading.
Thanks,
Jie
> + return -EINVAL;
> +
> + tmc_clean_etr_buf_list(etr_drvdata);
> + scoped_guard(raw_spinlock_irqsave, &byte_cntr_data->spin_lock) {
> + /* Configure the byte-cntr register to disable IRQ */
> + ctcu_cfg_byte_cntr_reg(byte_cntr_data->ctcu_drvdata, 0,
> + byte_cntr_data->irq_ctrl_offset);
> + disable_irq_wake(byte_cntr_data->irq);
> + byte_cntr_data->buf_node = NULL;
> + byte_cntr_data->reading = false;
> + }
> + wake_up(&byte_cntr_data->wq);
> +
> + return 0;
> +}
> +
> +const struct tmc_sysfs_ops byte_cntr_sysfs_ops = {
> + .read_prepare = tmc_read_prepare_byte_cntr,
> + .read_unprepare = tmc_read_unprepare_byte_cntr,
> + .get_trace_data = tmc_byte_cntr_get_data,
> +};
> +
> +/* Start the byte-cntr function when the path is enabled. */
> +void ctcu_byte_cntr_start(struct coresight_device *csdev, struct coresight_path *path)
> +{
> + struct coresight_device *sink = coresight_get_sink(path);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(csdev, sink);
> + if (!byte_cntr_data)
> + return;
> +
> + /* Don't start byte-cntr function when irq_enabled is not set. */
> + if (!byte_cntr_data->irq_enabled || byte_cntr_data->enable)
> + return;
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + byte_cntr_data->enable = true;
> +}
> +
> +/* Stop the byte-cntr function when the path is disabled. */
> +void ctcu_byte_cntr_stop(struct coresight_device *csdev, struct coresight_path *path)
> +{
> + struct coresight_device *sink = coresight_get_sink(path);
> + struct ctcu_byte_cntr *byte_cntr_data;
> +
> + if (coresight_get_mode(sink) == CS_MODE_SYSFS)
> + return;
> +
> + byte_cntr_data = ctcu_get_byte_cntr(csdev, sink);
> + if (!byte_cntr_data)
> + return;
> +
> + guard(raw_spinlock_irqsave)(&byte_cntr_data->spin_lock);
> + byte_cntr_data->enable = false;
> +}
> +
> +void ctcu_byte_cntr_init(struct device *dev, struct ctcu_drvdata *drvdata, int etr_num)
> +{
> + struct ctcu_byte_cntr *byte_cntr_data;
> + struct device_node *nd = dev->of_node;
> + int irq_num, ret, i, irq_registered = 0;
> +
> + for (i = 0; i < etr_num; i++) {
> + byte_cntr_data = &drvdata->byte_cntr_data[i];
> + irq_num = of_irq_get(nd, i);
> + if (irq_num < 0) {
> + dev_err(dev, "Failed to get IRQ from DT for port%d\n", i);
> + continue;
> + }
> +
> + ret = devm_request_irq(dev, irq_num, byte_cntr_handler,
> + IRQF_TRIGGER_RISING | IRQF_SHARED,
> + dev_name(dev), byte_cntr_data);
> + if (ret) {
> + dev_err(dev, "Failed to register IRQ for port%d\n", i);
> + continue;
> + }
> +
> + byte_cntr_data->irq = irq_num;
> + byte_cntr_data->ctcu_drvdata = drvdata;
> + init_waitqueue_head(&byte_cntr_data->wq);
> + raw_spin_lock_init(&byte_cntr_data->spin_lock);
> + irq_registered++;
> + }
> +
> + if (irq_registered)
> + tmc_etr_set_byte_cntr_sysfs_ops(&byte_cntr_sysfs_ops);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
> index e8720026c9e3..2da1a6f3d29f 100644
> --- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
> +++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2024-2026 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #include <linux/clk.h>
> @@ -18,6 +19,7 @@
>
> #include "coresight-ctcu.h"
> #include "coresight-priv.h"
> +#include "coresight-tmc.h"
>
> #define ctcu_writel(drvdata, val, offset) __raw_writel((val), drvdata->base + offset)
> #define ctcu_readl(drvdata, offset) __raw_readl(drvdata->base + offset)
> @@ -43,17 +45,21 @@
>
> #define CTCU_ATID_REG_BIT(traceid) (traceid % 32)
> #define CTCU_ATID_REG_SIZE 0x10
> +#define CTCU_ETR0_IRQCTRL 0x6c
> +#define CTCU_ETR1_IRQCTRL 0x70
> #define CTCU_ETR0_ATID0 0xf8
> #define CTCU_ETR1_ATID0 0x108
>
> static const struct ctcu_etr_config sa8775p_etr_cfgs[] = {
> {
> - .atid_offset = CTCU_ETR0_ATID0,
> - .port_num = 0,
> + .atid_offset = CTCU_ETR0_ATID0,
> + .irq_ctrl_offset = CTCU_ETR0_IRQCTRL,
> + .port_num = 0,
> },
> {
> - .atid_offset = CTCU_ETR1_ATID0,
> - .port_num = 1,
> + .atid_offset = CTCU_ETR1_ATID0,
> + .irq_ctrl_offset = CTCU_ETR1_IRQCTRL,
> + .port_num = 1,
> },
> };
>
> @@ -62,6 +68,85 @@ static const struct ctcu_config sa8775p_cfgs = {
> .num_etr_config = ARRAY_SIZE(sa8775p_etr_cfgs),
> };
>
> +void ctcu_program_register(struct ctcu_drvdata *drvdata, u32 val, u32 offset)
> +{
> + CS_UNLOCK(drvdata->base);
> + ctcu_writel(drvdata, val, offset);
> + CS_LOCK(drvdata->base);
> +}
> +
> +static ssize_t irq_enabled_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> +
> + if (!drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + return -EINVAL;
> +
> + return sysfs_emit(buf, "%u\n",
> + (unsigned int)drvdata->byte_cntr_data[port].irq_enabled);
> +}
> +
> +static ssize_t irq_enabled_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> + unsigned long val;
> +
> + if (kstrtoul(buf, 0, &val))
> + return -EINVAL;
> +
> + guard(raw_spinlock_irqsave)(&drvdata->byte_cntr_data[port].spin_lock);
> + if (drvdata->byte_cntr_data[port].reading)
> + return -EBUSY;
> + else if (drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + drvdata->byte_cntr_data[port].irq_enabled = !!val;
> +
> + return size;
> +}
> +
> +static umode_t irq_enabled_is_visible(struct kobject *kobj,
> + struct attribute *attr, int n)
> +{
> + struct device_attribute *dev_attr =
> + container_of(attr, struct device_attribute, attr);
> + struct ctcu_byte_cntr_irq_attribute *irq_attr =
> + container_of(dev_attr, struct ctcu_byte_cntr_irq_attribute, attr);
> + struct device *dev = kobj_to_dev(kobj);
> + struct ctcu_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + u8 port = irq_attr->port;
> +
> + if (drvdata && drvdata->byte_cntr_data[port].irq_ctrl_offset)
> + return attr->mode;
> +
> + return 0;
> +}
> +
> +static struct attribute *ctcu_attrs[] = {
> + ctcu_byte_cntr_irq_rw(0),
> + ctcu_byte_cntr_irq_rw(1),
> + NULL,
> +};
> +
> +static struct attribute_group ctcu_attr_grp = {
> + .attrs = ctcu_attrs,
> + .is_visible = irq_enabled_is_visible,
> +};
> +
> +static const struct attribute_group *ctcu_attr_grps[] = {
> + &ctcu_attr_grp,
> + NULL,
> +};
> +
> static void ctcu_program_atid_register(struct ctcu_drvdata *drvdata, u32 reg_offset,
> u8 bit, bool enable)
> {
> @@ -140,11 +225,15 @@ static int ctcu_set_etr_traceid(struct coresight_device *csdev, struct coresight
> static int ctcu_enable(struct coresight_device *csdev, enum cs_mode mode,
> struct coresight_path *path)
> {
> + ctcu_byte_cntr_start(csdev, path);
> +
> return ctcu_set_etr_traceid(csdev, path, true);
> }
>
> static int ctcu_disable(struct coresight_device *csdev, struct coresight_path *path)
> {
> + ctcu_byte_cntr_stop(csdev, path);
> +
> return ctcu_set_etr_traceid(csdev, path, false);
> }
>
> @@ -195,7 +284,10 @@ static int ctcu_probe(struct platform_device *pdev)
> for (i = 0; i < cfgs->num_etr_config; i++) {
> etr_cfg = &cfgs->etr_cfgs[i];
> drvdata->atid_offset[i] = etr_cfg->atid_offset;
> + drvdata->byte_cntr_data[i].irq_ctrl_offset =
> + etr_cfg->irq_ctrl_offset;
> }
> + ctcu_byte_cntr_init(dev, drvdata, cfgs->num_etr_config);
> }
> }
>
> @@ -209,6 +301,7 @@ static int ctcu_probe(struct platform_device *pdev)
> desc.dev = dev;
> desc.ops = &ctcu_ops;
> desc.access = CSDEV_ACCESS_IOMEM(base);
> + desc.groups = ctcu_attr_grps;
> raw_spin_lock_init(&drvdata->spin_lock);
>
> drvdata->csdev = coresight_register(&desc);
> @@ -244,10 +337,34 @@ static int ctcu_platform_probe(struct platform_device *pdev)
> static void ctcu_platform_remove(struct platform_device *pdev)
> {
> struct ctcu_drvdata *drvdata = platform_get_drvdata(pdev);
> + struct ctcu_byte_cntr *byte_cntr_data;
> + unsigned long flags;
> + int i;
>
> if (WARN_ON(!drvdata))
> return;
>
> + /*
> + * Signal all active byte-cntr readers to exit, then wait for them to
> + * finish before resetting the ops pointer and freeing driver data.
> + * Without this, a reader blocked in wait_event_interruptible_timeout()
> + * would access the freed ctcu_drvdata wait-queue head (use-after-free).
> + */
> + for (i = 0; i < ETR_MAX_NUM; i++) {
> + byte_cntr_data = &drvdata->byte_cntr_data[i];
> + raw_spin_lock_irqsave(&byte_cntr_data->spin_lock, flags);
> + /* Set enable=false for all ports to signal teardown to racing readers */
> + byte_cntr_data->enable = false;
> + if (!byte_cntr_data->reading) {
> + raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
> + continue;
> + }
> + raw_spin_unlock_irqrestore(&byte_cntr_data->spin_lock, flags);
> + wake_up_all(&byte_cntr_data->wq);
> + wait_event(byte_cntr_data->wq, !byte_cntr_data->reading);
> + }
> +
> + tmc_etr_reset_byte_cntr_sysfs_ops();
> ctcu_remove(pdev);
> pm_runtime_disable(&pdev->dev);
> }
> diff --git a/drivers/hwtracing/coresight/coresight-ctcu.h b/drivers/hwtracing/coresight/coresight-ctcu.h
> index e9594c38dd91..a2ae0a0d91d0 100644
> --- a/drivers/hwtracing/coresight/coresight-ctcu.h
> +++ b/drivers/hwtracing/coresight/coresight-ctcu.h
> @@ -1,23 +1,31 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> - * Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2024-2026 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #ifndef _CORESIGHT_CTCU_H
> #define _CORESIGHT_CTCU_H
> +
> +#include <linux/time.h>
> #include "coresight-trace-id.h"
>
> /* Maximum number of supported ETR devices for a single CTCU. */
> #define ETR_MAX_NUM 2
>
> +#define BYTE_CNTR_TIMEOUT (3 * HZ)
> +#define MAX_IRQ_CNT 20
> +
> /**
> * struct ctcu_etr_config
> * @atid_offset: offset to the ATID0 Register.
> - * @port_num: in-port number of CTCU device that connected to ETR.
> + * @port_num: in-port number of the CTCU device that connected to ETR.
> + * @irq_ctrl_offset: offset to the BYTECNTRVAL register.
> */
> struct ctcu_etr_config {
> const u32 atid_offset;
> const u32 port_num;
> + const u32 irq_ctrl_offset;
> };
>
> struct ctcu_config {
> @@ -25,15 +33,68 @@ struct ctcu_config {
> int num_etr_config;
> };
>
> -struct ctcu_drvdata {
> - void __iomem *base;
> - struct clk *apb_clk;
> - struct device *dev;
> - struct coresight_device *csdev;
> +/**
> + * struct ctcu_byte_cntr
> + * @enable: indicates that byte_cntr function is enabled or not.
> + * @irq_enabled: indicates that the interruption is enabled.
> + * @reading: indicates that byte_cntr is reading.
> + * @irq: allocated number of the IRQ.
> + * @irq_cnt: IRQ count number of the triggered interruptions.
> + * @wq: waitqueue for reading data from ETR buffer.
> + * @spin_lock: spinlock of the byte_cntr_data.
> + * @irq_ctrl_offset: offset to the BYTECNTVAL Register.
> + * @ctcu_drvdata: drvdata of the CTCU device.
> + * @buf_node: etr_buf_node for reading.
> + */
> +struct ctcu_byte_cntr {
> + bool enable;
> + bool irq_enabled;
> + bool reading;
> + int irq;
> + atomic_t irq_cnt;
> + wait_queue_head_t wq;
> raw_spinlock_t spin_lock;
> - u32 atid_offset[ETR_MAX_NUM];
> + u32 irq_ctrl_offset;
> + struct ctcu_drvdata *ctcu_drvdata;
> + struct etr_buf_node *buf_node;
> +};
> +
> +struct ctcu_drvdata {
> + void __iomem *base;
> + struct clk *apb_clk;
> + struct device *dev;
> + struct coresight_device *csdev;
> + struct ctcu_byte_cntr byte_cntr_data[ETR_MAX_NUM];
> + raw_spinlock_t spin_lock;
> + u32 atid_offset[ETR_MAX_NUM];
> /* refcnt for each traceid of each sink */
> - u8 traceid_refcnt[ETR_MAX_NUM][CORESIGHT_TRACE_ID_RES_TOP];
> + u8 traceid_refcnt[ETR_MAX_NUM][CORESIGHT_TRACE_ID_RES_TOP];
> };
>
> +/**
> + * struct ctcu_byte_cntr_irq_attribute
> + * @attr: The device attribute.
> + * @port: port number.
> + */
> +struct ctcu_byte_cntr_irq_attribute {
> + struct device_attribute attr;
> + u8 port;
> +};
> +
> +#define ctcu_byte_cntr_irq_rw(port) \
> + (&((struct ctcu_byte_cntr_irq_attribute[]) { \
> + { \
> + __ATTR(irq_enabled##port, 0644, irq_enabled_show, \
> + irq_enabled_store), \
> + port, \
> + } \
> + })[0].attr.attr)
> +
> +void ctcu_program_register(struct ctcu_drvdata *drvdata, u32 val, u32 offset);
> +
> +/* Byte-cntr functions */
> +void ctcu_byte_cntr_start(struct coresight_device *csdev, struct coresight_path *path);
> +void ctcu_byte_cntr_stop(struct coresight_device *csdev, struct coresight_path *path);
> +void ctcu_byte_cntr_init(struct device *dev, struct ctcu_drvdata *drvdata, int port_num);
> +
> #endif
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
> index 110eedde077f..9f4fd86e8c32 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
> @@ -293,7 +293,8 @@ static ssize_t tmc_read(struct file *file, char __user *data, size_t len,
> return -EFAULT;
> }
>
> - *ppos += actual;
> + if (!tmc_etr_update_buf_node_pos(drvdata, actual))
> + *ppos += actual;
> dev_dbg(&drvdata->csdev->dev, "%zu bytes copied\n", actual);
>
> return actual;
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index b0c5f3559085..54ca9616fa66 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1168,6 +1168,8 @@ static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata,
> return rc;
> }
>
> +static const struct tmc_sysfs_ops *byte_cntr_sysfs_ops;
> +
> /*
> * Return the available trace data in the buffer (starts at etr_buf->offset,
> * limited by etr_buf->len) from @pos, with a maximum limit of @len,
> @@ -1178,23 +1180,39 @@ static int tmc_etr_enable_hw(struct tmc_drvdata *drvdata,
> * We are protected here by drvdata->reading != 0, which ensures the
> * sysfs_buf stays alive.
> */
> -ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> - loff_t pos, size_t len, char **bufpp)
> +ssize_t tmc_etr_read_sysfs_buf(struct etr_buf *sysfs_buf, loff_t pos,
> + size_t len, char **bufpp)
> {
> s64 offset;
> ssize_t actual = len;
> - struct etr_buf *etr_buf = drvdata->sysfs_buf;
>
> - if (pos + actual > etr_buf->len)
> - actual = etr_buf->len - pos;
> + if (pos + actual > sysfs_buf->len)
> + actual = sysfs_buf->len - pos;
> if (actual <= 0)
> return actual;
>
> /* Compute the offset from which we read the data */
> - offset = etr_buf->offset + pos;
> - if (offset >= etr_buf->size)
> - offset -= etr_buf->size;
> - return tmc_etr_buf_get_data(etr_buf, offset, actual, bufpp);
> + offset = sysfs_buf->offset + pos;
> + if (offset >= sysfs_buf->size)
> + offset -= sysfs_buf->size;
> + return tmc_etr_buf_get_data(sysfs_buf, offset, actual, bufpp);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_read_sysfs_buf);
> +
> +ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
> + loff_t pos, size_t len, char **bufpp)
> +{
> + ssize_t ret;
> + const struct tmc_sysfs_ops *byte_cntr_ops = READ_ONCE(byte_cntr_sysfs_ops);
> +
> + if (byte_cntr_ops) {
> + ret = byte_cntr_ops->get_trace_data(drvdata, pos, len, bufpp);
> + /* Return the filled buffer */
> + if (ret > 0 || ret == -ENOMEM)
> + return ret;
> + }
> +
> + return tmc_etr_read_sysfs_buf(drvdata->sysfs_buf, pos, len, bufpp);
> }
>
> static struct etr_buf *
> @@ -1248,6 +1266,39 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>
> }
>
> +static void tmc_etr_reset_sysfs_buf(struct tmc_drvdata *drvdata)
> +{
> + u32 sts;
> +
> + CS_UNLOCK(drvdata->base);
> + tmc_write_rrp(drvdata, drvdata->sysfs_buf->hwaddr);
> + tmc_write_rwp(drvdata, drvdata->sysfs_buf->hwaddr);
> + sts = readl_relaxed(drvdata->base + TMC_STS) & ~TMC_STS_FULL;
> + writel_relaxed(sts, drvdata->base + TMC_STS);
> + CS_LOCK(drvdata->base);
> +}
> +
> +/**
> + * tmc_etr_enable_disable_hw - enable/disable the ETR hw.
> + * @drvdata: drvdata of the TMC device.
> + * @enable: indicates enable/disable.
> + */
> +void tmc_etr_enable_disable_hw(struct tmc_drvdata *drvdata, bool enable)
> +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&drvdata->spinlock, flags);
> + if (enable) {
> + tmc_etr_reset_sysfs_buf(drvdata);
> + __tmc_etr_enable_hw(drvdata);
> + } else {
> + __tmc_etr_disable_hw(drvdata);
> + }
> +
> + raw_spin_unlock_irqrestore(&drvdata->spinlock, flags);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_enable_disable_hw);
> +
> void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> {
> __tmc_etr_disable_hw(drvdata);
> @@ -2047,15 +2098,54 @@ int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes)
> }
> EXPORT_SYMBOL_GPL(tmc_create_etr_buf_list);
>
> +void tmc_etr_set_byte_cntr_sysfs_ops(const struct tmc_sysfs_ops *sysfs_ops)
> +{
> + WRITE_ONCE(byte_cntr_sysfs_ops, sysfs_ops);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_set_byte_cntr_sysfs_ops);
> +
> +void tmc_etr_reset_byte_cntr_sysfs_ops(void)
> +{
> + WRITE_ONCE(byte_cntr_sysfs_ops, NULL);
> +}
> +EXPORT_SYMBOL_GPL(tmc_etr_reset_byte_cntr_sysfs_ops);
> +
> +bool tmc_etr_update_buf_node_pos(struct tmc_drvdata *drvdata, ssize_t size)
> +{
> + struct etr_buf_node *nd, *next;
> +
> + if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> + return false;
> +
> + list_for_each_entry_safe(nd, next, &drvdata->etr_buf_list, link) {
> + if (nd && nd->reading) {
> + nd->pos += size;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> {
> int ret = 0;
> unsigned long flags;
> + const struct tmc_sysfs_ops *byte_cntr_ops;
>
> /* config types are set a boot time and never change */
> if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
> return -EINVAL;
>
> + byte_cntr_ops = READ_ONCE(byte_cntr_sysfs_ops);
> + if (byte_cntr_ops) {
> + ret = byte_cntr_ops->read_prepare(drvdata);
> + if (!ret || ret == -EBUSY)
> + return ret;
> +
> + ret = 0;
> + }
> +
> raw_spin_lock_irqsave(&drvdata->spinlock, flags);
> if (drvdata->reading) {
> ret = -EBUSY;
> @@ -2087,11 +2177,17 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> {
> unsigned long flags;
> struct etr_buf *sysfs_buf = NULL;
> + const struct tmc_sysfs_ops *byte_cntr_ops;
>
> /* config types are set a boot time and never change */
> if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETR))
> return -EINVAL;
>
> + byte_cntr_ops = READ_ONCE(byte_cntr_sysfs_ops);
> + if (byte_cntr_ops)
> + if (!byte_cntr_ops->read_unprepare(drvdata))
> + return 0;
> +
> raw_spin_lock_irqsave(&drvdata->spinlock, flags);
>
> /* RE-enable the TMC if need be */
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index fbb015079872..a15e2f93f16a 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -211,12 +211,15 @@ struct tmc_resrv_buf {
> /**
> * @sysfs_buf: Allocated sysfs_buf.
> * @is_free: Indicates whether the buffer is free to choose.
> + * @reading: Indicates byte_cntr is reading the buffer attached to
> + * the node.
> * @pos: Offset to the start of the buffer.
> * @link: list_head of the node.
> */
> struct etr_buf_node {
> struct etr_buf *sysfs_buf;
> bool is_free;
> + bool reading;
> loff_t pos;
> struct list_head link;
> };
> @@ -480,5 +483,11 @@ struct etr_buf *tmc_etr_get_buffer(struct coresight_device *csdev,
> extern const struct attribute_group coresight_etr_group;
> void tmc_clean_etr_buf_list(struct tmc_drvdata *drvdata);
> int tmc_create_etr_buf_list(struct tmc_drvdata *drvdata, int num_nodes);
> +void tmc_etr_set_byte_cntr_sysfs_ops(const struct tmc_sysfs_ops *sysfs_ops);
> +void tmc_etr_reset_byte_cntr_sysfs_ops(void);
> +void tmc_etr_enable_disable_hw(struct tmc_drvdata *drvdata, bool enable);
> +bool tmc_etr_update_buf_node_pos(struct tmc_drvdata *drvdata, ssize_t size);
> +ssize_t tmc_etr_read_sysfs_buf(struct etr_buf *sysfs_buf, loff_t pos,
> + size_t len, char **bufpp);
>
> #endif
>
^ permalink raw reply
* Re: [PATCH v3 3/8] remoteproc: qcom: pas: register TMD thermal cooling devices
From: Gaurav Kohli @ 2026-06-11 4:45 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
linux-pm, linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <e9573827-81b5-4c75-9d1a-d59a4809300c@oss.qualcomm.com>
On 6/9/2026 5:33 PM, Konrad Dybcio wrote:
> On 6/9/26 12:22 PM, Gaurav Kohli wrote:
>> Add support for Thermal Mitigation Devices (TMDs) to enable
>> thermal throttling of remote processors through QMI.
>>
>> This enables the thermal framework to request mitigation when remote
>> subsystems (modem, CDSP) contribute to thermal issues.
>>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
>
> There's no other signs of Daniel in this patch, please fix the
> tags chain
>
> [...]
>
Thanks Konrad for review, will fix this.
>> +static int qcom_pas_setup_tmd(struct qcom_pas *pas)
>> +{
>> + struct device *dev = pas->dev;
>> + struct device_node *np = dev->of_node;
>> + const char **tmd_names;
>> + int num_tmds, ret, i;
>> +
>> + if (!of_find_property(np, "tmd-names", NULL))
>
> Let's use device_property_present() instead
>
Ack.
>> + return 0;
>> +
>> + /* Get the TMD names array */
>> + num_tmds = of_property_count_strings(np, "tmd-names");
>
> Is this something we can stuff into platform_data for a given rproc on a
> given SoC (for which we already store *some* data in the PAS driver)?
>
Without tmd-names in DT, it is unclear which index corresponds to which
binding. With #cooling-cells, tmd-names in DT provides an explicit
name-to-index mapping. Please suggest.
> Konrad
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Marek Vasut @ 2026-06-10 16:31 UTC (permalink / raw)
To: Liu Ying
Cc: Piyush Patle, dri-devel, imx, linux-arm-kernel, linux-clk,
devicetree, Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <aifOQtaAi_7F9hXt@raspi>
On 6/9/26 10:26 AM, Liu Ying wrote:
Hello Liu,
>>>> I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
>>>> LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
>>>> LVDS format handling, and DC enable sequencing which needed rework before
>>>> HDMI would come up reliably on the board.
>>>>
>>>> I don't see a v2 of the series and things seem to have been quiet since
>>>> November. Are you planning to post an updated version?
>>>
>>> My plan was to enable prefetch engine support[1] for i.MX8QXP display
>>> controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
>>> before adding i.MX95 display controller support.
>>>
>>> Unfortunately, it seems that Marek is not a big fan of [1]
>>
>> I am fine with [1] as long as it can be isolated and does not affect every
>> SoC that might reuse this driver, which I think it can be done.
>
> How can it be isolated?
if (compatible("mx8q"))
something->prefetch_op = somefunction;
And then wherever is prefetch used, do
if (something->prefetch_op)
something->prefetch_op()
Or something along those lines ?
>>> and I'm busy
>>> with downstream development so the plan doesn't move forward well. I still
>>> think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
>>> so I'd like to see review comments on [1] and hopefully people think that
>>> the overall idea of [1] is ok.
>>
>> My only concern is, to keep it isolated to MX8Q, so this driver can be
>> reused by MX95.
>>
>>>> I've accumulated a fair amount of rework while getting this running on the
>>>> FRDM. If you're not planning a v2, I can clean things up and send one based
>>>> on the current series.
>>>
>>> I still think that i.MX95 display controller driver should be in a separate
>>> driver, rather than sharing the same driver with i.MX8QXP display controller
>>> like this patch series does, because the two display controllers are quite
>>> different as I mentioned in comments on this patch series and in discussion
>>> in [1]. Also, the common part between the two display controllers should
>>> be extracted to a common helper library as I mentioned there too.
>> Are they really? It seems this series adds support for the MX95 DC without
>> that many changes, so are the DCs really that different ? It seems the MX95
>> DC is simply a reuse/evolution of the MX8Q DC blocks, so duplicating the
>> code seems like the wrong direction, it will only lead to disparate sets of
>> bugs in two drivers, which isn't desired.
>
> I pointed out a lot of H/W differences between the two display controllers
> during the discussions for this patch series and my i.MX8QXP prefetch engine
> patch series[1]. Please take a look at [1], which clearly shows that the
> prefetch engine would considerably impact CRTC/plane atomic callback
> implementations.
Is the prefetch engine actually grown into the CRTC/DE or not ? I
suspect it is separate and instead part of the built-in DMA, right ?
> Display controller internal blocks would also impact
> the implementations, e.g., DomainBlend block in i.MX95 display controller
> doesn't present in i.MX8QXP display controller. It makes sense to use
> separate drivers for the two display controllers instead of adding 'if/else'
> checks to a single driver's atomic callbacks or introducing two pairs of
> atomic callbacks to that single driver. I mentioned before, the code to
> simply add a DRM driver(struct drm_driver) is fairly limited.
Can't we simply have two sets of ops (one for mx8q and one for mx95) for
those ops which are too complicated to implement as a single op with
if/else statements ?
> I also mentioned before that separate drivers make them easier to maintain:
> we don't have to test both i.MX8QXP and i.MX95 if only one display controller
> specific code is changed.
The downside is lack of code reuse, which leads to disparate sets of
bugs in these two drivers and code duplication. And it seems to me, that
large parts of the MX8Q and MX95 DC are effectively identical.
>> (I might not fully understand what you have in mind with the helper library
>> though?)
>
> I said this could be something like imx-ldb-helper.c and plus perhaps some
> callbacks like fg->dc_fg_cfg_videomode().
Do you perceive that the DC driver cannot be parametrized easily enough
that it has to be turned into a library like that ? When I look at this
patchset, esp. the first half which updates the various blocks, it does
not seem to me that way.
^ permalink raw reply
* Re: (subset) [PATCH v5 0/3] Nuvoton NPCM FIU DTS fixes and binding conversion
From: Andrew Jeffery @ 2026-06-11 4:41 UTC (permalink / raw)
To: broonie, robh, krzk+dt, conor+dt, Tomer Maimon
Cc: openbmc, linux-spi, devicetree, linux-kernel, avifishman70,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260610121822.2524634-1-tmaimon77@gmail.com>
On Wed, 10 Jun 2026 15:18:19 +0300, Tomer Maimon wrote:
> This series fixes the in-tree NPCM7xx FIU controller nodes so their
> resources match what the DTS actually describes, and converts the legacy
> Nuvoton NPCM FIU binding to YAML DT schema.
>
> Patch 1 drops the bogus "memory" entry from reg-names on the NPCM7xx FIU
> nodes.
>
> [...]
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH v3 0/9] ARM: dts: aspeed: anacapa: restructure devicetree for development-phase
From: Andrew Jeffery @ 2026-06-11 4:06 UTC (permalink / raw)
To: u8813345, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
colin.huang2, Carl Lee, Rex Fu, Andy Chung, Peter Shen
In-Reply-To: <20260602-anacapa-devlop-phase-devicetree-v3-0-7c93c5df8d9b@gmail.com>
Hi Colin,
On Tue, 2026-06-02 at 21:24 +0800, Colin Huang via B4 Relay wrote:
...
>
> Colin Huang (5):
> ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
> ARM: dts: aspeed: anacapa: add EVT2 devicetree inheriting EVT1
> ARM: dts: aspeed: anacapa: add DVT devicetree inheriting EVT2
So my concern with these three are that none of the EVT1, EVT2 or DVT
devicetrees correspond with the current Anacapa devicetree. All of them
have variations on the configured GPIOs. Some GPIO lines are renamed
while others are added.
Adding them is (eventually) fine, but I'd rather not do that while
we're shuffling the devicetree sources around.
Renaming them to accommodate changes in the one devicetree is what
we're trying to escape here, so having renames hide in the rest of the
shuffling is definitely problematic.
For example:
-""
+"L_FNIC_FLT"
"FM_CPU0_SYS_RESET_N"
-""
+"L_BNIC0_FLT"
"CPU0_KBRST_N"
-""
+"L_BNIC1_FLT"
"FM_CPU0_PROCHOT_trigger_N"
-""
+"L_BNIC2_FLT"
"FM_CLR_CMOS_R_P0"
-""
+"L_BNIC3_FLT"
"Force_I3C_SEL"
-""
+"L_RTM_SW_FLT"
"SYSTEM_Force_Run_AC_Cycle"
""
""
@@ -20,55 +20,57 @@
"FM_SCM_JTAG_MUX_SEL"
"Channel2_leakage_Manifold1"
"FM_BRIDGE_JTAG_MUX_SEL"
-"Channel3_leakage"
+"Channel5_leakage_present_EAM1"
I've pasted a script below that helps compare the various dts files.
You can use it to generate the reference from the current aspeed-bmc-
facebook-anacapa.dts, then generate the comparison files from the newly
introduced dts files.
To reiterate, I expect the shuffling of the dts files to result in at
least one of the variants producing the same devicetree as the current
aspeed-bmc-facebook-anacapa.dts.
Andrew
#!/usr/bin/bash
set -x
: ${ANACAPA_VARIANT:=""}
: ${ANACAPA_REFERENCE:="arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.rt.dts.tmp"}
if [ -z "$ANACAPA_REFERENCE" ] || ! [ -e "$ANACAPA_REFERENCE" ]
then
gcc -E -Wp,-MMD,arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.d.pre.tmp -nostdinc -I ../scripts/dtc/include-prefixes -undef -D__DTS__ -x assembler-with-cpp -o arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.dts.tmp ../arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts ; ./scripts/dtc/dtc -o arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dtb -b 0 -i../arch/arm/boot/dts/aspeed/ -i../scripts/dtc/include-prefixes -Wno-unique_unit_address -Wno-unit_address_vs_reg -Wno-avoid_unnecessary_addr_size -Wno-alias_paths -Wno-interrupt_map -Wno-simple_bus_reg -d arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.d.dtc.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.dts.tmp ; cat arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.d.pre.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.d.dtc.tmp > arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.d
dtc -I dts -O dts -o arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.rt.dts.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.dts.tmp
ANACAPA_REFERENCE=arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa.dtb.rt.dts.tmp
fi
if [ -n "$ANACAPA_VARIANT" ]
then
gcc -E -Wp,-MMD,arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.d.pre.tmp -nostdinc -I ../scripts/dtc/include-prefixes -undef -D__DTS__ -x assembler-with-cpp -o arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.dts.tmp ../arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dts ; ./scripts/dtc/dtc -o arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb -b 0 -i../arch/arm/boot/dts/aspeed/ -i../scripts/dtc/include-prefixes -Wno-unique_unit_address -Wno-unit_address_vs_reg -Wno-avoid_unnecessary_addr_size -Wno-alias_paths -Wno-interrupt_map -Wno-simple_bus_reg -d arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.d.dtc.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.dts.tmp ; cat arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.d.pre.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.d.dtc.tmp > arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.d
dtc -I dts -O dts -o arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.rt.dts.tmp arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.dts.tmp
diff -u "$ANACAPA_REFERENCE" arch/arm/boot/dts/aspeed/.aspeed-bmc-facebook-anacapa-${ANACAPA_VARIANT}.dtb.rt.dts.tmp | tee ${ANACAPA_VARIANT}-{remove,add}
grep '^-[^-]' ${ANACAPA_VARIANT}-remove | grep gpio-line-names | sed -E 's/.+gpio-line-names = //' | tr ',' '\n' | sed -E 's/^ //' | sponge ${ANACAPA_VARIANT}-remove
grep '^[+][^+]' ${ANACAPA_VARIANT}-add | grep gpio-line-names | sed -E 's/.+gpio-line-names = //' | tr ',' '\n' | sed -E 's/^ //' | sponge ${ANACAPA_VARIANT}-add
diff -u ${ANACAPA_VARIANT}-{remove,add}
fi
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
From: Sherry Sun @ 2026-06-11 3:59 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Krzysztof Kozlowski, sashiko-reviews@lists.linux.dev,
manivannan.sadhasivam@oss.qualcomm.com, linux-pci@vger.kernel.org,
robh@kernel.org, Frank.Li@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev
In-Reply-To: <ihrmgh6etb2n5zqjbrykfjjms4a6zgpzwjgrd3rvy24jufbss7@f4nfxrp7jksy>
> On Wed, Jun 10, 2026 at 10:13:00AM +0000, Sherry Sun wrote:
> > > On Wed, Jun 10, 2026 at 08:40:54AM +0000, Sherry Sun wrote:
> > > > > On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org
> wrote:
> > > > > > Thank you for your contribution! Sashiko AI review found 1
> > > > > > potential
> > > > > issue(s) to consider:
> > > > > > - [Medium] The `vpcie3v3aux-supply` property describes a
> > > > > > non-existent
> > > > > hardware feature on the M.2 Key E connector to work around a
> > > > > software policy.
> > > > >
> > > > > Feels valid. Describe which pin on M2 connector are you representing.
> > > > >
> > > >
> > > > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources
> > > > and Grounds.
> > > >
> > > > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
> > > > voltage source, 3.3 V, is expected to be available during the
> > > > system’s stand-by/suspend state to support wake event processing
> > > > on the communications card.
> > > >
> > > > But the current vpcie3v3-supply may be gated off during system
> suspend.
> > > > So I tried to add vpcie3v3aux-supply to let this 3.3 V power
> > > > source always on for PCIe M.2 Key E connector. That means
> > > > vpcie3v3aux-supply and vpcie3v3-supply actually refer to the same 3.3 V
> power source.
> > > >
> > > > @Mani, do you think this is reasonable? Or do you have any other
> > > > better solutions? Thanks!
> > > >
> > >
> > > There is no Vaux defined in the M.2 spec. So you cannot define that
> > > supply in the binding. You can define the custom Vaux supply as a
> > > fixed regulator in DT and mark it always on so that it is keeps supplying
> 3.3v to the card.
> > >
> >
> > Hi Mani, thanks for the suggestion, but adding an always on regulator
> > may cause board power waste, current solution ensures the 3.3v
> > regulator is only enabled when M.2 connector needs to work .
> >
>
> What do you mean by 'need to work'? For getting the M.2 card to work, you
> already have 3.3v supply. If you want the board to be always ON, then you
> need to supply 3.3Vaux, which should be always ON too.
>
> But who is turning off vpcie3v3-supply? M.2 connector driver or the
> platform?
>
Hi Mani,
I'm not sure if I understand your question correctly, actually it's the platform
driver that calls the M.2 connector driver to turn off vpcie3v3-supply.
Take i.MX pci device as an example,
pm_suspend() -> imx_pcie_suspend_noirq() -> imx_pcie_host_exit() ->
pci_pwrctrl_power_off_devices() -> pwrseq_power_off() ->
pwrseq_unit_disable() -> pwrseq_pcie_m2_vregs_disable()
Taking back to M.2 Specification:
PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The
voltage source, 3.3 V, is expected to be available during the
system’s stand-by/suspend state to support wake event processing
on the communications card.
Per my understanding of the above, the M.2 Spec actually suggest the
3.3 V power source should not be turned off.
Should we simply enable the 3.3 V power source in pwrseq_pcie_m2_probe()
and remove the pwrseq_pcie_m2_vregs_unit_data?
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v1 3/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
From: sashiko-bot @ 2026-06-11 3:32 UTC (permalink / raw)
To: Zhang Yi; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611031824.4628-4-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing symmetric constraints for channels and sample bits allows concurrent streams to corrupt shared clock configuration.
- [High] Concurrent `hw_params` calls can race, leading to corrupted internal state and interleaved register writes.
--
commit 58316d49bbe1cd5f1a16ef61d0304cd59b1dd9ba
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: codecs: ES8389: Fix the issue about mclk_src
Fix the issue with incorrect modifications to mclk_src when configuring
the system to use MCLK from the SCLK pin. Changes the mclk_src member
from u8 to bool to better represent its purpose.
> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index be7a36f17083f..886069be1535f 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
[ ... ]
> @@ -607,9 +607,9 @@ static int es8389_pcm_hw_params(struct snd_pcm_substream *substream,
> regmap_update_bits(es8389->regmap, ES8389_ADC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state);
> regmap_update_bits(es8389->regmap, ES8389_DAC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state);
>
> - if (es8389->mclk_src == ES8389_SCLK_PIN) {
> + if (es8389->mclk_src) {
> regmap_update_bits(es8389->regmap, ES8389_MASTER_CLK,
> - ES8389_MCLK_SOURCE, es8389->mclk_src);
> + ES8389_MCLK_MASK, ES8389_MCLK_FROM_SCLK);
> es8389->sysclk = params_channels(params) * params_width(params) * params_rate(params);
[Severity: High]
This is a pre-existing issue, but I noticed the driver dynamically calculates
a shared internal clock (es8389->sysclk) based on the stream parameters here.
Since the es8389_dai definition doesn't set .symmetric_channels = 1 or
.symmetric_sample_bits = 1, couldn't user-space concurrently open playback
and capture streams with different channel counts or bit widths?
Would the second stream silently recalculate and overwrite the hardware clock
registers, breaking the already-running stream?
[Severity: High]
This is also a pre-existing issue, but does this function need locking to
protect against concurrent execution?
ALSA's PCM core does not serialize hw_params calls between separate playback
and capture substreams on the same DAI. If playback and capture streams
execute hw_params simultaneously, couldn't they race when updating shared
driver state like es8389->sysclk and es8389->vddd?
Later in this function, there's a sequence of about 20 non-atomic regmap_write
operations to clock control registers:
regmap_write(es8389->regmap, ES8389_CLK_DIV1, coeff_div[coeff].Reg0x04);
regmap_write(es8389->regmap, ES8389_CLK_MUL, coeff_div[coeff].Reg0x05);
...
Could concurrent execution interleave these hardware register writes and
potentially leave the codec's clocking tree in an invalid state?
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=3
^ permalink raw reply
* Re: [PATCH v1 2/7] ASoC: codecs: ES8389: Modify volatile_register
From: sashiko-bot @ 2026-06-11 3:31 UTC (permalink / raw)
To: Zhang Yi; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611031824.4628-3-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete volatile register whitelist causes state loss on suspend/resume.
- [High] Ignored `regmap_read()` return values lead to the use of uninitialized stack variables.
- [High] Unbalanced clock prepare/enable and disable/unprepare calls due to manual bias level manipulation.
--
commit 13fa26be72cc2a7540f3f86a2ef766aae985561e
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: codecs: ES8389: Modify volatile_register
Mark some registers that are not volatile as false
And modified the logic for cache_bypass during 8389_resume.
> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index 449d9574b03a8..be7a36f17083f 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
> @@ -50,10 +50,29 @@ static const char * const es8389_core_supplies[] = {
> static bool es8389_volatile_register(struct device *dev,
> unsigned int reg)
> {
> - if ((reg <= 0xff))
> - return true;
> - else
> + switch (reg) {
> + case ES8389_ADCL_VOL:
> + case ES8389_ADCR_VOL:
> + case ES8389_MIC1_GAIN:
> + case ES8389_MIC2_GAIN:
> + case ES8389_DACL_VOL:
> + case ES8389_DACR_VOL:
> + case ES8389_ALC_ON:
> + case ES8389_ALC_CTL:
> + case ES8389_ALC_TARGET:
> + case ES8389_ALC_GAIN:
> + case ES8389_ADC_MUTE:
> + case ES8389_OSR_VOL:
> + case ES8389_DAC_INV:
> + case ES8389_MIX_VOL:
> + case ES8389_DAC_MIX:
> + case ES8389_ADC_RESET:
> + case ES8389_ADC_MODE:
> + case ES8389_DMIC_EN:
> return false;
> + default:
> + return true;
> + }
> }
[Severity: High]
This isn't a bug introduced by this patch, but will this incomplete whitelist
cause state loss across suspend/resume cycles?
Because the default case marks all unlisted registers as volatile, critical
configuration registers like ES8389_ADC_HPF2, ES8389_MASTER_MODE, and
ES8389_CLK_DIV1 are omitted from the cache.
Since regcache_sync() skips volatile registers, won't es8389_init() just
overwrite these with default values during resume, discarding any active
user configurations?
[ ... ]
> @@ -861,13 +880,13 @@ static int es8389_resume(struct snd_soc_component *component)
> regcache_cache_only(es8389->regmap, false);
> regcache_cache_bypass(es8389->regmap, true);
> regmap_read(es8389->regmap, ES8389_RESET, ®v);
[Severity: High]
This is a pre-existing issue, but does this code risk branching on an
uninitialized variable?
If regmap_read() fails during early resume, regv will contain uninitialized
stack memory. The subsequent check against 0xff will yield unpredictable
results, potentially skipping the required initialization.
The same issue appears to exist in es8389_init() when reading
ES8389_MAX_REGISTER into the local variable reg before assigning it to
es8389->version. Could we check the return values of these reads?
> - regcache_cache_bypass(es8389->regmap, false);
>
> if (regv == 0xff)
> es8389_init(component);
> else
> es8389_set_bias_level(component, SND_SOC_BIAS_ON);
[Severity: High]
This is a pre-existing issue, but does calling es8389_set_bias_level()
directly from the resume and suspend handlers conflict with the ASoC DAPM
framework?
Since DAPM independently transitions bias levels and triggers the
registered set_bias_level callback, it seems this direct call would cause
clk_prepare_enable() to run multiple times on resume, leaking the clock
reference count.
Similarly, during suspend, wouldn't redundant calls to
clk_disable_unprepare() cause a clock underflow warning?
>
> + regcache_cache_bypass(es8389->regmap, false);
> regcache_sync(es8389->regmap);
>
> return 0;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox