[RFC] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation

[Jonas Karlman]

Hi Simon,

On 2023-08-17 00:29, Simon Glass wrote:
> Hi Jonas,
> 
> On Tue, 8 Aug 2023 at 20:03, Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi Jonas,
>>
>> On Sat, 5 Aug 2023 at 07:32, Jonas Karlman <jonas at kwiboo.se> wrote:
>>>
>>> Devices for nodes with e.g. bootph-pre-ram are initialized three times.
>>> 1. At SPL stage (always bind and probe only if used)
>>> 2. At U-Boot proper pre-reloc (always bind and probe)
>>> 3. At U-Boot proper normal (always bind and probe only if used)
>>>
>>> Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
>>> with a pre-reloc status only after U-Boot proper pre-relocation stage.
>>> This prevents the device from being probed at U-Boot proper pre-reloc.
>>>
>>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>>> ---
>>> I am not sure if U-Boot proper pre-reloc behaves like this by design and
>>> if there is some other way to signal that a device should not be probed
>>> during U-Boot proper pre-reloc stage if it has been probed at SPL stage.
>>>
>>> For my use-case I added bootph-pre-ram prop to my RK8xx device node to
>>> make the PMIC usable in SPL. However, I have no need for this device to
>>> probe at U-Boot proper pre-reloc stage just after jumping out of TF-A.
>>> And moments later bind and probe yet again at U-Boot proper normal stage.
>>>
>>> The bootph-pre-ram prop was used to have the device usable in SPL, else
>>> I could have used bootph-all or added bootph-some-ram prop to indicate
>>> use at U-Boot proper pre-reloc stage.
>>
>> This is changing how things work...we really need to have something
>> explicit to use this new behaviour. Perhaps we can augment the binding
>> in some way?
> 
> I had another look at this. The binding seems to be silent on this
> point, so I believe this patch is correct.

I agree, the documentation for binding and also for driver model make
this a little bit unclear:

"""
... Only drivers marked with DM_FLAG_PRE_RELOC or the device tree
‘bootph-all’ property are initialised prior to relocation. ...

...

It is possible to limit this to specific relocation steps, by using the
more specialized ‘bootph-pre-ram’ and ‘bootph-pre-sram’ flags in the
device tree node. For U-Boot proper you can use ‘bootph-some-ram’ which
means that it will be processed (and a driver bound) in U-Boot proper
prior to relocation, but will not be available in SPL or TPL.
"""

However the documentation for ofnode_pre_reloc contradict this a little:

"""
There are 4 settings currently in use
- bootph-some-ram: U-Boot proper pre-relocation only
- bootph-all: all phases
Existing platforms only use it to indicate nodes needed in
SPL. Should probably be replaced by bootph-pre-ram for new platforms.
- bootph-pre-ram: SPL and U-Boot pre-relocation
- bootph-pre-sram: TPL and U-Boot pre-relocation
"""

Should I send a v2 of this and drop the "and U-Boot pre-relocation" from
function doc comment? And do we need a new Kconfig option to enable or
opt-out of this new/changed/fixed behavior?

Regards,
Jonas

> 
> Reviewed-by: Simon Glass <sjg at chromium.org>
> 
> 
>>
>>>
>>>  drivers/core/ofnode.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>>> index 8df16e56af5c..ebd5a408ae58 100644
>>> --- a/drivers/core/ofnode.c
>>> +++ b/drivers/core/ofnode.c
>>> @@ -1353,7 +1353,7 @@ bool ofnode_pre_reloc(ofnode node)
>>>          */
>>>         if (ofnode_read_bool(node, "bootph-pre-ram") ||
>>>             ofnode_read_bool(node, "bootph-pre-sram"))
>>> -               return true;
>>> +               return !!(gd->flags & GD_FLG_RELOC);
>>
>> I believe that the compiler knows how to convert 'gd->flags &
>> GD_FLG_RELOC' into a bool, so !! is not needed.
>>
>>>
>>>         if (IS_ENABLED(CONFIG_OF_TAG_MIGRATE)) {
>>>                 /* detect and handle old tags */
>>> --
>>> 2.41.0
>>>
> 
> Regards,
> Simon