* [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
* [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 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 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 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 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 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 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 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 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 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
* Re: [PATCH v6 04/16] firmware: qcom: Add a PAS TEE service
From: Sumit Garg @ 2026-05-22 10:39 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260519073354.03927C2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 07:33:53AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Critical] Unvalidated buffer sizes from TEE lead to heap buffer overflow and out-of-bounds read.
> - [High] The `shm_free` cleanup wrapper fails to handle `ERR_PTR`, causing a kernel crash on allocation failure.
> - [High] Unconditional unregistration and global static ops structure corruption in probe/remove.
> --
>
> commit 117a287c92ded04ad43f9ed963b43a8069a13f94
> Author: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> firmware: qcom: Add a PAS TEE service
>
> Add support for Peripheral Authentication Service (PAS) driver based
> on TEE bus with OP-TEE providing the backend PAS service implementation.
>
> > diff --git a/drivers/firmware/qcom/qcom_pas_tee.c b/drivers/firmware/qcom/qcom_pas_tee.c
> > new file mode 100644
> > index 0000000000000..2067a43c44c37
> > --- /dev/null
> > +++ b/drivers/firmware/qcom/qcom_pas_tee.c
> > @@ -0,0 +1,476 @@
> [ ... ]
> > +DEFINE_FREE(shm_free, struct tee_shm *, tee_shm_free(_T))
>
> Will this crash if an allocation failure occurs? By default, DEFINE_FREE
> only guards against NULL pointers. However, tee_shm_alloc_kernel_buf() can
> return an ERR_PTR, which evaluates to true.
>
> > +
> > +static void *qcom_pas_tee_get_rsc_table(struct device *dev,
> > + struct qcom_pas_context *ctx,
> > + void *input_rt, size_t input_rt_size,
> > + size_t *output_rt_size)
> > +{
> [ ... ]
> > + if (param[1].u.memref.size) {
> > + struct tee_shm *rt_shm __free(shm_free) =
> > + tee_shm_alloc_kernel_buf(data->ctx,
> > + param[1].u.memref.size);
>
> If this allocation fails, rt_shm will be an ERR_PTR. When the function
> returns early, shm_free will pass the ERR_PTR to tee_shm_free(), triggering
> a kernel panic.
Ack, will fix it.
>
> > + void *rt_shm_va;
> > +
> > + if (IS_ERR(rt_shm)) {
> > + dev_err(dev, "rt_shm allocation failed\n");
> > + return rt_shm;
> > + }
> > +
> > + rt_shm_va = tee_shm_get_va(rt_shm, 0);
> > + if (IS_ERR(rt_shm_va)) {
> > + dev_err(dev, "rt_shm get VA failed\n");
> > + return ERR_CAST(rt_shm_va);
> > + }
> > + memcpy(rt_shm_va, input_rt, input_rt_size);
>
> Can this cause a heap buffer overflow? The buffer is allocated using
> param[1].u.memref.size, but the code unconditionally copies input_rt_size
> bytes into it.
Nope, param[1].u.memref.size is always more or equal to input_rt_size
based on OP-TEE ABI.
>
> > +
> > + param[1].u.memref.shm = rt_shm;
> > + ret = tee_client_invoke_func(data->ctx, &inv_arg, param);
> > + if (ret < 0 || inv_arg.ret != 0) {
> > + dev_err(dev, "PAS get RT failed, pas_id: %d, ret: %d, err: 0x%x\n",
> > + ctx->pas_id, ret, inv_arg.ret);
> > + return ret ? ERR_PTR(ret) : ERR_PTR(-EINVAL);
> > + }
> > +
> > + if (param[1].u.memref.size) {
> > + *output_rt_size = param[1].u.memref.size;
> > + rt_buf = kmemdup(rt_shm_va, *output_rt_size, GFP_KERNEL);
>
> Does this kmemdup() introduce an out-of-bounds read? The size returned by
> the TEE in param[1].u.memref.size could potentially be larger than the
> originally allocated size.
Nope, this won't happen as it's part of OP-TEE ABI.
>
> > + if (!rt_buf)
> > + return ERR_PTR(-ENOMEM);
> > + }
> > + }
> > +
> > + return rt_buf;
> > +}
> [ ... ]
> > +static struct qcom_pas_ops qcom_pas_ops_tee = {
> > + .drv_name = "qcom-pas-tee",
> > + .supported = qcom_pas_tee_supported,
> > + .init_image = qcom_pas_tee_init_image,
> > + .mem_setup = qcom_pas_tee_mem_setup,
> > + .get_rsc_table = qcom_pas_tee_get_rsc_table,
> > + .auth_and_reset = qcom_pas_tee_auth_and_reset,
> > + .prepare_and_auth_reset = qcom_pas_tee_prepare_and_auth_reset,
> > + .set_remote_state = qcom_pas_tee_set_remote_state,
> > + .shutdown = qcom_pas_tee_shutdown,
> > + .metadata_release = qcom_pas_tee_metadata_release,
> > +};
> > +
> > +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> > +{
> > + return ver->impl_id == TEE_IMPL_ID_OPTEE;
> > +}
> > +
> > +static int qcom_pas_tee_probe(struct tee_client_device *pas_dev)
> > +{
> > + struct device *dev = &pas_dev->dev;
> > + struct qcom_pas_tee_private *data;
> [ ... ]
> > + data->session_id = sess_arg.session;
> > + dev_set_drvdata(dev, data);
> > + qcom_pas_ops_tee.dev = dev;
>
> Could concurrent probes overwrite this shared static structure? Since the ops
> structure is global, multiple devices probing at the same time could clobber
> the dev pointer.
Only single device is supported on TEE bus here.
>
> > + qcom_pas_ops_register(&qcom_pas_ops_tee);
>
> Should this check for a return value or register failure? If another backend
> like SCM is already registered, this operation will fail, but the probe
> routine proceeds as if it was successful.
Only one PAS backend is expected to be present at a time.
>
> > +
> > + return ret;
> > +}
> > +
> > +static void qcom_pas_tee_remove(struct tee_client_device *pas_dev)
> > +{
> > + struct device *dev = &pas_dev->dev;
> > + struct qcom_pas_tee_private *data = dev_get_drvdata(dev);
> > +
> > + qcom_pas_ops_unregister();
>
> If the registration failed in probe, will this unconditionally unregister the
> active SCM backend and break PAS functionality system-wide?
Concurrent PAS backends aren't supported.
-Sumit
>
> > + tee_client_close_session(data->ctx, data->session_id);
> > + tee_client_close_context(data->ctx);
> > +}
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518072856.22790-1-sumit.garg@kernel.org?part=4
^ permalink raw reply
* Re: [PATCH v6 09/10] dmaengine: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-05-22 10:38 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, Laxman Dewangan, Philipp Zabel,
dmaengine, devicetree, linux-tegra, linux-kernel, Frank Li
In-Reply-To: <20260331102303.33181-10-akhilrajeev@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Tue, Mar 31, 2026 at 03:53:02PM +0530, Akhil R wrote:
> Add compatible and chip data to support GPCDMA in Tegra264, which has
> differences in register layout and address bits compared to previous
> versions.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Thierry Reding @ 2026-05-22 10:37 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, Laxman Dewangan, Philipp Zabel,
dmaengine, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260331102303.33181-9-akhilrajeev@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 5591 bytes --]
On Tue, Mar 31, 2026 at 03:53:01PM +0530, Akhil R wrote:
> Use 'iommu-map', when provided, to get the stream ID to be programmed
> for each channel. Iterate over the channels registered and configure
> each channel device separately using of_dma_configure_id() to allow
> it to use a separate IOMMU domain for the transfer. However, do this
> in a second loop since the first loop populates the DMA device channels
> list and async_device_register() registers the channels. Both are
> prerequisites for using the channel device in the next loop.
>
> Channels will continue to use the same global stream ID if the
> 'iommu-map' property is not present in the device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 53 ++++++++++++++++++++++++++++------
> 1 file changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
> index 9bea2ffb3b9e..cd480d047204 100644
> --- a/drivers/dma/tegra186-gpc-dma.c
> +++ b/drivers/dma/tegra186-gpc-dma.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_dma.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> #include <linux/slab.h>
> @@ -1380,9 +1381,13 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
> static int tegra_dma_probe(struct platform_device *pdev)
> {
> const struct tegra_dma_chip_data *cdata = NULL;
> + struct tegra_dma_channel *tdc;
> + struct tegra_dma *tdma;
> + struct dma_chan *chan;
> + struct device *chdev;
> + bool use_iommu_map = false;
No use in initiazising this since you immediately assign to it the
return value of of_property_present() below.
> unsigned int i;
> u32 stream_id;
> - struct tegra_dma *tdma;
> int ret;
>
> cdata = of_device_get_match_data(&pdev->dev);
> @@ -1410,9 +1415,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
>
> tdma->dma_dev.dev = &pdev->dev;
>
> - if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
> - dev_err(&pdev->dev, "Missing iommu stream-id\n");
> - return -EINVAL;
> + use_iommu_map = of_property_present(pdev->dev.of_node, "iommu-map");
> + if (!use_iommu_map) {
> + if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id))
> + return dev_err_probe(&pdev->dev, -EINVAL, "Missing iommu stream-id\n");
Looks like checkpatch.pl would complain about this being too long.
> }
>
> ret = device_property_read_u32(&pdev->dev, "dma-channel-mask",
> @@ -1424,9 +1430,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
> tdma->chan_mask = TEGRA_GPCDMA_DEFAULT_CHANNEL_MASK;
> }
>
> + /* Initialize vchan for each channel and populate the channels list */
> INIT_LIST_HEAD(&tdma->dma_dev.channels);
> for (i = 0; i < cdata->nr_channels; i++) {
> - struct tegra_dma_channel *tdc = &tdma->channels[i];
> + tdc = &tdma->channels[i];
>
> /* Check for channel mask */
> if (!(tdma->chan_mask & BIT(i)))
> @@ -1446,10 +1453,6 @@ static int tegra_dma_probe(struct platform_device *pdev)
>
> vchan_init(&tdc->vc, &tdma->dma_dev);
> tdc->vc.desc_free = tegra_dma_desc_free;
> -
> - /* program stream-id for this channel */
> - tegra_dma_program_sid(tdc, stream_id);
> - tdc->stream_id = stream_id;
> }
>
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(cdata->addr_bits));
> @@ -1483,6 +1486,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
> tdma->dma_dev.device_synchronize = tegra_dma_chan_synchronize;
> tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
>
> + /* Register the DMA device and the channels */
> ret = dmaenginem_async_device_register(&tdma->dma_dev);
> if (ret < 0) {
> dev_err_probe(&pdev->dev, ret,
> @@ -1490,6 +1494,37 @@ static int tegra_dma_probe(struct platform_device *pdev)
> return ret;
> }
>
> + /*
> + * Configure stream ID for each channel from the channels registered
> + * above. This is done in a separate iteration to ensure that only
> + * the channels available and registered for the DMA device are used.
> + */
> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> + chdev = &chan->dev->device;
> + tdc = to_tegra_dma_chan(chan);
> +
> + if (use_iommu_map) {
> + chdev->bus = pdev->dev.bus;
> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> +
> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> + true, &tdc->id);
> + if (ret)
> + return dev_err_probe(chdev, ret,
> + "Failed to configure IOMMU for channel %d\n", tdc->id);
> +
> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id))
> + return dev_err_probe(chdev, -EINVAL,
> + "Failed to get stream ID for channel %d\n", tdc->id);
There are also a few very long lines here. Make sure to run checkpatch
on these patches and remove all warnings. For dev_err_probe() some of
these might be okay. Otherwise, one alternative might be to reduce the
nesting here and push the inner "if" into a separate function.
Thierry
> +
> + chan->dev->chan_dma_dev = true;
> + }
> +
> + /* program stream-id for this channel */
> + tegra_dma_program_sid(tdc, stream_id);
> + tdc->stream_id = stream_id;
> + }
> +
> ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
> tegra_dma_of_xlate, tdma);
> if (ret < 0) {
> --
> 2.50.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] riscv: dts: spacemit: k1: Add Banana Pi BPI-CM6 IO board
From: sashiko-bot @ 2026-05-22 10:37 UTC (permalink / raw)
To: Junhui Liu; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260522-bpi-cm6-v1-3-707ef1917a30@pigmoral.tech>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `vpcie3v3-supply` property is incorrectly applied to both the PCIe host controller nodes (`&pcie1`, `&pcie2`) and their root port child nodes (`&pcie1_port`, `&pcie2_port`).
--
commit 0620787d4f86f8d706f7dc3a6b25263906add1bd
Author: Junhui Liu <junhui.liu@pigmoral.tech>
riscv: dts: spacemit: k1: Add Banana Pi BPI-CM6 IO board
This commit adds initial device tree support for the Banana Pi BPI-CM6 IO
board. The board features the SpacemiT K1 SoC, and this patch configures
interfaces such as UART, eMMC, SD card, I2C, PCIe, USB, and dual Ethernet.
Link: https://docs.banana-pi.org/en/BPI-CM6/BananaPi_BPI-CM6
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts
> new file mode 100644
> index 0000000000000..b2767f44e8d62
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts
[ ... ]
> +&pcie1_port {
> + phys = <&pcie1_phy>;
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
> +};
> +
> +&pcie1 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
[Severity: Low]
Does this cause a dt_binding_check validation failure for the host
controller node?
According to the spacemit,k1-pcie-host.yaml binding schema, the
vpcie3v3-supply property is exclusively defined and required within the
patternProperties for the root port child node, rather than for the
top-level host controller itself.
Should this property be removed from the &pcie1 node to avoid an
unevaluated property warning?
> + status = "okay";
> +};
[ ... ]
> +&pcie2_port {
> + phys = <&pcie2_phy>;
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
> +};
> +
> +&pcie2 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
[Severity: Low]
Similar to the &pcie1 node above, does the vpcie3v3-supply property belong
in the host controller node &pcie2, or should it only be present in the
&pcie2_port child node?
> + status = "okay";
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-bpi-cm6-v1-0-707ef1917a30@pigmoral.tech?part=3
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: rockchip: spdif: Reorder clock enable sequence
From: sashiko-bot @ 2026-05-22 10:37 UTC (permalink / raw)
To: phucduc.bui; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260522100318.73474-3-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Failure to restore regmap cache-only state if `regcache_sync()` fails during runtime resume.
--
commit 517eeaafec0deb4d7a25eb1c2641316c2b2e2b72
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: rockchip: spdif: Reorder clock enable sequence
This commit reorders the clock enablement sequence during runtime resume.
It ensures the bus clock (hclk) is prepared and enabled before the
controller clock (mclk) to guarantee proper register access.
> diff --git a/sound/soc/rockchip/rockchip_spdif.c b/sound/soc/rockchip/rockchip_spdif.c
> --- a/sound/soc/rockchip/rockchip_spdif.c
> +++ b/sound/soc/rockchip/rockchip_spdif.c
[ ... ]
> @@ -76,16 +76,16 @@ static int rk_spdif_runtime_resume(struct device *dev)
[ ... ]
> - ret = clk_prepare_enable(spdif->hclk);
> + ret = clk_prepare_enable(spdif->mclk);
> if (ret) {
> - clk_disable_unprepare(spdif->mclk);
> - dev_err(spdif->dev, "hclk clock enable failed %d\n", ret);
> + clk_disable_unprepare(spdif->hclk);
> + dev_err(spdif->dev, "mclk clock enable failed %d\n", ret);
> return ret;
> }
>
> regcache_cache_only(spdif->regmap, false);
> regcache_mark_dirty(spdif->regmap);
>
> ret = regcache_sync(spdif->regmap);
> if (ret) {
> clk_disable_unprepare(spdif->mclk);
> clk_disable_unprepare(spdif->hclk);
[Severity: High]
This is a pre-existing issue, but is the regmap cache-only state left
unrestored on this error path?
If regcache_sync() fails, the driver disables the clocks and returns an error.
This causes the runtime power management core to leave the device in the
suspended state.
However, the error path doesn't appear to restore the cache-only mode via
regcache_cache_only(spdif->regmap, true).
If a subsequent register read or write occurs while the device is in this
suspended state, could the regmap bypass the cache and attempt a physical
memory-mapped I/O access?
Since the generic power domain would be powered off when suspended,
attempting this access might trigger an asynchronous system error or
synchronous data abort.
> }
>
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522100318.73474-1-phucduc.bui@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property
From: Konrad Dybcio @ 2026-05-22 10:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kamal Wadhwa, jishnu.prakash
Cc: Rakesh Kota, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <df22ebcb-52d6-4a6f-852a-6d6ed376e313@kernel.org>
On 5/22/26 12:32 PM, Krzysztof Kozlowski wrote:
> On 22/05/2026 11:24, Konrad Dybcio wrote:
>> On 5/21/26 11:58 AM, Krzysztof Kozlowski wrote:
>>> On 21/05/2026 10:46, Konrad Dybcio wrote:
>>>> On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
>>>>>> Since firmware does not have a way to dynamically tell if it on a
>>>>>> debug-board powered device or a DCIN powered device, We are required to
>>>>>> add this new DT property.
>>>>>
>>>>> Neither debug-board powered device nor battery-less will have
>>>>> monitored-battery, thus again, why lack of that property cannot tell you
>>>>> what you need?
>>>>
>>>> A device with a battery will not have a monitored-battery either
>>> But why? If for such device property "no battery" is suitable, then for
>>> me "monitored-battery" is suitable as well. IOW, if you say that having
>>> a property describing batter is not a accurate hardware property here,
>>> then neither saying "no battery" is, because no batter is basically some
>>> sort of battery (just like empty set is still a set, empty array is
>>> still an array).
>>
>> The battmgr service running on one of the remoteprocs already has all
>> the information about the battery and it also handles all the type-c,
>> PD and charger configuration, only letting the OS know about the
>> results.
>>
>> Hence, unless there's some other hardware at play (e.g. for custom
>> 200 W charging), which wasn't fully implemented in the QC firmware,
>> there is no reason to describe a battery separately, since the OS
>> can't do anything useful with that information
>
> That's a good explanation and it implies: "no-battery" is not suitable.
I agree the firmware should be fixed
Konrad
^ permalink raw reply
* Re: [PATCH v6 07/10] dmaengine: tegra: Use managed DMA controller registration
From: Thierry Reding @ 2026-05-22 10:33 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, Laxman Dewangan, Philipp Zabel,
dmaengine, devicetree, linux-tegra, linux-kernel, Frank Li
In-Reply-To: <20260331102303.33181-8-akhilrajeev@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Tue, Mar 31, 2026 at 03:53:00PM +0530, Akhil R wrote:
> Switch to managed registration in probe. This simplifies the error
> paths in the probe and also removes the requirement of the driver
> remove function.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Suggested-by: Frank Li <frank.li@nxp.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 19 ++++---------------
> 1 file changed, 4 insertions(+), 15 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property
From: Krzysztof Kozlowski @ 2026-05-22 10:32 UTC (permalink / raw)
To: Konrad Dybcio, Kamal Wadhwa, jishnu.prakash
Cc: Rakesh Kota, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <82019c2e-6b6e-4edd-91b3-a28ef6eb09eb@oss.qualcomm.com>
On 22/05/2026 11:24, Konrad Dybcio wrote:
> On 5/21/26 11:58 AM, Krzysztof Kozlowski wrote:
>> On 21/05/2026 10:46, Konrad Dybcio wrote:
>>> On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
>>>>> Since firmware does not have a way to dynamically tell if it on a
>>>>> debug-board powered device or a DCIN powered device, We are required to
>>>>> add this new DT property.
>>>>
>>>> Neither debug-board powered device nor battery-less will have
>>>> monitored-battery, thus again, why lack of that property cannot tell you
>>>> what you need?
>>>
>>> A device with a battery will not have a monitored-battery either
>> But why? If for such device property "no battery" is suitable, then for
>> me "monitored-battery" is suitable as well. IOW, if you say that having
>> a property describing batter is not a accurate hardware property here,
>> then neither saying "no battery" is, because no batter is basically some
>> sort of battery (just like empty set is still a set, empty array is
>> still an array).
>
> The battmgr service running on one of the remoteprocs already has all
> the information about the battery and it also handles all the type-c,
> PD and charger configuration, only letting the OS know about the
> results.
>
> Hence, unless there's some other hardware at play (e.g. for custom
> 200 W charging), which wasn't fully implemented in the QC firmware,
> there is no reason to describe a battery separately, since the OS
> can't do anything useful with that information
That's a good explanation and it implies: "no-battery" is not suitable.
>
> In some abstract way, perhaps monitored_battery = <&pmic_glink> could
> be thought of as valid (since that's the data source the OS gets to
> see)
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 06/10] dmaengine: tegra: Support address width > 39 bits
From: Thierry Reding @ 2026-05-22 10:32 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, Laxman Dewangan, Philipp Zabel,
dmaengine, devicetree, linux-tegra, linux-kernel, Frank Li
In-Reply-To: <20260331102303.33181-7-akhilrajeev@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
On Tue, Mar 31, 2026 at 03:52:59PM +0530, Akhil R wrote:
> Tegra264 supports address width of 41 bits. Unlike older SoCs which use
> a common high_addr register for upper address bits, Tegra264 has separate
> src_high and dst_high registers to accommodate this wider address space.
>
> Add an addr_bits property to the device data structure to specify the
> number of address bits supported on each device and use that to program
> the appropriate registers.
>
> Update the sg_req struct to remove the high_addr field and use
> dma_addr_t for src and dst to store the complete addresses. Extract
> the high address bits only when programming the registers.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 83 +++++++++++++++++++++-------------
> 1 file changed, 52 insertions(+), 31 deletions(-)
Sorry for not noticing this earlier.
My understanding is that previously this IP (along with most others) did
support 40 bit addressing. That's a much more natural boundary, too. The
reason why 39 is often mentioned in this context is that bit 39 was
treated specially and interpreted by the memory controller as a way to
swizzle memory between the Tegra and discrete GPU formats.
I assume GPC DMA was in the same category. I'd be very surprised if
there really was a limit on exactly 39 bits. Looking at the register
documentation, I see that the high address register is 8 bits, which
together with the 32 bits from the regular ADR register gives 40 bits.
Given the above this patch looks wrong. Technically the previous
iterations did support the full 40 bits, and that should be reflected in
the DMA mask. The platform-specific 39-bit restriction due to the
swizzle bit is something that we've always represented via the
dma-ranges property, but it doesn't reflect the capabilities of the
hardware.
It's a bit odd that GPC DMA on Tegra264 supports 41 bits. I think the
regular address map is only 40 bits, but I guess if the registers define
it this way, might as well support it.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] spi: enable the SpacemiT K3 SoC QSPI
From: Mark Brown @ 2026-05-21 20:56 UTC (permalink / raw)
To: Han Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Zhengyu He
Cc: linux-spi, imx, devicetree, linux-kernel, linux-riscv, spacemit,
Wei Fu, Cody Kang
In-Reply-To: <20260521-k3-pico-itx-qspi-v2-for-next-20260521-v2-0-52bce26e5fd8@gmail.com>
On Thu, 21 May 2026 22:44:44 +0800, Zhengyu He wrote:
> spi: enable the SpacemiT K3 SoC QSPI
>
> Add the SpacemiT K3 QSPI compatible and enable SPI NOR flash on the
> K3 Pico-ITX board.
>
> K3 and K1 use the same QSPI controller, so the K3 devicetree uses
> "spacemit,k1-qspi" as fallback.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/2] spi: dt-bindings: fsl-qspi: support SpacemiT K3
https://git.kernel.org/broonie/spi/c/27cd2dde35b2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH 9/9] arm64: dts: renesas: rzg3s-smarc-som: Enable I3C
From: Claudiu Beznea @ 2026-05-22 10:22 UTC (permalink / raw)
To: geert+renesas, linusw, robh, krzk+dt, conor+dt, magnus.damm,
wsa+renesas
Cc: claudiu.beznea, claudiu.beznea, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Claudiu Beznea
In-Reply-To: <20260522102251.1723392-1-claudiu.beznea@kernel.org>
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The Renesas RZ/G3S SMARC SoM board has a connector for I3C interface.
Enable I3C.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
.../boot/dts/renesas/rzg3s-smarc-som.dtsi | 30 +++++++++++++++++++
.../boot/dts/renesas/rzg3s-smarc-switches.h | 4 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
index b45acfe6288a..370b39b6a33d 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
@@ -168,6 +168,15 @@ a0 80 30 30 9c
};
};
+&i3c {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&i3c_pins>;
+ pinctrl-1 = <&i3c_standby_pins>;
+ i2c-scl-hz = <400000>;
+ i3c-scl-hz = <12500000>;
+ status = "okay";
+};
+
&pcie_port0 {
clocks = <&versa3 5>;
clock-names = "ref";
@@ -302,6 +311,27 @@ mux {
};
};
+ i3c_pins: i3c {
+ pins = "I3C_SDA", "I3C_SCL";
+#if SW_CONFIG4 == SW_ON
+ power-source = <1200>;
+#else
+ power-source = <1800>;
+#endif
+ input-enable;
+ renesas,i3c-standby = <0>;
+ };
+
+ i3c_standby_pins: i3c-standby {
+ pins = "I3C_SDA", "I3C_SCL";
+#if SW_CONFIG4 == SW_ON
+ power-source = <1200>;
+#else
+ power-source = <1800>;
+#endif
+ renesas,i3c-standby = <1>;
+ };
+
sdhi0_pins: sd0 {
data {
pins = "SD0_DATA0", "SD0_DATA1", "SD0_DATA2", "SD0_DATA3";
diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc-switches.h b/arch/arm64/boot/dts/renesas/rzg3s-smarc-switches.h
index bbf908a5322c..9cccc87da057 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-switches.h
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-switches.h
@@ -25,9 +25,13 @@
* @SW_CONFIG3:
* SW_OFF - SD2 is connected to SoC
* SW_ON - SCIF1, SSI0, IRQ0, IRQ1 connected to SoC
+ * @SW_CONFIG4:
+ * SW_OFF - I3C voltage is 1.8V
+ * SW_ON - I3C voltage is 1.2V
*/
#define SW_CONFIG2 SW_OFF
#define SW_CONFIG3 SW_ON
+#define SW_CONFIG4 SW_OFF
/*
* SW_OPT_MUX[x] switches' states:
--
2.43.0
^ permalink raw reply related
* [PATCH 8/9] pinctrl: renesas: rzg2l: Add RZ/G3S support for selecting the I3C standby state
From: Claudiu Beznea @ 2026-05-22 10:22 UTC (permalink / raw)
To: geert+renesas, linusw, robh, krzk+dt, conor+dt, magnus.damm,
wsa+renesas
Cc: claudiu.beznea, claudiu.beznea, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Claudiu Beznea
In-Reply-To: <20260522102251.1723392-1-claudiu.beznea@kernel.org>
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The I3C pins on the Renesas RZ/G3S SoC can be switched to a standby mode
when the controller operates in I2C mode. According to the RZ/G3S HW
manual (Rev. 1.20), in standby mode "the output is fixed at Hi-Z and no
data is transferred to the inside even if data is input from outside".
Add support to configure the I3C standby mode.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
drivers/pinctrl/renesas/pinctrl-rzg2l.c | 49 ++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index 68329b6c6649..b313de35e9df 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -70,6 +70,7 @@
#define PIN_CFG_PVDD1833_OTH_ISO_POC BIT(20) /* known on RZ/G3L only */
#define PIN_CFG_WDTOVF_N_POC BIT(21) /* known on RZ/G3L only */
#define PIN_CFG_IO_VMC_I3C BIT(22)
+#define PIN_CFG_I3C_STANDBY_RZG3S BIT(23)
#define RZG2L_SINGLE_PIN BIT_ULL(63) /* Dedicated pin */
#define RZG2L_VARIABLE_CFG BIT_ULL(62) /* Variable cfg for port pins */
@@ -215,15 +216,24 @@
/* Custom pinconf parameters */
#define RENESAS_RZV2H_PIN_CONFIG_OUTPUT_IMPEDANCE (PIN_CONFIG_END + 1)
+#define RENESAS_RZG3S_PIN_CONFIG_I3C_STANDBY (PIN_CONFIG_END + 2)
static const struct pinconf_generic_params renesas_rzv2h_custom_bindings[] = {
{ "renesas,output-impedance", RENESAS_RZV2H_PIN_CONFIG_OUTPUT_IMPEDANCE, 1 },
};
+static const struct pinconf_generic_params renesas_rzg3s_custom_bindings[] = {
+ { "renesas,i3c-standby", RENESAS_RZG3S_PIN_CONFIG_I3C_STANDBY, 0 },
+};
+
#ifdef CONFIG_DEBUG_FS
static const struct pin_config_item renesas_rzv2h_conf_items[] = {
PCONFDUMP(RENESAS_RZV2H_PIN_CONFIG_OUTPUT_IMPEDANCE, "output-impedance", "x", true),
};
+
+static const struct pin_config_item renesas_rzg3s_conf_items[] = {
+ PCONFDUMP(RENESAS_RZG3S_PIN_CONFIG_I3C_STANDBY, "standby", NULL, true),
+};
#endif
/* Read/write 8 bits register */
@@ -279,6 +289,7 @@ struct rzg2l_register_offsets {
* @other_poc_pvdd1833_oth_iso_poc: PVDD1833_OTH_ISO_POC mask
* @other_poc_wdtovf_n_poc: WDTOVF_N_POC mask
* @i3c_set_poc: I3C_SET_POC mask
+ * @i3c_set_stbn: I3C_SET_STBN mask
*/
struct rzg2l_register_masks {
union {
@@ -292,6 +303,7 @@ struct rzg2l_register_masks {
/* RZ/G3S masks */
struct {
u8 i3c_set_poc;
+ u8 i3c_set_stbn;
};
};
};
@@ -1560,6 +1572,8 @@ static int rzg2l_pinctrl_pinconf_get(struct pinctrl_dev *pctldev,
struct rzg2l_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
const struct rzg2l_hwcfg *hwcfg = pctrl->data->hwcfg;
const struct pinctrl_pin_desc *pin = &pctrl->desc.pins[_pin];
+ const struct rzg2l_register_offsets *regs = &hwcfg->regs;
+ const struct rzg2l_register_masks *masks = &hwcfg->masks;
u32 param = pinconf_to_config_param(*config);
u64 *pin_data = pin->drv_data;
unsigned int arg = 0;
@@ -1702,6 +1716,14 @@ static int rzg2l_pinctrl_pinconf_get(struct pinctrl_dev *pctldev,
arg = rzg2l_read_pin_config(pctrl, IOLH(off), bit, IOLH_MASK);
break;
+ case RENESAS_RZG3S_PIN_CONFIG_I3C_STANDBY:
+ if (!(cfg & PIN_CFG_I3C_STANDBY_RZG3S))
+ return -EINVAL;
+
+ arg = readb(pctrl->base + regs->i3c_set);
+ arg = !field_get(masks->i3c_set_stbn, arg);
+ break;
+
default:
return -ENOTSUPP;
}
@@ -1720,6 +1742,8 @@ static int rzg2l_pinctrl_pinconf_set(struct pinctrl_dev *pctldev,
const struct pinctrl_pin_desc *pin = &pctrl->desc.pins[_pin];
const struct rzg2l_hwcfg *hwcfg = pctrl->data->hwcfg;
struct rzg2l_pinctrl_pin_settings settings = pctrl->settings[_pin];
+ const struct rzg2l_register_offsets *regs = &hwcfg->regs;
+ const struct rzg2l_register_masks *masks = &hwcfg->masks;
u64 *pin_data = pin->drv_data;
unsigned int i, arg, index;
u32 off, param;
@@ -1846,6 +1870,19 @@ static int rzg2l_pinctrl_pinconf_set(struct pinctrl_dev *pctldev,
rzg2l_rmw_pin_config(pctrl, IOLH(off), bit, IOLH_MASK, arg);
break;
+ case RENESAS_RZG3S_PIN_CONFIG_I3C_STANDBY:
+ if (!(cfg & PIN_CFG_I3C_STANDBY_RZG3S))
+ return -EINVAL;
+
+ scoped_guard(raw_spinlock, &pctrl->lock) {
+ u8 tmp = readb(pctrl->base + regs->i3c_set);
+
+ tmp &= ~masks->i3c_set_stbn;
+ tmp |= field_prep(masks->i3c_set_stbn, !arg);
+ writeb(tmp, pctrl->base + regs->i3c_set);
+ }
+ break;
+
default:
return -ENOTSUPP;
}
@@ -2551,8 +2588,10 @@ static const struct rzg2l_dedicated_configs rzg3s_dedicated_pins[] = {
{ "AUDIO_CLK1", RZG2L_SINGLE_PIN_PACK(0x2, 0, PIN_CFG_IEN) },
{ "AUDIO_CLK2", RZG2L_SINGLE_PIN_PACK(0x2, 1, PIN_CFG_IEN) },
{ "WDTOVF_PERROUT#", RZG2L_SINGLE_PIN_PACK(0x6, 0, PIN_CFG_IOLH_A | PIN_CFG_SOFT_PS) },
- { "I3C_SDA", RZG2L_SINGLE_PIN_PACK(0x9, 0, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C)) },
- { "I3C_SCL", RZG2L_SINGLE_PIN_PACK(0x9, 1, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C)) },
+ { "I3C_SDA", RZG2L_SINGLE_PIN_PACK(0x9, 0, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C |
+ PIN_CFG_I3C_STANDBY_RZG3S)) },
+ { "I3C_SCL", RZG2L_SINGLE_PIN_PACK(0x9, 1, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C |
+ PIN_CFG_I3C_STANDBY_RZG3S)) },
{ "SD0_CLK", RZG2L_SINGLE_PIN_PACK(0x10, 0, (PIN_CFG_IOLH_B | PIN_CFG_IO_VMC_SD0)) },
{ "SD0_CMD", RZG2L_SINGLE_PIN_PACK(0x10, 1, (PIN_CFG_IOLH_B | PIN_CFG_IEN |
PIN_CFG_IO_VMC_SD0)) },
@@ -3934,6 +3973,7 @@ static const struct rzg2l_hwcfg rzg3s_hwcfg = {
.oen = 0x3018,
},
.masks = {
+ .i3c_set_stbn = BIT(0),
.i3c_set_poc = BIT(2),
},
.iolh_groupa_ua = {
@@ -4020,6 +4060,11 @@ static struct rzg2l_pinctrl_data r9a08g045_data = {
.pin_to_oen_bit = &rzg3s_pin_to_oen_bit,
.hw_to_bias_param = &rzg2l_hw_to_bias_param,
.bias_param_to_hw = &rzg2l_bias_param_to_hw,
+ .num_custom_params = ARRAY_SIZE(renesas_rzg3s_custom_bindings),
+ .custom_params = renesas_rzg3s_custom_bindings,
+#ifdef CONFIG_DEBUG_FS
+ .custom_conf_items = renesas_rzg3s_conf_items,
+#endif
};
static struct rzg2l_pinctrl_data r9a08g046_data = {
--
2.43.0
^ permalink raw reply related
* [PATCH 7/9] dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Document the I3C standby property
From: Claudiu Beznea @ 2026-05-22 10:22 UTC (permalink / raw)
To: geert+renesas, linusw, robh, krzk+dt, conor+dt, magnus.damm,
wsa+renesas
Cc: claudiu.beznea, claudiu.beznea, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Claudiu Beznea
In-Reply-To: <20260522102251.1723392-1-claudiu.beznea@kernel.org>
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The I3C pins on the Renesas RZ/G3S SoC can be configured in standby mode
when operating in I2C mode. According to the RZ/G3S HW manual (Rev. 1.20),
when standby mode is selected, the output is fixed at Hi-Z and no data is
transferred internally, even if data is received from outside.
Document the renesas,i3c-standby property.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
.../devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
index 32864c9add4a..94a51666b1a2 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
@@ -153,6 +153,13 @@ additionalProperties:
register, which adjusts the drive strength value and is pin-dependent.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
+ renesas,i3c-standby:
+ description:
+ Controls the standby mode of the I3C interface when operating in I2C mode.
+ When standby mode is selected, the output is fixed at Hi-Z and no data is
+ transferred internally, even if data is received from outside.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
- type: object
additionalProperties:
--
2.43.0
^ permalink raw reply related
* [PATCH 6/9] pinctrl: renesas: rzg2l: Add RZ/G3S support for selecting the I3C power source
From: Claudiu Beznea @ 2026-05-22 10:22 UTC (permalink / raw)
To: geert+renesas, linusw, robh, krzk+dt, conor+dt, magnus.damm,
wsa+renesas
Cc: claudiu.beznea, claudiu.beznea, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Claudiu Beznea
In-Reply-To: <20260522102251.1723392-1-claudiu.beznea@kernel.org>
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The Renesas RZ/G3S I3C pins can be powered at either 1.8V or 1.2V. The
pin controller provides a register to select between these two options.
Update the Renesas RZ/G2L pin controller driver to allow selecting the
I3C power source on RZ/G3S SoC.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
drivers/pinctrl/renesas/pinctrl-rzg2l.c | 73 +++++++++++++++++++++++--
1 file changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index 517001145bd0..68329b6c6649 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -69,6 +69,7 @@
#define PIN_CFG_PVDD1833_OTH_AWO_POC BIT(19) /* known on RZ/G3L only */
#define PIN_CFG_PVDD1833_OTH_ISO_POC BIT(20) /* known on RZ/G3L only */
#define PIN_CFG_WDTOVF_N_POC BIT(21) /* known on RZ/G3L only */
+#define PIN_CFG_IO_VMC_I3C BIT(22)
#define RZG2L_SINGLE_PIN BIT_ULL(63) /* Dedicated pin */
#define RZG2L_VARIABLE_CFG BIT_ULL(62) /* Variable cfg for port pins */
@@ -186,6 +187,9 @@
#define PVDD_3300 0 /* I/O domain voltage >= 3.3V */
#define PVDD_MASK 0x3
+#define PVDD_I3C_1200 1 /* I3C I/O domain voltage 1.2V */
+#define PVDD_I3C_1800 0 /* I3C I/O domain voltage 1.8V */
+
#define PWPR_B0WI BIT(7) /* Bit Write Disable */
#define PWPR_PFCWE BIT(6) /* PFC Register Write Enable */
#define PWPR_REGWE_A BIT(6) /* PFC and PMC Register Write Enable on RZ/V2H(P) */
@@ -257,6 +261,7 @@ static const struct pin_config_item renesas_rzv2h_conf_items[] = {
* @oen: OEN register offset
* @qspi: QSPI register offset
* @other_poc: OTHER_POC register offset
+ * @i3c_set: I3C_SET register offset
*/
struct rzg2l_register_offsets {
u16 pwpr;
@@ -265,6 +270,7 @@ struct rzg2l_register_offsets {
u16 oen;
u16 qspi;
u16 other_poc;
+ u16 i3c_set;
};
/**
@@ -272,6 +278,7 @@ struct rzg2l_register_offsets {
* @other_poc_pvdd1833_oth_awo_poc: PVDD1833_OTH_AWO_POC mask
* @other_poc_pvdd1833_oth_iso_poc: PVDD1833_OTH_ISO_POC mask
* @other_poc_wdtovf_n_poc: WDTOVF_N_POC mask
+ * @i3c_set_poc: I3C_SET_POC mask
*/
struct rzg2l_register_masks {
union {
@@ -281,6 +288,11 @@ struct rzg2l_register_masks {
u8 other_poc_pvdd1833_oth_iso_poc;
u8 other_poc_wdtovf_n_poc;
};
+
+ /* RZ/G3S masks */
+ struct {
+ u8 i3c_set_poc;
+ };
};
};
@@ -391,6 +403,7 @@ struct rzg2l_pinctrl_pin_settings {
* @oen: Output Enable register cache
* @other_poc: OTHER_POC register cache
* @qspi: QSPI registers cache
+ * @i3c_set: I3C_SET register cache
*/
struct rzg2l_pinctrl_reg_cache {
u8 *p;
@@ -409,6 +422,7 @@ struct rzg2l_pinctrl_reg_cache {
u8 oen;
u8 other_poc;
u8 qspi;
+ u8 i3c_set;
};
struct rzg2l_pinctrl {
@@ -441,6 +455,7 @@ struct rzg2l_pinctrl {
};
static const u16 available_ps[] = { 1800, 2500, 3300 };
+static const u16 available_i3c_ps[] = { 1200, 1800 };
static u64 rzg2l_pinctrl_get_variable_pin_cfg(struct rzg2l_pinctrl *pctrl,
u64 pincfg,
@@ -1101,12 +1116,28 @@ static int rzg2l_caps_to_pwr_reg(const struct rzg2l_register_offsets *regs,
*mask = masks->other_poc_wdtovf_n_poc;
return 0;
}
+ if (caps & PIN_CFG_IO_VMC_I3C) {
+ *offset = regs->i3c_set;
+ *mask = masks->i3c_set_poc;
+ return 0;
+ }
return -EINVAL;
}
static int rzg2l_pwr_reg_val_to_ps(u8 val, u32 caps)
{
+ if (caps & PIN_CFG_IO_VMC_I3C) {
+ switch (val) {
+ case PVDD_I3C_1200:
+ return 1200;
+ case PVDD_I3C_1800:
+ return 1800;
+ }
+
+ return -EINVAL;
+ }
+
switch (val) {
case PVDD_1800:
return 1800;
@@ -1121,6 +1152,19 @@ static int rzg2l_pwr_reg_val_to_ps(u8 val, u32 caps)
static int rzg2l_ps_to_pwr_reg_val(u8 *val, u32 ps, u32 caps)
{
+ if (caps & PIN_CFG_IO_VMC_I3C) {
+ switch (ps) {
+ case 1200:
+ *val = PVDD_I3C_1200;
+ return 0;
+ case 1800:
+ *val = PVDD_I3C_1800;
+ return 0;
+ }
+
+ return -EINVAL;
+ }
+
switch (ps) {
case 1800:
*val = PVDD_1800;
@@ -1194,12 +1238,21 @@ static int rzg2l_set_power_source(struct rzg2l_pinctrl *pctrl, u32 pin, u32 caps
return 0;
}
-static bool rzg2l_ps_is_supported(u16 ps)
+static bool rzg2l_ps_is_supported(u16 ps, u32 caps)
{
- unsigned int i;
+ unsigned int i, len;
+ const u16 *array;
- for (i = 0; i < ARRAY_SIZE(available_ps); i++) {
- if (available_ps[i] == ps)
+ if (caps & PIN_CFG_IO_VMC_I3C) {
+ array = available_i3c_ps;
+ len = ARRAY_SIZE(available_i3c_ps);
+ } else {
+ array = available_ps;
+ len = ARRAY_SIZE(available_ps);
+ }
+
+ for (i = 0; i < len; i++) {
+ if (array[i] == ps)
return true;
}
@@ -1800,7 +1853,7 @@ static int rzg2l_pinctrl_pinconf_set(struct pinctrl_dev *pctldev,
/* Apply power source. */
if (settings.power_source != pctrl->settings[_pin].power_source) {
- ret = rzg2l_ps_is_supported(settings.power_source);
+ ret = rzg2l_ps_is_supported(settings.power_source, cfg);
if (!ret)
return -EINVAL;
@@ -2498,6 +2551,8 @@ static const struct rzg2l_dedicated_configs rzg3s_dedicated_pins[] = {
{ "AUDIO_CLK1", RZG2L_SINGLE_PIN_PACK(0x2, 0, PIN_CFG_IEN) },
{ "AUDIO_CLK2", RZG2L_SINGLE_PIN_PACK(0x2, 1, PIN_CFG_IEN) },
{ "WDTOVF_PERROUT#", RZG2L_SINGLE_PIN_PACK(0x6, 0, PIN_CFG_IOLH_A | PIN_CFG_SOFT_PS) },
+ { "I3C_SDA", RZG2L_SINGLE_PIN_PACK(0x9, 0, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C)) },
+ { "I3C_SCL", RZG2L_SINGLE_PIN_PACK(0x9, 1, (PIN_CFG_IEN | PIN_CFG_IO_VMC_I3C)) },
{ "SD0_CLK", RZG2L_SINGLE_PIN_PACK(0x10, 0, (PIN_CFG_IOLH_B | PIN_CFG_IO_VMC_SD0)) },
{ "SD0_CMD", RZG2L_SINGLE_PIN_PACK(0x10, 1, (PIN_CFG_IOLH_B | PIN_CFG_IEN |
PIN_CFG_IO_VMC_SD0)) },
@@ -3717,6 +3772,8 @@ static int rzg2l_pinctrl_suspend_noirq(struct device *dev)
cache->oen = readb(pctrl->base + pctrl->data->hwcfg->regs.oen);
if (regs->other_poc)
cache->other_poc = readb(pctrl->base + regs->other_poc);
+ if (regs->i3c_set)
+ cache->i3c_set = readb(pctrl->base + regs->i3c_set);
if (pctrl->syscon) {
int ret;
@@ -3759,6 +3816,8 @@ static int rzg2l_pinctrl_resume_noirq(struct device *dev)
writeb(cache->qspi, pctrl->base + regs->qspi);
if (regs->other_poc)
writeb(cache->other_poc, pctrl->base + regs->other_poc);
+ if (regs->i3c_set)
+ writeb(cache->i3c_set, pctrl->base + regs->i3c_set);
raw_spin_lock_irqsave(&pctrl->lock, flags);
rzg2l_oen_write_with_pwpr(pctrl, cache->oen);
@@ -3871,8 +3930,12 @@ static const struct rzg2l_hwcfg rzg3s_hwcfg = {
.pwpr = 0x3000,
.sd_ch = 0x3004,
.eth_poc = 0x3010,
+ .i3c_set = 0x301c,
.oen = 0x3018,
},
+ .masks = {
+ .i3c_set_poc = BIT(2),
+ },
.iolh_groupa_ua = {
/* 1v8 power source */
[RZG2L_IOLH_IDX_1V8] = 2200, 4400, 9000, 10000,
--
2.43.0
^ permalink raw reply related
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