Skip to contentSkip to conversation

usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup

PATCH Superseded [email protected] 3 participants 4 messages Aug 6 – Aug 7

Subsystems (3)
USB Arm i.MX and Layerscape Chipidea USB high speed dual role controller

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH 1/1 usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup

From: bui duc phuc <[email protected]>

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 <[email protected]>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/usb/chipidea/ci_hdrc_imx.c +2 -0
index 56d2ba824a0b..f53d09e90010 100644
@@ -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) {
Signature · 1 line
2.43.0
AI review
#1 lore raw
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

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.

drivers/usb/chipidea/ci_hdrc_imx.c static int ci_hdrc_imx_probe(struct platform_device *pdev) · line 529

Quoted 10 lines
drivers/usb/chipidea/ci_hdrc_imx.c +2 -0
index 56d2ba824a0b2..f53d09e900102 100644
@@ -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?

Quoted 4 lines
drivers/usb/chipidea/ci_hdrc_imx.c +0 -0
 	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?

Quoted 2 lines
drivers/usb/chipidea/ci_hdrc_imx.c +0 -0
 			goto err_clk;
 		}
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
author
#3 lore raw

Hi Greg,

Thank you for your feedback.

Quoted 4 lines
Quoted 1 line

From: bui duc phuc <[email protected]>

All lower case?

Yes, I’ll keep it lowercase.

Quoted 6 lines
Quoted 3 lines

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/[email protected]/

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