What To Do When Your Device Depends on Another One

Contemporary computer systems are quite complicated. There may be multiple connections between various components in them and the components may depend on each other in various ways. At the same time, however, in many cases it is practical to use a separate device driver for each sufficiently distinct system component, depending on the functionality provided by them. Each driver may then focus on providing the required functionality without worrying about the rest of the system too much, but the dependencies between different system components are still there and need to be taken into account in some situations, for example related to power management.

The Linux kernel’s driver model allows the system to be represented as a hierarchy of device objects with a proper tree structure. In that hierarchy, a device can be a leaf, in which case no other devices should depend on it, or it can be a parent of some other device and, as a rule, device drivers bind to individual devices. That is sufficient if the system topology is a proper tree too, but it may not be entirely adequate otherwise. There are cases in which one device uses resources provided by another device that is not its parent and it may not function correctly if the device providing those resources becomes unavailable, for example due to power management.

The device links framework was added to the Linux kernel with such use cases in mind and it has been revamped recently, which is a good opportunity to look at it again. It allows a dependency between two devices to be represented as a link between the corresponding device objects. If such a link is added, the driver core will automatically take it into account in power management, among other places, so that the device providing resources, referred to as the supplier, is always available as long as the device using them, referred to as the consumer, is active. However, there are two types of device links and there are flags to specify at the link creation time to let the driver core know what to use the link for and how to handle it going forward, so some care needs to be taken in order to get the desired results. I will explain how device links work, what the driver core can be expected to do with then depending on the flags used at the link creation time and why it always is a good idea to check the return value of device_link_add().

Rafael Wysocki, Intel

Transcript

1. What To Do When Your Device Depends on Another One Rafael J. Wysocki Intel Linux Systems Engineering September 25, 2019 Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 1 / 20
2. Introduction Background Devices Depend On One Another Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 2 / 20
3. Introduction Background Simple Case: Tree Topology Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 3 / 20
4. Introduction Imperfections Example: Driver Core and Power Management Driver Core Type Middle Layer Device Driver Device Action PM Domain Class Bus Device Driver Device Device Device Device Device Device Device Device Bus Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 4 / 20
5. Introduction Imperfections Example: Driver Probe Ordering Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 5 / 20
6. Device Links Design Idea: Light-weight Solution On Top Of What Is There Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 6 / 20
7. Device Links Design Device Links Data Structure Device Device Device Device Device Device Device Device Device Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 7 / 20
8. Device Links Post-probe Use Cases System-wide PM And Shutdown Ordering Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 8 / 20
9. Device Links Post-probe Use Cases Asynchronous Execution Of System-wide PM Callbacks Call Notifiers Freeze Tasks Device Suspend Device Resume Thaw Tasks Call Notifiers Wait For a Wakeup Interrupt Call Notifiers Freeze Tasks Nonboot CPU Offline System Core Offline Device Suspend Platform Offline System Core Online Nonboot CPU Online Device Resume Thaw Tasks Call Notifiers Platform Online .prepare() .suspend() .suspend_late() .suspend_noirq() .prepare() .suspend() .suspend_late() .suspend_noirq() .resume_noirq() .resume_early() .resume() .complete() .resume_noirq() .resume_early() .resume() .complete() Wait For a Wakeup Event Platform-based Suspend Suspend to Idle Working State Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 9 / 20
10. Device Links Post-probe Use Cases PM-runtime Ordering Suspended Active Is Idle? YES NO Suspend Resume Trigger Event DL_FLAG_PM_RUNTIME (+ DL_FLAG_RPM_ACTIVE) Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 10 / 20
11. Device Links Post-probe Use Cases Device Links Usage In Power Management Driver Core Type Middle Layer Device Driver Device Action PM Domain Class Bus Device Driver Device Device Device Device Device Device Device Device Bus Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 11 / 20
12. Device Links Device Link Management Managed Device Links DL_FLAG_AUTOREMOVE_CONSUMER DL_FLAG_AUTOREMOVE_SUPPLIER DL_FLAG_AUTOPROBE_CONSUMER Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 12 / 20
13. Device Links Device Link Management Stateless Device Links DL_FLAG_STATELESS Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 13 / 20
14. API and State Machine Addition and Removal API Adding Device Links struct device_link *device_link_add(struct device *consumer, struct device *supplier, u32 flags); Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 14 / 20
15. API and State Machine Addition and Removal API Removing Stateless Device Links void device_link_del(struct device_link *link); void device_link_remove(void *consumer, struct device *supplier); Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 15 / 20
16. API and State Machine Device Link State Machine Managed Device Link State Machine Dormant Available Consumer Probe Supplier Unbind Active Supplier Probe Consumer Unbind Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 16 / 20
17. API and State Machine Device Link State Machine Rules Regarding Device Link Flags 1 STATELESS bumps up the reference counter. 2 Passing STATELESS along with link management flags is invalid. 3 AUTOREMOVE_SUPPLIER overrides AUTOREMOVE_CONSUMER. 4 “No management flags” overrides both autoremove flags. 5 Passing AUTOPROBE_CONSUMER along with autoremove flags is invalid. 6 RPM_ACTIVE without PM_RUNTIME is ignored. 7 PM_RUNTIME can always be set and is never unset. Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 17 / 20
18. Wrap-Up Summary / Discussion Questions? Comments? Concerns? Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 18 / 20
19. Resources References Greg Kroah-Hartman, Linux Driver Model (https://www.youtube.com/watch?v=AdPxeGHIZ74). Rafael J. Wysocki, Power Management Challenges in Linux (https: //www.linuxplumbersconf.org/2017/ocw//system/presentations/4652/original/linux_pm_challenges.pdf). Rafael J. Wysocki, PM Infrastructure in the Linux Kernel – Current Status and Future (https://events.linuxfoundation.org/sites/events/files/slides/kernel_PM_infra_0.pdf). Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 19 / 20
20. Disclaimer Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at www.intel.com. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. c Intel Corporation Rafael J. Wysocki Addressing Device Dependencies September 25, 2019 20 / 20