[PATCH v4 2/5] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The PHY device is marked as wakeup capable, but the driver lacks the necessary PM callbacks and interrupt handling to actually implement wakeup functionality, rendering the exposed sysfs entry non-functional.
--

commit 8736c5d3dc323070e318c02e401cc5a5d6dd083d
Author: Xu Yang <xu.yang_2 at nxp.com>

phy: fsl-imx8mq-usb: set usb phy to be wakeup capable

This commit marks the i.MX8MQ USB PHY device as wakeup capable. This
advertises the capability to the PM core and exposes a power/wakeup sysfs
entry to userspace.

> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 88b804b2c982b..591ddf3460618 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -728,6 +728,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>  					"failed to get tca\n");
>  
>  	imx8m_get_phy_tuning_data(imx_phy);
> +	device_set_wakeup_capable(dev, true);

[Severity: Medium]
Does this regression expose a non-functional sysfs node to userspace?

The commit message notes that the PHY supports remote wakeup, but the
driver itself does not appear to implement any PM callbacks or interrupt
handling to actually process the wakeup or check device_may_wakeup(dev).

Because actual USB remote wakeup is typically managed by the parent USB
controller and its glue layer, which have their own functional wakeup
sysfs nodes, could this create a dead toggle in sysfs where userspace can
enable wakeup on the PHY device without any actual effect?

>  
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605-imx8mp-usb-phy-improvement-v4-0-b2ddf2f3862c@nxp.com?part=2