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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87v7io9c23.fsf@bootlin.com>
Date: Wed, 03 Dec 2025 09:58:28 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  <richard@....at>,
  <vigneshr@...com>,  <broonie@...nel.org>,  <tudor.ambarus@...aro.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

> Just to summarize, fallback logic during probe:
>    - If the controller reports a tuning failure, the spi-mem client may
> either retry tuning with the next-best (max-1) operation

There is no such "next-best" variant once in ODDR mode unfortunately. We
will have to return an error indicating that PHY calibration needs to
happen again and just retry without it.

As to when/if we shall perform it again, this is a delicate topic. Being
conservative might imply just disabling the feature and no longer using
it from a SPI controller perspective until SPI NAND/NOR calls for
calibration again, but it is unclear to me when this should
happen. Maybe we could trigger a background job with a low priority for
that. But don't bother implementing this in the first place. Just make
it work, make it fit in the current subsystems, just KISS. We can figure
this out in a second time, especially since failures are not supposed to
happen very often.

> or fallback to
> the non-PHY, slower operation and adjust the dummy cycles accordingly to
> use the optimal non-PHY variant.

Why adjusting the dummy cycles? I am not aware of a different number of
cycles with and without PHY mode. It should be identical, no? The
difference lays in the frequency we use, not the fact that PHY is
active. And once we've decided a configuration, we can always handle
slower frequencies, at the cost of a few 100kiB/s maybe. So I would not
see this as a concern.

> And yes, for now the priority is to have a robust probe-time tuning flow
> before addressing any runtime tuning concerns.

Yes.

>>> 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?
>> Santhosh, do you have any numbers on write performance improvements? I
>> am curious if it is even worth the effort.
>
> There's no real performance gain for SPI NOR, but SPI NAND shows notable
> improvement wrt. page size.
>
> Write performance numbers from AM62A SK with W35N01JW OSPI NAND:
>
>    - without PHY: 6 MB/s
>    - with PHY: 9.2 MB/s

Eager to see this in SPI NAND (only) then!

Thanks,
Miquèl