device_bind() with ofnode_null() tripping assert()?

[Quentin Schulz]

Hi all,

Not sure how to word this better so here goes nothing.

I recently wanted to debug some issues possibly related to DM which had 
a bunch of debug() log messages I wanted to see. To see those, one needs 
to define DEBUG. Once that's done, assert() calls are now built in.

It turns out that this means I cannot boot my board anymore because (at 
least) one of the assert() fails (specifically an ofnode_valid()).

I've for now narrowed the one in SPL to dev_read_u32(protocol, 
"arm,smc-id", &func_id) in smccc_agent.c, c.f. 
https://elixir.bootlin.com/u-boot/v2024.10/source/drivers/firmware/scmi/smccc_agent.c#L91
If I change ofnode_null() with ofnode_root() in the device_bind() 
creating the scmi-base.0 device from the SCMI UCLASS, then it goes 
further, c.f. 
https://elixir.bootlin.com/u-boot/v2024.10/source/drivers/firmware/scmi/scmi_agent-uclass.c#L377.

However, I then get another assert() being tripped later in U-Boot 
proper (right after the Ethernet has been initialized and before I get 
to the shell, no idea if it actually is related to Ethernet), which 
makes it reset again.

So... I basically have no clue how to go forward with this. We've 
started to discuss to decouple debug() log messages from assert() 
(meaning they don't share the same knob) but that wouldn't fix the 
issue. Should this assert() really be tripping? If not, how should we 
handle that instead?

Cheers,
Quentin