Hi Jonas,
On 2/17/24 13:08, Jonas Karlman wrote:
Pinconfig nodes normally bind recursively with PINCTRL_FULL and
PINCONF_RECURSIVE enabled. However, during U-Boot proper pre-relocation
any node marked with e.g. bootph-all will not bind unless its parent is
also marked for pre-reloc.
group1 {
pinconf1 {
bootph-all;
};
};
This cause the following warning message to be shown during U-Boot
proper pre-reloc stage on Rockchip devices, e.g on RK3568:
ns16550_serial serial@fe660000: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
and on RK3328:
ns16550_serial serial@ff130000: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
Check pinconfig nodes pre-reloc status recursively to fix this and to
make pinconfig_post_bind work same at both U-Boot proper pre-reloc and
at TPL/SPL stage.
Signed-off-by: Jonas Karlman <jo...@kwiboo.se>
---
v2:
- No change
A recent change to fdtgrep was believed to solve this however, fdtgrep
is only applied to control fdt for xPL so this issue still exist at
U-Boot proper pre-reloc stage.
Link to v1: https://patchwork.ozlabs.org/patch/1817296/
---
drivers/pinctrl/pinctrl-uclass.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index 73dd7b1038bb..fe2ba5021a78 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -100,6 +100,22 @@ static int pinctrl_select_state_full(struct udevice *dev,
const char *statename)
return 0;
}
+static bool ofnode_pre_reloc_recursive(ofnode parent)
+{
+ ofnode child;
+
+ if (ofnode_pre_reloc(parent))
+ return true;
+
+ if (CONFIG_IS_ENABLED(PINCONF_RECURSIVE)) {
You could move the ofnode child declaration here for limiting the scope.
I also got confused by "parent" name, as it isn't actually the parent
we're looking at right now, but the node itself, so it was a bit
misleading. I would have kept "node" and the "child" one is explicit enough.
In any case,
Reviewed-by: Quentin Schulz <quentin.sch...@theobroma-systems.com>
Thanks,
Quentin