linux-kernel - Re: [PATCH v3 1/3] dt-bindings: usb: Add binding for WCH CH334/CH335 hub controller

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 for Android: free password hash cracker in your pocket

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

Message-ID: <dc5dbed9-cd48-4d22-9960-d35f9dcdc5f0@rock-chips.com>
Date: Tue, 13 Jan 2026 11:38:20 +0800
From: Chaoyi Chen <chaoyi.chen@...k-chips.com>
To: Quentin Schulz <quentin.schulz@...rry.de>
Cc: Chaoyi Chen <kernel@...kyi.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jonas Karlman <jonas@...boo.se>, Hsun Lai <i@...insx.cn>,
 John Clark <inindev@...il.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>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: usb: Add binding for WCH CH334/CH335
 hub controller

Hi Quentin,

On 1/12/2026 10:00 PM, Quentin Schulz wrote:
> Hi Chaoyi,
> 
> On 1/12/26 3:28 AM, Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@...k-chips.com>
>>
>> The WCH CH334/CH335[0] are USB2.0 protocol compliant 4-port USB HUB
>> controller chips, supporting USB2.0 high-speed and full-speed for
>> upstream ports, and USB2.0 high-speed 480Mbps, full-speed 12Mbps and
>> low-speed 1.5Mbps for downstream ports, supporting not only low-cost STT
>> mode (single TT schedules 4 downstream ports in time share), but also
>> supports high performance MTT mode (4 TTs each corresponding to 1 port,
>> concurrent processing).
>>
>> Add a device tree binding for it.
>>
>> [0]: https://www.wch-ic.com/downloads/CH334DS1_PDF.html
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@...k-chips.com>
>> ---
>>   .../devicetree/bindings/usb/wch,ch334.yaml    | 65 +++++++++++++++++++
>>   1 file changed, 65 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/usb/wch,ch334.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/usb/wch,ch334.yaml b/Documentation/devicetree/bindings/usb/wch,ch334.yaml
>> new file mode 100644
>> index 000000000000..2eeb92f25b4c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/wch,ch334.yaml
>> @@ -0,0 +1,65 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/usb/wch,ch334.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: WCH CH334/CH335 USB 2.0 Hub Controller
>> +
>> +maintainers:
>> +  - Chaoyi Chen <kernel@...kyi.com>
>> +
>> +allOf:
>> +  - $ref: usb-hub.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - usb1a86,8091
>> +
> 
> Which driver does this node bind to? I couldn't quickly find a driver which would match this compatible?
>

Oh, I missed that part. It will be fixed in the next version.

>> +  reg: true
>> +
>> +  reset-gpios:
>> +    description: GPIO controlling the RESET# pin.
>> +
>> +  vdd-supply:
>> +    description:
>> +      The regulator that provides 3.3V core power to the hub.
>> +
>> +  vdd2-supply:
>> +    description:
>> +      The regulator that provides 3.3V or 5V power to the hub.
>> +
> 
> There's v5 and vdd33 as power input, shouldn't we maybe use those names instead? How did you come up with vdd/vdd2?
>

That make sense. Will fix in next version.

> There's also a timing that needs to be respected after a power-on event so that the reset has enough time to be performed, c.f. 3.2.1 Power-on Reset in the datasheet you linked to in the commit log. How are you making sure we wait those (apparently, the wording in the datasheet is confusing) 14ms?

This part should be described in the driver. 
I'll fix it in the next version.

-- 
Best, 
Chaoyi