Allow for selective deferment of device initialization (aka manual init)

[palchak-google]

Is your enhancement proposal related to a problem? Please describe.
Zephyr currently assumes that all devices available in the system should be automatically initialized at boot. This assumption does not account for the the following common embedded scenarios:

• Multiple devices share a common resource, such as a set of GPIO pins, and only one device is ever enabled/active at a time depending on some runtime state. A example of this would be having a SPI master controller and a SPI slave controller configured to the use the same pins, and the system dynamically changes which controller to activate based on a separate control signal.
• The power source for the system may not always be capable of supporting the entire system load. The system needs to boot first with a minimal set of devices enabled, determine the current power state, and then selectively enable additional devices as appropriate.

Describe the solution you'd like
Add an optional parameter to the Devicetree bindings for device nodes that allows application developers to specify whether initialization for that device should be deferred. This information should be stored in the init_entry struct for each device and checked in the z_sys_init_runlevel function before calling the init function for the device.

Devices with deferred initialization would then need to be manually initialized by the application code prior to use; Zephyr would provide a system call for manually invoking a device's initialization function (after checking that the device was not already initialized).

Describe alternatives you've considered
An alternative solution would be to add a "deferred" status enumeration for devices, alongside "okay" and "disabled". This status indication would serve the same purpose as described above, namely inhibiting automatic boot-time execution of the device's initialization function. At compile time the build system could also check if any "okay" nodes appear to depend on other nodes marked as "deferred". This would help catch potential initialization defects.

[tbursztyka]

I don't think it would require an init_entry information here, another init level could just do: #define _SYS_INIT_LEVEL_MANUAL in init.h for instance. (thus a MANUAL to use in drivers). kernel/device.c would need relevant update of course. And a device_init() function exposed obviously (which would check that the device is being in the MANUAL level, else it would return -EALREADY or current init status).
This solution would not make any structure to grow at least.

[tokolist]

Zephyr would provide a system call for manually invoking a device's initialization function (after checking that the device was not already initialized).

I believe there should not be a check if driver is already initialized. I faced issue when LCD should be reinitialized after cutting off LCD (and other devices) power to save battery life. And there is no way to reinitialize screen driver. Your idea is good, just if Zyphyr checks if driver was initialized it won't allow to reinitialize driver.

As an option there should be function to unload/destroy driver before doing something so in that case mentioned check makes sense.

[palchak-google]

The issue with no checking is that then it's possible for the system to get into an initialization loop where driver A depends on driver B, both require manual initialization, and each call the other's init method in their own init method. Admittedly this is a corner case, but so is the case of needing to re-init hardware that was powered off.

As an alternative, I'd propose that function that is called to manually invoke an init function take an argument to allow a "forced" initialization. A forced init would run the routine regardless of the current init state. This would be useful not just for re-initializing when the device is known to be uninitialized, but also for situations in which a device seems unresponsive and needs to be recovered.

I like the idea of a MANUAL init level. That's cleaner than a separate flag.

[tbursztyka]

I believe there should not be a check if driver is already initialized. I faced issue when LCD should be reinitialized after cutting off LCD (and other devices) power to save battery life. And there is no way to reinitialize screen driver. Your idea is good, just if Zyphyr checks if driver was initialized it won't allow to reinitialize driver.

As an option there should be function to unload/destroy driver before doing something so in that case mentioned check makes sense.

That's being discussed in this issue #20012

[tbursztyka]

As an alternative, I'd propose that function that is called to manually invoke an init function take an argument to allow a "forced" initialization. A forced init would run the routine regardless of the current init state. This would be useful not just for re-initializing when the device is known to be uninitialized, but also for situations in which a device seems unresponsive and needs to be recovered.

This would also fall within issue #20012

[bvm84]

In my scenario LCD ST7785R needs first to be powered up by GPIO pins switching in main function. But ST7785R has POST_KERNEL initialization priority. So initialization fails because LCD do not respond on spi bus due to lack of power.
Any suggestion how to fix this in Zephyr version: 3.2.99 before permanent solution will rise?

[carlescufi]

Architecture WG:

• @keith-zephyr describes the proposal he posted here
• @nashif then discusses the issues that can come with that approach, also described here
• @keith-zephyr mentions that their use case is to decide which driver will be instantiated at runtime. Having both in ROM is required, given that the selection happens at runtime
• @henrikbrixandersen agrees that the proposal from @keith-zephyr is reasonable.
• @gmarull states that as soon as we have deferred device init we will also need to take care of dependencies
• @gmarull states that the init function is not currently stored as part of the structure, so we would have to add code to find the correct init function. Otherwise agrees with the proposal including the new deferred-init property and device_init() API call
• @galak states that we may want to instead use the status = disabled property instead. Then uses would have to use delete node to achieve what they achieve today with status = disabled. This would be helpful to have consistent Devicetrees among Linux and Zephyr instead of a custom Zephyr property. A Kconfig option could help during the transition, where enabling it would revert to the current behavior
• @nashif states that maybe we could use reserved instead, a status that is not used today in Zephyr. But @galak mentions that we are better off introducing a new status or using the zephyr-specific property instead, because reserved is not meant for this use case in the spec
• @gmarull mentions that many drivers use the DT_INST_FOREACH_STATUS_OKAY macro today, which would need to be modified if we rely on the status
• @teburd says that the option with delete-node would require a massive rework of all the Devicetree source files to change disabled into delete node. @galak counters that this only affects board-level Devicetree files. @galak counters that they can keep the old behavior is kept with the Kconfig option
• @henrikbrixandersen says that deleting the nodes from the SoC makes sense for a final product, but not so much for development kits, where the list of peripherals to be used is not clear

[keith-zephyr]

From the Arch WG, there were 3 possible approaches discussed. Summaries of three options are presented below.

All approaches will need to consider dependencies for any deferred nodes. For instance, if a node is deferred children/dependent nodes should also be deferred. We need to decide whether the application is responsible for initialization of all dependent nodes, or this will be handled automatically.

Option 1: new devictree property

Add a new property zephyr,deferred-init. This is described here.

Advantages

• Easiest to implement.
• Maintains existing devicetree contract for the status property.
• No new Kconfig or other software guards required. Only boards/applications that have at least one deferred node will change.
• No changes to CONFIG_DT_HAS_xxx_ENABLED Kconfig symbol generation.

Disadvantages

• Introduces Zephyr specific devicetree property to the base class.

Option 2: Set status property to "disabled"

Use status = "disabled"; to mark devicetree node instances that should be skipped by system initialization.

To exclude a devicetree node or driver instance, board overlay files need to use the /delete-node/.

Advantages

• This best matches the devicetree documentation.

Indicates that the device is not presently operational, but it might become operational in the future (for
example, something is not plugged in, or switched off).
Refer to the device binding for details on what disabled means for a given device.

Disadvantages

• Fundamental change to the devicetree contract for the status property. This likely requires a new Kconfig symbol to differentiate between the old and new contract. This also creates a fragmented design pattern - board overlay files are structured differently based on the Kconfig setting.
• Such fundamental change probably makes more sense as part of the device init overall.

Option 3: Create new value for status property for deferred nodes

Use the status property, but define a new value, "deferred", that is distinct from "disabled" or "reserved".

This is essentially a compromise between options 1 and 2.

Advantages

• Uses the status property to indicate deferred state. This can be viewed as offering better compatibility to other devicetree models (Linux).
• Likely macrobatics on can handle the changes needed to DT_INST_FOREACH_STATUS_OKAY without changing the macro signature, allowing drivers to remain unchanged.

Disadvantages

• Zephyr specific status property value.
• Changes to CONFIG_DT_HAS_xxx_ENABLED Kconfig symbol generation required