Linux Laying Out Guidelines To Avoid Kernel Updates Breaking Firmware Compatibility

Written by Michael Larabel in Linux Kernel on 18 July 2022 at 06:01 AM EDT. 31 Comments
Stemming from my article last week noting how Linux 5.19 Git broke Intel Alder Lake P graphics support due to requiring new firmware while not retaining backwards compatibility with the existing Intel GuC firmware, a solution is still being worked on prior to Linux 5.19 final whether it be a revert or the proposed patch working on GuC v69/70 firmware compatibility. Linux firmware guidelines are also being proposed to ensure kernel developers in the future don't try to break firmware support guarantees.

DRM maintainer David Airlie this morning sent out proposed Linux kernel documentation that clearly spells out firmware expectations for the mainline Linux kernel drivers. The documentation explicitly notes that users should not have to install newer firmware to use existing hardware with a new kernel -- i.e. backwards compatibility with firmware on newer kernels must be maintained. This has been an unwritten rule already but abused by Intel now with this Alder Lake P graphics fiasco.

It's becoming a written rule now that upgrading your kernel can't break graphics acceleration by mandating newer firmware for released hardware... While motivated by the Intel ADL-P graphics example last week, this firmware handling should apply to all hardware/drivers on Linux.

Airlie's proposed documentation around Linux firmware guidelines can be found on the mailing list and embedded below in its initial form.
Firmware Guidelines

Drivers that use firmware from linux-firmware should attempt to follow the rules in this guide.

* Firmware should be versioned with at least a major/minor version. It is suggested that the firmware files in linux-firmware be named with some device specific name, and just the major version. The major/minor/patch versions should be stored in a header in the firmware file for the driver to detect any non-ABI fixes/issues. The firmware files in linux-firmware should be overwritten with the newest compatible major version. Newer major version firmware should remain compatible with all kernels that load that major number.

* Users should *not* have to install newer firmware to use existing hardware when they install a newer kernel. If the hardware isn't enabled by default or under development, this can be ignored, until the first kernel release that enables that hardware. This means no major version bumps without the kernel retaining backwards compatibility for the older major versions. Minor version bumps should not introduce new features that newer kernels depend on non-optionally.

* If a security fix needs lockstep firmware and kernel fixes in order to be successful, then all supported major versions in the linux-firmware repo should be updated with the security fix, and the kernel patches should detect if the firmware is new enough to declare if the security issue is fixed. All communications around security fixes should point at both the firmware and kernel fixes. If a security fix requires deprecating old major versions, then this should only be done as a last option, and be stated clearly in all communications.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week