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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 19/08/2026 19:04, Doug Anderson wrote:
> Hi,
> 
> On Wed, Aug 19, 2026 at 2:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>> Is there some other documentation saying "aliases == evil" that I
>>> missed? Maybe some email thread we're all supposed to have read?
>>
>> A lot of rules are implied by other rules and this one, how Linus stated
>> in other thread, might be implied by no-Linuxisms as you want ordering
>> or stable naming of Linux /dev entries.
>>
>> I understand your reason is actually different than above, but your code
>> does not suggest that.
>>
>> Anyway, if you wanted to have aliases as ABI, it would have to be
>> documented. You cannot send post-factum DTS and say "we already use it".
>> Every ABI must be documented before usage.
> 
> I'm happy to document. Can you please point to how / where I would

Description of:
Documentation/devicetree/bindings/ufs/ufs-common.yaml
And obviously, as with every binding/ABI, you also need open-source,
upstream user of this.

> document this? As far as I can tell, no aliases are documented today,

git grep disagrees with you, e.g. second paragraph of serial.yaml.

> so this would be the first. If you could give me a hint of where you'd
> expect it, that would probably be better than me guessing.
> 
> 
>> And this is what my comment was about: "they MUST talk
>> with upstream open source maintainers before they ship such ABI."
>>
>> And no, sending such DTS in your v1 is not documenting ABI. Does not count.
> 
> Sure, sending a DTS isn't documenting, but it _is_ talking. Discussion
> in responses to patches is where we figure things out. For that to
> work, reviewers need to point out problems and then we need to have a
> continued discussion until we can figure out a solution. When that
> discussion just stops, it's incredibly hard to make progress.
> 
> 
>>> thus implicitly provides an "instance ID"?  Would it be OK if I
>>> changed my alias name to "ufs-primary" or "ufs-internal" or "ufs-boot"
>>> or just "ufs"? We're not using the alias to get an instance ID, but
>>> when I added the alias I followed the pattern of all the other aliases
>>> and put an number at the end.
>>>
>>> I'm happy to attempt to fix our bootloader using whatever scheme
>>> upstream suggests. I'm trying to "talk to upstream" as requested, but
>>> for it to work I need upstream to talk back. :-)
>>
>> Make your case - what is the purpose of it? Boot device? Then you have
>> "chosen" node for stuff between firmware and OS. There is even a
>> property called "bootsource". If this is not boot device, but some
>> calibration data for ONE given instance of IP, regardless whether you
>> boot from it or not, then I find such case as border-base and not worth
>> implementing, because basically one can come one month later with "I
>> need 1000 aliases because my bootloader is patching up every device
>> node".
> 
> 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 gave you two solutions, depending on actual upstream need of this. If
you have the second case - so not the boot device - then you basically
want to re-implement overlays which you cannot. Use overlays, which
gives you nice stable and build-time verifiable label/phandle.



Best regards,
Krzysztof