From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH] usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup
Date: Thu, 06 Aug 2026 06:57:55 +0000 [thread overview]
Message-ID: <20260806065755.C9F361F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806065254.28204-1-phucduc.bui@gmail.com>
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
next prev parent reply other threads:[~2026-08-06 6:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 6:52 [PATCH] usb: chipidea: ci_hdrc_imx: Propagate -EPROBE_DEFER from IRQ lookup phucduc.bui
2026-08-06 6:57 ` sashiko-bot [this message]
2026-08-06 7:02 ` Greg Kroah-Hartman
2026-08-07 4:57 ` Bui Duc Phuc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260806065755.C9F361F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=phucduc.bui@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.