[PATCH v11 16/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] _ufs_mtk_clk_scale ignores hardware configuration failures, causing the UFS core to apply clock rates to the wrong parent.
--

commit ea79392ecd3d0415deb8de00d83deee028772b07
Author: Nicolas Frattaroli <nicolas.frattaroli at collabora.com>

scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths

This commit updates the error logging in _ufs_mtk_clk_scale to use
dev_err instead of dev_info. It also adds missing goto statements in
the scale-up branches to ensure proper cleanup on failure.

> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
> index 5d8c02b7a857b..43fb5dbb250b0 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c

[ ... ]

> @@ -2029,51 +2029,48 @@ static void _ufs_mtk_clk_scale(struct ufs_hba *hba, bool scale_up)
>  		if (clk_bind_vcore) {
>  			ret = regulator_set_voltage(reg, volt, INT_MAX);
>  			if (ret) {
> -				dev_info(hba->dev,
> -					"Failed to set vcore to %d\n", volt);
> +				dev_err(hba->dev, "Failed to set vcore to %d\n", volt);
>  				goto out;

[Severity: High]
This is a pre-existing issue, but by handling the error internally and 
returning void, _ufs_mtk_clk_scale() prevents error propagation.

If regulator_set_voltage() or clk_set_parent() fails here and jumps to out,
the calling function ufs_mtk_clk_scale() will incorrectly update the driver
state as if the operation succeeded:

drivers/ufs/host/ufs-mediatek.c:ufs_mtk_clk_scale() {
    ...
    if (scale_up)
        _ufs_mtk_clk_scale(hba, true);
    ...
    host->clk_scale_up = scale_up;
    ...
    clki->curr_freq = clki->max_freq;
}

Because ufs_mtk_clk_scale_notify() unconditionally returns 0 to the UFS
core regardless of PRE_CHANGE failures, the UFS core will proceed as if the
clock scaling completed.

Will this mismatch between the physical hardware state and the driver state
cause the UFS core to apply target frequencies to the wrong clock parent,
potentially leading to controller hangs or data corruption? Should
_ufs_mtk_clk_scale() and ufs_mtk_clk_scale() be updated to return an int so
ufs_mtk_clk_scale_notify() can properly abort the scale operation?

>  			}
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-mt8196-ufs-v11-0-dbd007704490@collabora.com?part=16