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.1On 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
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
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
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,
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
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,
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
© 2016 - 2025 Red Hat, Inc.