Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
Linux Laying Out Guidelines To Avoid Kernel Updates Breaking Firmware Compatibility
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.
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.