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

[Thinh Nguyen]

On Mon, Jul 13, 2026, Krzysztof Kozlowski wrote:
> On 10/07/2026 23:02, Thinh Nguyen wrote:
> > On Fri, Jul 10, 2026, Krzysztof Kozlowski wrote:
> >> On 10/07/2026 09:16, Krzysztof Kozlowski wrote:
> >>> On Fri, Jul 10, 2026 at 01:52:45AM +0000, Thinh Nguyen wrote:
> >>>> 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
> >>>
> >>> You have a fixed/finite list of phys which needs something special, so
> >>> that information as Dmitry said is in DT already.
> > 
> > Are you referring to a fixed list of eusb2 phy compatibles, or a fixed
> > list of dwc3 node compatibles?
> 
> The phys.
> 
> > 
> > Either way, the list is not fixed. New eusb2 SoC variants are added
> > regularly, and there are already 12 eusb2 phy compatible strings in the
> 
> It is fixed. You have 12 compatible strings, so it is strictly defined.

That's the current list. New eusb2 SoC will require updating
dwc3-qcom.c, which is a burden in the wrong driver.

> 
> > DT bindings but only 3 in the PHY driver of_match tables, they don't
> > land at the same time. As for what information is already in DT, I've
> > addressed this above and in my earlier response.
> > 
> >>>
> >>> Anyway, the commit msg and property field have insufficient description
> >>> of actual hardware problem being represented by this property, so it
> >>> looks way too much as SW policy.
> > 
> > That's fair feedback to raise with Krishna.
> > 
> >>
> >>
> >> And Dmitry already said this at v3.
> > 
> > And I've already responded to his comment in v3:
> > https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/ahjYwJtiMsm0BcCh@vbox/__;!!A4F2R9G_pg!ZEG8l-sDLzQFahbzy3JtuLWdhpqQ4VQ7Z62AaqP7IxJ7r3Ua0UfUtFg1NMar0nnPw86WlKXm6J8_PMfNvg$ 
> 
> It does not change the fact that type of phy is implied by compatible,
> thus you do not get a new property.
> 

The dwc3 glue driver should not need to maintain a list of phy
compatible strings. The phy compatible strings should be for the phy
driver to identify its own hardware, not an interface for other drivers
to use. Using them in dwc3-qcom.c creates cross-subsystem dependency
that bypass the phy framework.

BR,
Thinh