Am Donnerstag, 5. Februar 2026, 17:49:15 Mitteleuropäische Normalzeit schrieb Quentin Schulz:

Hi Heiko,

On 2/5/26 11:21 AM, Heiko Stuebner wrote:

quoted

From: Heiko Stuebner <redacted>

While specific driver in the Linux-Kernel handles GPIOs gracefully without
matching pinctrl entries, this might not be true for other operating
systems. So having pinctrl entries makes the hardware-description
more complete.

The somewhat similar rk3588-jaguar board has a pinctrl entry already,
so also add one for rk3588-tiger.

Signed-off-by: Heiko Stuebner <redacted>
---
  arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 8 ++++++++
  1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
index 259fb125e13f..91057b166690 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi

@@ -58,6 +58,8 @@ pcie_refclk: pcie-clock-generator {
  		clock-frequency = <100000000>;
  		clock-output-names = "pcie3_refclk";
  		enable-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* PCIE30X4_CLKREQN_M1_L */
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie30x4_clkreqn_m1_l>;
  		vdd-supply = <&vcca_3v3_s0>;
  	};
  

@@ -357,6 +359,12 @@ module_led_pin: module-led-pin {
  		};
  	};
  
+	pcie30x4 {
+		pcie30x4_clkreqn_m1_l: pcie30x4-clkreqn-m1-l {
+			rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;

So this is interesting because it made me double-check the schematics 
and I think we did a mistake on Jaguar.

This one here is fine as this SoC pin is connected to the PDn pin of the 
IC which has an internal Pull-Up, so the state is defined.

However, on Jaguar this signal controls a transistor and there's no 
external Pull-Up or Pull-Down between the SoC and the transistor gate so 
we probably should not have pull_none for the pinconf. The default reset 
state of this pin in Pull-Up so maybe we should go with that such that 
there's no difference between the reset default and the time between 
application of the pinconf by the core and asserting of the pin by the 
driver. What do you think?

Looking at the datasheet for the PI6C557-05B, both nPD and OE are
described as having an "internal pull up resistor", so the pinconf side
should not matter?

As for Tiger, this is fine, so:

Reviewed-by: Quentin Schulz <redacted>

Heiko