All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Junzhong Pan" <panjunzhong@linux.spacemit.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 2/6] usb: chipidea: usb2: add optional reset support
Date: Wed, 12 Aug 2026 09:41:34 +0000	[thread overview]
Message-ID: <20260812094134.CDCF91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-b4-spacemit-k1-usb2-v1-2-f28cf29e522b@linux.spacemit.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Teardown order inversion between manual clock disable and devm-managed reset assertion.
--

--- Patch [2]: [PATCH 2/6] usb: chipidea: usb2: add optional reset support ---
commit 5129acb0e56d5e6166124800f0bd1996cf88389b
Author: Junzhong Pan <panjunzhong@linux.spacemit.com>

usb: chipidea: usb2: add optional reset support

This commit adds optional reset control support for the USB2 controller
found on the SpacemiT K1 SoC.

> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c b/drivers/usb/chipidea/ci_hdrc_usb2.c
> index 8ffa1e95d8e86..00d575cd29557 100644
> --- a/drivers/usb/chipidea/ci_hdrc_usb2.c
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
[ ... ]
> @@ -80,6 +82,12 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	priv->reset = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> +	if (IS_ERR(priv->reset)) {
> +		ret = PTR_ERR(priv->reset);
> +		goto clk_err;
> +	}
> +

[Severity: High]
Does this create a teardown order inversion later in ci_hdrc_usb2_probe()
or ci_hdrc_usb2_remove()?

Because the reset is acquired using
devm_reset_control_get_optional_exclusive_deasserted(), the devres cleanup
will automatically assert the reset after probe failure or device removal.

However, looking at the rest of ci_hdrc_usb2_probe(), if ci_hdrc_add_device()
fails, the code jumps to clk_err and manually calls clk_disable_unprepare()
before the devres cleanup runs:

ci_hdrc_usb2_probe() {
	...
	priv->ci_pdev = ci_hdrc_add_device(...);
	if (IS_ERR(priv->ci_pdev)) {
		...
		goto clk_err;
	}
	...
clk_err:
	clk_disable_unprepare(priv->clk);
	return ret;
}

This means the reset will be asserted after the clock is disabled. On many
architectures, asserting a peripheral reset while its clock is disabled can
cause bus lockups or system hangs.

This same inversion appears to affect device unbind as well, since
ci_hdrc_usb2_remove() manually disables the clock before devres runs.

Would using devres for the clock enablement ensure standard LIFO teardown
ordering?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-b4-spacemit-k1-usb2-v1-0-f28cf29e522b@linux.spacemit.com?part=2

  reply	other threads:[~2026-08-12  9:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  9:26 [PATCH 0/6] Add SpacemiT K1 USB2.0 controllers support Junzhong Pan
2026-08-12  9:26 ` Junzhong Pan
2026-08-12  9:26 ` [PATCH 1/6] dt-bindings: usb: ci-hdrc-usb2: add spacemit,k1-usb2 compatible Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan
2026-08-12 16:00   ` Conor Dooley
2026-08-12 16:00     ` Conor Dooley
2026-08-12  9:26 ` [PATCH 2/6] usb: chipidea: usb2: add optional reset support Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan
2026-08-12  9:41   ` sashiko-bot [this message]
2026-08-12 10:04     ` Junzhong Pan
2026-08-12  9:26 ` [PATCH 3/6] usb: chipidea: usb2: add SpacemiT K1 support Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan
2026-08-12  9:26 ` [PATCH 4/6] riscv: dts: spacemit: add USB2.0 controller nodes for K1 Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan
2026-08-12  9:51   ` sashiko-bot
2026-08-12 10:12     ` Junzhong Pan
2026-08-12  9:26 ` [PATCH 5/6] riscv: dts: spacemit: enable USB2.0 controllers on BananaPi F3 Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan
2026-08-12  9:26 ` [PATCH 6/6] riscv: defconfig: enable ChipIdea USB controller support Junzhong Pan
2026-08-12  9:26   ` Junzhong Pan

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=20260812094134.CDCF91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=panjunzhong@linux.spacemit.com \
    --cc=robh@kernel.org \
    --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.