How (Not) to Get the Vendor Driver Merged Upstream
summary
This gives a checklist: fix all build warnings and compile on x86/arm/arm64, handle missing hardware and bad IO so the driver never crashes, document device-tree properties and pass schema checks, split large patchsets (avoid 30–40 patches or hundreds of kilobytes in one series), start from linux-next (or Linus) as baseline, expect many iterations (some reach 10–20 versions), and note volunteers contribute ~1/3 of DRM MSM changes. Use use b4 to prepare patches and obey the mail-based submission only workflow.
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
58mUpstreaming 101
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
45mBOF: Corporate Use of Embedded Linux
36mNo, It's (Still) Never Too Late to Upstream Your Legacy Linux Based Platforms
45mFrom an Idea to a Patch in the Linux Mainline
49mThe Salmon Diet: Up-Streaming Drivers as a Form of Optimization
37mCreating a Healthy Vibrant Kernel Subsystem Community