From: sashiko-bot@kernel.org
To: "Geert Uytterhoeven" <geert+renesas@glider.be>
Cc: linux-clk@vger.kernel.org, neil.armstrong@linaro.org,
linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
Date: Fri, 21 Aug 2026 10:18:20 +0000 [thread overview]
Message-ID: <20260821101820.D012A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <4b9a377a810b69a4eb885fc00cb34ef63e7fc1f1.1787240090.git.geert+renesas@glider.be>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Uninitialized spinlock access in interrupt handler
--
--- Patch [1]: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized ---
commit 20368821444f654f1165c58c0816283a3774d376
Author: Geert Uytterhoeven <geert+renesas@glider.be>
mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
This commit fully initializes the clk_init_data structure to avoid subtle
initialization issues. By ensuring all members are zeroed, it prevents bugs
when specific stack initialization configs are enabled.
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 694bb443d5f3f..698febdcd4988 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
> */
> static int meson_mmc_clk_init(struct meson_host *host)
> {
> - struct clk_init_data init;
> + struct clk_init_data init = {};
> struct clk_mux *mux;
> struct clk_divider *div;
> char clk_name[32];
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how the
interrupt handler is registered relative to lock initialization in this driver.
In drivers/mmc/host/meson-gx-mmc.c:meson_mmc_probe(), the interrupt is
requested before the spinlock is initialized:
ret = request_threaded_irq(host->irq, meson_mmc_irq,
meson_mmc_irq_thread, IRQF_ONESHOT,
dev_name(&pdev->dev), host);
if (ret)
goto err_init_clk;
spin_lock_init(&host->lock);
If an interrupt fires immediately upon registration, the interrupt handler
can begin execution and attempt to acquire the uninitialized lock:
drivers/mmc/host/meson-gx-mmc.c:meson_mmc_irq() {
...
if (status & IRQ_SDIO) {
spin_lock(&host->lock);
__meson_mmc_enable_sdio_irq(host->mmc, 0);
sdio_signal_irq(host->mmc);
spin_unlock(&host->lock);
...
}
Could this result in a lockdep warning or kernel oops if a spurious interrupt
or pending hardware event triggers before spin_lock_init() completes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787240090.git.geert+renesas@glider.be?part=1
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Geert Uytterhoeven" <geert+renesas@glider.be>
Cc: linux-clk@vger.kernel.org, neil.armstrong@linaro.org,
linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
Date: Fri, 21 Aug 2026 10:18:20 +0000 [thread overview]
Message-ID: <20260821101820.D012A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <4b9a377a810b69a4eb885fc00cb34ef63e7fc1f1.1787240090.git.geert+renesas@glider.be>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Uninitialized spinlock access in interrupt handler
--
--- Patch [1]: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized ---
commit 20368821444f654f1165c58c0816283a3774d376
Author: Geert Uytterhoeven <geert+renesas@glider.be>
mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized
This commit fully initializes the clk_init_data structure to avoid subtle
initialization issues. By ensuring all members are zeroed, it prevents bugs
when specific stack initialization configs are enabled.
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 694bb443d5f3f..698febdcd4988 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -418,7 +418,7 @@ static int meson_mmc_clk_set(struct meson_host *host, unsigned long rate,
> */
> static int meson_mmc_clk_init(struct meson_host *host)
> {
> - struct clk_init_data init;
> + struct clk_init_data init = {};
> struct clk_mux *mux;
> struct clk_divider *div;
> char clk_name[32];
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how the
interrupt handler is registered relative to lock initialization in this driver.
In drivers/mmc/host/meson-gx-mmc.c:meson_mmc_probe(), the interrupt is
requested before the spinlock is initialized:
ret = request_threaded_irq(host->irq, meson_mmc_irq,
meson_mmc_irq_thread, IRQF_ONESHOT,
dev_name(&pdev->dev), host);
if (ret)
goto err_init_clk;
spin_lock_init(&host->lock);
If an interrupt fires immediately upon registration, the interrupt handler
can begin execution and attempt to acquire the uninitialized lock:
drivers/mmc/host/meson-gx-mmc.c:meson_mmc_irq() {
...
if (status & IRQ_SDIO) {
spin_lock(&host->lock);
__meson_mmc_enable_sdio_irq(host->mmc, 0);
sdio_signal_irq(host->mmc);
spin_unlock(&host->lock);
...
}
Could this result in a lockdep warning or kernel oops if a spurious interrupt
or pending hardware event triggers before spin_lock_init() completes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787240090.git.geert+renesas@glider.be?part=1
next prev parent reply other threads:[~2026-08-21 10:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 10:06 [PATCH 0/2] mmc: Make sure clk_init_data is fully initialized Geert Uytterhoeven
2026-08-21 10:06 ` Geert Uytterhoeven
2026-08-21 10:06 ` [PATCH 1/2] mmc: meson-gx: FIXME: " Geert Uytterhoeven
2026-08-21 10:06 ` Geert Uytterhoeven
2026-08-21 10:18 ` sashiko-bot [this message]
2026-08-21 10:18 ` sashiko-bot
2026-08-21 10:06 ` [PATCH 2/2] mmc: sdhci-of-arasan: " Geert Uytterhoeven
2026-08-21 10:06 ` Geert Uytterhoeven
2026-08-21 10:15 ` sashiko-bot
2026-08-21 10:15 ` sashiko-bot
2026-08-21 10:56 ` [PATCH 0/2] mmc: " Michal Simek
2026-08-21 10:56 ` Michal Simek
2026-08-21 11:36 ` Geert Uytterhoeven
2026-08-21 11:36 ` Geert Uytterhoeven
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=20260821101820.D012A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=geert+renesas@glider.be \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=neil.armstrong@linaro.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.