Re: [PATCH 1/2] mmc: meson-gx: FIXME: Make sure clk_init_data is fully initialized

[sashiko-bot@kernel.org]

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