How (Not) to Get the Vendor Driver Merged Upstream
summary
Vendor drivers must compile clean across architectures, pass checkpatch and device-tree schema checks, and handle missing hardware, bad firmware and resource failures without crashing. Use b4 and git send-email for the canonical mail-based submission, base patches on Linus-next (not an old LTS), split into readable, buildable commits with a cover letter and trailers, expect many review iterations (20+ sometimes), wait before re-sending, and address maintainer comments rather than ignoring them.
AI-written summary · about
chapters (18)
- 0:00Upstreaming vendor drivers
- 1:06Why upstreaming matters
- 3:15Risks of out-of-tree drivers
- 5:04Myths about driver quality
- 6:29Preparing code for submission
- 8:35Following upstream process
- 10:47Device tree and API
- 12:12Structuring patch sets
- 14:22Mail submission rules
- 16:07Handling feedback
- 17:10Patch review mistakes
- 20:24Ignored patches
- 22:15Iterative improvement
- 23:01Expecting rewrites
- 24:23Timeline pressures
- 25:26Asking questions
- 26:28Resources and closing
- 27:55Q&A
related talks
32mHow (Not) to Get the Vendor Driver Merged Upstream
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
58mUpstreaming 101
45mFrom an Idea to a Patch in the Linux Mainline
39mThe Life of a Kernel Bugfix
45mBOF: Corporate Use of Embedded Linux
53mUpstreaming 201
40mContributing to Zephyr vs (Linux and U-boot)