Re: [PATCH v4 04/16] spi: spi-mem: teach spi_mem_adjust_op_freq() about post-config ops

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Overloading `op->max_freq` as a magic exact-match token to identify post-configuration operations breaks frequency limit semantics, preventing valid operations from running at tuned speeds or erroneously allowing untuned operations to bypass safe limits.
--

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

spi: spi-mem: teach spi_mem_adjust_op_freq() about post-config ops

This commit extends spi_mem_adjust_op_freq() to allow post-configuration
operations to run at higher speeds. It bypasses the max_speed_hz cap if the
operation's max_freq exactly matches the post_config_max_speed_hz value.

> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index f64eda9bbd9f0..b0b111642a358 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
[ ... ]
> @@ -584,9 +584,18 @@ EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
>   * Some chips have per-op frequency limitations and must adapt the maximum
>   * speed. This function allows SPI mem drivers to set @op->max_freq to the
>   * maximum supported value.
> + *
> + * When @mem->spi->post_config_max_speed_hz is set, ops with @op->max_freq
> + * equal to that value are treated as post-configuration ops (e.g. PHY-tuned)
> + * and are allowed to run at the full post-config rate. All other ops are
> + * capped to @mem->spi->max_speed_hz, the always-reachable base rate.
>   */
>  void spi_mem_adjust_op_freq(struct spi_mem *mem, struct spi_mem_op *op)
>  {
> +	if (mem->spi->post_config_max_speed_hz &&
> +	    op->max_freq == mem->spi->post_config_max_speed_hz)
> +		return;

[Severity: High]
Does this overload op->max_freq as a magic exact-match token to identify
post-configuration operations?

If an untuned operation (e.g., a write or alternate read variant defined in a
flash driver with a static hardware limit of 104MHz) happens to exactly match
the configured post_config_max_speed_hz, won't it incorrectly bypass the safe
max_speed_hz cap?

Furthermore, controller drivers like Cadence QuadSPI appear to rely on this
exact same equality check to decide whether to route the incoming operation
through the hardware PHY:

drivers/spi/spi-cadence-quadspi.c:cqspi_use_tuned_phy() {
    ...
    return f_pdata->use_tuned_phy &&
           op->max_freq == post_config_max_speed_hz;
}

Could this cause uncalibrated operations to be erroneously executed via the
PHY at high speeds, leading to potential data corruption or hardware lockups?

Would it be safer to use an explicit boolean flag (e.g., op->is_tuned) rather
than hijacking the frequency limit field?

> +
>  	if (!op->max_freq || op->max_freq > mem->spi->max_speed_hz)
>  		op->max_freq = mem->spi->max_speed_hz;
>  }

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