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

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Fri, Jul 17, 2026, Krishna Kurapati wrote:
> 
> 
> 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?

The controller doesn't know that.

> > 
> > 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://urldefense.com/v3/__https://lore.kernel.org/all/3de365a0-4632-42ea-8a8a-5a4765945a76@oss.qualcomm.com/__;!!A4F2R9G_pg!bFfHVkKIznULZPI2qLzahGobT6OIz4j3-XA_n_3hHnRuvzps_XuAGJdphzxkK4bk6twEah-Zn6xRS1uCQCjZ1ud3HnRftKhw2SXfqA$
> 
> This involves cleaning all drivers using these enums if we take that route.

We should not be using phy_attrs.mode. It's a runtime operation mode.

Instead, we can introduce a new phy attribute phy_attrs.type and
phy_get_type(). The phy driver can set this at probe and the dwc3-qcom.c
can query it from the phy phandle.

We can define PHY_TYPE_EUSB2 along with the existing types in
include/dt-bindings/phy/phy.h for this attribute.

BR,
Thinh