Re: [PATCH v3] usb: dwc3: qcom: Modify interrupt handling for eUSB2 Phy targets

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

On Thu, May 28, 2026, Dmitry Baryshkov wrote:
> On Thu, May 28, 2026 at 12:46:53AM +0000, Thinh Nguyen wrote:
> > On Wed, May 27, 2026, Thinh Nguyen wrote:
> > > On Thu, May 21, 2026, Konrad Dybcio wrote:
> > > > On 5/13/26 10:48 PM, Dmitry Baryshkov wrote:
> > > > > On Mon, May 11, 2026 at 03:14:22PM +0530, Krishna Kurapati wrote:
> > > > >> eUSB2 targets handle wakeup interrupts differently depending on device
> > > > >> speed when operating in host mode.
> > > > >>
> > > > >> According to the eUSB2 specification, remote wakeup signaling in host
> > > > >> mode is detected via different data-line assertions based on the
> > > > >> connected device speed.
> > > > >>
> > > > >> When a low-speed device is connected, the host repeater drives eD+ to
> > > > >> logic '1' upon detecting a K-state on the USB lines during remote wakeup
> > > > >> (eUSB2 specification, Section 5.5.14).
> > > > >>
> > > > >> When a full-speed or high-speed device is connected, the host repeater
> > > > >> drives eD- to logic '1' upon detecting a K-state on the USB line during
> > > > >> remote wakeup (eUSB2 specification, Sections 5.5.15 and 5.5.18).
> > > > >>
> > > > >> Since the eUSB2 PHY's "DP" and "DM" interrupt lines monitor the eD+ and
> > > > >> eD- line states, configure the wakeup interrupts accordingly
> > > > >>
> > > > >> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> > > > >> ---
> > > > 
> > > > [...]
> > > > 
> > > > >> +	{
> > > > >> +		.compatible = "qcom,x1e80100-dwc3-mp",
> > > > >> +		.data = &dwc3_qcom_glymur_pdata,
> > > > > 
> > > > > This would result in the list of the platforms keeping on growing.
> > > > > Would you mind instead detecting eUSB2 by checking that HS PHY has its
> > > > > own phys property?
> > > > 
> > > > I think we've had a very similar issue on some other patch.. we could
> > > > use phy_mode, but it'd require first fixing this mess:
> > > > 
> > > > 28:     PHY_MODE_USB_HOST,
> > > > 29:     PHY_MODE_USB_HOST_LS,
> > > > 30:     PHY_MODE_USB_HOST_FS,
> > > > 31:     PHY_MODE_USB_HOST_HS,
> > > > 32:     PHY_MODE_USB_HOST_SS,
> > > > 33:     PHY_MODE_USB_DEVICE,
> > > > 34:     PHY_MODE_USB_DEVICE_LS,
> > > > 35:     PHY_MODE_USB_DEVICE_FS,
> > > > 36:     PHY_MODE_USB_DEVICE_HS,
> > > > 37:     PHY_MODE_USB_DEVICE_SS,
> > > > 38:     PHY_MODE_USB_OTG
> > > > 
> > > > into PHY_MODE_USB + submodes and phy_opts
> > > > 
> > > 
> > > IMHO, this seems to fit better in the DT binding, ie. a DT property
> > > "qcom,eusb2-phy" would be a cleaner solution than trying to match this
> > > with to compatible string.
> > 
> > Actually, it should be "qcom,has-eusb2-phy".
> 
> No, it's a bad idea from my point of view. The platform defines whether
> it is using eUSB2 or not. As such, it already can be determined from DT.
> The property seems to be a duplicate of the information.
> 

I understand your point, and there may be cases where associating
configuration with a compatible string makes sense. However, I think a
DT property is the better approach here.

The DT does not currently describe the phy interface type in a way the
driver can easily check, the phy phandle is there, but there is no
framework-level attribute that says it is eusb2. So this property
is not duplicating existing info.

More importantly, this is common across many qcom platforms and will
only grow. Maintaining a list of compatible strings in the driver puts
an ongoing burden on driver maintainer every time a new platform is
added. A DT property is only a one-time cost per DTS, and the driver
remains the same.

Both approaches require DT binding documentation (new compatible strings
need to be added). The .data matching approach doesn't avoid binding
maintenance, it just makes it less visible.

The "qcom,has-eusb2-phy" does describe the hardware property and seems to
fit fine in the DTS.

BR,
Thinh