Re: [PATCH v4 1/2] dt-bindings: qcom,snps-dwc3: Add property indicating presence of eUSB2 phy

[Thinh Nguyen]

On Thu, Jul 09, 2026, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 02:22:36PM +0530, Krishna Kurapati wrote:
> > Add property "qcom,has-eusb2-phy" to indicate whether the SoC has eUSB2 phy
> > or not. This is used to modify dp/dm interrupts during host mode suspend.
> > 
> > Signed-off-by: Krishna Kurapati <krishna.kurapati@xxxxxxxxxxxxxxxx>
> > ---
> >  Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> > index 8201656b41ed..0c6a839be82f 100644
> > --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> > +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> > @@ -152,6 +152,13 @@ properties:
> >        HS/FS/LS modes are supported.
> >      type: boolean
> >  
> > +  qcom,has-eusb2-phy:
> > +    description:
> > +      If present, it indicates that the controller is working with eUSB2
> > +      phy. This property is used to modify dp/dm interrupt configurations
> > +      while entering suspend.
> > +    type: boolean
> 
> I still have exactly the same concern. This information is already
> present in the DT.
> 

Could you clarify what you mean by "this information is already present
in the DT"? Are you suggesting we use the dwc3 node's compatible string
to infer the phy type?

The dwc3 glue compatible describes the controller, not the phy. They are
separate IP blocks. A board variant could reuse the same dwc3 compatible
with a different phy attached, making that inference silently wrong.

The phy type is described somewhere else in the DT (in the phy node
itself), referenced via the phy's phandle on the dwc3 core child node.
We could walk that phandle and check whether the phy node's compatible
contains "eusb2". However, that relies on a naming convention that isn't
enforced anywhere. All current eusb2 phy compatibles happen to follow it
(qcom,sm8550-snps-eusb2-phy, qcom,sm8750-m31-eusb2-phy,
samsung,exynos2200-eusb2-phy, etc.), but a future phy driver could break
that assumption silently. The alternative is maintaining an explicit
list of eusb2 compatibles inside dwc3-qcom.c just moves the maintenance
burden into the wrong place.

The "qcom,has-eusb2-phy" on the dwc3 node is explicit. I think it's the
right approach here. If you have a better suggestion, please share with
us.

Thanks,
Thinh