[PATCH v2] pinctrl: Check pinconfig nodes pre-reloc status recursively

[Quentin Schulz]

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 at fe660000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
> 
> and on RK3328:
> 
>    ns16550_serial serial at 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 <jonas at 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.schulz at theobroma-systems.com>

Thanks,
Quentin