* [PATCH v2 03/10] arm64: dts: qcom: sc8280xp-arcata: add USB-C orientation GPIOs
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Define the USB-C orientation GPIOs so that the orientation is known
for the two USB-C ports on the left-side.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index 476e17415da273330e3638e040db9cd4ed408bf1..c3b143ed11c73b7c1bedc576c10af8db30effc36 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -60,6 +60,8 @@ pmic-glink {
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 166 GPIO_ACTIVE_HIGH>,
+ <&tlmm 49 GPIO_ACTIVE_HIGH>;
/* Left-side top port */
connector@0 {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 01/10] arm64: dts: qcom: sc8280xp-arcata: Enable backlight
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Add backlight nodes and enable backlight so that it can be controlled
with the corresponding buttons found on Surface Pro Type Cover keyboards.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index f2b4470d4407fb5b6a3dbac8bc972c010c31bd06..f24f60dc73afea6eeee0ea26472cda3223811752 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -46,6 +46,15 @@ wcd938x: audio-codec {
#sound-dai-cells = <1>;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pmc8280c_lpg 3 1000000>;
+ enable-gpios = <&pmc8280_1_gpios 8 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&edp_bl_en>, <&edp_bl_pwm>;
+ pinctrl-names = "default";
+ };
+
pmic-glink {
compatible = "qcom,sc8280xp-pmic-glink", "qcom,pmic-glink";
@@ -553,6 +562,10 @@ &pcie4_phy {
status = "okay";
};
+&pmc8280c_lpg {
+ status = "okay";
+};
+
&pmk8280_pon_pwrkey {
status = "okay";
};
@@ -853,6 +866,13 @@ &lpass_tlmm {
status = "okay";
};
+&pmc8280_1_gpios {
+ edp_bl_en: edp-bl-en-state {
+ pins = "gpio8";
+ function = "normal";
+ };
+};
+
&pmc8280_2_gpios {
wwan_sw_en: wwan-sw-en-state {
pins = "gpio1";
@@ -860,6 +880,13 @@ wwan_sw_en: wwan-sw-en-state {
};
};
+&pmc8280c_gpios {
+ edp_bl_pwm: edp-bl-pwm-state {
+ pins = "gpio8";
+ function = "func1";
+ };
+};
+
&pmr735a_gpios {
hastings_reg_en: hastings-reg-en-state {
pins = "gpio1";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 00/10] Microsoft Surface Pro 9 5G update
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Jens Glathe, Konrad Dybcio,
Bartosz Golaszewski, Stephan Gerhold
This series updates the support for the Microsoft Surface 9 5G
(Arcata), bringing it more up-to-date and aligned with the other
sc8280xp models such as the Lenovo ThinkPad X13s.
As highlights, it finally enables the built-in screen, it fixes
Display Port alt mode on the top left-side USB-C port, it enables
the volume up/down keys and the lid switch.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
Changes in v2:
- The panel-edp patch was accepted as a subset. Removed from this series [Doug]
- Update the backlight patch to keep only the necessary nodes
- Add R-by: tags and move a Fixes tag [Konrad]
- Strip details from the "Enable the eDP display" commit message [Konrad]
- Fix misleading commit message about USB-C orientation [Konrad]
- Link to v1: https://lore.kernel.org/r/20260520-surface-sp9-5g-for-next-v1-0-9df52552bf87@gmail.com
---
Jérôme de Bretagne (10):
arm64: dts: qcom: sc8280xp-arcata: Enable backlight
arm64: dts: qcom: sc8280xp-arcata: Enable the eDP display
arm64: dts: qcom: sc8280xp-arcata: add USB-C orientation GPIOs
arm64: dts: qcom: sc8280xp-arcata: Fix top USB-C DP alt mode
arm64: dts: qcom: sc8280xp-arcata: Enable 4-lane DP support
arm64: dts: qcom: sc8280xp-arcata: Add volume up/down GPIO keys
arm64: dts: qcom: sc8280xp-arcata: Add lid switch
arm64: dts: qcom: sc8280xp-arcata: model the PMU of the on-board wcn6855
arm64: dts: qcom: sc8280xp-arcata: Switch to uefi rtc offset
arm64: dts: qcom: sc8280xp-arcata: Drop duplicate DMIC supplies
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 279 ++++++++++++++++++---
1 file changed, 243 insertions(+), 36 deletions(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260520-surface-sp9-5g-for-next-7897cbb0f42c
Best regards,
--
Jérôme de Bretagne <jerome.debretagne@gmail.com>
^ permalink raw reply
* [PATCH v2 02/10] arm64: dts: qcom: sc8280xp-arcata: Enable the eDP display
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Add the vreg_edp_3p3, edp_reg_en and mdss0_dp3 nodes to enable the
Surface Pro 9 5G eDP-based LCD display (LG LP129WT232166).
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 64 ++++++++++++++++++++--
1 file changed, 59 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index f24f60dc73afea6eeee0ea26472cda3223811752..476e17415da273330e3638e040db9cd4ed408bf1 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -136,6 +136,22 @@ pmic_glink_con1_sbu: endpoint {
};
};
+ vreg_edp_3p3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_EDP_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 36 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&edp_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
vreg_nvme: regulator-nvme {
compatible = "regulator-fixed";
@@ -344,7 +360,6 @@ vreg_l6b: ldo6 {
regulator-max-microvolt = <880000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
regulator-boot-on;
- regulator-always-on; // FIXME: VDD_A_EDP_0_0P9
};
};
@@ -448,10 +463,6 @@ &dispcc0 {
status = "okay";
};
-&dispcc1 {
- status = "okay";
-};
-
&gpi_dma0 {
status = "okay";
};
@@ -494,6 +505,42 @@ &mdss0_dp1_out {
remote-endpoint = <&usb_1_qmpphy_dp_in>;
};
+&mdss0_dp3 {
+ compatible = "qcom,sc8280xp-edp";
+ /delete-property/ #sound-dai-cells;
+
+ data-lanes = <0 1 2 3>;
+
+ status = "okay";
+
+ aux-bus {
+ panel {
+ compatible = "edp-panel";
+
+ backlight = <&backlight>;
+ power-supply = <&vreg_edp_3p3>;
+
+ port {
+ edp_panel_in: endpoint {
+ remote-endpoint = <&mdss0_dp3_out>;
+ };
+ };
+ };
+ };
+};
+
+&mdss0_dp3_out {
+ remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss0_dp3_phy {
+ compatible = "qcom,sc8280xp-edp-phy";
+ vdda-phy-supply = <&vreg_l6b>;
+ vdda-pll-supply = <&vreg_l3b>;
+
+ status = "okay";
+};
+
&pcie2a {
perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
@@ -910,6 +957,13 @@ hstp-sw-ctrl-pins {
};
};
+ edp_reg_en: edp-reg-en-state {
+ pins = "gpio36";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
nvme_reg_en: nvme-reg-en-state {
pins = "gpio135";
function = "gpio";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 04/10] arm64: dts: qcom: sc8280xp-arcata: Fix top USB-C DP alt mode
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Jens Glathe, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
The top USB-C port (usb0) didn't switch to DP alt mode, as reusing the
same GPIO 101 as on the SC8280XP CRD or Lenovo ThinkPad X13s was not
working on the Surface Pro 9 5G.
Investigation [1] by Jens on the Windows Dev Kit (WDK2023), the other
sc8280xp-based "blackrock" model from Microsoft, found a reference
to GPIO 100 in the DSDT in addition to 101. Switching to GPIO 100
fixed the issue on blackrock, as it does on arcata to enable
external screen when using the left-side top USB-C port.
[1] https://lore.kernel.org/all/20250609-blackrock-usb0-mux-v1-1-7903c3b071e4@oldschoolsolutions.biz/
Cc: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Fixes: f6231a2eefd4 ("arm64: dts: qcom: sc8280xp: Add Microsoft Surface Pro 9 5G")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index c3b143ed11c73b7c1bedc576c10af8db30effc36..9abb52e3763715c8f72f8c95c068fd0b32901a1d 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -270,7 +270,7 @@ map1 {
usb0-sbu-mux {
compatible = "pericom,pi3usb102", "gpio-sbu-mux";
- enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&tlmm 100 GPIO_ACTIVE_LOW>;
select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&usb0_sbu_default>;
@@ -1079,7 +1079,7 @@ tx-pins {
usb0_sbu_default: usb0-sbu-state {
oe-n-pins {
- pins = "gpio101";
+ pins = "gpio100";
function = "gpio";
bias-disable;
drive-strength = <16>;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 07/10] arm64: dts: qcom: sc8280xp-arcata: Add lid switch
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Enable the lid switch for the Microsoft Surface Pro 9 5G using
GPIO pin 180.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
.../arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index 4e601eb4165b1eea16d2772786ac0a18f6177e60..f92c37bfe9c72d1854ab9893747991da9cbf033e 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sc8280xp.dtsi"
@@ -59,7 +60,7 @@ backlight: backlight {
gpio-keys {
compatible = "gpio-keys";
- pinctrl-0 = <&vol_down_n>, <&vol_up_n>;
+ pinctrl-0 = <&hall_int_n_default>, <&vol_down_n>, <&vol_up_n>;
pinctrl-names = "default";
key-vol-down {
@@ -79,6 +80,15 @@ key-vol-up {
linux,can-disable;
wakeup-source;
};
+
+ switch-lid {
+ label = "lid";
+ gpios = <&tlmm 180 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ wakeup-source;
+ wakeup-event-action = <EV_ACT_DEASSERTED>;
+ };
};
pmic-glink {
@@ -1010,6 +1020,13 @@ edp_reg_en: edp-reg-en-state {
bias-disable;
};
+ hall_int_n_default: hall-int-n-state {
+ pins = "gpio180";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
nvme_reg_en: nvme-reg-en-state {
pins = "gpio135";
function = "gpio";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 09/10] arm64: dts: qcom: sc8280xp-arcata: Switch to uefi rtc offset
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Align with the reference implementation from the ThinkPad X13s:
Switch to using the Qualcomm specific UEFI variable that is used by the
UEFI firmware (and Windows) to store the RTC offset.
Use the new 'qcom,uefi-rtc-info' property to indicate that the offset is
stored in a UEFI variable so that the OS can determine whether to wait
for it to become available.
Cc: Johan Hovold <johan@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index d1f72cddebf1df7b67be698a77656532d2f74766..60f65fd450ecba8196509a620be029314e5efc05 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -732,20 +732,11 @@ &pmk8280_pon_resin {
};
&pmk8280_rtc {
- nvmem-cells = <&rtc_offset>;
- nvmem-cell-names = "offset";
+ qcom,uefi-rtc-info;
status = "okay";
};
-&pmk8280_sdam_6 {
- status = "okay";
-
- rtc_offset: rtc-offset@bc {
- reg = <0xbc 0x4>;
- };
-};
-
&qup0 {
status = "okay";
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 10/10] arm64: dts: qcom: sc8280xp-arcata: Drop duplicate DMIC supplies
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Stephan Gerhold, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Align with the reference implementation from the ThinkPad X13s.
The audio-routing setup specifies two power supplies for each DMIC,
but only one of them can be active at the same time.
Drop the redundant routes to the pull-up "VA MIC BIASn" supplies as
done in commit a2e617f4e698 ("arm64: dts: qcom: sc8280xp-x13s: Drop
duplicate DMIC supplies").
There is no functional difference except that we skip briefly switching
to pull-up mode when shutting down the microphone.
Cc: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index 60f65fd450ecba8196509a620be029314e5efc05..74e218cf8aaaa5658982c5cda0b231802712650d 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -776,9 +776,6 @@ &sound {
"VA DMIC0", "MIC BIAS1",
"VA DMIC1", "MIC BIAS1",
"VA DMIC2", "MIC BIAS3",
- "VA DMIC0", "VA MIC BIAS1",
- "VA DMIC1", "VA MIC BIAS1",
- "VA DMIC2", "VA MIC BIAS3",
"TX SWR_ADC1", "ADC2_OUTPUT";
wcd-playback-dai-link {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 05/10] arm64: dts: qcom: sc8280xp-arcata: Enable 4-lane DP support
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Allow up to 4 lanes for the DisplayPort link from the PHYs to the
controllers and allow mode-switch events to reach the QMP Combo PHYs
for the 2 left-side USB-C ports.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index 9abb52e3763715c8f72f8c95c068fd0b32901a1d..10fafd752734450ecddb2113ff972a08793a763c 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -494,7 +494,7 @@ &mdss0_dp0 {
};
&mdss0_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_0_qmpphy_dp_in>;
};
@@ -503,7 +503,7 @@ &mdss0_dp1 {
};
&mdss0_dp1_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_1_qmpphy_dp_in>;
};
@@ -840,6 +840,7 @@ &usb_0_qmpphy {
vdda-phy-supply = <&vreg_l9d>;
vdda-pll-supply = <&vreg_l4d>;
+ mode-switch;
orientation-switch;
status = "okay";
@@ -877,6 +878,7 @@ &usb_1_qmpphy {
vdda-phy-supply = <&vreg_l4b>;
vdda-pll-supply = <&vreg_l3b>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.47.3
^ permalink raw reply related
* [PATCH v2 08/10] arm64: dts: qcom: sc8280xp-arcata: model the PMU of the on-board wcn6855
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Bartosz Golaszewski, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Align the Surface Pro 9 5G with the other sc8280xp-based models as done in
this patch series [1] from Bartosz.
Add a node for the PMU of the WCN6855 and rework the inputs of the wifi
and bluetooth nodes to consume the PMU's outputs.
With this we can drop the regulator-always-on properties from vreg_s11b
and vreg_s12b as they will now be enabled by the power sequencing
driver.
Use the fixed BT vddrfa1p7-supply supply name to align with bindings.
[1] https://lore.kernel.org/all/20241018-sc8280xp-pwrseq-v6-0-8da8310d9564@linaro.org/
Cc: Bartosz Golaszewski <brgl@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 103 ++++++++++++++++++---
1 file changed, 89 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index f92c37bfe9c72d1854ab9893747991da9cbf033e..d1f72cddebf1df7b67be698a77656532d2f74766 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -340,6 +340,70 @@ usb1_sbu_mux: endpoint {
};
};
};
+
+ wcn6855-pmu {
+ compatible = "qcom,wcn6855-pmu";
+
+ pinctrl-0 = <&bt_default>, <&wlan_en>;
+ pinctrl-names = "default";
+
+ wlan-enable-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 132 GPIO_ACTIVE_HIGH>;
+
+ vddio-supply = <&vreg_s10b>;
+ vddaon-supply = <&vreg_s12b>;
+ vddpmu-supply = <&vreg_s12b>;
+ vddpmumx-supply = <&vreg_s12b>;
+ vddpmucx-supply = <&vreg_s12b>;
+ vddrfa0p95-supply = <&vreg_s12b>;
+ vddrfa1p3-supply = <&vreg_s11b>;
+ vddrfa1p9-supply = <&vreg_s1c>;
+ vddpcie1p3-supply = <&vreg_s11b>;
+ vddpcie1p9-supply = <&vreg_s1c>;
+
+ regulators {
+ vreg_pmu_rfa_cmn_0p8: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn_0p8";
+ };
+
+ vreg_pmu_aon_0p8: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p8";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p8: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p8";
+ };
+
+ vreg_pmu_btcmx_0p8: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p8";
+ };
+
+ vreg_pmu_pcie_1p8: ldo5 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo6 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_rfa_0p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo8 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo9 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+ };
+ };
};
&apps_rsc {
@@ -366,7 +430,6 @@ vreg_s11b: smps11 {
regulator-min-microvolt = <1272000>;
regulator-max-microvolt = <1272000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- regulator-always-on;
};
vreg_s12b: smps12 {
@@ -374,7 +437,6 @@ vreg_s12b: smps12 {
regulator-min-microvolt = <984000>;
regulator-max-microvolt = <984000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- regulator-always-on;
};
vreg_l3b: ldo3 {
@@ -636,6 +698,16 @@ wifi@0 {
compatible = "pci17cb,1103";
reg = <0x10000 0x0 0x0 0x0 0x0>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
+
qcom,calibration-variant = "MS_SP9_5G";
};
};
@@ -820,20 +892,16 @@ &uart2 {
bluetooth {
compatible = "qcom,wcn6855-bt";
- vddio-supply = <&vreg_s10b>;
- vddbtcxmx-supply = <&vreg_s12b>;
- vddrfacmn-supply = <&vreg_s12b>;
- vddrfa0p8-supply = <&vreg_s12b>;
- vddrfa1p2-supply = <&vreg_s11b>;
- vddrfa1p7-supply = <&vreg_s1c>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
max-speed = <3200000>;
-
- enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
- swctrl-gpios = <&tlmm 132 GPIO_ACTIVE_HIGH>;
-
- pinctrl-0 = <&bt_default>;
- pinctrl-names = "default";
};
};
@@ -1179,4 +1247,11 @@ reset-pins {
bias-disable;
};
};
+
+ wlan_en: wlan-en-state {
+ pins = "gpio134";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 06/10] arm64: dts: qcom: sc8280xp-arcata: Add volume up/down GPIO keys
From: Jérôme de Bretagne via B4 Relay @ 2026-05-22 10:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Jérôme de Bretagne, Konrad Dybcio
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com>
From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Configure gpio6 to serve as volume down and gpio9 as volume up to enable
the volume up/down keys located at the top of the screen.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
.../boot/dts/qcom/sc8280xp-microsoft-arcata.dts | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
index 10fafd752734450ecddb2113ff972a08793a763c..4e601eb4165b1eea16d2772786ac0a18f6177e60 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sc8280xp.dtsi"
@@ -55,6 +56,31 @@ backlight: backlight {
pinctrl-names = "default";
};
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&vol_down_n>, <&vol_up_n>;
+ pinctrl-names = "default";
+
+ key-vol-down {
+ label = "Volume Down";
+ gpios = <&pmc8280_1_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEDOWN>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+
+ key-vol-up {
+ label = "Volume Up";
+ gpios = <&pmc8280_1_gpios 9 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
pmic-glink {
compatible = "qcom,sc8280xp-pmic-glink", "qcom,pmic-glink";
@@ -922,6 +948,22 @@ edp_bl_en: edp-bl-en-state {
pins = "gpio8";
function = "normal";
};
+
+ vol_down_n: vol-down-n-state {
+ pins = "gpio6";
+ function = "normal";
+ power-source = <1>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ vol_up_n: vol-up-n-state {
+ pins = "gpio9";
+ function = "normal";
+ power-source = <1>;
+ input-enable;
+ bias-pull-up;
+ };
};
&pmc8280_2_gpios {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v6 05/16] remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
From: Sumit Garg @ 2026-05-22 10:44 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260519073355.98831C2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 07:33:55AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [Critical] Unconditionally calling `qcom_scm_assign_mem()` without checking SCM availability causes a NULL pointer dereference on non-SCM platforms.
> - [High] MDT firmware loading is not abstracted and continues to hardcode SCM APIs, causing both a build warning and functional failure on non-SCM backends.
> - [High] The DTB subsystem (dtb_pas_id) is authenticated but never shut down in the error paths of qcom_pas_start().
> - [High] The firmware object pas->dtb_firmware is leaked on the success path of qcom_pas_load().
> --
>
> commit e21bc74de5d7e3215e46e9baa1c3a6b26f353409
> Author: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
>
> This patch switches the qcom_q6v5_pas client driver over to generic PAS TZ
> APIs. This allows supporting multiple TrustZone implementation backends
> such as QTEE and OP-TEE.
>
> > diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> > index da27d1d3c9da6..847249c28c1be 100644
> > --- a/drivers/remoteproc/qcom_q6v5_pas.c
> > +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> [ ... ]
> > @@ -118,8 +119,8 @@ struct qcom_pas {
> > struct qcom_rproc_ssr ssr_subdev;
> > struct qcom_sysmon *sysmon;
> >
> > - struct qcom_scm_pas_context *pas_ctx;
> > - struct qcom_scm_pas_context *dtb_pas_ctx;
> > + struct qcom_pas_context *pas_ctx;
> > + struct qcom_pas_context *dtb_pas_ctx;
> > };
>
> Does changing this struct cause a compiler warning and functional regression
> for non-SCM backends?
>
> Since this patch changes the context type to struct qcom_pas_context * but
> still passes it to qcom_mdt_pas_load(), it appears to cause an incompatible
> pointer type warning.
>
> Furthermore, qcom_mdt_pas_load() internally hardcodes calls to SCM-specific
> APIs like qcom_scm_pas_init_image(), bypassing the generic PAS backend
> entirely. This seems to prevent the driver from working on non-SCM backends
> like OP-TEE.
>
> I notice this is fixed later in the series in the commit "soc: qcom:
> mdtloader: Switch to generic PAS TZ APIs", but I am pointing it out here as
> it breaks the build and functionality at this step.
Ack, will rather merge the mdtloader patch into this one instead to
enable git bisection.
>
> [ ... ]
> > @@ -250,7 +251,7 @@ static int qcom_pas_load(struct rproc *rproc, const struct firmware *fw)
> > return 0;
> >
> > release_dtb_metadata:
> > - qcom_scm_pas_metadata_release(pas->dtb_pas_ctx);
> > + qcom_pas_metadata_release(pas->dtb_pas_ctx);
> > release_firmware(pas->dtb_firmware);
> >
> > return ret;
>
> Is there a pre-existing resource leak here?
>
> When request_firmware() allocates the DTB firmware and qcom_mdt_pas_load()
> succeeds, the function returns 0 and skips the release_dtb_metadata label
> where release_firmware() is called.
>
> The pas->dtb_firmware pointer appears to be retained but never freed in any
> teardown function like qcom_pas_unprepare() or qcom_pas_stop(). Could this
> permanently leak the firmware object and its backing buffer on every
> successful start?
Out of scope for this patch-set.
>
> [ ... ]
> > @@ -339,13 +340,13 @@ static int qcom_pas_start(struct rproc *rproc)
> > ret = qcom_q6v5_wait_for_start(&pas->q6v5, msecs_to_jiffies(5000));
> > if (ret == -ETIMEDOUT) {
> > dev_err(pas->dev, "start timed out\n");
> > - qcom_scm_pas_shutdown(pas->pas_id);
> > + qcom_pas_shutdown(pas->pas_id);
> > goto unmap_carveout;
> > }
>
> Does this error path miss shutting down the DTB subsystem?
>
> While this was not introduced by this patch, if the DTB authentication
> step earlier in this function succeeds, but a subsequent step like
> qcom_q6v5_wait_for_start() fails, the error path shuts down the main PAS but
> misses calling qcom_pas_shutdown(pas->dtb_pas_id).
>
> The code then jumps to unmap_dtb_carveout and unmaps the Linux-side memory,
> leaving the DTB subsystem active in TrustZone while its backing memory is
> unmapped.
>
Out of scope for this patch-set.
> [ ... ]
> > @@ -746,7 +747,7 @@ static int qcom_pas_probe(struct platform_device *pdev)
> > if (!desc)
> > return -EINVAL;
> >
> > - if (!qcom_scm_is_available())
> > + if (!qcom_pas_is_available())
> > return -EPROBE_DEFER;
> >
> > fw_name = desc->firmware_name;
>
> Could this change lead to a NULL pointer dereference on non-SCM platforms?
>
> By replacing the qcom_scm_is_available() check with qcom_pas_is_available(),
> the probe function can now continue on platforms using non-SCM backends like
> OP-TEE.
>
> However, further down in probe, qcom_pas_assign_memory_region() is still
> unconditionally called if pas->region_assign_idx is set:
>
> qcom_pas_assign_memory_region()
> qcom_scm_assign_mem()
>
> qcom_scm_assign_mem() accesses __scm->mempool without checking if __scm is
> NULL. On non-SCM platforms, __scm will be NULL, which seems like it would
> cause a kernel panic during probe for devices requiring memory region
> assignment.
qcom_scm_assign_mem() is still supported with an OP-TEE PAS backend too.
-Sumit
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: arduino-monza: add WLAN enable and rfkill GPIO
From: Konrad Dybcio @ 2026-05-22 10:47 UTC (permalink / raw)
To: Qian Zhang
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Bartosz Golaszewski,
Manivannan Sadhasivam, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CALC2J1PqdKGozWX-WapCZSkjGZcM_JjOX29HQ8r7ghKyaBXj_A@mail.gmail.com>
On 5/19/26 4:58 AM, Qian Zhang wrote:
> You're right that GPIO 56 (wlan_en) is consumed by pwrseq-qcom-wcn
> through the wcn6855-pmu node — apologies for the confusion in my
> earlier reply.
> Let me explain the hardware on this board, because it
> differs slightly from the typical WCN6855 reference design and is the
> source of a problem we're now stuck on.
The wording, structure and magic characters within your reply make
me think you're using a LLM to respond to me. I will not entertain
this conversation further if that's the case.
> Hardware
>
> The WLAN module fitted on Monaco-Monza is not a bare WCN6855 — it
> contains an additional, module-internal PMU (PMCA6850) that gates
> power to the WCN6855 die. So the signal chain is:
>
> SoC TLMM gpio56 (wlan_en) ──► PMCA6850 EN ──► WCN6855 rails ──► PCIe link up
>
> wlan_en is therefore the enable pin of PMCA6850, not of the
> WCN6855 itself. From the host's point of view, asserting wlan_en
> brings the module out of reset; the WCN6855 only becomes visible on
> PCIe after PMCA6850 has finished its own ramp-up.
The powerseq driver for WCN PMUs exists precisely to handle this setup.
> Initially we reused the qcom,wcn6855-pmu compatible so that
> pwrseq-qcom-wcn would drive wlan_en for us. But we hit a
> resource-allocation issue this hardware behavior creates.
>
> The problem
>
> Because PMCA6850's enable is driven by pwrseq (which runs after the
> PCI host bridge has scanned the bus), WCN6855 only appears on the bus
> ~10 s after PCIe enumeration has already finished, with no resources
> reserved for it.
>
> Topology — WCN6855 sits behind a Pericom PI7C9X2G304 switch alongside
> a TI USB controller:
>
> pcie0 RC ── 00:00.0 ── 01:00.0 (switch UP)
> ├── 02:01.0 (DN) ── 03:00.0 WCN6855 (BAR0 = 2
> MB, appears late)
> └── 02:02.0 (DN) ── 04:00.0 TUSB7340 (BAR0 =
> 64K, BAR2 = 8K, present at boot)
>
> dmesg (kernel 6.8.0-1071-qcom):
> [ 5.545559] qcom-pcie 1c00000.pci: PCIe Gen.2 x1 link up
> [ 5.882178] pci 0000:00:00.0: bridge window [mem
> 0x40400000-0x404fffff]: assigned
> [ 5.912197] pci 0000:02:01.0: PCI bridge to [bus 03]
> [ 5.917368] pci 0000:04:00.0: BAR 0 [mem 0x40400000-0x4040ffff
> 64bit]: assigned
> [ 5.924919] pci 0000:04:00.0: BAR 2 [mem 0x40410000-0x40411fff
> 64bit]: assigned
> [ 16.476921] pci 0000:03:00.0: [17cb:1103] type 00 class 0x028000
> PCIe Endpoint
> [ 16.477176] pci 0000:03:00.0: BAR 0 [mem 0x00000000-0x001fffff 64bit]
> [ 16.516689] pcieport 0000:02:01.0: bridge window [mem size
> 0x00200000]: can't assign; no space
> [ 16.516704] pcieport 0000:02:01.0: bridge window [mem size
> 0x00200000]: failed to assign
> [ 16.516713] pci 0000:03:00.0: BAR 0 [mem size 0x00200000 64bit]:
> can't assign; no space
> [ 16.516720] pci 0000:03:00.0: BAR 0 [mem size 0x00200000 64bit]:
> failed to assign
> [ 18.093137] ath11k_pci 0000:03:00.0: Adding to iommu group 24
> [ 18.101694] ath11k_pci 0000:03:00.0: BAR 0 [??? 0x00000000 flags
> 0x20000000]: can't assign; bogus alignment
> [ 18.101724] ath11k_pci 0000:03:00.0: failed to assign pci resource: -22
> [ 18.108613] ath11k_pci 0000:03:00.0: failed to claim device: -22
> [ 18.115481] ath11k_pci: probe of 0000:03:00.0 failed with error -22
>
> At the initial scan the PCI core sizes the root-port window to 1 MB
> based only on the TI USB endpoint that is currently visible, and
> gives the 02:01.0 downstream port no MMIO window at all. When
> WCN6855 appears later it requires a 2 MB BAR0 and there is nowhere
> to put it.
This is a separate issue that needs fixing. I see Mani is already
part of the thread, maybe he can take a peek
Konrad
^ permalink raw reply
* Re: [PATCH v8 2/9] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
From: Erikas Bitovtas @ 2026-05-22 10:48 UTC (permalink / raw)
To: Taniya Das, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd,
Brian Masney
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <6ae3a89c-f205-45c5-87c0-5550f78502d6@oss.qualcomm.com>
On 5/21/26 12:29 PM, Taniya Das wrote:
>
>
> On 5/20/2026 2:02 PM, Bryan O'Donoghue wrote:
>> On 19/05/2026 16:10, Erikas Bitovtas wrote:
>>> Allow Venus core GDSCs to have their control passed to hardware, so they
>>> can be powered on by Venus firmware.
>>>
>>> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
>>> ---
>>> drivers/clk/qcom/gcc-msm8939.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/clk/qcom/gcc-msm8939.c b/drivers/clk/qcom/gcc-
>>> msm8939.c
>>> index 45193b3d714b..243d31a32e92 100644
>>> --- a/drivers/clk/qcom/gcc-msm8939.c
>>> +++ b/drivers/clk/qcom/gcc-msm8939.c
>>> @@ -3664,6 +3664,7 @@ static struct clk_branch gcc_venus0_vcodec0_clk = {
>>>
>>> static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
>>> .halt_reg = 0x4c02c,
>>> + .halt_check = BRANCH_HALT_SKIP,
>
> please use .halt_check = BRANCH_HALT
>
If I do that, the clock fails to power on on boot.
[ 20.324488] ------------[ cut here ]------------
[ 20.324520] gcc_venus0_core0_vcodec0_clk status stuck at 'off'
[ 20.324663] WARNING: drivers/clk/qcom/clk-branch.c:88 at
clk_branch_toggle+0x124/0x170, CPU#7: (udev-worker)/1010
[ 20.324723] Modules linked in: snd_soc_apq8016_sbc(+)
snd_soc_qcom_common venus_core(+) qcom_q6v5_mss(+) v4l2_mem2mem
qcom_pil_info videobuf2_v4l2 qcom_common qcom_q6v5 videobuf2_common
videodev mc qcom_memshare tun binfmt_misc nft_reject_inet nft_reject
nf_reject_ipv6 nf_reject_ipv4 nft_ct nf_conntrack zram nf_defrag_ipv6
nf_defrag_ipv4 zsmalloc lz4_compress zstd_compress nf_tables uhid uinput
fuse nfnetlink ipv6 xfs usb_f_ncm u_ether panel_asus_z00t_tm5p5_nt35596
edt_ft5x06 pm8916_bms_vm msm ubwc_config mdt_loader gpu_sched drm_gpuvm
drm_exec drm_display_helper cec libcomposite
[ 20.325245] CPU: 7 UID: 0 PID: 1010 Comm: (udev-worker) Not tainted
7.0.0-msm8916 #41 PREEMPT
[ 20.325273] Hardware name: Asus ZenFone 2 Laser/Selfie (1080p) (DT)
[ 20.325290] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 20.325314] pc : clk_branch_toggle+0x124/0x170
[ 20.325348] lr : clk_branch_toggle+0x120/0x170
[ 20.325377] sp : ffff800082ab3430
[ 20.325390] x29: ffff800082ab3440 x28: 0000000000000001 x27:
ffff0000236724c0
[ 20.325435] x26: 0000000000000002 x25: ffff0000236724c0 x24:
0000000000000000
[ 20.325477] x23: 0000000000000000 x22: ffff800081017b3e x21:
ffff8000813e9f38
[ 20.325519] x20: ffff8000806f7f50 x19: 0000000000000001 x18:
0000000000000000
[ 20.325560] x17: 0000000000000001 x16: 0000000000000800 x15:
0000000000000003
[ 20.325601] x14: ffff800081315120 x13: 0000000000000003 x12:
0000000000000003
[ 20.325643] x11: 0000000000000000 x10: 0000000000000027 x9 :
ebcfd48ff0c24800
[ 20.325684] x8 : ebcfd48ff0c24800 x7 : 7461206b63757473 x6 :
0000000000000027
[ 20.325725] x5 : ffff80008151038a x4 : ffff800080fc8d13 x3 :
0000000000000000
[ 20.325766] x2 : 0000000000000000 x1 : ffff800082ab3200 x0 :
00000000fffffff0
[ 20.325808] Call trace:
[ 20.325821] clk_branch_toggle+0x124/0x170 (P)
[ 20.325859] clk_branch2_enable+0x20/0x30
[ 20.325894] clk_core_enable+0x6c/0x2c8
[ 20.325923] clk_core_enable_lock+0x8c/0x120
[ 20.325960] clk_enable+0x1c/0x30
[ 20.325994] vcodec_clks_enable+0x4c/0xc8 [venus_core]
[ 20.326190] core_power_v1+0x270/0x2c0 [venus_core]
[ 20.326370] venus_runtime_resume+0x58/0x80 [venus_core]
[ 20.326548] pm_generic_runtime_resume+0x2c/0x48
[ 20.326579] __rpm_callback+0x80/0x470
[ 20.326609] rpm_resume+0x3cc/0x5f8
[ 20.326637] __pm_runtime_resume+0x4c/0x98
[ 20.326665] venus_probe+0x1fc/0x3b8 [venus_core]
[ 20.326844] platform_probe+0x60/0xa8
[ 20.326881] really_probe+0x154/0x448
[ 20.326911] __driver_probe_device+0xa4/0x120
[ 20.326943] driver_probe_device+0x44/0x230
[ 20.326973] __driver_attach+0xf0/0x280
[ 20.327003] bus_for_each_dev+0xf0/0x150
[ 20.327031] driver_attach+0x28/0x38
[ 20.327061] bus_add_driver+0x14c/0x2a8
[ 20.327088] driver_register+0x6c/0x108
[ 20.327119] __platform_driver_register+0x24/0x38
[ 20.327154] init_module+0x24/0xfb8 [venus_core]
[ 20.327332] do_one_initcall+0xe4/0x3e0
[ 20.327363] do_init_module+0x5c/0x248
[ 20.327393] load_module+0x16ac/0x18c0
[ 20.327421] __arm64_sys_finit_module+0x238/0x360
[ 20.327449] invoke_syscall+0x44/0xd8
[ 20.327483] el0_svc_common+0x84/0xe0
[ 20.327515] do_el0_svc+0x20/0x30
[ 20.327547] el0_svc+0x24/0x70
[ 20.327582] el0t_64_sync_handler+0x7c/0x120
[ 20.327616] el0t_64_sync+0x154/0x158
[ 20.327643] ---[ end trace 0000000000000000 ]---
^ permalink raw reply
* Re: [PATCH 3/4] PCI: qcom: Add Support for Eliza
From: Manivannan Sadhasivam @ 2026-05-22 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Krishna Chaitanya Chundru, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <c751f5f9-f9c2-4575-a029-0be4148e1aee@kernel.org>
On Fri, May 22, 2026 at 11:34:30AM +0200, Krzysztof Kozlowski wrote:
> On 22/05/2026 11:31, Krishna Chaitanya Chundru wrote:
> >
> >
> > On 5/22/2026 12:21 PM, Krzysztof Kozlowski wrote:
> >> On Thu, May 21, 2026 at 07:35:31PM +0530, Krishna Chaitanya Chundru wrote:
> >>> Add support for Eliza soc, which has two PCIe controllers capable
> >>> of 8GT/s X1 and 8GT/s X2, using the cfg_1_9_0 configuration.
> >>>
> >>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> >>> ---
> >>> drivers/pci/controller/dwc/pcie-qcom.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> >>> index af6bf5cce65b..40f0a5f247eb 100644
> >>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> >>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> >>> @@ -2123,6 +2123,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
> >>> static const struct of_device_id qcom_pcie_match[] = {
> >>> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
> >>> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
> >>> + { .compatible = "qcom,pcie-eliza", .data = &cfg_1_9_0 },
> >> So compatible with sm8550. Why isn't this explained in commit msg of
> >> the binding?
> > No, PCIe controller is not compatible with sm8550, we are just re using the boot
> > sequence used by the sm8550.
>
> Then with what it is compatible? You cannot use someone else's match
> data and claim they are not compatible. This is contradictory to itself.
>
'cfg_1_9_0' is the match data of base PCIe IP v1.9.0, not just SM8550. The 'ops'
callbacks for 'cfg_1_9_0' are compatible with PCIe IPs used in many SoCs such as
SM8550, SM8450, SM8350, SM8250, SM8150, SDX55, SC8180X, and SC7280. And Eliza is
also falling into the same category.
@Krishna: You need to reword the commit message to clearly state the fact that
PCIe controller found in Eliza SoC is compatible with base IP version 1.9.0, so
it reuses 'cfg_1_9_0' match data.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH] arm64: dts: qcom: qcs615-ride: fix sdhc_2 vqmmc-supply for UHS-I mode
From: monish.chunara @ 2026-05-22 10:50 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, linux-mmc, ulf.hansson,
nitin.rawat, pradeep.pragallapati, komal.bajaj, monish.chunara,
jsodhapa
From: Monish Chunara <monish.chunara@oss.qualcomm.com>
SD card is detected as SDHS instead of UHS-I because sdhc_2 was
configured with vreg_s4a as vqmmc-supply, which cannot switch
between 1.8V and 3.3V.
Switch vqmmc-supply to vreg_l2a and update its voltage range to
1800000-2960000 uV to enable proper UHS-I signaling.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index 51b13b492472..047b4efb04b9 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -232,8 +232,8 @@ vreg_l1a: ldo1 {
vreg_l2a: ldo2 {
regulator-name = "vreg_l2a";
- regulator-min-microvolt = <1650000>;
- regulator-max-microvolt = <3100000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2960000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
regulator-allow-set-load;
regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
@@ -599,7 +599,7 @@ &sdhc_2 {
cd-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
vmmc-supply = <&vreg_l10a>;
- vqmmc-supply = <&vreg_s4a>;
+ vqmmc-supply = <&vreg_l2a>;
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 14/16] wifi: ath12k: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-05-22 10:51 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260519073409.91EC8C2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 07:34:08AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The transition from `QCOM_SCM` to the generic `QCOM_PAS` framework introduces an asynchronous probing bug where `ath12k` fails to check if the PAS backend is available, causing permanent probe failures.
> --
>
> commit 9d619dc2a0265a4c4b222e1e790293c324c3c591
> Author: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> wifi: ath12k: Switch to generic PAS TZ APIs
>
> This commit switches the ath12k client driver over to the generic PAS TZ
> APIs. This abstracts the TZ implementation, allowing the driver to support
> multiple backends such as the QTEE based SCM PAS service or OP-TEE based
> PAS service.
>
> > diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
> > --- a/drivers/net/wireless/ath/ath12k/ahb.c
> > +++ b/drivers/net/wireless/ath/ath12k/ahb.c
>
> [ ... ]
>
> > @@ -420,7 +420,7 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
> >
> > if (ab_ahb->scm_auth_enabled) {
> > /* Authenticate FW image using peripheral ID */
> > - ret = qcom_scm_pas_auth_and_reset(pasid);
> > + ret = qcom_pas_auth_and_reset(pasid);
> > if (ret) {
> > ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
> > goto err_fw2;
>
> Does this change introduce an asynchronous probing failure?
>
> Since the generic QCOM_PAS layer allows its backends (like QCOM_SCM or
> QCOM_PAS_TEE) to be built as loadable modules, the ath12k_ahb driver might
> probe before the backend has registered its operations.
>
> If that happens, qcom_pas_auth_and_reset() returns -ENODEV:
>
> drivers/firmware/qcom/qcom_pas.c:qcom_pas_auth_and_reset() {
> if (!ops_ptr)
> return -ENODEV;
>
> return ops_ptr->auth_and_reset(ops_ptr->dev, pas_id);
> }
>
> Because this returns -ENODEV instead of -EPROBE_DEFER, the ath12k_ahb driver
> will treat this as a fatal hardware initialization error. The kernel driver
> core will not retry the probe, resulting in a permanent failure.
>
> Should the driver be updated to check if the PAS backend is available and
> explicitly return -EPROBE_DEFER if it is not yet registered?
QCOM_SCM was already allowed to be built as a module, so not in scope of
this patch-set.
-Sumit
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518072856.22790-1-sumit.garg@kernel.org?part=14
^ permalink raw reply
* Re: [PATCH v1 2/2] iio: adc: Add StarFive SAR-ADC driver
From: Jonathan Cameron @ 2026-05-22 10:52 UTC (permalink / raw)
To: Xingyu Wu
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
In-Reply-To: <NTZPR01MB095660868B0DE59B2B0161CC9F0F2@NTZPR01MB0956.CHNPR01.prod.partner.outlook.cn>
On Fri, 22 May 2026 02:20:53 +0000
Xingyu Wu <xingyu.wu@starfivetech.com> wrote:
> On 2026/5/21 19:37, Jonathan Cameron wrote:
> >
> > >
> > > >
> > > > > +
> > > > > + starfive_saradc_ch_monitor_stop(priv, ch);
> > > >
> > > > Why stop it? Add a comment. We aren't interested in future events?
> > >
> > > If we do not stop it and the input voltage remains constant, the ADC could
> > continuously monitor the voltage and continuously trigger interrupts for the
> > bound.
> > > As a result, the CPU utilization rate will be high.
> >
> > Can you use an edge interrupt instead of a level one?
>
> No, it is a level interrupt in hardware.
Just to check. That's a restriction of the interrupt controller IP in that
it doesn't support edge interrupts on this particularly line?
Seems unfortunate given the block on the other end is providing something
that seems like an edge :( Ah well - hardly the first time we've hit that.
Add some comments to the code when you add the timer approach to
re enabling.
>
> >
> > If not, then a common solution is to disable for a period (maybe a second or so)
> > then reenable. There are various more refined ways of doing this.
>
> This is good idea. How about using timer to disable it?
yes, there are examples in tree doing that.
J
>
> >
> > Basically we don't want to be in a situation where a momentary blip disables the
> > event and we miss a later condition that must be handled.
> >
>
> Noted.
>
> Best regards,
> Xingyu Wu
^ permalink raw reply
* Re: [PATCH V8 02/10] dt-bindings: iio: imu: icm42600: Add icm42607 binding
From: Jonathan Cameron @ 2026-05-22 10:54 UTC (permalink / raw)
To: Conor Dooley
Cc: Chris Morgan, Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko, Krzysztof Kozlowski
In-Reply-To: <20260521-challenge-flaccid-26b6f5d2d0bd@spud>
On Thu, 21 May 2026 21:08:07 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Thu, May 21, 2026 at 12:43:09PM -0500, Chris Morgan wrote:
> > On Thu, May 21, 2026 at 05:44:21PM +0100, Conor Dooley wrote:
> > > On Wed, May 20, 2026 at 05:42:17PM +0100, Jonathan Cameron wrote:
> > > > On Mon, 18 May 2026 15:05:17 -0500
> > > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > > >
> > > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > > >
> > > > > Add devicetree binding for the Invensense ICM42607 and Invensense
> > > > > ICM42607P inertial measurement unit. This unit is a combined
> > > > > accelerometer, gyroscope, and thermometer available via I2C or SPI.
> > > > >
> > > > > This device is functionally very similar to the icm42600 series with a
> > > > > very different register layout.
> > > > >
> > > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > > Note that Sashiko has highlighted that the binding this being added to
> > > > has a potential problem.
> > > >
> > > > interrupts are required but interrupt-names are not.
> > > > That would be fine but the binding doesn't say there is a default
> > > > ordering for the interrupts - so if we don't have names we have no
> > > > idea which interrupt it is.
> > > >
> > > > This needs fixing - probably by adding a default
> > >
> > > Worth pointing out that this isn't an issue with this particular patch,
> > > the problem exists in mainline.
> >
> > The driver I lovingly borrowed this code from seems to have fallback
> > logic, basically picking the first interrupt if it couldn't find one
> > named "INT1". I was told early on not to do this that way, so in my
> > case the interrupt-names would be required (but not for the existing
> > driver because of this fallback).
> >
Ah, so it has a default that we've elected not to document.
I can't remember the history of that - probably similar discussion about
there being no right default when there are two (near?) identical operating interrupt
pins.
> > Should I make the requirement conditional just to my compatible
> > strings?
>
> Sure, sounds like a good idea to me
Agreed - that closes this for this part without spitting lots of warnings
for the older one.
J
^ permalink raw reply
* Re: [PATCH RFC v4 5/9] phy: qcom: qmp-pcie: Refactor pipe clk register and parse_dt helpers
From: Manivannan Sadhasivam @ 2026-05-22 10:57 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Qiang Yu, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <ipzncrxi3x45fc6tz5xb7frxt62zmg4gwr25xmvzghlbt5miio@7eavln3cydfa>
On Wed, May 20, 2026 at 07:25:01PM +0300, Dmitry Baryshkov wrote:
> On Mon, May 18, 2026 at 10:47:16PM -0700, Qiang Yu wrote:
> > Some QMP PCIe PHY hardware blocks can be split into multiple sub-PHYs
> > under a single DT node, each requiring its own pipe clock registration and
> > DT resource mapping. The current helpers are tightly coupled to a single
> > qmp_pcie instance, which prevents reuse across sub-PHY instances.
> >
> > Refactor __phy_pipe_clk_register() as a generic helper and reduce
> > phy_pipe_clk_register() to a thin wrapper around it. Similarly, extract
> > qmp_pcie_parse_dt_common() from qmp_pcie_parse_dt() to hold the register-
> > mapping and pipe-clock setup that will be shared between sub-PHY instances,
> > with pipe clock names parameterised per instance.
> >
> > This is a preparatory step before adding multi-PHY support. No functional
> > change for existing platforms.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 76 ++++++++++++++++++--------------
> > 1 file changed, 44 insertions(+), 32 deletions(-)
>
> I'd suggest splitting the Glymur PHY to a separate driver. Otherwise we
> end up having too many single-platform, single-device specifics which
> don't apply to other platforms.
>
I don't think that's really needed. This shared PHY concept is going to be
applicable to upcoming SoCs as well. And moreover, the split won't be clean
either. We still need to reuse a lot of common logic in the 'phy-qcom-qmp-pcie'
driver and may only end up keeping very minimal code in
'phy-qcom-qmp-pcie-glymur'.
If you are concerned about the file size of 'phy-qcom-qmp-pcie', then we should
move the SoC specific 'cfg' structs into a separate file as that's what
occupying majority of the space.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 02/10] arm64: dts: qcom: sc8280xp-arcata: Enable the eDP display
From: sashiko-bot @ 2026-05-22 11:01 UTC (permalink / raw)
To: Jérôme de Bretagne via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-2-dd9d477407f5@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The 'data-lanes' property is incorrectly placed directly within the main '&mdss0_dp3' node.
- [Low] The commit silently removes the `&dispcc1` node block without mentioning it in the commit message.
--
commit 5312e63401d73e35f694eed3e8a7dcb4db6c95e5
Author: Jérôme de Bretagne <jerome.debretagne@gmail.com>
arm64: dts: qcom: sc8280xp-arcata: Enable the eDP display
This commit adds the necessary regulator, pinctrl, and display controller
nodes to enable the eDP LCD display on the Surface Pro 9 5G.
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
> index f24f60dc73afe..476e17415da27 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
[ ... ]
> @@ -448,10 +463,6 @@ &dispcc0 {
> status = "okay";
> };
>
> -&dispcc1 {
> - status = "okay";
> -};
> -
[Severity: Low]
This isn't a bug, but is it intentional to silently remove the &dispcc1
node here?
The commit message focuses on enabling the eDP display and does not mention
removing this block.
> &gpi_dma0 {
> status = "okay";
[ ... ]
> @@ -494,6 +505,42 @@ &mdss0_dp1_out {
> remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> +&mdss0_dp3 {
> + compatible = "qcom,sc8280xp-edp";
> + /delete-property/ #sound-dai-cells;
> +
> + data-lanes = <0 1 2 3>;
[Severity: Low]
Should the data-lanes property be placed inside the controller's output
endpoint node (&mdss0_dp3_out) rather than here in the main &mdss0_dp3 node?
Placing data-lanes in the root controller node is deprecated in the
qcom,dp-controller Devicetree binding and will trigger dtbs_check
validation warnings.
> +
> + status = "okay";
> +
> + aux-bus {
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence
From: sashiko-bot @ 2026-05-22 11:03 UTC (permalink / raw)
To: phucduc.bui; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260522100318.73474-4-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked return value of `pm_runtime_get_sync()` in `rockchip_pdm_set_fmt()` can lead to hardware access while suspended.
- [High] Manual disable of hardware clocks and PM runtime before devm teardown can cause bus faults.
--
commit 8f19ac4b34f49c4a08218121167b705580c4469a
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence
Enable the 'hclk' bus clock before the 'clk' controller clock during runtime
resume. The bus clock provides the register access interface and should be
enabled before the controller clock.
> diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c
> index c69cdd6f24994..8f78f7bc1806c 100644
> --- a/sound/soc/rockchip/rockchip_pdm.c
> +++ b/sound/soc/rockchip/rockchip_pdm.c
[ ... ]
While reviewing this patch, I noticed a couple of pre-existing issues in the
same file:
sound/soc/rockchip/rockchip_pdm.c:rockchip_pdm_set_fmt() {
...
pm_runtime_get_sync(cpu_dai->dev);
regmap_update_bits(pdm->regmap, PDM_CLK_CTRL, mask, val);
pm_runtime_put(cpu_dai->dev);
...
}
[Severity: High]
This isn't a bug introduced by this patch, but is it safe to ignore the
return value of pm_runtime_get_sync() here?
If the runtime resume fails (for example, if clock enablement or power
domain restoration fails), the function ignores the negative error code
and proceeds to call regmap_update_bits().
Accessing hardware registers when the hardware is powered down or unclocked
can lead to a synchronous external abort (bus fault) and a kernel panic.
Should pm_runtime_resume_and_get() be used instead, and the error handled?
sound/soc/rockchip/rockchip_pdm.c:rockchip_pdm_remove() {
...
static void rockchip_pdm_remove(struct platform_device *pdev)
{
struct rk_pdm_dev *pdm = dev_get_drvdata(&pdev->dev);
pm_runtime_disable(&pdev->dev);
if (!pm_runtime_status_suspended(&pdev->dev))
rockchip_pdm_runtime_suspend(&pdev->dev);
clk_disable_unprepare(pdm->clk);
clk_disable_unprepare(pdm->hclk);
}
...
}
[Severity: High]
This is a pre-existing issue, but can manually disabling the clocks and PM
runtime before the devm teardown cause bus faults?
The driver registers the ASoC component using
devm_snd_soc_register_component() in rockchip_pdm_probe(), which defers
unregistration until after the remove() callback returns.
If the device is unbound via sysfs while an audio stream is active, ALSA
will attempt to tear down the stream during the deferred devres
unregistration. This triggers operations like
rockchip_pdm_trigger(SNDRV_PCM_TRIGGER_STOP), which writes to the
hardware registers.
Since the clocks and power domains were already forcibly disabled in
remove(), this could result in a bus fault and kernel panic.
Should the driver use devm_pm_runtime_enable() with a devres action for
clock disable, or unregister the component manually before turning off
resources?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522100318.73474-1-phucduc.bui@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 3/4] PCI: qcom: Add Support for Eliza
From: Krzysztof Kozlowski @ 2026-05-22 11:03 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Krishna Chaitanya Chundru, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Bjorn Andersson,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci
In-Reply-To: <t6wljnlnz77dvthbohlr7v4qlhsqzvykhcm6evmtnvkgtqk34w@o7sl6nq5lkbi>
On 22/05/2026 12:48, Manivannan Sadhasivam wrote:
> On Fri, May 22, 2026 at 11:34:30AM +0200, Krzysztof Kozlowski wrote:
>> On 22/05/2026 11:31, Krishna Chaitanya Chundru wrote:
>>>
>>>
>>> On 5/22/2026 12:21 PM, Krzysztof Kozlowski wrote:
>>>> On Thu, May 21, 2026 at 07:35:31PM +0530, Krishna Chaitanya Chundru wrote:
>>>>> Add support for Eliza soc, which has two PCIe controllers capable
>>>>> of 8GT/s X1 and 8GT/s X2, using the cfg_1_9_0 configuration.
>>>>>
>>>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/pci/controller/dwc/pcie-qcom.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>>>> index af6bf5cce65b..40f0a5f247eb 100644
>>>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>>>> @@ -2123,6 +2123,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
>>>>> static const struct of_device_id qcom_pcie_match[] = {
>>>>> { .compatible = "qcom,pcie-apq8064", .data = &cfg_2_1_0 },
>>>>> { .compatible = "qcom,pcie-apq8084", .data = &cfg_1_0_0 },
>>>>> + { .compatible = "qcom,pcie-eliza", .data = &cfg_1_9_0 },
>>>> So compatible with sm8550. Why isn't this explained in commit msg of
>>>> the binding?
>>> No, PCIe controller is not compatible with sm8550, we are just re using the boot
>>> sequence used by the sm8550.
>>
>> Then with what it is compatible? You cannot use someone else's match
>> data and claim they are not compatible. This is contradictory to itself.
>>
>
> 'cfg_1_9_0' is the match data of base PCIe IP v1.9.0, not just SM8550. The 'ops'
> callbacks for 'cfg_1_9_0' are compatible with PCIe IPs used in many SoCs such as
> SM8550, SM8450, SM8350, SM8250, SM8150, SDX55, SC8180X, and SC7280. And Eliza is
> also falling into the same category.
>
And if all implementations uses the same SW interface, why are you
claiming these are not compatible?
I don't care with which device this is compatible, BTW. I do care about
incomplete or incorrect hardware description.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V8 05/10] iio: imu: inv_icm42607: Add PM support for icm42607
From: Jonathan Cameron @ 2026-05-22 11:05 UTC (permalink / raw)
To: Chris Morgan
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <PH0PR19MB9973386EF146AD6590DE5508F5A50E2@PH0PR19MB997338.namprd19.prod.outlook.com>
> >
> > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > index e9c81b52f9ef..bc0cefa2fb77 100644
> > > --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > @@ -9,6 +9,7 @@
> > > #include <linux/irq.h>
> > > #include <linux/module.h>
> > > #include <linux/mutex.h>
> > > +#include <linux/pm_runtime.h>
> > > #include <linux/property.h>
> > > #include <linux/regmap.h>
> > > #include <linux/regulator/consumer.h>
> > > @@ -72,6 +73,62 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
> > > };
> > > EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
> > >
> > > +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> > > + enum inv_icm42607_sensor_mode gyro,
> > > + enum inv_icm42607_sensor_mode accel,
> > > + bool temp, unsigned int *sleep_ms)
> > > +{
> > > + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> > > + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> > > + bool oldtemp = st->conf.temp_en;
> > > + unsigned int sleepval;
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> > > + return 0;
> > > +
> > > + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> > > + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
> > > + if (!temp)
> > > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> > > + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + st->conf.gyro.mode = gyro;
> > > + st->conf.accel.mode = accel;
> > > + st->conf.temp_en = temp;
> > > +
> > > + sleepval = 0;
> > > + if (temp && !oldtemp) {
> > > + if (sleepval < INV_ICM42607_TEMP_STARTUP_TIME_MS)
> > > + sleepval = INV_ICM42607_TEMP_STARTUP_TIME_MS;
> > sleepval = max(sleepval,)
> > or just assign it here if not later patches add stuff in between
> > the assignment to 0 and here.
Wow I write some garbage English sometimes (no excuse, it is my
native language!)
>
> I'm going to assign it to 0 here (unless you think I should define it
> at the beginning as 0) and then tweak as needed. I think this code
> here can be further optimized, especially if we make the assumption
> that START and STOP time for each sensor is comparable (the datasheet
> doesn't say, so I'm going to go with yes since that greatly simplifies
> things).
I'm a bit lost. Suggestion was just to do
sleepval = INV_ICM42607_TEMP_STARTUP_TIME_MS;
as we know it is 0. Probably not worth it though as ends up with fragile
code. Fine to keep it to what you have but use max() rather than
if()
...
> > > +static int inv_icm42607_resume(struct device *dev)
> > > +{
> > > + struct inv_icm42607_state *st = dev_get_drvdata(dev);
> > > + int ret;
> > > +
> > > + guard(mutex)(&st->lock);
> > > +
> > Given the bunch of stuff we've run into recently around these
> > I'm getting more paranoid.
> > Similar to above, could you use pm_runtime_force_resume()
> > You would need to gate stuff added later to not occur
> > though if it wasn't runtime suspended.
>
> This I'm having trouble understanding. If I use
> pm_force_runtime_resume() I'm assuming that either I got an error (in
> which case I'd return the error) or the device is runtime resumed
> after the call completes. If that's the case, wouldn't my suspend and
> resume steps just be pm_force_runtime_suspend/resume, and enabling the
> regulator (first for resume) or disabling the regulator (last for
> suspend) as needed?
If you call pm_runtime_force_resume() it will do the right thing
wrt to runtime PM state prior to suspend. If it wasn't runtime suspended
it will runtime resume - if it was it'll no do anything. It won't
directly tell you which one it did though.
The extra stuff that you know can't be the case if runtime pm is on
will need some sort of gating. However, looking again it may already
be protected by more specific checks.
pm_runtime_force_resume();
if (st->fifo.on) { //I'd failed to look at what was added.
ret = regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
INV_ICM42607_FIFO_CONFIG1_MODE);
if (ret)
return ret;
}
That if (st->fifo.on) previously didn't get checked if we were runtime
suspended because in fifo mode we never are. So I was thinking you'd
need that check to be
if (!pm_runtime_suspended(dev) && st->fifo.on)
but the fifo.on check is sufficient by the same argument that if fifo.on
is true we aren't in runtime suspend.
Basically I overthought it and didn't check what got added where the
comment is in this patch.
>
> >
> >
> > > + if (pm_runtime_suspended(dev))
> > > + return 0;
> > > +
> > > + ret = inv_icm42607_enable_vddio_reg(st);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Nothing else to restore at this time. */
> > > +
> > > + return 0;
> > > +}
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: kodiak: consolidate IPA properties
From: Konrad Dybcio @ 2026-05-22 11:08 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alex Elder,
cros-qcom-dts-watchers
Cc: linux-arm-msm, devicetree, linux-kernel, Stanislav Zaikin
In-Reply-To: <20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com>
On 5/17/26 4:56 PM, Dmitry Baryshkov wrote:
> Move generic IPA-related properties to the base DTSI file. The herobrine
> has special software configuration, so delete the memory-region property
> which wasn't set for it beforehand. Also delete the property for several
> IoT devices, which don't enable IPA memory at this point (and don't
> seem to have IPA supported by the modem firmware).
>
> Co-developed-by: Stanislav Zaikin <zstaseg@gmail.com>
> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
[...]
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -504,6 +504,10 @@ &i2c13 {
> status = "okay";
> };
>
> +&ipa {
> + /delete-property/ memory-region;
> +};
On QC*S* parts, wouldn't IPA be disabled anyway?
That's what downstream did historically on APQ-ish SoCs, anyway
Konrad
^ 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