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

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

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

Return -EPROBE_DEFER from platform_get_irq_optional() so the driver is
re-probed when the interrupt resource becomes available instead of
continuing probe without an IRQ.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index 56d2ba824a0b..f53d09e90010 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;
 	if (data->wakeup_irq > 0) {
 		irq_name = devm_kasprintf(dev, GFP_KERNEL, "%s:wakeup", pdata.name);
 		if (!irq_name) {
-- 
2.43.0

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

[sashiko-bot]

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 <phucduc.bui@gmail.com>

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/20260806065254.28204-1-phucduc.bui@gmail.com?part=1

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

[Greg Kroah-Hartman]

On Thu, Aug 06, 2026 at 01:52:54PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>

All lower case?

> Return -EPROBE_DEFER from platform_get_irq_optional() so the driver is
> re-probed when the interrupt resource becomes available instead of
> continuing probe without an IRQ.

How was this found and tested?

thanks,

greg k-h

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

[Bui Duc Phuc]

Hi Greg,

Thank you for your feedback.

> > From: bui duc phuc <phucduc.bui@gmail.com>
>
> All lower case?
>

Yes, I’ll keep it lowercase.

> > Return -EPROBE_DEFER from platform_get_irq_optional() so the driver is
> > re-probed when the interrupt resource becomes available instead of
> > continuing probe without an IRQ.
>
> How was this found and tested?
>

I found this during code inspection while cleaning up probe functions in
the Rockchip ASoC drivers.

https://lore.kernel.org/all/20260806052136.21034-1-phucduc.bui@gmail.com/

platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure, including -EPROBE_DEFER. The driver
handled positive IRQ numbers but ignored -EPROBE_DEFER, continuing
probe without an IRQ instead of deferring.

I only compile-tested the change. I don't have the hardware to test this
path at runtime.

While reviewing this,I noticed that -EINVAL also deserves to be returned,
not just -EPROBE_DEFER only -ENXIO really means "no IRQ".
I’ll update this to:

if (data->wakeup_irq < 0 && data->wakeup_irq != -ENXIO) {
        ret = data->wakeup_irq;
        goto err_clk;
}

I also found another issue in the same area:

        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");
+                       ret = dev_err_probe(dev, -ENOMEM, "failed to
create irq_name\n");
                        goto err_clk;
                }


the error return from dev_err_probe() was not assigned to ret,  so the
error path could still return 0.
I’ll send v2 soon.

Best regards,
Phuc