-
Notifications
You must be signed in to change notification settings - Fork 7k
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
devicetree: support disabled devices #19448
Comments
The Maybe having no |
In dev-review because this impacts power management solution design and |
Revisiting this again, I believe the basic functionality is there: /**
* @brief Does a node identifier refer to a node?
*
* Tests whether a node identifier refers to a node which exists, i.e.
* is defined in the devicetree.
*
* It doesn't matter whether or not the node has a matching binding,
* or what the node's status value is. This is purely a check of
* whether the node exists at all.
*
* @param node_id a node identifier
* @return 1 if the node identifier refers to a node,
* 0 otherwise.
*/
#define DT_NODE_EXISTS(node_id) IS_ENABLED(DT_CAT(node_id, _EXISTS))
/**
* @brief Does a node identifier refer to a node with a status?
*
* Example uses:
*
* DT_NODE_HAS_STATUS(DT_PATH(soc, i2c_12340000), okay)
* DT_NODE_HAS_STATUS(DT_PATH(soc, i2c_12340000), disabled)
*
* Tests whether a node identifier refers to a node which:
*
* - exists in the devicetree, and
* - has a status property matching the second argument
* (except that either a missing status or an "ok" status
* in the devicetree is treated as if it were "okay" instead)
*
* @param node_id a node identifier
* @param status a status as one of the tokens okay or disabled, not a string
* @return 1 if the node has the given status, 0 otherwise.
*/
#define DT_NODE_HAS_STATUS(node_id, status) \
DT_NODE_HAS_STATUS_INTERNAL(node_id, status) Please advise if any additional helpers would be useful. If what is available is enough, please close. Thanks! |
I think what we have is enough until I figure out how this can be used. Thanks. |
The devicetree
status
property is generally set to one of these properties (ignoring failure states; descriptions from v0.3-rc2):okay
Indicates the device is operational.disabled
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).reserved
Indicates that the device is operational, but should not be used. Typically this is used for devices that are controlled by another software component, such as platform firmware.Currently the logic in edtlib sets the
Node.enabled
flag whenever the devicetree nodestatus
property is notdisabled
. In the current device management paradigmenabled
has the effect of (a) providing devicetree binding data in the headers and.conf
file, and (b) causing the corresponding device to be initialized on startup.Applications that are power-sensitive are likely to have devices that are to be left off at startup, but become enabled at certain points based on application logic. A natural way to express this is to leave
status = disabled
in the device tree, then locating the driver and initializing it on demand. A status ofreserved
could be used for this situation as well.Applications with a pluggable bus such as USB may have devices that are optional and detected at runtime when they are connected. This also corresponds to a
disabled
devicetree node status, butreserved
is not appropriate.Neither of these will work edtlib's current handling of
enabled
: there is no ability to distinguishokay
fromreserved
, and binding data is not generated for devices that aredisabled
.We need to figure out how to handle the case of delayed init and pluggable devices in terms of devicetree
status
field values.One off-the-cuff approach is to always generate binding data for nodes with status
okay
,reserved
, anddisabled
, but to also generate the correspondingstatus
value. Then store that instruct device
and provide a mechanism for device discovery and enable/disable, possibly based on device power management.The text was updated successfully, but these errors were encountered: