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

Massimo Pegorer massimo.pegorer+oss at gmail.com
Sat Sep 30 12:25:03 CEST 2023


Hi Simon,

Il giorno ven 11 ago 2023 alle ore 02:29 Simon Glass
<sjg at chromium.org> ha scritto:
>
> Hi Jonas,
>
> On Sat, 5 Aug 2023 at 08:29, Jonas Karlman <jonas at kwiboo.se> wrote:
> >
> > Hi Massimo,
> >
> > On 2023-08-05 16:06, Massimo Pegorer wrote:
> > > Hi Jonas,
> > >
> > > Il giorno sab 5 ago 2023 alle ore 13:11 Jonas Karlman <jonas at kwiboo.se> ha
> > > scritto:
> > >
> > >> 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 RK3568 devices.
> > >>
> > >>   ns16550_serial serial at fe660000: 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>
> > >> ---
> > >>  drivers/pinctrl/pinctrl-uclass.c | 18 +++++++++++++++++-
> > >>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> This is actually something we want to change about fdtgrep. I believe
> we should try to adjust that tool rather than loading this ontoU-Boot,
> not least because it controls what properties are visible in SPL.

So IIUC your idea is that fdtgrep tool will automatically add
bootph-xxx property to any ancestor of a node with that property? Or
to log a warning, or exit with an error, during build?

BTW, fdtgrep is applied to DT only for xPL builds, not for U-Boot
proper build. Therefore, Jonas approach could be used at least during
U-Boot proper pre-relocation phase to manage "bootph-some-ram" and
"bootph-all".

Side note: I've noticed that quiet_cmd_fdtgrep in Makefile.lib does
not strip bootph-some-sram. I think it should, doesn't it?

>
> Regards,
> Simon


More information about the U-Boot mailing list