How Not to Write X86 Platform Drivers
summary
MinnowBoard work shows why x86 board files break the platform: a 462‑line board description hardcodes GPIO, LEDs and buttons and doesn’t scale. UART clocks required DMI matching to pick 48MHz vs 50MHz; MAC address storage uses an EFI variable and firmware writes the PCI config so drivers need no change; the PHY needed a PCI subsystem ID plus a per‑board platform init callback to flip reset, set 2ns RGMII delay and disable hibernate. ACPI with an _PRP method supplies named GPIO properties and lets upstream drivers reuse existing code; most fixes land in 3.12, GPIO board files remain rejected.
AI-written summary · about
chapters (16)
- 0:00Start
- 6:45MinnowBoard: Overview
- 9:18MinnowBoard: GPIO
- 14:54MinnowBoard: Board-Files Bad
- 16:35MinnowBoard: UART
- 18:02MinnowBoard: Ethernet PHY
- 24:35MinnowBoard: Ethernet MAC
- 27:19Lessons: Platform
- 28:54Lessons: Complexity
- 35:16Lessons: It's Not About You!
- 36:15Agenda
- 36:33Take 2: GPIO Revisited
- 37:01Take 2: Identification and Description
- 43:01Take 2: ACPI Device Enumeration
- 45:33Take 2: ACPI Device Description
- 47:14Next Steps
related talks
41mHow to Avoid Writing Device Drivers for Embedded Linux
42mPorting Linux to a Baseboard Management Controller Asic, Feedbacks and Perspectives
19mPinctrl and GPIO - Interactions and Footguns
46mEarly Platform Drivers in Linux Kernel
47mLinux on POWER Driver Porting, Optimization, and Test
10mUpstreaming a linux kernel driver.
59mUnderstanding the Structure of a Linux Kernel Device Driver- 19mPinctrl and GPIO - Interactions and Footguns