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