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

[Krishna Kurapati]

On 7/17/2026 9:12 AM, Peter Chen wrote:
> On 26-07-17 01:56:59, Thinh Nguyen wrote:
> > On Thu, Jul 16, 2026, Peter Chen wrote:
> > > On 26-07-17 00:06:37, Thinh Nguyen wrote:
> > > > > I have seen fewer platforms use "phy_type" at dts for arm64, dwc3
> > > > > core uses it only for special cases and the code was added for
> > > > > ten years ago. For the default situation, we may not need to
> > > > > change DWC3_GUSB2PHYCFG_EUSB2OPMODE value for UTMI+, Thinh, is it
> > > > > correct?
> > > >
> > > > The GUSB2PHYCFG.eUSB2OPMODE is only relevant for host mode and mainly
> > > > for electrical compliance. Usually by default, the CoreConsultant
> > > > setting should have this set correctly. So not explicitly setting it
> > > > should be functionally fine (IIRC).
> > > >
> > > > That said, this is separate from the GUSB2PHYCFG.PHYIF, which the core
> > > > uses dwc->hsphy_mode to indicate whether the UTMI interface is 8-bit or
> > > > 16-bit.
> > >
> > > Why only rockchip uses this "phy_type" property, why other SoC vendors
> > > no this requirement for UTMI width setting?
> >
> > Not just rockchip, some tegra and hikey also use it. Some old qcom dts
> > files also have it for ulpi.
>
> Tegra and old qcom platforms use chipidea, hikey uses dwc3.
>
> > It is typically set when the coreConsultant default differs from what
> > the platform needs, so the driver can override it with the correct
> > setting.
> >
> > My point is that changing "phy_type" definition is more involved than it
> > looks. I'm open to alternatives.
>
> I know your concern that in case the eUSB2 PHY SoC wants to change UTMI
> width, it can't do that. Are there controller register know it connects
> eUSB2 PHY?
>
> For the place to put "eusb2" for phy type, I still think enum
> usb_phy_interface at: include/linux/usb/phy.h is the most suitable
> place, would you have any alternatives?
>
> Another solution is using generic PHY API phy_get_mode, set fixed "eusb2"
> mode at eUSB2 PHY driver, but it depends on PHY driver doesn't have
> different settings for device and host mode.

Konrad did suggest this on v3:

https://lore.kernel.org/all/3de365a0-4632-42ea-8a8a-5a4765945a76@xxxxxxxxxxxxxxxx/

This involves cleaning all drivers using these enums if we take that route.

Regards,
Krishna,

> Other solution is compare the generic PHY compatible string at dwc3 qcom
> glue layer, it depends on eUSB2 PHY compatible string always contains
> "eusb2-phy"
>
> I prefer the solution that extend enum usb_phy_interface for eUSB2 PHY,
> it uses existed kernel structure and device tree binding.