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: <1956308.1xdlsreqCQ@diego>
Date: Wed, 07 Jan 2026 15:54:47 +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, 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 :-) 

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