tree 9d9375d8eb69d1243e2620a74e1b0ef5176a4d7b
parent 8a8077215e7d8166ce67aff30cf742da74fe5c93
author Jerzy Kasenberg <jerzy.kasenberg@codecoup.pl> 1689672174 +0200
committer kasjer <kasjer@users.noreply.github.com> 1695635385 +0200

kernel/os: Update device initialization condition

Function os_dev_init() is called in two places
First possibility is when device is created in
 os_dev_create() AND g_os_started is not 0
This apply to devices that are created after main
function is called (including package defined syscfg
functions).

Other place that calls os_dev_init is os_dev_initialize_all()
This function calls all os_dev_init() functions for requested
stage. When os_dev_initalize_all() is called only devices
added by bsp (often delegated to mcu) are created.
Keep in mind that since g_os_started is not set yet condition is
not checked.

When mcuboot starts with sysinit() enabled it calls os_dev_initalize_all()
twice then executes sysinit(). Any device created in sysinit() will not
be initialized since g_os_started is not set.

This change stores device init stage number and uses it when devices are
initialized. For devices created by BSP initial stage is 0 so dev_init is
not called during device creation but postponed till os_dev_initialize_all()
is called (so despite condition change initialization sequence stays the same).

For devices created in sysinit() stage is already set to KERNEL and they are
initialized during creation even though g_os_started is not checked any more.
So there should not be any differences in behavior.

For MCUBoot, devices created in sysinit() will have dev_init called when created
just like it would happen when OS_SCHEDULING is enabled.

Only difference is that when device initialization fails at one stage but is not
marked as critical initialization will be attempted in next stage.

Signed-off-by: Jerzy Kasenberg <jerzy.kasenberg@codecoup.pl>