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: <1907895.QZUTf85G27@diego>
Date: Wed, 07 Jan 2026 15:56:31 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Chaoyi Chen <kernel@...kyi.com>, Alexey Charkov <alchark@...il.com>,
 Chaoyi Chen <chaoyi.chen@...k-chips.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Quentin Schulz <quentin.schulz@...rry.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>, Shawn Lin <shawn.lin@...k-chips.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Andy Yan <andy.yan@...k-chips.com>, 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

Am Mittwoch, 7. Januar 2026, 15:54:47 Mitteleuropäische Normalzeit schrieb Heiko Stübner:
> Am Mittwoch, 7. Januar 2026, 11:04:42 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> > On 1/7/2026 5:57 PM, Chaoyi Chen wrote:
> > > On 1/7/2026 4:21 PM, Heiko Stübner wrote:
> > >> Am Mittwoch, 7. Januar 2026, 08:56:04 Mitteleuropäische Normalzeit schrieb Alexey Charkov:
> > >>> On Wed, Jan 7, 2026 at 11:04 AM Chaoyi Chen <kernel@...kyi.com> wrote:
> 
> [...]
> 
> > >>>> +       vcc3v3_hubreset: vcc3v3-hubreset {
> > >>>> +               compatible = "regulator-fixed";
> > >>>> +               regulator-name = "vcc3v3_hubreset";
> > >>>> +               regulator-boot-on;
> > >>>> +               regulator-always-on;
> > >>>
> > >>> If this regulator supplies a soldered-on discrete hub and is required
> > >>> to power it up, won't it be better to describe the hub in the device
> > >>> tree (see binding at [1]), make the regulator its supply, and perhaps
> > >>> drop the "regulator-boot-on/regulator-always-on" annotation here,
> > >>> letting the regulator core deal with its enabling instead?
> > >>>
> > >>> [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.yaml
> > >>
> > >> Yep, it would be nicer to it this way.
> > >> A live example can be found in the Rock 5 ITX [2]
> > >>
> > >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts#n1266
> > > 
> > > Thank you for the great example. BTW the hub used here is CH344. It
> > > looks like we need to add a new binding :)
> > >
> > 
> > Typo... It is WCH CH334.
>
> I don't think you need a new compatible at all :-) 

Please ignore everything I wrote :-)

I just looked farther into the usb bindings.
So yes you'll probably need a binding for your hub.


Sorry about the noise
Heiko



> When you look at the usb-device.yaml linked above you'll the compatible
> already defined as a pattern:
> 
>   compatible:
>     contains:
>       pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
>     description: Device nodes or combined nodes.
>       "usbVID,PID", where VID is the vendor id and PID the product id.
>       The textual representation of VID and PID shall be in lower case
>       hexadecimal with leading zeroes suppressed. The other compatible
>       strings from the above standard binding could also be used,
>       but a device adhering to this binding may leave out all except
>       for "usbVID,PID".
> 
> Which will match everything VID + PID combination, so you just need
> to use the VID+PID from your hub.
> 
> 
> Heiko
>