[PATCH 0/4] Add HUSB311 Type-C controller

[PATCH 0/4] Add HUSB311 Type-C controller

[Alexey Charkov]

HUSB311 is a drop-in replacement for RT1711H, used in Rockchip RK3576 EVB1
board and some other boards closely following the reference schematic.

The existing RT1711H driver seems to work fine with HUSB311, and there is
no public documentation available for HUSB311 to identify any meaningful
differences, so this series wires up the existing driver to treat
HUSB311 in the same way it treats RT1711H.

This also enables a bare-bones DT node for HUSB311 on RK3576 EVB1, but
currently misses the connections graph for the USB SS and SBU lines, as
those might require the USBDP PHY ports schema to be updated first for
proper DP AltMode support as indicated by Sebastian.

Signed-off-by: Alexey Charkov <alchark@flipper.net>

---
Alexey Charkov (4):
      dt-bindings: vendor-prefixes: Add Hynetek Semiconductor Co., Ltd.
      dt-bindings: usb: richtek,rt1711h: Add Hynetek HUSB311
      usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311
      arm64: dts: rockchip: Add HUSB311 Type-C controller on RK3576 EVB1

 .../devicetree/bindings/usb/richtek,rt1711h.yaml    |  2 ++
 .../devicetree/bindings/vendor-prefixes.yaml        |  2 ++
 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts    | 20 ++++++++++++++++++++
 drivers/usb/typec/tcpm/tcpci_rt1711h.c              | 21 +++++++++++++++++++--
 4 files changed, 43 insertions(+), 2 deletions(-)
---
base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
change-id: 20260115-husb311-291bbb1a7776

Best regards,
-- 
Alexey Charkov <alchark@flipper.net>

[PATCH 1/4] dt-bindings: vendor-prefixes: Add Hynetek Semiconductor Co., Ltd.

[Alexey Charkov]

Hynetek Semiconductor Co., Ltd. focuses on intelligent energy control
technology, mainly for the intelligent fast charging and digital energy
fields.

Link: https://en.hynetek.com/
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 04b7d1aaaef1..f1e6b1d03839 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -745,6 +745,8 @@ patternProperties:
     description: Hycon Technology Corp.
   "^hydis,.*":
     description: Hydis Technologies
+  "^hynetek,.*":
+    description: Hynetek Semiconductor Co., Ltd.
   "^hynitron,.*":
     description: Shanghai Hynitron Microelectronics Co. Ltd.
   "^hynix,.*":

-- 
2.52.0

[PATCH 2/4] dt-bindings: usb: richtek,rt1711h: Add Hynetek HUSB311

[Alexey Charkov]

HUSB311 is a pin-compatible and register-compatible drop-in replacement
for RT1711H, so add its compatible string to the existing binding.

Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
index ae611f7e57ca..b24502bc8213 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
@@ -21,8 +21,10 @@ properties:
     enum:
       - richtek,rt1711h
       - richtek,rt1715
+      - hynetek,husb311
     description:
       RT1711H support PD20, RT1715 support PD30 except Fast Role Swap.
+      HUSB311 is a rebrand of RT1711H which is pin and register compatible.
 
   reg:
     maxItems: 1

-- 
2.52.0

[PATCH 3/4] usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311

[Alexey Charkov]

HUSB311 is a pin-compatible and register-compatible drop-in replacement
for RT1711H, so add its IDs to the existing driver.

Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 drivers/usb/typec/tcpm/tcpci_rt1711h.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
index 88c50b984e8a..ac5917c1e253 100644
--- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
+++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
@@ -18,6 +18,9 @@
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
+#define HUSB311_VID		0x2E99
+#define HUSB311_PID		0x0311
+#define HUSB311_DID		0x0000
 #define RT1711H_VID		0x29CF
 #define RT1711H_PID		0x1711
 #define RT1711H_DID		0x2171
@@ -55,6 +58,8 @@
 
 struct rt1711h_chip_info {
 	u32 rxdz_sel;
+	u16 vid;
+	u16 pid;
 	u16 did;
 	bool enable_pd30_extended_message;
 };
@@ -308,14 +313,14 @@ static int rt1711h_check_revision(struct i2c_client *i2c, struct rt1711h_chip *c
 	ret = i2c_smbus_read_word_data(i2c, TCPC_VENDOR_ID);
 	if (ret < 0)
 		return ret;
-	if (ret != RT1711H_VID) {
+	if (ret != chip->info->vid) {
 		dev_err(&i2c->dev, "vid is not correct, 0x%04x\n", ret);
 		return -ENODEV;
 	}
 	ret = i2c_smbus_read_word_data(i2c, TCPC_PRODUCT_ID);
 	if (ret < 0)
 		return ret;
-	if (ret != RT1711H_PID) {
+	if (ret != chip->info->pid) {
 		dev_err(&i2c->dev, "pid is not correct, 0x%04x\n", ret);
 		return -ENODEV;
 	}
@@ -405,17 +410,28 @@ static void rt1711h_remove(struct i2c_client *client)
 	tcpci_unregister_port(chip->tcpci);
 }
 
+static const struct rt1711h_chip_info husb311 = {
+	.vid = HUSB311_VID,
+	.pid = HUSB311_PID,
+	.did = HUSB311_DID,
+};
+
 static const struct rt1711h_chip_info rt1711h = {
+	.vid = RT1711H_VID,
+	.pid = RT1711H_PID,
 	.did = RT1711H_DID,
 };
 
 static const struct rt1711h_chip_info rt1715 = {
 	.rxdz_sel = RT1711H_BMCIO_RXDZSEL,
+	.vid = RT1711H_VID,
+	.pid = RT1711H_PID,
 	.did = RT1715_DID,
 	.enable_pd30_extended_message = true,
 };
 
 static const struct i2c_device_id rt1711h_id[] = {
+	{ "husb311", (kernel_ulong_t)&husb311 },
 	{ "rt1711h", (kernel_ulong_t)&rt1711h },
 	{ "rt1715", (kernel_ulong_t)&rt1715 },
 	{}
@@ -423,6 +439,7 @@ static const struct i2c_device_id rt1711h_id[] = {
 MODULE_DEVICE_TABLE(i2c, rt1711h_id);
 
 static const struct of_device_id rt1711h_of_match[] = {
+	{ .compatible = "hynetek,husb311", .data = &husb311 },
 	{ .compatible = "richtek,rt1711h", .data = &rt1711h },
 	{ .compatible = "richtek,rt1715", .data = &rt1715 },
 	{}

-- 
2.52.0

[PATCH 4/4] arm64: dts: rockchip: Add HUSB311 Type-C controller on RK3576 EVB1

[Alexey Charkov]

Rockchip RK3576 EVB1 board has a Hynetek HUSB311 USB Type-C controller on
its Type-C OTG port, which also supports DisplayPort Alternate Mode.

Add the required DT nodes to enable basic HUSB311 operation.

Note that for full support of mode and orientation switching, the USBDP
PHY schema may need to be expanded, such as in [1]. This is left out for
now until the respective schema is finalized and merged.

[1] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/fe29a74fd38aa1beb4a8101fdcecebaf3444e5f9

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
index f5746bc2970b..59bc1ac6d3d1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
@@ -11,6 +11,7 @@
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
 #include "rk3576.dtsi"
 
 / {
@@ -768,6 +769,25 @@ regulator-state-mem {
 &i2c2 {
 	status = "okay";
 
+	usbc0: typec-portc@4e {
+		compatible = "hynetek,husb311";
+		reg = <0x4e>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA5 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usbc0_int>;
+		vbus-supply = <&vbus5v0_typec>;
+
+		connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			data-role = "dual";
+			power-role = "source";
+			source-pdos = <PDO_FIXED(5000, 2000,
+						 PDO_FIXED_USB_COMM | PDO_FIXED_DATA_SWAP)>;
+		};
+	};
+
 	hym8563: rtc@51 {
 		compatible = "haoyu,hym8563";
 		reg = <0x51>;

-- 
2.52.0

Re: [PATCH 1/4] dt-bindings: vendor-prefixes: Add Hynetek Semiconductor Co., Ltd.

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/4] Add HUSB311 Type-C controller

[Dragan Simic]

Hello Alexey,

On Wednesday, March 11, 2026 17:20 CET, Alexey Charkov <alchark@flipper.net> wrote:
> HUSB311 is a drop-in replacement for RT1711H, used in Rockchip RK3576 EVB1
> board and some other boards closely following the reference schematic.
> 
> The existing RT1711H driver seems to work fine with HUSB311, and there is
> no public documentation available for HUSB311 to identify any meaningful
> differences, so this series wires up the existing driver to treat
> HUSB311 in the same way it treats RT1711H.

I'm a bit surprised that you haven't managed to find any HUSB311 datasheets,
because they are seemingly rather easy to obtain.  I've got a couple of
HUSB311 datasheet versions with the register descriptions and whatnot, would
you like me to send them over?

> This also enables a bare-bones DT node for HUSB311 on RK3576 EVB1, but
> currently misses the connections graph for the USB SS and SBU lines, as
> those might require the USBDP PHY ports schema to be updated first for
> proper DP AltMode support as indicated by Sebastian.
> 
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> 
> ---
> Alexey Charkov (4):
>       dt-bindings: vendor-prefixes: Add Hynetek Semiconductor Co., Ltd.
>       dt-bindings: usb: richtek,rt1711h: Add Hynetek HUSB311
>       usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311
>       arm64: dts: rockchip: Add HUSB311 Type-C controller on RK3576 EVB1
> 
>  .../devicetree/bindings/usb/richtek,rt1711h.yaml    |  2 ++
>  .../devicetree/bindings/vendor-prefixes.yaml        |  2 ++
>  arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts    | 20 ++++++++++++++++++++
>  drivers/usb/typec/tcpm/tcpci_rt1711h.c              | 21 +++++++++++++++++++--
>  4 files changed, 43 insertions(+), 2 deletions(-)

Re: [PATCH 3/4] usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

On Wed, Mar 11, 2026 at 08:20:46PM +0400, Alexey Charkov wrote:
> HUSB311 is a pin-compatible and register-compatible drop-in replacement
> for RT1711H, so add its IDs to the existing driver.
> 
> Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
> Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
>  drivers/usb/typec/tcpm/tcpci_rt1711h.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> index 88c50b984e8a..ac5917c1e253 100644
> --- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> +++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> @@ -18,6 +18,9 @@
>  #include <linux/regmap.h>
>  #include <linux/regulator/consumer.h>
>  
> +#define HUSB311_VID		0x2E99
> +#define HUSB311_PID		0x0311
> +#define HUSB311_DID		0x0000
>  #define RT1711H_VID		0x29CF
>  #define RT1711H_PID		0x1711
>  #define RT1711H_DID		0x2171
> @@ -55,6 +58,8 @@
>  
>  struct rt1711h_chip_info {
>  	u32 rxdz_sel;
> +	u16 vid;
> +	u16 pid;
>  	u16 did;
>  	bool enable_pd30_extended_message;
>  };
> @@ -308,14 +313,14 @@ static int rt1711h_check_revision(struct i2c_client *i2c, struct rt1711h_chip *c
>  	ret = i2c_smbus_read_word_data(i2c, TCPC_VENDOR_ID);
>  	if (ret < 0)
>  		return ret;
> -	if (ret != RT1711H_VID) {
> +	if (ret != chip->info->vid) {
>  		dev_err(&i2c->dev, "vid is not correct, 0x%04x\n", ret);

Why are we checking vids and pids here? Rejecting a non-match prevents
using fallback compatibles, so I'd like to know why the code exists.

Is it just here for the sake of it, or to prevent some actual issues?
Not really familiar with USB devices unfortunately.

>  		return -ENODEV;
>  	}
>  	ret = i2c_smbus_read_word_data(i2c, TCPC_PRODUCT_ID);
>  	if (ret < 0)
>  		return ret;
> -	if (ret != RT1711H_PID) {
> +	if (ret != chip->info->pid) {
>  		dev_err(&i2c->dev, "pid is not correct, 0x%04x\n", ret);
>  		return -ENODEV;
>  	}
> @@ -405,17 +410,28 @@ static void rt1711h_remove(struct i2c_client *client)
>  	tcpci_unregister_port(chip->tcpci);
>  }
>  
> +static const struct rt1711h_chip_info husb311 = {
> +	.vid = HUSB311_VID,
> +	.pid = HUSB311_PID,
> +	.did = HUSB311_DID,
> +};
> +
>  static const struct rt1711h_chip_info rt1711h = {
> +	.vid = RT1711H_VID,
> +	.pid = RT1711H_PID,
>  	.did = RT1711H_DID,
>  };
>  
>  static const struct rt1711h_chip_info rt1715 = {
>  	.rxdz_sel = RT1711H_BMCIO_RXDZSEL,
> +	.vid = RT1711H_VID,
> +	.pid = RT1711H_PID,
>  	.did = RT1715_DID,
>  	.enable_pd30_extended_message = true,
>  };
>  
>  static const struct i2c_device_id rt1711h_id[] = {
> +	{ "husb311", (kernel_ulong_t)&husb311 },
>  	{ "rt1711h", (kernel_ulong_t)&rt1711h },
>  	{ "rt1715", (kernel_ulong_t)&rt1715 },
>  	{}
> @@ -423,6 +439,7 @@ static const struct i2c_device_id rt1711h_id[] = {
>  MODULE_DEVICE_TABLE(i2c, rt1711h_id);
>  
>  static const struct of_device_id rt1711h_of_match[] = {
> +	{ .compatible = "hynetek,husb311", .data = &husb311 },
>  	{ .compatible = "richtek,rt1711h", .data = &rt1711h },
>  	{ .compatible = "richtek,rt1715", .data = &rt1715 },
>  	{}
> 
> -- 
> 2.52.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/4] Add HUSB311 Type-C controller

[Alexey Charkov]

On Wed, Mar 11, 2026 at 10:32 PM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Alexey,
>
> On Wednesday, March 11, 2026 17:20 CET, Alexey Charkov <alchark@flipper.net> wrote:
> > HUSB311 is a drop-in replacement for RT1711H, used in Rockchip RK3576 EVB1
> > board and some other boards closely following the reference schematic.
> >
> > The existing RT1711H driver seems to work fine with HUSB311, and there is
> > no public documentation available for HUSB311 to identify any meaningful
> > differences, so this series wires up the existing driver to treat
> > HUSB311 in the same way it treats RT1711H.
>
> I'm a bit surprised that you haven't managed to find any HUSB311 datasheets,
> because they are seemingly rather easy to obtain.  I've got a couple of
> HUSB311 datasheet versions with the register descriptions and whatnot, would
> you like me to send them over?

Hi Dragan,

The only ones I could find were those I linked in the commit messages
for the bindings and the driver change:
Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf

They are notably abridged in their register description (which is the
most relevant part as far as drivers are concerned), only covering the
common TCPCI registers and not any vendor defined extensions. It even
references registers in the 0x90 range on page 17 but doesn't describe
them.

Compare that for instance to the RT1711H datasheet:
Link: https://www.richtek.com/assets/product_file/RT1711H/DS1711H-04.pdf

It does look like 's/RT1711H/HUSB311/' apart from that omitted
vendor-defined range.

If you happen to see a version of a HUSB311 datasheet that includes a
description of the 0x90-0xaf register range I would definitely be
eager to have a look.

Best regards,
Alexey

Re: [PATCH 3/4] usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311

[Alexey Charkov]

On Wed, Mar 11, 2026 at 10:33 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Wed, Mar 11, 2026 at 08:20:46PM +0400, Alexey Charkov wrote:
> > HUSB311 is a pin-compatible and register-compatible drop-in replacement
> > for RT1711H, so add its IDs to the existing driver.
> >
> > Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
> > Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf
> > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > ---
> >  drivers/usb/typec/tcpm/tcpci_rt1711h.c | 21 +++++++++++++++++++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > index 88c50b984e8a..ac5917c1e253 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > @@ -18,6 +18,9 @@
> >  #include <linux/regmap.h>
> >  #include <linux/regulator/consumer.h>
> >
> > +#define HUSB311_VID          0x2E99
> > +#define HUSB311_PID          0x0311
> > +#define HUSB311_DID          0x0000
> >  #define RT1711H_VID          0x29CF
> >  #define RT1711H_PID          0x1711
> >  #define RT1711H_DID          0x2171
> > @@ -55,6 +58,8 @@
> >
> >  struct rt1711h_chip_info {
> >       u32 rxdz_sel;
> > +     u16 vid;
> > +     u16 pid;
> >       u16 did;
> >       bool enable_pd30_extended_message;
> >  };
> > @@ -308,14 +313,14 @@ static int rt1711h_check_revision(struct i2c_client *i2c, struct rt1711h_chip *c
> >       ret = i2c_smbus_read_word_data(i2c, TCPC_VENDOR_ID);
> >       if (ret < 0)
> >               return ret;
> > -     if (ret != RT1711H_VID) {
> > +     if (ret != chip->info->vid) {
> >               dev_err(&i2c->dev, "vid is not correct, 0x%04x\n", ret);
>
> Why are we checking vids and pids here? Rejecting a non-match prevents
> using fallback compatibles, so I'd like to know why the code exists.
>
> Is it just here for the sake of it, or to prevent some actual issues?
> Not really familiar with USB devices unfortunately.

Hi Conor,

It looks like a relic of some original vendor provided driver code.
Rockchip's implementation of a HUSB311 driver [1] contains similar
checks but I don't think it adds practical value in the world of
Device Tree (after all, it's just an I2C device - I haven't seen many
I2C drivers reject a DT match based on hardware IDs found in
registers). I chose to avoid removing them with my patch though,
because I don't have any Richtek hardware to test such a change.

Maybe the error could be downgraded to a warning though.

Best regards,
Alexey

https://github.com/rockchip-linux/kernel/blob/develop-6.6/drivers/usb/typec/tcpm/tcpci_husb311.c#L217-L244

Re: [PATCH 3/4] usb: typec: tcpci_rt1711h: Add support for Hynetek HUSB311

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

On Thu, Mar 12, 2026 at 11:09:43AM +0400, Alexey Charkov wrote:
> On Wed, Mar 11, 2026 at 10:33 PM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Wed, Mar 11, 2026 at 08:20:46PM +0400, Alexey Charkov wrote:
> > > HUSB311 is a pin-compatible and register-compatible drop-in replacement
> > > for RT1711H, so add its IDs to the existing driver.
> > >
> > > Link: https://www.hynetek.com/uploadfiles/site/219/news/0863c0c7-f535-4f09-bacd-0440d2c21088.pdf
> > > Link: https://dl.xkwy2018.com/downloads/RK3588S/03_Product%20Line%20Branch_Tablet/02_Key%20Device%20Specifications/HUSB311%20introduction%2020210526.pdf
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > > ---
> > >  drivers/usb/typec/tcpm/tcpci_rt1711h.c | 21 +++++++++++++++++++--
> > >  1 file changed, 19 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > > index 88c50b984e8a..ac5917c1e253 100644
> > > --- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > > +++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> > > @@ -18,6 +18,9 @@
> > >  #include <linux/regmap.h>
> > >  #include <linux/regulator/consumer.h>
> > >
> > > +#define HUSB311_VID          0x2E99
> > > +#define HUSB311_PID          0x0311
> > > +#define HUSB311_DID          0x0000
> > >  #define RT1711H_VID          0x29CF
> > >  #define RT1711H_PID          0x1711
> > >  #define RT1711H_DID          0x2171
> > > @@ -55,6 +58,8 @@
> > >
> > >  struct rt1711h_chip_info {
> > >       u32 rxdz_sel;
> > > +     u16 vid;
> > > +     u16 pid;
> > >       u16 did;
> > >       bool enable_pd30_extended_message;
> > >  };
> > > @@ -308,14 +313,14 @@ static int rt1711h_check_revision(struct i2c_client *i2c, struct rt1711h_chip *c
> > >       ret = i2c_smbus_read_word_data(i2c, TCPC_VENDOR_ID);
> > >       if (ret < 0)
> > >               return ret;
> > > -     if (ret != RT1711H_VID) {
> > > +     if (ret != chip->info->vid) {
> > >               dev_err(&i2c->dev, "vid is not correct, 0x%04x\n", ret);
> >
> > Why are we checking vids and pids here? Rejecting a non-match prevents
> > using fallback compatibles, so I'd like to know why the code exists.
> >
> > Is it just here for the sake of it, or to prevent some actual issues?
> > Not really familiar with USB devices unfortunately.
> 
> Hi Conor,
> 
> It looks like a relic of some original vendor provided driver code.
> Rockchip's implementation of a HUSB311 driver [1] contains similar
> checks but I don't think it adds practical value in the world of
> Device Tree (after all, it's just an I2C device - I haven't seen many
> I2C drivers reject a DT match based on hardware IDs found in

There's been a lot of drivers in drivers/iio that do this kind of
although they're gradually being modified over time to support using
fallback compatibles.

> registers). I chose to avoid removing them with my patch though,
> because I don't have any Richtek hardware to test such a change.
> 
> Maybe the error could be downgraded to a warning though.

To make use of a fallback, it can't produce a warning. If you wanna keep
it, just make them dev_dbg() I think.

Also, the devicetree binding should then be modified to support using
the fallback.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]