Re: [PATCH v2 3/3] mmc: davinci: Handle optional IRQ return value correctly

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Hardware clock is disabled before devm-managed IRQ handlers are unregistered, creating a window for fatal unclocked register accesses.
- [High] The probe function overwrites `pdev->id_entry` with `NULL` for legacy devices, breaking hardware version detection.
- [High] The device's memory region name points to a dynamically allocated string that is freed prior to the region itself during teardown.
- [High] Failure to check the `dma_map_sg` return value leads to an invalid `dma_unmap_sg` call during PIO fallback.
--

--- Patch [3]: [PATCH v2 3/3] mmc: davinci: Handle optional IRQ return value correctly ---
commit 27e81af9e24b190ffa17b59c0cbac338793c903c
Author: bui duc phuc <phucduc.bui@gmail.com>

mmc: davinci: Handle optional IRQ return value correctly

host->sdio_irq is assigned from platform_get_irq_optional(), which
returns a positive IRQ number on success or a negative error code on
failure. Therefore, 0 is not a possible return value from this API.

Check for a positive IRQ number before requesting the SDIO IRQ instead
of treating zero as a valid IRQ.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>

> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index 773577a105124..c503e5f5c8865 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -1303,7 +1303,7 @@ static int davinci_mmcsd_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto mmc_add_host_fail;
>  
> -	if (host->sdio_irq >= 0) {
> +	if (host->sdio_irq > 0) {
>  		ret = devm_request_irq(&pdev->dev, host->sdio_irq,
>  				       mmc_davinci_sdio_irq, 0,
>  				       mmc_hostname(mmc), host);

[Severity: High]
This is a pre-existing issue, but does the error handling in probe and the
remove function create a window where unclocked register accesses can occur?

In the probe error path and the remove function, the hardware clock is
disabled before the devres-managed IRQ handlers are unregistered:

drivers/mmc/host/davinci_mmc.c:davinci_mmcsd_probe() {
    ...
dma_probe_defer:
    clk_disable_unprepare(host->clk);
    return ret;
}

Since the IRQ is managed by devm_request_irq(), it remains active while the
clock is explicitly disabled. Could an interrupt fire during this window and
cause a synchronous external abort when the handler reads unclocked registers?

[Severity: High]
This isn't a bug introduced by this patch, but does the probe function break
hardware version detection for legacy non-OF devices?

The probe function unconditionally overwrites the platform device's id_entry:

drivers/mmc/host/davinci_mmc.c:davinci_mmcsd_probe() {
    ...
    pdev->id_entry = device_get_match_data(&pdev->dev);
    ...
}

If the device is instantiated via legacy platform data rather than device
tree, device_get_match_data() will return NULL. This overwrites the
previously valid pdev->id_entry, which corrupts subsequent
platform_get_device_id() lookups later in the probe sequence.

[Severity: High]
This is a pre-existing issue, but could the memory region rename cause a
use-after-free during device teardown?

In the probe function, the memory region's name is set to a dynamically
allocated string from the mmc host:

drivers/mmc/host/davinci_mmc.c:davinci_mmcsd_probe() {
    ...
    rename_region(mem, mmc_hostname(mmc));
    ...
}

During teardown in davinci_mmcsd_remove(), devres executes in reverse order.
The MMC host (which contains the mmc_hostname string) will be freed before
the devres-managed memory region is released. If /proc/iomem is read during
this window, would it dereference a dangling pointer?

[Severity: High]
This isn't a bug introduced by this patch, but could a failure in DMA mapping
lead to an invalid unmap call later?

In mmc_davinci_start_dma_transfer(), the return value of dma_map_sg() is not
checked for failure (which returns 0):

drivers/mmc/host/davinci_mmc.c:mmc_davinci_start_dma_transfer() {
    ...
    host->sg_len = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
                              mmc_get_dma_dir(data));
    ...
    host->do_dma = 1;
    ...
}

If dma_map_sg() fails and returns 0, host->do_dma is still set to 1. This
engages the PIO fallback but retains the DMA state, potentially causing
invalid dma_unmap_sg() calls when the transfer completes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813053404.21553-1-phucduc.bui@gmail.com?part=3

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic