-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Description
I wasn't able to find an existing issue (neither #20348 nor #6293 cover it exactly). Happy to close if I missed something.
Is your feature request related to a problem? Please describe.
Currently, device drivers must specify the initialization level (PRE_KERNEL_1, etc.) and priority (usually something like CONFIG_KERNEL_INIT_PRIORITY_DEVICE) within that initialization level for each device. These determine the order in which device init functions are called.
This mechanism can make it awkward to capture more complex dependencies, e.g. a GPIO expander that controls a SPI device CS line, which should therefore be initialized before the SPI device.
It's always possible to do this by manually messing around with priorities. However, that's cumbersome, especially since the dependency information is already available in the devicetree.
Describe the solution you'd like
It should be possible to perform device initialization based on the dependency order implied by the "dependency ordinal" assigned to each node in the devicetree (and available in edtlib.Node.dep_ordinal).
To avoid breaking things too much, I think this could be added under a new Kconfig bool, CONFIG_DEVICE_DT_INIT
. When enabled, this would allow devices to pass their dependency ordinal from devicetree to a new DEVICE_INIT-type macro (DEVICE_AND_API_INIT_DT
or so as prototyped in #20253) that assigns a priority based on this value.
To avoid breakage, I think this also means we need to make sure the following when CONFIG_DEVICE_DT_INIT=y
:
CONFIG_KERNEL_INIT_PRIORITY_DEFAULT
is higher priority than the highest DT-based priorityCONFIG_KERNEL_INIT_PRIORITY_DEVICE
is lower priority than the lowest DT-based priority
We'll also probably need to increase the number of .init_<LEVEL><PRIO>
linker sections.
Open questions
- How should initialization levels fit into this world? Example: does it still make sense to have a PRE_KERNEL_1 and PRE_KERNEL_2, or can we merge them into one PRE_KERNEL init level and just let DT ordinals sort it out?
- If we do keep separate init levels, what should happen if actual initialization order is the reverse of DT dependency order? For example, suppose deviceA is in PRE_KERNEL_1 and deviceB is in PRE_KERNEL_2, but deviceA depends on deviceB in the DT. That seems like it should be a build-time error, or at least a warning.
- How do "pseudo-devices" created using SYS_INIT() fit into this picture? For example, should we ensure their priorities always lie outside of the DT ordinal priority range?