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

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

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