Re: [PATCH v2 3/3] nvmem: mtk-efuse: add mt6572 support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Medium] Flawed string matching logic in NVMEM cell fixup causes false positive matches and potential data corruption.
--

--- Patch [3]: [PATCH v2 3/3] nvmem: mtk-efuse: add mt6572 support ---
commit 859e63115931e7de172aeee767133c45a658b170
Author: Roman Vivchar <rva333@protonmail.com>

nvmem: mtk-efuse: add mt6572 support

This commit adds platform data to support the efuse controller on the mt6572
SoC. It configures the controller to use aligned reads and explicitly disables
post-processing for this device.

> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 178b9d85f813e..99d061eef6e33 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
[ ... ]
> @@ -132,6 +132,11 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct mtk_efuse_pdata mtk_mt6572_efuse_pdata = {
> +	.uses_post_processing = false,

[Severity: Medium]
This is a pre-existing issue, but looking at the post-processing logic that
is toggled by this flag, does the string matching logic cause false positive
matches?

drivers/nvmem/mtk-efuse.c:mtk_efuse_fixup_dt_cell_info() {
    ...
    if (cell->nbits <= 3 &&
        strncmp(cell->name, "gpu-speedbin", min(sz, strlen("gpu-speedbin"))) == 0)
        cell->read_post_process = mtk_efuse_gpu_speedbin_pp;
    ...
}

Because strncmp() takes the minimum of the two string lengths, any cell name
that is a prefix of "gpu-speedbin" (such as "gpu" or "gpu-speed") and has
3 or fewer bits will incorrectly match and have its data unintentionally
modified by mtk_efuse_gpu_speedbin_pp() upon read. Can this lead to NVMEM
cell data corruption for unrelated cells?

> +	.needs_aligned_read = true,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724-6572-nvmem-v2-0-e58d16a29621@protonmail.com?part=3