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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/08/2026 01:40, Doug Anderson wrote:
> Hi,
> 
> On Wed, Aug 19, 2026 at 11:03 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>> I'm happy to document. Can you please point to how / where I would
>>
>> Description of:
>> Documentation/devicetree/bindings/ufs/ufs-common.yaml
> 
> Got it.
> 
> If you tell me that the patch won't be instantly NAKed I'd be happy to
> post an addition to this file saying:
> 
> If this UFS controller has a well-known ID <N>, a "ufsN" alias may be
> created in the "aliases" node. If this UFS controller is a singleton
> (no other UFS controllers in the system), a "ufs0" alias may be
> created in the "aliases" node.
> 
> 
>> And obviously, as with every binding/ABI, you also need open-source,
>> upstream user of this.
> 
> As I understand it, this isn't truly policy. I know DT folks often
> want to look at an open-source driver to ensure the hardware is
> described correctly. I also know that a badly written but
> "open-source" driver doesn't justify landing your bindings. ...but in
> this case, it doesn't feel like there is any complexity understanding
> what's going on.

It is a policy. We do not take unused bindings. Also we do not take
bindings for downstream, because then we would have to take a ton of crap.

> 
> 
>>> 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.
> 
> Ah, I see! I was looking for something more formal. Something like a
> list of allowed aliases or something that would automatically validate
> which aliases are permitted. You're just saying to document this in
> prose.
> 
> Thank you for clarifying. I didn't understand this based on your
> previous emails.
> 
> 
>>> 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.

And then someone might need to calibrate UFS and SPI NOR storage? And MMC?

> 
> In my opinion, this would be fine as an ABI contract between the
> device trees intended to run on Pixel 10 phones and the Pixel 10
> bootloader. While I'm still of the opinion that people should be

Unfortunately no, because you are coming with a generic property so it
has to be treated as generic one.

> allowed to include UFS aliases in general and it would be handy if
> that affected the "dev/ufsN" node created in Linux, I know that's not
> a popular opinion among DT maintainers. If upstream would allow a less
> "generic" sounding alias "google,ufs = <&xyz>" I could do that, but I
> doubt that would make you any happier.
> 
> 
>> 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.
> 
> 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), thus this should be treated as adding calibration to multiple
random nodes, then essentially you are reimplementing overlays and this
won't be accepted. Instead you should use overlays.

"-@" will give you the labels in __symbols__ section, but it won't be
treated as ABI because it is not feasible. No one would remember which
boards have @ and which don't thus which labels are needed externally.
Only a comment in DTS code would prevent it from being changed.

Well, same for aliases honestly. There is no tool which would guard that
ABI.

Best regards,
Krzysztof