[PATCH v2 0/2] Implement vbus support for HD3SS3220 port controller

[PATCH v2 0/2] Implement vbus support for HD3SS3220 port controller

[Krishna Kurapati]

As per the data sheet of HD3SS3220:

"Upon detecting a UFP device, HD3SS3220 will keep ID pin high if VBUS is
not at VSafe0V. Once VBUS is at VSafe0V, the HD3SS3220 will assert ID pin
low. This is done to enforce Type-C requirement that VBUS must be at
VSafe0V before re-enabling VBUS"

This series implements support to read ID pin state and accordingly enable
VBUS.

Changes in v2:
Fixed inclusion of header files appropriately.
Modified commit text for driver patch.

Link to v1:
https://lore.kernel.org/all/20251002172539.586538-1-krishna.kurapati@oss.qualcomm.com/

Krishna Kurapati (2):
  dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state
  usb: typec: hd3ss3220: Enable VBUS based on ID pin state

 .../devicetree/bindings/usb/ti,hd3ss3220.yaml | 13 ++++
 drivers/usb/typec/hd3ss3220.c                 | 60 +++++++++++++++++++
 2 files changed, 73 insertions(+)

-- 
2.34.1

[PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Krishna Kurapati]

Update the bindings to support reading ID state and VBUS, as per the
HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
VBUS must be at VSafe0V before re-enabling VBUS.

Add id-gpios property to describe the input gpio for USB ID pin and vbus-
supply property to describe the regulator for USB VBUS.

Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
 .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
index bec1c8047bc0..c869eece39a7 100644
--- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
@@ -25,6 +25,19 @@ properties:
   interrupts:
     maxItems: 1
 
+  id-gpios:
+    description:
+      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
+      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
+      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
+      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
+
+    maxItems: 1
+
+  vbus-supply:
+    description: A phandle to the regulator for USB VBUS if needed when host
+      mode or dual role mode is supported.
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
     description: OF graph bindings (specified in bindings/graph.txt) that model
-- 
2.34.1

[PATCH v2 2/2] usb: typec: hd3ss3220: Enable VBUS based on ID pin state

[Krishna Kurapati]

There is a ID pin present on HD3SS3220 controller that can be routed
to SoC. As per the datasheet:

"Upon detecting a UFP device, HD3SS3220 will keep ID pin high if VBUS is
not at VSafe0V. Once VBUS is at VSafe0V, the HD3SS3220 will assert ID pin
low. This is done to enforce Type-C requirement that VBUS must be at
VSafe0V before re-enabling VBUS"

Add support to read the ID pin state and enable VBUS accordingly.

Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
 drivers/usb/typec/hd3ss3220.c | 60 +++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/drivers/usb/typec/hd3ss3220.c b/drivers/usb/typec/hd3ss3220.c
index 3ecc688dda82..0e81e92f253c 100644
--- a/drivers/usb/typec/hd3ss3220.c
+++ b/drivers/usb/typec/hd3ss3220.c
@@ -15,6 +15,8 @@
 #include <linux/usb/typec.h>
 #include <linux/delay.h>
 #include <linux/workqueue.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
 
 #define HD3SS3220_REG_CN_STAT		0x08
 #define HD3SS3220_REG_CN_STAT_CTRL	0x09
@@ -54,6 +56,11 @@ struct hd3ss3220 {
 	struct delayed_work output_poll_work;
 	enum usb_role role_state;
 	bool poll;
+
+	struct gpio_desc *id_gpiod;
+	int id_irq;
+
+	struct regulator *vbus;
 };
 
 static int hd3ss3220_set_power_opmode(struct hd3ss3220 *hd3ss3220, int power_opmode)
@@ -319,6 +326,28 @@ static const struct regmap_config config = {
 	.max_register = 0x0A,
 };
 
+static irqreturn_t hd3ss3220_id_isr(int irq, void *dev_id)
+{
+	struct hd3ss3220 *hd3ss3220 = dev_id;
+	int ret;
+	int id;
+
+	if (IS_ERR_OR_NULL(hd3ss3220->vbus))
+		return IRQ_HANDLED;
+
+	id = hd3ss3220->id_gpiod ? gpiod_get_value_cansleep(hd3ss3220->id_gpiod) : 1;
+
+	if (!id) {
+		ret = regulator_enable(hd3ss3220->vbus);
+		if (ret)
+			dev_err(hd3ss3220->dev, "enable vbus regulator failed\n");
+	} else {
+		regulator_disable(hd3ss3220->vbus);
+	}
+
+	return IRQ_HANDLED;
+}
+
 static int hd3ss3220_probe(struct i2c_client *client)
 {
 	struct typec_capability typec_cap = { };
@@ -354,6 +383,37 @@ static int hd3ss3220_probe(struct i2c_client *client)
 		hd3ss3220->role_sw = usb_role_switch_get(hd3ss3220->dev);
 	}
 
+	hd3ss3220->id_gpiod = devm_gpiod_get_optional(hd3ss3220->dev, "id", GPIOD_IN);
+	if (IS_ERR(hd3ss3220->id_gpiod))
+		return PTR_ERR(hd3ss3220->id_gpiod);
+
+	if (hd3ss3220->id_gpiod) {
+		hd3ss3220->id_irq = gpiod_to_irq(hd3ss3220->id_gpiod);
+		if (hd3ss3220->id_irq < 0) {
+			dev_err(hd3ss3220->dev, "failed to get ID IRQ\n");
+			return hd3ss3220->id_irq;
+		}
+
+		ret = devm_request_threaded_irq(hd3ss3220->dev,
+						hd3ss3220->id_irq, NULL,
+						hd3ss3220_id_isr,
+						IRQF_TRIGGER_RISING |
+						IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+						dev_name(hd3ss3220->dev), hd3ss3220);
+		if (ret < 0) {
+			dev_err(hd3ss3220->dev, "failed to get id irq\n");
+			return ret;
+		}
+	}
+
+	hd3ss3220->vbus = devm_regulator_get_optional(hd3ss3220->dev, "vbus");
+	if (PTR_ERR(hd3ss3220->vbus) == -ENODEV)
+		hd3ss3220->vbus = NULL;
+
+	if (IS_ERR(hd3ss3220->vbus))
+		return dev_err_probe(hd3ss3220->dev,
+				     PTR_ERR(hd3ss3220->vbus), "failed to get vbus\n");
+
 	if (IS_ERR(hd3ss3220->role_sw)) {
 		ret = PTR_ERR(hd3ss3220->role_sw);
 		goto err_put_fwnode;
-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Dmitry Baryshkov]

On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
> Update the bindings to support reading ID state and VBUS, as per the
> HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
> asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
> VBUS must be at VSafe0V before re-enabling VBUS.
> 
> Add id-gpios property to describe the input gpio for USB ID pin and vbus-
> supply property to describe the regulator for USB VBUS.
> 
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> index bec1c8047bc0..c869eece39a7 100644
> --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> @@ -25,6 +25,19 @@ properties:
>    interrupts:
>      maxItems: 1
>  
> +  id-gpios:
> +    description:
> +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
> +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
> +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
> +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
> +

Stray empty line?

> +    maxItems: 1
> +
> +  vbus-supply:
> +    description: A phandle to the regulator for USB VBUS if needed when host
> +      mode or dual role mode is supported.

Why are we adding the property here while we can use the vbus-supply of
the usb-c-connector?

> +
>    ports:
>      $ref: /schemas/graph.yaml#/properties/ports
>      description: OF graph bindings (specified in bindings/graph.txt) that model
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Rob Herring]

On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
> On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
> > Update the bindings to support reading ID state and VBUS, as per the
> > HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
> > asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
> > VBUS must be at VSafe0V before re-enabling VBUS.
> > 
> > Add id-gpios property to describe the input gpio for USB ID pin and vbus-
> > supply property to describe the regulator for USB VBUS.
> > 
> > Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> > ---
> >  .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > index bec1c8047bc0..c869eece39a7 100644
> > --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > @@ -25,6 +25,19 @@ properties:
> >    interrupts:
> >      maxItems: 1
> >  
> > +  id-gpios:
> > +    description:
> > +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
> > +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
> > +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
> > +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
> > +
> 
> Stray empty line?
> 
> > +    maxItems: 1
> > +
> > +  vbus-supply:
> > +    description: A phandle to the regulator for USB VBUS if needed when host
> > +      mode or dual role mode is supported.
> 
> Why are we adding the property here while we can use the vbus-supply of
> the usb-c-connector?

Normally, that's my question on both of these, too. However, it does 
look like both are connected to the chip. There's VBUS_DET which is 
connected to Vbus (thru a 900k resistor). So having these here does look 
like accurate representation of the h/w. The commit message should make 
this more clear. Honestly, that's really the only part I care about. 
How it works is not so important. 

Rob

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Dmitry Baryshkov]

On Thu, Oct 09, 2025 at 08:15:43AM -0500, Rob Herring wrote:
> On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
> > > Update the bindings to support reading ID state and VBUS, as per the
> > > HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
> > > asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
> > > VBUS must be at VSafe0V before re-enabling VBUS.
> > > 
> > > Add id-gpios property to describe the input gpio for USB ID pin and vbus-
> > > supply property to describe the regulator for USB VBUS.
> > > 
> > > Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> > > ---
> > >  .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > > index bec1c8047bc0..c869eece39a7 100644
> > > --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> > > @@ -25,6 +25,19 @@ properties:
> > >    interrupts:
> > >      maxItems: 1
> > >  
> > > +  id-gpios:
> > > +    description:
> > > +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
> > > +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
> > > +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
> > > +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
> > > +
> > 
> > Stray empty line?
> > 
> > > +    maxItems: 1
> > > +
> > > +  vbus-supply:
> > > +    description: A phandle to the regulator for USB VBUS if needed when host
> > > +      mode or dual role mode is supported.
> > 
> > Why are we adding the property here while we can use the vbus-supply of
> > the usb-c-connector?
> 
> Normally, that's my question on both of these, too. However, it does 
> look like both are connected to the chip. There's VBUS_DET which is 
> connected to Vbus (thru a 900k resistor). So having these here does look 
> like accurate representation of the h/w. The commit message should make 
> this more clear. Honestly, that's really the only part I care about. 
> How it works is not so important. 

The VBUS_DET pin is used by the controller to detect the VBUS provided
by the USB-C partner and to identify when it's safe to turn on the
device's VBUS supply. I think this still fits into the description of
the connector's vbus-supply.

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Krishna Kurapati PSSNV]

On 10/9/2025 8:08 PM, Dmitry Baryshkov wrote:
> On Thu, Oct 09, 2025 at 08:15:43AM -0500, Rob Herring wrote:
>> On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
>>> On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
>>>> Update the bindings to support reading ID state and VBUS, as per the
>>>> HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
>>>> asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
>>>> VBUS must be at VSafe0V before re-enabling VBUS.
>>>>
>>>> Add id-gpios property to describe the input gpio for USB ID pin and vbus-
>>>> supply property to describe the regulator for USB VBUS.
>>>>
>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>>> ---
>>>>   .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
>>>>   1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>> index bec1c8047bc0..c869eece39a7 100644
>>>> --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>> +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>> @@ -25,6 +25,19 @@ properties:
>>>>     interrupts:
>>>>       maxItems: 1
>>>>   
>>>> +  id-gpios:
>>>> +    description:
>>>> +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
>>>> +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
>>>> +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
>>>> +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
>>>> +
>>>
>>> Stray empty line?
>>>
>>>> +    maxItems: 1
>>>> +
>>>> +  vbus-supply:
>>>> +    description: A phandle to the regulator for USB VBUS if needed when host
>>>> +      mode or dual role mode is supported.
>>>
>>> Why are we adding the property here while we can use the vbus-supply of
>>> the usb-c-connector?
>>
>> Normally, that's my question on both of these, too. However, it does
>> look like both are connected to the chip. There's VBUS_DET which is
>> connected to Vbus (thru a 900k resistor). So having these here does look
>> like accurate representation of the h/w. The commit message should make
>> this more clear. Honestly, that's really the only part I care about.
>> How it works is not so important.
> 
> The VBUS_DET pin is used by the controller to detect the VBUS provided
> by the USB-C partner and to identify when it's safe to turn on the
> device's VBUS supply. I think this still fits into the description of
> the connector's vbus-supply.
> 


Hi Dmitry,

  In case we put the vbus supply in usb-c-connector node, is there any 
way we can get its phandle reference in hd3 driver given that the 
connector node is not a child or parent of port controller node.

Regards,
Krishna,

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Dmitry Baryshkov]

On Mon, 13 Oct 2025 at 04:17, Krishna Kurapati PSSNV
<krishna.kurapati@oss.qualcomm.com> wrote:
>
>
>
> On 10/9/2025 8:08 PM, Dmitry Baryshkov wrote:
> > On Thu, Oct 09, 2025 at 08:15:43AM -0500, Rob Herring wrote:
> >> On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
> >>> On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
> >>>> Update the bindings to support reading ID state and VBUS, as per the
> >>>> HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
> >>>> asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
> >>>> VBUS must be at VSafe0V before re-enabling VBUS.
> >>>>
> >>>> Add id-gpios property to describe the input gpio for USB ID pin and vbus-
> >>>> supply property to describe the regulator for USB VBUS.
> >>>>
> >>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> >>>> ---
> >>>>   .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
> >>>>   1 file changed, 13 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> >>>> index bec1c8047bc0..c869eece39a7 100644
> >>>> --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> >>>> +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
> >>>> @@ -25,6 +25,19 @@ properties:
> >>>>     interrupts:
> >>>>       maxItems: 1
> >>>>
> >>>> +  id-gpios:
> >>>> +    description:
> >>>> +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
> >>>> +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
> >>>> +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
> >>>> +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
> >>>> +
> >>>
> >>> Stray empty line?
> >>>
> >>>> +    maxItems: 1
> >>>> +
> >>>> +  vbus-supply:
> >>>> +    description: A phandle to the regulator for USB VBUS if needed when host
> >>>> +      mode or dual role mode is supported.
> >>>
> >>> Why are we adding the property here while we can use the vbus-supply of
> >>> the usb-c-connector?
> >>
> >> Normally, that's my question on both of these, too. However, it does
> >> look like both are connected to the chip. There's VBUS_DET which is
> >> connected to Vbus (thru a 900k resistor). So having these here does look
> >> like accurate representation of the h/w. The commit message should make
> >> this more clear. Honestly, that's really the only part I care about.
> >> How it works is not so important.
> >
> > The VBUS_DET pin is used by the controller to detect the VBUS provided
> > by the USB-C partner and to identify when it's safe to turn on the
> > device's VBUS supply. I think this still fits into the description of
> > the connector's vbus-supply.
> >

>   In case we put the vbus supply in usb-c-connector node, is there any
> way we can get its phandle reference in hd3 driver given that the
> connector node is not a child or parent of port controller node.

Sure. Use devm_of_regulator_get() passing connector node to the function.

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Krishna Kurapati PSSNV]

On 10/13/2025 2:38 PM, Dmitry Baryshkov wrote:
> On Mon, 13 Oct 2025 at 04:17, Krishna Kurapati PSSNV
> <krishna.kurapati@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 10/9/2025 8:08 PM, Dmitry Baryshkov wrote:
>>> On Thu, Oct 09, 2025 at 08:15:43AM -0500, Rob Herring wrote:
>>>> On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
>>>>> On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
>>>>>> Update the bindings to support reading ID state and VBUS, as per the
>>>>>> HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at VSafe0V and
>>>>>> asserted low once VBUS is at VSafe0V, enforcing the Type-C requirement that
>>>>>> VBUS must be at VSafe0V before re-enabling VBUS.
>>>>>>
>>>>>> Add id-gpios property to describe the input gpio for USB ID pin and vbus-
>>>>>> supply property to describe the regulator for USB VBUS.
>>>>>>
>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>>>>> ---
>>>>>>    .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++++++++++
>>>>>>    1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>>>> index bec1c8047bc0..c869eece39a7 100644
>>>>>> --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>>>> @@ -25,6 +25,19 @@ properties:
>>>>>>      interrupts:
>>>>>>        maxItems: 1
>>>>>>
>>>>>> +  id-gpios:
>>>>>> +    description:
>>>>>> +      An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
>>>>>> +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
>>>>>> +      the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
>>>>>> +      requirement that VBUS must be at VSafe0V before re-enabling VBUS.
>>>>>> +
>>>>>
>>>>> Stray empty line?
>>>>>
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  vbus-supply:
>>>>>> +    description: A phandle to the regulator for USB VBUS if needed when host
>>>>>> +      mode or dual role mode is supported.
>>>>>
>>>>> Why are we adding the property here while we can use the vbus-supply of
>>>>> the usb-c-connector?
>>>>
>>>> Normally, that's my question on both of these, too. However, it does
>>>> look like both are connected to the chip. There's VBUS_DET which is
>>>> connected to Vbus (thru a 900k resistor). So having these here does look
>>>> like accurate representation of the h/w. The commit message should make
>>>> this more clear. Honestly, that's really the only part I care about.
>>>> How it works is not so important.
>>>
>>> The VBUS_DET pin is used by the controller to detect the VBUS provided
>>> by the USB-C partner and to identify when it's safe to turn on the
>>> device's VBUS supply. I think this still fits into the description of
>>> the connector's vbus-supply.
>>>
> 
>>    In case we put the vbus supply in usb-c-connector node, is there any
>> way we can get its phandle reference in hd3 driver given that the
>> connector node is not a child or parent of port controller node.
> 
> Sure. Use devm_of_regulator_get() passing connector node to the function.
> 

I am not sure if I am asking the right question, but in case there are 
multiple connector nodes, each one corresponding to one port controller 
node, how do we get the reference of proper connector node in hd3 driver 
since the port controller node and connector node are not parent/child 
or each of them don't have reference to one another.

Regards,
Krishna,

Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state

[Dmitry Baryshkov]

On 14/10/2025 05:39, Krishna Kurapati PSSNV wrote:
> 
> 
> On 10/13/2025 2:38 PM, Dmitry Baryshkov wrote:
>> On Mon, 13 Oct 2025 at 04:17, Krishna Kurapati PSSNV
>> <krishna.kurapati@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 10/9/2025 8:08 PM, Dmitry Baryshkov wrote:
>>>> On Thu, Oct 09, 2025 at 08:15:43AM -0500, Rob Herring wrote:
>>>>> On Wed, Oct 08, 2025 at 09:31:59PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Wed, Oct 08, 2025 at 11:27:49PM +0530, Krishna Kurapati wrote:
>>>>>>> Update the bindings to support reading ID state and VBUS, as per the
>>>>>>> HD3SS3220 data sheet. The ID pin is kept high if VBUS is not at 
>>>>>>> VSafe0V and
>>>>>>> asserted low once VBUS is at VSafe0V, enforcing the Type-C 
>>>>>>> requirement that
>>>>>>> VBUS must be at VSafe0V before re-enabling VBUS.
>>>>>>>
>>>>>>> Add id-gpios property to describe the input gpio for USB ID pin 
>>>>>>> and vbus-
>>>>>>> supply property to describe the regulator for USB VBUS.
>>>>>>>
>>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>>>>>> ---
>>>>>>>    .../devicetree/bindings/usb/ti,hd3ss3220.yaml       | 13 +++++ 
>>>>>>> ++++++++
>>>>>>>    1 file changed, 13 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/usb/ 
>>>>>>> ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ 
>>>>>>> ti,hd3ss3220.yaml
>>>>>>> index bec1c8047bc0..c869eece39a7 100644
>>>>>>> --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
>>>>>>> @@ -25,6 +25,19 @@ properties:
>>>>>>>      interrupts:
>>>>>>>        maxItems: 1
>>>>>>>
>>>>>>> +  id-gpios:
>>>>>>> +    description:
>>>>>>> +      An input gpio for USB ID pin. Upon detecting a UFP device, 
>>>>>>> HD3SS3220
>>>>>>> +      will keep ID pin high if VBUS is not at VSafe0V. Once VBUS 
>>>>>>> is at VSafe0V,
>>>>>>> +      the HD3SS3220 will assert ID pin low. This is done to 
>>>>>>> enforce Type-C
>>>>>>> +      requirement that VBUS must be at VSafe0V before re- 
>>>>>>> enabling VBUS.
>>>>>>> +
>>>>>>
>>>>>> Stray empty line?
>>>>>>
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  vbus-supply:
>>>>>>> +    description: A phandle to the regulator for USB VBUS if 
>>>>>>> needed when host
>>>>>>> +      mode or dual role mode is supported.
>>>>>>
>>>>>> Why are we adding the property here while we can use the vbus- 
>>>>>> supply of
>>>>>> the usb-c-connector?
>>>>>
>>>>> Normally, that's my question on both of these, too. However, it does
>>>>> look like both are connected to the chip. There's VBUS_DET which is
>>>>> connected to Vbus (thru a 900k resistor). So having these here does 
>>>>> look
>>>>> like accurate representation of the h/w. The commit message should 
>>>>> make
>>>>> this more clear. Honestly, that's really the only part I care about.
>>>>> How it works is not so important.
>>>>
>>>> The VBUS_DET pin is used by the controller to detect the VBUS provided
>>>> by the USB-C partner and to identify when it's safe to turn on the
>>>> device's VBUS supply. I think this still fits into the description of
>>>> the connector's vbus-supply.
>>>>
>>
>>>    In case we put the vbus supply in usb-c-connector node, is there any
>>> way we can get its phandle reference in hd3 driver given that the
>>> connector node is not a child or parent of port controller node.
>>
>> Sure. Use devm_of_regulator_get() passing connector node to the function.
>>
> 
> I am not sure if I am asking the right question, but in case there are 
> multiple connector nodes, each one corresponding to one port controller 
> node, how do we get the reference of proper connector node in hd3 driver 
> since the port controller node and connector node are not parent/child 
> or each of them don't have reference to one another.

You have of graph connection between your Type-C controller and the 
USB-C connector. So you can use the of_graph API to get the connector's 
device node.

-- 
With best wishes
Dmitry