Hi Manorit,
On 7/10/24 8:15 AM, Manorit Chawdhry wrote:
Hi Simon,
On 09:36-20231217, Simon Glass wrote:
The existing bootph binding is defined such that properties in a
subnode are also implied in the supernode also, as in this example:
buttons {
/* bootph,pre-ram is implied by btn1 */
compatible = "gpio-keys";
btn1 {
bootph,pre-ram;
gpios = <&gpio_a 3 0>;
label = "button1";
linux,code = <BTN_1>;
};
Provide an option to implement this in fdtgrep.
Signed-off-by: Simon Glass <s...@chromium.org>
Coming back to this patch as am facing some issues with the bootph-all
propagation to the parent nodes [0]. We have a dmsc/sms node in our
devices and it is a parent node of k3_pds, k3_clks, k3_reset.
During U-boot proper we are initializing the serial console and during
that time we have to make some calls to our Device manager for clocks
and power domains. With the DT modelling, the clocks and power domains
come under the device manager node ( dmsc/sms ) but interestingly that
driver is not getting probed while putting bootph-all in the child
nodes. Do you know anything about this? I thought putting it in child
node will propagate it to the parent nodes as well so it'll be probed as
well. We are having to put bootph-all explicitely in the dmsc/sms node
for it to work.
I haven't followed the whole thread but it seems to match something I
looked into recently.
The properties aren't actually propagated. What happens is that this
option is used to NOT delete parents (or rather, their properties) of a
node with the passed bootph- property. This is only useful for TPL and
SPL device trees which are stripped down versions of the full U-Boot
DTB. The parent nodes also incidentally do not have this property added,
they just are merely allowed to exist.
fdtgrep needs to be reworked to allow passing the bootph- properties to
the parent nodes. I quickly looked into it a few weeks ago and it didn't
seem like a 5min job to me. This would be also beneficial for U-Boot
proper pre-relocation stage, which suffers from missing bootph-
properties in parent nodes (been there recently) as well.
Cheers,
Quentin
