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 sjg@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