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] [day] [month] [year] [list]

Message-ID: <93704b59-fbd1-41f2-928e-a4398e3714da@cherry.de>
Date: Mon, 9 Feb 2026 18:12:26 +0100
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Heiko Stübner <heiko@...ech.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

Hi Heiko,

On 2/9/26 5:27 PM, Heiko Stübner wrote:
> 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?
> 

I believe it does because it's an undefined state for the gate of the 
transistor. Look at Q21 on the schematics of v1.4.0, it's directly 
routed to the SoC pin. There's no HW pull-up or pull-down on the gate 
side of the transistor so we rely on the SoC internal pull-up/pull-down 
to have a stable state at the gate. This means the transistor gate may 
be either high or low based on who knows what since the line is left 
floating the moment the pinconf is applied (by the core, thus before the 
driver is even attempted to be probed) until the driver probes and 
drives the enable-gpios low, meaning we either conduct between drain and 
source (meaning we pull the PDn and OE pins of the PI6C557-05B to 
ground) or not (left floating, no external HW pull-up or pull-down, 
internal pull-up of PDn and OE should be enough to guarantee a stable 
state) but we cannot say for sure which. Of course we exit this state 
once we drive the enable-gpios line from the driver.

This was discussed with the HW department, you can double-check with 
them, maybe we overlooked something or I got something wrong, my 
transistor-fu is not even beginner-level ;)

Cheers,
Quentin