Device (de)initialization use case

[tbursztyka]

There seems to be a cross-over of uses-cases/requirements between 2 issues around device initialization, so gathering both here for tracking and discussion.

• Allow for selective deferment of device initialization (aka manual init) Allow for selective deferment of device initialization (aka manual init) #39896
• Support peripheral deallocation at runtime Support peripheral deallocation at runtime #20012

Let's summarize the requirements:

Add the ability to manually initialize a device:

This means adding 2 things:

• marking a device as manually initialized
• exposing a device_init() function

Add the ability to de-initialize a device:

• exposing a device_deinit() function (or some other relevant name)

Cross-over requirements:

• Forcing initialization: device_deinit() needs to be called prior to device_init()
• In case PM is enabled: device_deninit() should call PM to put the device OFF (so all dependencies will also be properly affected)
• In case PM is not enabled: we will need a better error-management so if a device is put down, things will not just explode (dependencies still trying to access the device etc...). Device APIs do not check for device status, so currently calling a device that has been de-initialized, would lead to unknown state.

[gregshue]

Is device de/initialization only concerned with the FW structures, or also the HW state?

Consider when application code inherits a running device initialized by boot code, and de-initialization is not an option. The simplest example of this is GPIOs, but it is effectively true of every HW block touched by boot code.

Consider also the scope of de-initialization. Does it return the HW block to a reset state? Does it clear out all pending interrupts? Does it make sure no pending DMA transactions are left hanging? What state should the HW be left in before boot code calls the application code?

[danielstuart14]

This would be huge!
I have a use case here that I found, that has proven to be impossible using zephyr's SPI driver:

I'm porting Zephyr to a board that has an odd SPI communication between the main controller and the ble chipset (nordic nrf52832).

The BLE chipset (which I'm porting Zephyr) is the slave in the SPI bus, but it also uses the chipselect as a wake pin for the main controller.
When it wants to wake the main controller, the device disables the SPI peripheral, changes the CS pin direction and sends a low signal. After 50us, it changes back the CS pin direction and enable again the SPI. It does all of that using the NRFX SPIS driver.

One dev has suggest the use of dynamic pinctrl, but currently, as we don't have de-initialization, I can't use that.

[keith-zephyr]

Looking the requirements listed, the "Cross-over requirements" seem to only apply to the de-initialization use case.

If the deferred initialization device_init() verifies that the specified device is not already initialized, then I believe the deferred initialization could be implemented now with no dependencies on the de-initialization.

The deferred initialization could always be updated if de-initialization support is added later.

I have a use case for supporting multiple board configurations with a single image. With deferred init, a devicetree could do the following:

device_a: device_a {
    compatible = "vnd,device-a";
    status = "okay";
    deferred-init;
};
device_b: device_b {
    compatible = "vnd,device-b";
    status = "okay";
    deferred-init;
}'

The application can the chose the device to initialize:

static int init_my_devices(void)
{
    if (board_revision == BOARD_REV_A) {
        rc = device_init(DEVICE_DT_GET(DT_NODELABEL(device_a));
    } else {
        rc = device_init(DEVICE_DT_GET(DT_NODELABEL(device_b));
    }
    return rc;
}
SYS_INIT(init_my_devices, POST_KERNEL, 50);

I'm happy to create an RFC and draft PR for the deferred initialization only use case.

[yashi]

A Discord thread:
https://discord.com/channels/720317445772017664/905146919880388668