-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
need API to get list of succeed initialization device or add initialization status flag in struct device #24750
Comments
This API just provides the start and end of the linker section that contains all devices. It doesn't synthesize a new list of any sort. It should be possible to iterate over the devices in that list and determine whether they've been initialized successfully or not, though that capability may not be present. If not this is related to #19448 which also needs to know device status. |
@wentongwu consensus is that we should document this properly so that it explicitly states that this returns the full list of devices, started or not, and then it's the responsibility of the caller to walk the array and determine which ones are initialized or not. |
yes, we should have that API or there is status flag in struct device. |
Thanks, the title of this issue maybe confuse, my intention is to get the list of succeed initialization device in ether way(device module provide that API or caller iterate over the devices by the initialization status which currently doesn't exist in struct device), currently PM module use device_list_get to suspend/resume device and it may not be well considered. |
@wentongwu Agreed, we need #23407 merged then I'll work this, adding a function to check the state and clarifying the documentation. #19448 needs to be taken into account in the API, though the implementation can wait. |
Just a quick notice, as your discussion caught my attention: driver_api pointer is not going to be used anymore as a marker for initialization success/failure. Reason being that it prevents device driver instance to be "const-ified" to stay in ROM. (I am actually working on this const issue)
Yes a status flag per-device driver instance will be the solution (it will be used for other things as well, maybe we'll be able to pack other things there, it's 32 bits: there is space).
I already made a draft RFC on device status reporting, it's still in a very early stage, but the grounds for such check is there already (the function is called device_check_status(), it's not yet part of device public API but your use case would definitely need it). There is at least this one #24511 (it introduces the status, but only uses it for synchronization purposes), then the status reporting RFC extends its usage to initializtion status, hw fault, etc... Note that stuff in this PR could be used to reduce the PM structure size as well later on, most notably the lock attribute. |
Describe the bug
device_list_get located in device sub system is the API exposed to other modules, and the returned list shouldn't include the initialization failed devices, or at least we should have that kind of API to get all the devices whose initialization is well, though it's not common case that device fail it's initialization.
The text was updated successfully, but these errors were encountered: