Re: [PATCH] usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Direct return of -EPROBE_DEFER causes severe resource and PM QoS leaks.

Pre-existing issues:
- [High] Unassigned return value from `dev_err_probe()` leads to silent probe failure.
--

--- Patch [1]: [PATCH] usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup ---
commit f3178922b4ca9aa8ccf0ccf0a9ffbc1a5d201ad1
Author: bui duc phuc <[email protected]>

usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup
    
This commit updates the driver to explicitly check if the optional IRQ lookup
returns -EPROBE_DEFER, propagating the error so the driver can be re-probed
when the interrupt resource becomes available.

> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 56d2ba824a0b2..f53d09e900102 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -525,6 +525,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  		data->supports_runtime_pm = true;
>  
>  	data->wakeup_irq = platform_get_irq_optional(pdev, 1);
> +	if (data->wakeup_irq == -EPROBE_DEFER)
> +		return -EPROBE_DEFER;

[Severity: High]
Does this direct return skip necessary cleanup steps?

Returning directly here bypasses the cleanup labels (`err_clk`,
`qos_remove_request`, etc.) which leaks resources like the CPU latency
PM QoS request, clocks, and device refcounts.

Should this set `ret = -EPROBE_DEFER` and jump to `phy_shutdown` instead?

>  	if (data->wakeup_irq > 0) {
>  		irq_name = devm_kasprintf(dev, GFP_KERNEL, "%s:wakeup", pdata.name);
>  		if (!irq_name) {
>  			dev_err_probe(dev, -ENOMEM, "failed to create irq_name\n");

[Severity: High]
This is a pre-existing issue, but does this code fail to assign the return
value?

If `irq_name` allocation fails, `ret` remains 0 from earlier initialization.
This causes the probe function to jump to `err_clk` and return 0, falsely
signaling that the device was successfully probed while leaving it
uninitialized.

Should the result of `dev_err_probe()` be assigned to `ret`?

>  			goto err_clk;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1