summaryrefslogtreecommitdiff
path: root/Documentation/ABI
diff options
context:
space:
mode:
authorSaravana Kannan <saravanak@google.com>2020-05-21 22:17:59 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-07-10 16:24:56 +0300
commit8fd456ec0cf03875908d6b67c1cd20cf0a7b4474 (patch)
tree553496d0bbead2370f0eb1510a92db046bc9df9e /Documentation/ABI
parent287905e68dd29873bcb7986a8290cd1e4cfde600 (diff)
downloadlinux-8fd456ec0cf03875908d6b67c1cd20cf0a7b4474.tar.xz
driver core: Add state_synced sysfs file for devices that support it
This can be used to check if a device supports sync_state() callbacks and therefore keeps resources left on by the bootloader enabled till all its consumers have probed. This can also be used to check if sync_state() has been called for a device or whether it is still trying to keep resources enabled because they were left enabled by the bootloader and all its consumers haven't probed yet. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200521191800.136035-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/ABI')
-rw-r--r--Documentation/ABI/testing/sysfs-devices-state_synced24
1 files changed, 24 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-devices-state_synced b/Documentation/ABI/testing/sysfs-devices-state_synced
new file mode 100644
index 000000000000..0c922d7d02fc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-state_synced
@@ -0,0 +1,24 @@
+What: /sys/devices/.../state_synced
+Date: May 2020
+Contact: Saravana Kannan <saravanak@google.com>
+Description:
+ The /sys/devices/.../state_synced attribute is only present for
+ devices whose bus types or driver provides the .sync_state()
+ callback. The number read from it (0 or 1) reflects the value
+ of the device's 'state_synced' field. A value of 0 means the
+ .sync_state() callback hasn't been called yet. A value of 1
+ means the .sync_state() callback has been called.
+
+ Generally, if a device has sync_state() support and has some of
+ the resources it provides enabled at the time the kernel starts
+ (Eg: enabled by hardware reset or bootloader or anything that
+ run before the kernel starts), then it'll keep those resources
+ enabled and in a state that's compatible with the state they
+ were in at the start of the kernel. The device will stop doing
+ this only when the sync_state() callback has been called --
+ which happens only when all its consumer devices are registered
+ and have probed successfully. Resources that were left disabled
+ at the time the kernel starts are not affected or limited in
+ any way by sync_state() callbacks.
+
+