About 1/4 of the people in the audience are actively working with device trees.
Evolution in device tree is too fast nowadays, because of ARM moving to device tree. When there is a stumbling block, there is no time to solve it well because there are so many boards that want to use the device trees (otherwise it’s not accepted upstream).
It’s too easy to get data out of the device tree – people use it in various ways, while maybe it’s not so appropriate.
Drivers have to be converted from platform data and device tree. There are two important differences:
- Platform data is embedded in the kernel, so it’s internal API. Therefore you can easily update the platform data and globally fix all users. Device trees are essentially external, even if the kernel is shipped with some samples. E.g. the DT can be generated at runtime by OpenFirmware. Therefore, newer kernels must support older device trees.
- Platform data can be used for anything. Device trees are OS-independent descriptions only; they can’t replace part of the driver.
Therefore, be careful before adding a new binding. Consider it like a syscall (i.e. external ABI). Make bindings sufficiently generic. 1-to-1 mapping from platform data to DT bindings almost never work. Think about how the bindings can be set up so they can be used in a general way (several HW platforms, several drivers, several OSes).
Because of these things, device tree conversion patches can have some delay. Even so, a lot of things get accepted in the mainline kernel even if they’re not perfect, because developers need a solution now.
Suggestion: don’t try to create properties for everything that is in pdata. Often you can hardcode things because there is only one sensible setting, or derive it from other information (e.g. the presence of other nodes in the DT). Or with the compatible property you can find out which HW version you have and derive quirks from that.
DT shouldn’t encode software configuration. There is now no good way to add driver configuration without platform data. In PowerPC, this is often hardcoded in the driver.
Question from ThomasP: is it worth the effort? Isn’t DT making things more difficult with little benefit? Answer: it’s very useful to have one kernel that can boot on several devices.