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 for Android: free password hash cracker in your pocket

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

Message-Id: <DEOH4AUI33SQ.DGKJ4W258658@kernel.org>
Date: Wed, 03 Dec 2025 10:28:23 +0100
From: "Michael Walle" <mwalle@...nel.org>
To: "Santhosh Kumar K" <s-k6@...com>, "Pratyush Yadav" <pratyush@...nel.org>
Cc: "Miquel Raynal" <miquel.raynal@...tlin.com>, <richard@....at>,
 <vigneshr@...com>, <broonie@...nel.org>, <tudor.ambarus@...aro.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

Hi,

>> I think we should start with the requirement to have the pattern flashed
>> already and figure out how SPI NOR or SPI NAND can discover that
>> (perhaps via NVMEM?).

But we should also keep in mind that certain flashes might return
tuning data during the dummy cycles. I.e. the PHY might probably be
tuned on each read and there is no need for any pre-programmed
pattern.

I'm not saying it should be implemented, but the current
implementation should be that flexible that it will be easy to add
that later.

> For SPI NOR, we do not have an equivalent "write-to-cache" possible, so
> we still require a pre-flashed pattern region. At the moment this is
> provided via a dedicated "phypattern" partition, and its offset is
> obtained through the of_get_* APIs.
>
> Regarding ways to locate the partition:
>
> 1. Using NVMEM:
>     a. Exposing the phypattern partition as an NVMEM cell and issuing an
>        NVMEM read during tuning does not work reliably, because NVMEM
>        ends up calling into the MTD read path and we cannot control which
>        read_op variant is used for the read.
>
>     b. Advertising the partition as an NVMEM cell and using NVMEM only
>        to fetch the offset is not possible either. NVMEM abstracts the
>        private data, including partition offsets, so we can't retrieve
>        the offset as well.

You can probably extend the NVMEM API in some way - or switching the
read_op on the fly.

> 2. Using of_get_* APIs:
>        Using the standard OF helpers to locate the phypattern partition
>        and retrieve its offset is both reliable and straighforward, and
>        is the approach currently implemented in v2.

I don't like that hardcoded partition name which is basically
becoming an ABI then.

At least we'd need some kind of phandle to the partition inside the
controller node (and get the ACK from the DT maintainers).

>> I think SFDP is quite nice for this, but IIRC for spi-candence-quadspi,
>> that was not a viable option due to some reasons. If you can now make it
>> work with SFDP, then that would be even better, since we don't have to
>> deal with the pain of pre-flashing.
>
> The current tuning flow requires a specific stress pattern to ensure
> robustness, and the SFDP data aren't good enough for it.

Yes that is also what I can remember from the flexspi controller on
the NXP SoCs. IIRC they need a very specific sequence of ones and
zeros.

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)