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

Hi Doug,

On Thu, Aug 20, 2026 at 1:41 AM Doug Anderson <[email protected]> wrote:

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

So, thebootloader needs to make changes to the calibration of
the UFS storage, and it needs to find the right UFS storage
to calibrate, right. I get that part.

But this is what boggles my mind. It is actually a pretty
deep philosophical subject.

A piece of software (the bootloader) want to make changes
to the calibration of a piece of hardware, which it somehow
has the calibration for.

This pretty much means that at some point *some* unit
of software producing that said calibration already had a
handle on the hardware.

So there is a missing piece of the puzzle here.

This is where the imperialistic ambition of device tree
kicks in: the piece of software - be that a manufacturing
run-it-once piece of code - that produced said calibration
should have *also* used device tree to find the thing it
was to calibrate. Supposedly looping over all UFS devices
in the device tree and calibrating them one at a time,
something like this.

Ideally that piece of software should have updated the
device tree too, but OK that is intervening with software
engineering, maybe it does not have the capability to
do that.

But that piece of software *should* have at least encoded
some kind of identifier for the thing it calibrated, like a
unique serial number from the hardware, or in worst case
at least the device tree node name.

So the information to locate the right node in the device
tree *should* have been present inside the calibration
binary blob thingy.

What is controversial with this patch is that an authority
on the side comes in and says with a device tree property:

"I have a random piece of calibration data and only I know
which UFS it is for, so I am going to encode that knowledge
into the device tree as an alias."

The device tree "thinks" that this should already be evident.

The device tree has the underlying assumption that
everything is using it. The kernel, the boot loader, the
secure operating environment, the GPU, accelerators...
also the manufacturing tools.

From the view of the device tree world, a manufacturing
tool not using device tree is a hack, and if it is a hack
then the system can put the information in there using
a hack, and this whole ambition of finding the UFS node
from the top down is moot. It's like polishing dirt.

Now, I know this way of thinking is oddly bureaucratic
and imperialistic, but it is in the core essence of how
device tree was thought out. It wants to be the authoritative
source of all hardware information, any other source
is a hack in the view of the device tree.

I don't know if this solves your problem other than saying
"go with any hack because this takes place in an imperfect
world", but at least it points out how this kind of problems
collide with some of the core philosophy of device tree.

Yours,
Linus Walleij