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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <654b804d-fbeb-45ea-a6fd-9d551224c934@oss.qualcomm.com>
Date: Tue, 14 Oct 2025 08:09:23 +0530
From: Krishna Kurapati PSSNV <krishna.kurapati@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
        Biju Das <biju.das.jz@...renesas.com>, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: usb: ti,hd3ss3220: Add support for
 VBUS based on ID state



On 10/13/2025 2:38 PM, Dmitry Baryshkov wrote:
> On Mon, 13 Oct 2025 at 04:17, Krishna Kurapati PSSNV
> <krishna.kurapati@....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@....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,