Kernel Recipes 2019 - 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
Видео Kernel Recipes 2019 - What To Do When Your Device Depends on Another One канала Kernel Recipes
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
Видео Kernel Recipes 2019 - What To Do When Your Device Depends on Another One канала Kernel Recipes
Показать
Комментарии отсутствуют
Информация о видео
Другие видео канала
![Kernel Recipes 2022 - What’s new with io_uring](https://i.ytimg.com/vi/ToSRCSijRuE/default.jpg)
![Embedded Recipes 2022 - The next 50 million firmware updates](https://i.ytimg.com/vi/iR_KAjRe9fA/default.jpg)
![Kernel Recipes 2018 - Mitigating Spectre and Meltdown vulnerabilities - David Woodhouse](https://i.ytimg.com/vi/wZmqzB4QMpg/default.jpg)
![Embedded Recipes 2019 - Testing firmware the devops way](https://i.ytimg.com/vi/Cs6S928qw6Q/default.jpg)
![Kernel Recipes 2018 - A year of fixing Coverity issues... - Gustavo A. R. Silva](https://i.ytimg.com/vi/qj1Yjc_dK6s/default.jpg)
![Embedded Recipes 2017 - Proper APIs to HW video codec accelerators - Olivier Crete](https://i.ytimg.com/vi/bntAsF8IaLo/default.jpg)
![Kernel Recipes 2016 - Man-pages: discovery, feedback loops, commit message - Michael Kerrisk](https://i.ytimg.com/vi/TbKtpLHjG1I/default.jpg)
![Embedded Recipes 2022 - Tracing on embedded boards](https://i.ytimg.com/vi/7KHLoZKwlBk/default.jpg)
![Kernel Recipes 2022](https://i.ytimg.com/vi/nhJqaZT94z0/default.jpg)
![Kernel Recipes - Creating custom Debian images for your embedded device](https://i.ytimg.com/vi/467kgcSxDf0/default.jpg)
![Kernel Recipes 2015 - Solving the Linux storage scalability bottlenecks - by Jens Axboe](https://i.ytimg.com/vi/VIdKBD9-Ozg/default.jpg)
![Kernel Recipes 2019 - pidfds: Process file descriptors on Linux](https://i.ytimg.com/vi/19SlR_zjPxc/default.jpg)
![Kernel Recipes 2022 - Rethinking the kernel camera framework](https://i.ytimg.com/vi/KL3ajTu8VzU/default.jpg)
![Kernel Recipes 2022 - Make Linux developers fix your kernel bug](https://i.ytimg.com/vi/Uh_mWWMJHDY/default.jpg)
![Kernel Recipes 2019 - BPF at Facebook](https://i.ytimg.com/vi/bbHFg9IsTk8/default.jpg)
![Embedded Recipes 2018 - Using yocto to generate container images for yocto - Jérémy Rosen](https://i.ytimg.com/vi/0S2Qow1IcQA/default.jpg)
![Kernel Recipes 2018 - CLIP OS: a defense-in-depth OS - Mickael Salaün, Timothée Ravier](https://i.ytimg.com/vi/PjRE0uBtkHU/default.jpg)
![Embedded Recipes 2018 - SoC+FPGA support in 2018 - Marek Vasut](https://i.ytimg.com/vi/H7EsuyPQgFc/default.jpg)
![Kernel Recipes 2019 - No NMI? No Problem! – Implementing Arm64 Pseudo-NMI](https://i.ytimg.com/vi/7cVaEiaeSmo/default.jpg)
![Julia Lawall, INRIA - Coccinelle](https://i.ytimg.com/vi/ohyn1DTuh18/default.jpg)
![Kernel Recipes 2023 - Demystifying the Linux kernel security process](https://i.ytimg.com/vi/2TZe5EROFhE/default.jpg)