Re: [PATCH v4 16/16] mtd: spi-nor: run PHY tuning after init and update dirmap frequency

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] If probe steps fail after device initialization, `spi_nor_probe()` returns without restoring hardware state, leaving the device in an inconsistent configuration across soft reboots.
--

commit 7ac575a84edff91451a5b41913132dbcedb404cd
Author: Santhosh Kumar K <s-k6@ti.com>

mtd: spi-nor: run PHY tuning after init and update dirmap frequency

Run PHY tuning in spi_nor_probe() before creating dirmaps so the validated
frequency is available at dirmap construction time, falling back to base
rate on failure.

> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 2c9859fb07949..e9e66d28fa52a 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
[ ... ]
> @@ -3773,6 +3776,17 @@ static int spi_nor_probe(struct spi_mem *spimem)
>  			return -ENOMEM;
>  	}
>  
> +	/*
> +	 * Populate the persistent template and run PHY tuning before dirmap
> +	 * creation so the validated frequency feeds into the dirmap op.
> +	 * Tuning failure is non-fatal; the device operates at base speed.
> +	 */
> +	nor->max_read_op = spi_nor_spimem_get_read_op(nor);
> +
> +	ret = spi_mem_execute_tuning(spimem, &nor->max_read_op, NULL);
> +	if (ret && ret != -EOPNOTSUPP)
> +		dev_warn(dev, "Failed to execute PHY tuning: %d\n", ret);
> +
>  	ret = spi_nor_create_read_dirmap(nor);
>  	if (ret)
>  		return ret;

[Severity: High]
This isn't a bug introduced by this patch, but does spi_nor_probe() fail to
restore the hardware state on error paths after device initialization?

Looking at the error returns here for spi_nor_create_read_dirmap() and
subsequent calls like spi_nor_create_write_dirmap() or mtd_device_register(),
the function returns the error code directly without calling spi_nor_restore().

Because spi_nor_scan() executes spi_nor_init() earlier in the probe to
modify the physical flash hardware state (such as enabling 4-byte address
mode or Octal DTR mode), returning without unwinding these changes leaves
the flash in a non-default mode.

Unlike spi_nor_remove() and spi_nor_shutdown() which explicitly call
spi_nor_restore() to revert the flash to its default 3-byte/1-1-1 state,
this error path lacks teardown, and spi_nor_restore() is not registered as
a devm action.

If probe fails here, could this prevent the system's ROM bootloader from
reading the flash after a soft reboot, effectively bricking the device
until a hard power cycle?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618073725.84733-1-s-k6@ti.com?part=16