linux-kernel - Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board

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: <2520283a-3131-422c-aa7b-45ec1ad4a875@cherry.de>
Date: Thu, 8 Jan 2026 11:51:04 +0100
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Chaoyi Chen <chaoyi.chen@...k-chips.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Kever Yang <kever.yang@...k-chips.com>, Jonas Karlman <jonas@...boo.se>,
 John Clark <inindev@...il.com>, FUKAUMI Naoki <naoki@...xa.com>,
 Jimmy Hon <honyuenkwun@...il.com>, Dragan Simic <dsimic@...jaro.org>,
 Michael Riesch <michael.riesch@...labora.com>,
 Peter Robinson <pbrobinson@...il.com>, Alexey Charkov <alchark@...il.com>,
 Shawn Lin <shawn.lin@...k-chips.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Andy Yan <andy.yan@...k-chips.com>, Chaoyi Chen <kernel@...kyi.com>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board

Hi Chaoyi,

On 1/8/26 11:41 AM, Chaoyi Chen wrote:
> Hi Quentin,
> 
> On 1/8/2026 6:07 PM, Quentin Schulz wrote:
>> Hi Chaoyi,
>>
>> On 1/8/26 7:27 AM, Chaoyi Chen wrote:
>>> Hi Quentin,
>>>
>>> Thank you for your patient review.
>>>
>>> On 1/7/2026 11:46 PM, Quentin Schulz wrote:
>>>> Hi Chaoyi,
>>>>
>>>> On 1/7/26 8:03 AM, Chaoyi Chen wrote:

[...]

>>>>> +    vcc3v3_rtc_s5: regulator-vcc3v3-rtc-s5 {
>>>>> +        compatible = "regulator-fixed";
>>>>> +        regulator-name = "vcc3v3_rtc_s5";
>>>>> +        regulator-boot-on;
>>>>> +        regulator-always-on;
>>>>> +        regulator-min-microvolt = <3300000>;
>>>>> +        regulator-max-microvolt = <3300000>;
>>>>> +        vin-supply = <&vcc_sys>;
>>>>
>>>> If this is for the rtc, shouldn't we declare this dependency in the RTC device node and not have it always-on?
>>>>
>>>
>>> I checked other boards that use the hym8563 device and couldn't find
>>> a similar approach. Could you give an example?
>>>
>>
>> If this is truly always on by hardware design, then I guess it's "fine". That other boards aren't doing isn't much of an argument, as they may not need it. Typically, you could need to update the driver (and its binding) to accept and control power supplies so that you can link the two together in the device tree. I'm assuming for an RTC it doesn't make much sense to have its power supply controllable as it likely needs to be powered even when the device is turned off (otherwise the RTC stops counting :) ).
>>
> 
> Yes, this seems unnecessary, which is why I'm asking if you've
> encountered similar designs before.
> 

I think it's fine for me. It's not a controllable regulator and its 
parent supply (and the parent supply of that supply) all are always-on 
as well and non-configurable so there cannot be a way for this to not be 
on. Please ignore this comment.

[...]

>>>>> +        gpio = <&gpio4 RK_PC7 GPIO_ACTIVE_HIGH>;
>>>>> +        pinctrl-names = "default";
>>>>> +        pinctrl-0 = <&satapm_pwren>;
>>>>> +    };
>>>>> +
>>>>> +    vcc5v0_device: regulator-vcc5v0-device {
>>>>> +        compatible = "regulator-fixed";
>>>>> +        regulator-name = "vcc5v0_device";
>>>>> +        regulator-always-on;
>>>>> +        regulator-boot-on;
>>>>> +        regulator-min-microvolt = <5000000>;
>>>>> +        regulator-max-microvolt = <5000000>;
>>>>> +        vin-supply = <&vcc12v_dcin>;
>>>>> +    };
>>>>> +
>>>>> +    vcc5v0_host: regulator-vcc5v0-host {
>>>>> +        compatible = "regulator-fixed";
>>>>> +        regulator-name = "vcc5v0_host";
>>>>> +        regulator-boot-on;
>>>>> +        regulator-always-on;
>>>>> +        regulator-min-microvolt = <5000000>;
>>>>> +        regulator-max-microvolt = <5000000>;
>>>>> +        enable-active-high;
>>>>> +        gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
>>>>> +        vin-supply = <&vcc5v0_device>;
>>>>> +        pinctrl-names = "default";
>>>>> +        pinctrl-0 = <&usb_host_pwren>;
>>>>> +    };
>>>>> +
>>>>
>>>> I assume both of the above are related to USB operating in host or device mode? Maybe there's a way to have something more useful to the user in regulator-name (and possibly the regulator node name) so that they have an idea what this pertains to?
>>>
>>> It's a good idea. Actually, we have two regulators here, one for USB0
>>> and another for USB1. I'll try to rename them in v2.
>>>
>>
>> Are you sure? vcc5v0_device is a supply for vcc5v0_host, so it'd be odd that in order for USB1 to work, you need USB0 powered?
> 
> No, the "vcc5v0_device" serves as the vin-supply for both
> "VCC5V0_USB3_HOST0" and "VCC5V0_USB3_HOST1".
> And "VCC5V0_USB3_HOSTx" is supply for USB VBUS.
> 
> All the names marked here are those shown in the schematic. As you
> suggested, it would be better to set regulator-name to the schematic
> name "VCC5V0_USB3_HOSTx" and use "usbx_vbus" for the label.
> 

Yes, that does make sense to me.

Cheers,
Quentin