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

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

[Krishna Kurapati]

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>
---
Changes in v3:
- Removed multiple glymur-dwc3-mp pdata entries
- Replaced use of ternary operators with if-else

Link to v2:
https://lore.kernel.org/all/20260505194242.1947891-1-krishna.kurapati@oss.qualcomm.com/

Changes in v2:
- Updated commit message
- added supported eUSB2 targets

Link to v1:
https://lore.kernel.org/all/20260502095616.666938-1-krishna.kurapati@oss.qualcomm.com/

This patch was tested on Glymur.

 drivers/usb/dwc3/dwc3-qcom.c | 94 +++++++++++++++++++++++++++++++-----
 1 file changed, 83 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index f43f73ac36ff..3b025d4beeae 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -60,6 +60,10 @@ static const u32 pwr_evnt_irq_stat_reg[DWC3_QCOM_MAX_PORTS] = {
 	0x238,
 };
 
+struct dwc3_qcom_platform_data {
+	bool			uses_eusb2_phy;
+};
+
 struct dwc3_qcom_port {
 	int			qusb2_phy_irq;
 	int			dp_hs_phy_irq;
@@ -85,6 +89,7 @@ struct dwc3_qcom {
 	struct icc_path		*icc_path_apps;
 
 	enum usb_role		current_role;
+	bool			uses_eusb2_phy;
 };
 
 #define to_dwc3_qcom(d) container_of((d), struct dwc3_qcom, dwc)
@@ -272,15 +277,23 @@ static void dwc3_qcom_disable_wakeup_irq(int irq)
 	disable_irq_nosync(irq);
 }
 
-static void dwc3_qcom_disable_port_interrupts(struct dwc3_qcom_port *port)
+static void dwc3_qcom_disable_port_interrupts(struct dwc3_qcom *qcom, int port_index)
 {
+	struct dwc3_qcom_port *port = &qcom->ports[port_index];
+
 	dwc3_qcom_disable_wakeup_irq(port->qusb2_phy_irq);
 
 	if (port->usb2_speed == USB_SPEED_LOW) {
-		dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
+		if (qcom->uses_eusb2_phy)
+			dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
+		else
+			dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
 	} else if ((port->usb2_speed == USB_SPEED_HIGH) ||
 			(port->usb2_speed == USB_SPEED_FULL)) {
-		dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
+		if (qcom->uses_eusb2_phy)
+			dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
+		else
+			dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
 	} else {
 		dwc3_qcom_disable_wakeup_irq(port->dp_hs_phy_irq);
 		dwc3_qcom_disable_wakeup_irq(port->dm_hs_phy_irq);
@@ -289,8 +302,10 @@ static void dwc3_qcom_disable_port_interrupts(struct dwc3_qcom_port *port)
 	dwc3_qcom_disable_wakeup_irq(port->ss_phy_irq);
 }
 
-static void dwc3_qcom_enable_port_interrupts(struct dwc3_qcom_port *port)
+static void dwc3_qcom_enable_port_interrupts(struct dwc3_qcom *qcom, int port_index)
 {
+	struct dwc3_qcom_port *port = &qcom->ports[port_index];
+
 	dwc3_qcom_enable_wakeup_irq(port->qusb2_phy_irq, 0);
 
 	/*
@@ -303,12 +318,20 @@ static void dwc3_qcom_enable_port_interrupts(struct dwc3_qcom_port *port)
 	 */
 
 	if (port->usb2_speed == USB_SPEED_LOW) {
-		dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
-					    IRQ_TYPE_EDGE_FALLING);
+		if (qcom->uses_eusb2_phy)
+			dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
+						    IRQ_TYPE_EDGE_RISING);
+		else
+			dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
+						    IRQ_TYPE_EDGE_FALLING);
 	} else if ((port->usb2_speed == USB_SPEED_HIGH) ||
 			(port->usb2_speed == USB_SPEED_FULL)) {
-		dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
-					    IRQ_TYPE_EDGE_FALLING);
+		if (qcom->uses_eusb2_phy)
+			dwc3_qcom_enable_wakeup_irq(port->dm_hs_phy_irq,
+						    IRQ_TYPE_EDGE_RISING);
+		else
+			dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
+						    IRQ_TYPE_EDGE_FALLING);
 	} else {
 		dwc3_qcom_enable_wakeup_irq(port->dp_hs_phy_irq,
 					    IRQ_TYPE_EDGE_RISING);
@@ -324,7 +347,7 @@ static void dwc3_qcom_disable_interrupts(struct dwc3_qcom *qcom)
 	int i;
 
 	for (i = 0; i < qcom->num_ports; i++)
-		dwc3_qcom_disable_port_interrupts(&qcom->ports[i]);
+		dwc3_qcom_disable_port_interrupts(qcom, i);
 }
 
 static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
@@ -332,7 +355,7 @@ static void dwc3_qcom_enable_interrupts(struct dwc3_qcom *qcom)
 	int i;
 
 	for (i = 0; i < qcom->num_ports; i++)
-		dwc3_qcom_enable_port_interrupts(&qcom->ports[i]);
+		dwc3_qcom_enable_port_interrupts(qcom, i);
 }
 
 static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
@@ -609,6 +632,7 @@ struct dwc3_glue_ops dwc3_qcom_glue_ops = {
 
 static int dwc3_qcom_probe(struct platform_device *pdev)
 {
+	const struct dwc3_qcom_platform_data *pdata;
 	struct dwc3_probe_data	probe_data = {};
 	struct device		*dev = &pdev->dev;
 	struct dwc3_qcom	*qcom;
@@ -624,6 +648,10 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
 
 	qcom->dev = &pdev->dev;
 
+	pdata = device_get_match_data(dev);
+	if (pdata)
+		qcom->uses_eusb2_phy = pdata->uses_eusb2_phy;
+
 	qcom->resets = devm_reset_control_array_get_optional_exclusive(dev);
 	if (IS_ERR(qcom->resets)) {
 		return dev_err_probe(&pdev->dev, PTR_ERR(qcom->resets),
@@ -838,8 +866,52 @@ static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
 	.prepare = pm_sleep_ptr(dwc3_qcom_prepare),
 };
 
+static const struct dwc3_qcom_platform_data dwc3_qcom_glymur_pdata = {
+	.uses_eusb2_phy = true,
+};
+
 static const struct of_device_id dwc3_qcom_of_match[] = {
-	{ .compatible = "qcom,snps-dwc3" },
+	{ .compatible = "qcom,snps-dwc3", },
+	{
+		.compatible = "qcom,eliza-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,glymur-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,glymur-dwc3-mp",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,kaanapali-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,milos-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,sm8550-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,sm8650-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,sm8750-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,x1e80100-dwc3",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
+	{
+		.compatible = "qcom,x1e80100-dwc3-mp",
+		.data = &dwc3_qcom_glymur_pdata,
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, dwc3_qcom_of_match);
-- 
2.34.1

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

[Dmitry Baryshkov]

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>
> ---
> Changes in v3:
> - Removed multiple glymur-dwc3-mp pdata entries
> - Replaced use of ternary operators with if-else
> 
> Link to v2:
> https://lore.kernel.org/all/20260505194242.1947891-1-krishna.kurapati@oss.qualcomm.com/
> 
> Changes in v2:
> - Updated commit message
> - added supported eUSB2 targets
> 
> Link to v1:
> https://lore.kernel.org/all/20260502095616.666938-1-krishna.kurapati@oss.qualcomm.com/
> 
> This patch was tested on Glymur.
> 
>  drivers/usb/dwc3/dwc3-qcom.c | 94 +++++++++++++++++++++++++++++++-----
>  1 file changed, 83 insertions(+), 11 deletions(-)

> @@ -838,8 +866,52 @@ static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
>  	.prepare = pm_sleep_ptr(dwc3_qcom_prepare),
>  };
>  
> +static const struct dwc3_qcom_platform_data dwc3_qcom_glymur_pdata = {
> +	.uses_eusb2_phy = true,
> +};

There is nothing _glymur_ in this pdata. Please name it accordingly.

> +
>  static const struct of_device_id dwc3_qcom_of_match[] = {
> -	{ .compatible = "qcom,snps-dwc3" },
> +	{ .compatible = "qcom,snps-dwc3", },
> +	{
> +		.compatible = "qcom,eliza-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,glymur-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,glymur-dwc3-mp",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,kaanapali-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,milos-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,sm8550-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,sm8650-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,sm8750-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.compatible = "qcom,x1e80100-dwc3",
> +		.data = &dwc3_qcom_glymur_pdata,
> +	},
> +	{
> +		.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?

> +	},
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, dwc3_qcom_of_match);
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Konrad Dybcio]

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

Konrad

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

[Thinh Nguyen]

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.

Also Krishna, your patch is corrupted. Please fix it.

BR,
Thinh

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

[Thinh Nguyen]

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".

> 
> Also Krishna, your patch is corrupted. Please fix it.
> 

I notice all the qcom phy with eusb2 phy as a eusb2-phy substring. We
can (maybe) match the phy compatible substring:

/* not tested */
static bool dwc3_qcom_has_eusb2_phy(struct device *dev)
{
	struct device_node *hs_phy;
	int i;
	bool ret;

	if (of_property_match_string(dev->of_node, "phy-names", "usb2-phy"))
		return false;

	hs_phy = of_parse_phandle(dev->of_node, "phys", i);
	if (!hs_phy)
		return false;

	ret = of_device_is_compatible(hs_phy, "eusb2-phy");
	of_node_put(hs_phy);
	return ret;
}

But I don't like this approach either. Seems very fragile.

BR,
Thinh

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

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

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

[Thinh Nguyen]

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