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

[Krishna Kurapati]

On 7/16/2026 4:49 AM, Thinh Nguyen wrote:
> On Wed, Jul 15, 2026, Krishna Kurapati wrote:
> > On 7/15/2026 4:53 AM, Thinh Nguyen wrote:
> > > On Mon, Jul 13, 2026, Peter Chen wrote:
> > > > On 26-07-13 23:41:14, Thinh Nguyen wrote:
> > > > > On Mon, Jul 13, 2026, Peter Chen wrote:
> > > > > > On 26-07-13 08:26:59, Krzysztof Kozlowski wrote:
> > > > > > > > > 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!YksJ0tPtRth9ez8t0GB_WaxH3ynx3ya8M8aFIyKfYpApRC_79Ig93CqE2MKcrGJ6O6t_Dl3RD1zftrnxhdtcfoW7hgep8w$
> > > > > > >
> > > > > > > It does not change the fact that type of phy is implied by compatible,
> > > > > > > thus you do not get a new property.
> > > > > >
> > > > > > For USB2 PHY, it has property "phy_type" already, it could extend support
> > > > > > list to eUSB2 like below, dwc3 qcom glue layer could call of_usb_get_phy_mode
> > > > > > or re-use dwc3->hsphy_mode depends on where it needs to use.
> > > > > >
> > > > > > diff --git a/drivers/usb/phy/of.c b/drivers/usb/phy/of.c
> > > > > > index 1ab134f45d67..5cbf17d493ad 100644
> > > > > > --- a/drivers/usb/phy/of.c
> > > > > > +++ b/drivers/usb/phy/of.c
> > > > > > @@ -16,6 +16,7 @@ static const char *const usbphy_modes[] = {
> > > > > >    	[USBPHY_INTERFACE_MODE_ULPI]	= "ulpi",
> > > > > >    	[USBPHY_INTERFACE_MODE_SERIAL]	= "serial",
> > > > > >    	[USBPHY_INTERFACE_MODE_HSIC]	= "hsic",
> > > > > > +	[USBPHY_INTERFACE_MODE_EUSB2]	= "eusb2",
> > > > > >    };
> > > > >
> > > > > eusb2 uses utmi, so it doesn't fit here as a separate mode.
> > > >
> > > > Hi Thinh
> > > >
> > > > Yes, eUSB2 is based on UTMI Parallel mode, but it has dedicated
> > > > Physical Layer Supplement [1], eg at CH2.4, it lists eUSB2 PHY
> > > > Features.
> > > >
> > > >
> > > > > To go this route properly, we'd need to introduce a new phy type
> > > > > attribute in the phy framework, which will be a bigger change that may
> > > > > impact more than this driver.
> > > >
> > > > It is not at generic PHY framework, it is just for USB PHY dedicated.
> > > >
> > > > I do not see big changes, it only needs to change above files and related
> > > > dt-binding files, and other users may leverage it if the controller
> > > > has special sequence or settings for eUSB2.
> > >
> > > The usbphy_modes describes the interface between the controller and the
> > > phy. eusb2 still uses utmi, so adding eusb2 there is sematically
> > > incorrect. If we introduce the eusb2 mode there, we'd have to audit dwc3
> > > and every other driver that uses usbphy_modes to handle the new mode
> > > correctly.
> >
> > Hi Thinh,
> >
> > I don't think any existing drivers need to be modified after adding this. If
> > anyone wants to use the newly added enum for any eusb2 specific purpose,
> > they can do so in a diff change/patch I guess.
>
> At minimum, dwc3 needs to be reviewed and updated for dwc->hsphy_mode
> check when configuring GUSB2PHYCFG. Regardless, phy type should not be a
> usbphy_modes enum as I noted above.
We can just add the enum for eusb2 in of.c as pointed by Peter in [1], 
read that in dwc3-qcom.c and use it during suspend resume for interrupt 
handling and to modify the DWC3_GUSB2PHYCFG_EUSB2OPMODE bit once we are 
modifying it in core.

[1]: https://lore.kernel.org/all/alhDjZ0gJZq_7G6z@xxxxxxxxxxxxxxxxxxxxxxxxx/

Regards,
Krishna,