Re: [PATCH v3] usb: dwc3: qcom: Modify interrupt handling for eUSB2 Phy targets
From: Dmitry Baryshkov
Date: Thu May 28 2026 - 01:39:02 EST
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@xxxxxxxxxxxxxxxx>
> > > >> ---
> > >
> > > [...]
> > >
> > > >> + {
> > > >> + .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.
--
With best wishes
Dmitry