linux-kernel - Re: [PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5539724.6PsWsQAL7t@diego>
Date: Mon, 09 Feb 2026 17:27:51 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Quentin Schulz <quentin.schulz@...rry.de>
Cc: linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Heiko Stuebner <heiko.stuebner@...rry.de>
Subject:
 Re: [PATCH 3/3] arm64: dts: rockchip: add pinctrl for clk-generator GPIO on
 rk3588-tiger

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:
> > From: Heiko Stuebner <heiko.stuebner@...rry.de>
> > 
> > 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 <heiko.stuebner@...rry.de>
> > ---
> >   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 <quentin.schulz@...rry.de>

Heiko