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] [day] [month] [year] [list]
Message-ID: <CAO9ioeX51SzaMS4TK7=xfCXBNYi7SGsMBZAv4FrZ1LzONWFw3A@mail.gmail.com>
Date: Mon, 13 Oct 2025 12:08:58 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Krishna Kurapati PSSNV <krishna.kurapati@....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 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.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ