[RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller
Miquel Raynal
miquel.raynal at bootlin.com
Thu Dec 11 06:16:43 PST 2025
>>>> 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
More information about the linux-mtd
mailing list