linux-kernel - Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ecqcakjo.fsf@bootlin.com>
Date: Wed, 05 Nov 2025 10:35:55 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...com>
Cc: <richard@....at>,  <vigneshr@...com>,  <broonie@...nel.org>,
  <tudor.ambarus@...aro.org>,  <pratyush@...nel.org>,  <mwalle@...nel.org>,
  <p-mantena@...com>,  <linux-spi@...r.kernel.org>,
  <linux-mtd@...ts.infradead.org>,  <linux-kernel@...r.kernel.org>,
  <a-dutta@...com>,  <u-kumar1@...com>,  <praneeth@...com>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning
 controller

Hello Santhosh,

>>>     - On tuning failure, retry by re-running spi_mem_needs_tuning() with
>>> the second best set of ops (max throughput - 1)
>> I would like to challenge this need. Can the same calibration fail if
>> attempted multiple times (eg. because of the heat?) If yes, then we need
>> a fallback indeed. Otherwise, I'd be in favor of just failing the
>> probe. Calibration is an opt-in -> users must allow a higher frequency
>> than they use to in order to enable the feature?
>
> It's possible the same calibration will fail intermittently for
> different reasons (temperature changes, as you mentioned). If tuning
> fails, the driver should fallback to the non-PHY frequency so the flash
> continues operating with slower reads/writes rather than failing the
> probe (availability should be prioritized, right?).

Agreed, if the tuning may fail we must fallback in this case. However
there is another situation that must be handled in this case: once
tuning is done and we want to use PHY-optimized paths, we must fallback
to more basic/slower reads if for some external reason, they start
failing, right?

The obvious choice in this case would be to let this error handling to
the controller driver. Re-using the same operation at a lower speed
would be suboptimal, because the fastest operation at a high speed might
not be the most efficient at slower speeds due to the number of dummy
cycles needed,. But I believe this is negligible based on the fact that
we already are in degraded mode at that stage.

However, this may conflict with:
- read retries
- continuous reads (?)

So in practice the fallback might be needed on the SPI NAND/NOR side
(this can be further discussed).

But once we solve this, comes a similar problem on the write side. How
do we know if a write will or did fail because of a temperature change?
What may be the heuristics to fallback in this case?

Thanks,
Miquèl