| b.liu | e958203 | 2025-04-17 19:18:16 +0800 | [diff] [blame^] | 1 | What: /sys/devices/.../state_synced |
| 2 | Date: May 2020 |
| 3 | Contact: Saravana Kannan <saravanak@google.com> |
| 4 | Description: |
| 5 | The /sys/devices/.../state_synced attribute is only present for |
| 6 | devices whose bus types or driver provides the .sync_state() |
| 7 | callback. The number read from it (0 or 1) reflects the value |
| 8 | of the device's 'state_synced' field. A value of 0 means the |
| 9 | .sync_state() callback hasn't been called yet. A value of 1 |
| 10 | means the .sync_state() callback has been called. |
| 11 | |
| 12 | Generally, if a device has sync_state() support and has some of |
| 13 | the resources it provides enabled at the time the kernel starts |
| 14 | (Eg: enabled by hardware reset or bootloader or anything that |
| 15 | run before the kernel starts), then it'll keep those resources |
| 16 | enabled and in a state that's compatible with the state they |
| 17 | were in at the start of the kernel. The device will stop doing |
| 18 | this only when the sync_state() callback has been called -- |
| 19 | which happens only when all its consumer devices are registered |
| 20 | and have probed successfully. Resources that were left disabled |
| 21 | at the time the kernel starts are not affected or limited in |
| 22 | any way by sync_state() callbacks. |
| 23 | |
| 24 | |