z_device_ready() lies

[pabigot]

#28369 was merged in the late days of 2.4 development to fix a problem where device drivers with incorrect/conflicting dependencies used device_get_binding() to identify a driver they depend on before that driver was initialized. Consequently z_device_ready() will succeed for devices that have not yet been initialized.

This really needs to get fixed as there are limited checks that a successfully obtained device pointer remains valid when it's actually used.

[tbursztyka]

I don't know why this is being assigned to me.
#28369 was merged to "fix" drivers that have buggy level/prio of initialization, due to lack of time to actually fix those.

so @pabigot, revert #28369 and let's fix these drivers that have un-proper lever/prio values.

[pabigot]

I don't know why this is being assigned to me.

Because in triage @nashif said to give it to you.

If I remain assigned I'll do it in the context of #19448 and other enhancements that require a finer grained distinction between the potential states of not-yet-initialized, initializing, initialized-success, initialized-failed, de-initialized, etc. There are distinct use cases to be able to get the device pointer in both not-yet-initialized and initialized-success states, so there are at least three states to track.

[tbursztyka]

@pabigot @nashif I have no time to work on that atm.

But I disagree on fixing it along with #19448, I mean these 2 issues are far different. This one is about DTS while current one is about runtime readyness and drivers that have buggy level/prio values.

And device states in general is again another subject.
There is no need for an in-between state such as "initializing" since initializing a device should be always synchronous, and "not-yet-initialized" and "de-initialized" are basically the same: it is not initialized (when initializing, one should not assume anything on the previous state of the hw). And to differentiate between successful and erroneous initialization, I had proposed months ago to store the last error in a device context (something like in 930a718 though this is outdated). That should give more clues, if the driver is using errno codes relevantly.
Failed initialization would not set the init bit, but set an error code. A de-initialization would clear all. etc.. etc..

[pabigot]

Fair enough, but #28369 was a temporary fix because #24873 changed behavior and broke existing uses. We don't have infrastructure to detect cases where the priority levels are "wrong", and won't until at least #26616 starts moving forward (it's not stalled on me...).[*]

We can't just revert it and play whack-a-mole trying to find the problems, many of which are likely to be out-of-tree, and we really do need to handle the use cases I identified. So this will have to wait until there's agreement on how to proceed and somebody has resource to apply to the consensus solution.

[*] They're "wrong" only because Zephyr initializes everything at startup unconditionally, and even then they're not wrong if the driver doesn't immediately start using the device it depends on.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.