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: <87jyz3ao8b.fsf@bootlin.com>
Date: Wed, 03 Dec 2025 10:50:12 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Michael Walle" <mwalle@...nel.org>
Cc: "Santhosh Kumar K" <s-k6@...com>,  "Pratyush Yadav"
 <pratyush@...nel.org>,  <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


>>> 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.

Conceptually, yes, but in practice, I know no controller capable of
using just a few cycles every transfer to calibrate themselves
automatically and reaching such an optimized speed state as the cadence
controller is capable of ATM.

Despite the end result being close, I would still consider this other
way to optimize the I/Os somewhat orthogonal. If someone has some
knowledge to share about the training patterns sent during the dummy
cycles, I am all ears though.

>> 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).

Yes, agreed, this is controller specific, if we need to use an of_ API
(which is still not needed for SPI NANDs, only for tuning the read SPI
NOR path), it should not just be a partition hardcoded name but a
phandle in the controller node.

Thanks,
Miquèl