Blinking Lights getting it wrong again again and again
summary
RJ45 LEDs often end up configured by brittle device tree hacks (Marvel’s 2010 register-write example), and many patches get NACKed for encoding vendor register values in DT. The netdev stack adds concrete kernel support: extend the LED subsystem triggers with can_offload / set_offload ops, an upstream-device selector and a flags bitmap to describe behaviours. The new API offloads PHY/MAC blinking when supported and falls back to software otherwise; reviewers rate the flags design about Rusty Russell 7–8.
AI-written summary · about
chapters (10)
- 0:00Introduction to blinking lights
- 1:26History of LED control in networking
- 3:53Why standardization failed
- 5:17Silo thinking in driver development
- 6:42Common driver mistakes
- 8:07How to design better APIs
- 9:14Linux LED subsystem basics
- 11:47Extending LED API for hardware offload
- 13:52Rusty Russell API score
- 14:57Q&A on driver APIs
related talks
41mBraiding Wires Into the Linux Network Stack - Recent Work on Embedded Networking
59mUnderstanding the Structure of a Linux Kernel Device Driver
50mHotplug of Non-discoverable Hardware: Status and Future Directions
34mFW centric devices, NIC customization
52mIn the Kernel Trenches: Mastering Ethernet Drivers on Linux- 52mIn the Kernel Trenches: Mastering Ethernet Drivers on Linux
20mTeach an Old Network Driver New Tricks
34mEarly Ethernet With Linux