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: <878qf96r3o.fsf@bootlin.com>
Date: Thu, 11 Dec 2025 15:16:43 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...com>
Cc: Michael Walle <mwalle@...nel.org>,  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


>>>> 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.
>
> Yes, using a phandle is a valid idea to avoid relying on a hard-coded
> name. But, it does not work well when multiple chip selects are
> involved. The controller is not tied to a single flash device - a single
> SPI controller may host both NOR and NAND flashes, for example. In such
> case, only the NOR would require this phandle, while the NAND would
> not,

This honestly doesn't seem a problem to me.

> which makes the phandle approach unsuitable. Another example is a
> controller hosting two NOR flashes - both would then need their own
> phandle references.
>
> An alternative would be to associate the phandle with the flash device
> itself rather than with the controller. Let me know your thoughts on
> this approach.

I find pretty strange to have this property in the flash node, even
though I understand the reason. Perhaps an array of phandles may work in
the controller node instead?

Thanks,
Miquèl