[U-Boot] Accessing nested device tree nodes via phandle

[Vlad Zakharov]

Hi everybody, 

I am working on reorganization of device trees for ARC boards in U-Boot in order to create a common device tree blob for
both Linux and U-Boot.

And I've struggled with a kind of problem and need some help.

On AXS10x motherboard clocks for various peripherals are managed by one hardware block, so clock nodes in Linux device
tree are grouped into one "clocks" node like this:
---------------------------------->8------------------------------------
clocks {
    i2cclk: i2cclk {
        compatible = "fixed-clock";
        clock-frequency = <50000000>;
        #clock-cells = <0>;
    };
 ...
 ...
 ...
    uartclk: uartclk {
        compatible = "fixed-clock";
        clock-frequency = <33333333>;
        #clock-cells = <0>;
    };  
};
---------------------------------->8------------------------------------
And then some of them a referenced via phandle from other nodes, e.g. &uartclk is referenced from uart node.

When I try to create such hierarchy in U-Boot I find that uart driver is not able to get clock via phandle and
corresponding uart doesn't work. 

As I understand that is because children clocks nodes, i.e. "uartclk" in my case, never got bound as it's parent node
"clocks" never got bound too.
So when I add "compatible" and "u-boot,dm-pre-reloc" properties to "clocks" parent node everything works fine, e.g.:
---------------------------------->8------------------------------------
clocks {
    compatible = "simple-bus";
    u-boot,dm-pre-reloc;
    uartclk: uartclk {
        compatible = "fixed-clock";
 
       clock-frequency = <33333333>;
        #clock-cells = <0>;
    }; 
 ...
 ...
 ...
};
---------------------------------->8------------------------------------

Please correct me if I wrongly interpret such behavior.

I wonder if it the only approach to implement Linux-like hierarchy for ARC? Or I am mistaken and in fact can use pure
Linux device tree without adding properties, described above?

Thank you!

-- 
Best regards,
Vlad Zakharov <vzakhar at synopsys.com>