Re: [PATCH v3 1/3] dt-bindings: usb: Add binding for WCH CH334/CH335 hub controller
From: Quentin Schulz <hidden>
Date: 2026-01-12 14:01:17
Also in:
linux-devicetree, linux-rockchip, linux-usb, lkml
Hi Chaoyi, On 1/12/26 3:28 AM, Chaoyi Chen wrote:
quoted hunk ↗ jump to hunk
From: Chaoyi Chen <redacted> 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 <redacted> --- .../devicetree/bindings/usb/wch,ch334.yaml | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/wch,ch334.yamldiff --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@airkyi.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?
+ 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? 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? Cheers, Quentin