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

Hi,

On Wed, Aug 19, 2026 at 4:29 PM Linus Walleij <[email protected]> wrote:
>
> On Wed, Aug 19, 2026 at 7:03 PM Doug Anderson <[email protected]> wrote:
>
> > I appreciate your suggestion of having a separate node for calibration
> > storage. This feels more awkward to me than just giving up and having
> > the bootloader hardcode all known device-tree paths that the UFS node
> > might be found at. That being said, if everyone says that this would
> > be a great solution, I could try prototyping it. The trick would now
> > be that the Linux UFS driver would need to be able to find this
> > calibration data, so the Linux UFS driver would either need to be able
> > to find it at a specific hardcoded device tree path or the Linux UFS
> > driver would need to search the device tree for a specific
> > ufs-calibration compatible string.
>
> Can't you just put the calibration data as a custom property inside
> the UFS DT node? Just a long byte array or whatever it is.
> The driver would certainly know where to find it that way.
> I don't know who or how it has to be put there during manufacturing
> or inserted by the boot loader into the node from wherever
> manufacturing stores it though. (Assuming it's some calibration
> added at manufacturing, I don't exactly know what it is...)
> If the actual storage place is in something the OS can read
> then we could probably use the nvmem to fetch it live?
>
> The calibration business and what it is and where it is stored
> evades me a bit...

The problem we're facing is _finding_ the UFS node in the bootloader.

The device tree for the board is stored / maintained outside of the
bootloader codebase. It is compiled and stored on the device. The
bootloader runs, locates the device tree and then wants to make
changes to it.

The bootloader needs to _find_ the UFS node in the device tree in
order to make changes to it.

The question is: how does the bootloader find the UFS node?

* Does it hardcode the DT path to the UFS node?

* Does it use an "alias" to find the path to the UFS node?

* Does it search the whole device tree for a certain "compatible"
string and use that to locate the node?

Hardcoding the path is the easiest thing to do here, but then the
bootloader will break if the UFS node ever changes. We also know that
this path will differ for every SoC and is currently different between
the downstream device trees and the upstream ones (because downstream
device trees don't have a "soc@0" node). I've also been told that
device tree paths are not ABI, so hardcoding paths in the bootloader
seems less ideal.

We could just hardcode the path in the bootloader. If this
conversation goes nowhere I'll just change it to do that. If paths
ever break, then I guess we'll just have to get yelled at when folks
say "Why in the world would you hardcode DT paths in the bootloader?
That's not ABI!"

-Doug