Improving fw_devlink dependency tracking
summary
Current fw_devlink parses every device tree property with a dedicated parser in drivers/of/property (around 40 today) and that won't scale to hundreds, so the proposal tests three fixes: have DTC emit a _references property listing all phandles, use the DT overlay local fixups node created by the plugin directive to record phandle offsets, or extend libfdt/DTB to encode per-property type info. Tradeoffs are parsing overhead, DTB size, runtime patching consistency, and whether async probing can safely become default.
AI-written summary · about
chapters (5)
- 0:00Introduction to fw_devlink
- 2:28Current dependency tracking issues
- 3:55Potential solutions for fw_devlink
- 10:01Devlink as functional requirement
- 19:40Q&A and wrap-up
related talks
01h 10mBoF: Devicetree
44mBoF: Devicetree
44mSolving Devicetree Issues, part 3.0
14mfw_devlink and parallelization updates
40mSecond Source Component Probing on Device Tree Platforms
40mOF-nodes, Fwnodes, Swnodes, Devlinks, Properties - Understanding How Devices...
40mSecond Source Component Probing on Device Tree Platforms
50mRethinking U-Boot Devicetree Story
