Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

On 21/08/2026 18:40, Doug Anderson wrote:
> Hi,
> 
> On Thu, Aug 20, 2026 at 11:51 PM Krzysztof Kozlowski <[email protected]> wrote:
>>
>>>>> I think I've presened my problem fairly concretely [1]. If you hate
>>>>
>>>> There is no description of the problem at [1], except "bootloader adds
>>>> the same type of calibration data".
>>>>
>>>> So I repeat my questions: to every UFS node? To every node? To one UFS
>>>> node (but how do you guarantee that?)?
>>>
>>> I'm sure it's not what you want to hear, but I guess my answer would
>>> be "for these boards".
>>
>> No, the question is how many aliases you need. Devices might have more
>> than one UFS storage, e.g. ExynosAuto.
> 
> How many UFS aliases do I need for this board? The answer is in the
> patch that started this whole discussion: one UFS alias.
> 
> 
>> And then someone might need to calibrate UFS and SPI NOR storage? And MMC?
> 
> Not for this board.

We do not talk about your board. You are adding GENERIC alias, so you
are solving GENERIC problem for everyone and needs to be addressed as such.

If you are solving here only your board problem and do not care how does
it scale or whether it makes sense for anyone else, then topic is done -
we do not need this feature.

> 
> If you're asking about all future boards, of course they may have
> other things to calibrate / tune. My point is that the contract here
> is between the bootloader that will be run on these boards and the
> device tree that will be run on these boards.
> 
> FWIW: the idea of a bootloader using an alias to find a node is not
> something I invented. Coreboot (the upstream, open-source project)
> uses "wifi" and "bluetooth" aliases to find nodes on Chromebooks. It
> uses these aliases to place MAC addresses (which are stored by
> manufacturing outside of DT) into the DT nodes (where bindings expect
> them). Perhaps coreboot is doing it wrong, but this concept isn't new,
> and I didn't invent it.
> 
> 
>>> I'm not quite clear on the "overlay" suggestion here. You're saying
>>> that we should require the base device tree to be compiled with "-@"?
>>> ...and not because we necessarily have any overlays upstream, but
>>> because the bootloader will generate an overlay dynamically? Compiling
>>> with "-@" would mean we could give a "ufs:" label to the UFS node and
>>> with "-@" that would be preserved. The bootloader could then use the
>>> "ufs:" label to find the node. When compiling with "-@", the exposed
>>> labels are essentially ABI. Did I get that right?
>>
>> I am saying that if you cannot answer my questions earlier (and you did
>> not)
> 
> I'm still not quite sure which question I didn't answer, but I guess
> at this point it doesn't matter.

I gave you the code which solves your problem, IMO. I do not see so far
any reason to reimplement it with aliases.

Best regards,
Krzysztof