Linux Laying Out Guidelines To Avoid Kernel Updates Breaking Firmware Compatibility

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.