[PATCH] docs: driver-api: firmware: add driver firmware guidelines. (v3)
From: Dave Airlie airlied@redhat.com
A recent snafu where Intel ignored upstream feedback on a firmware change, led to a late rc6 fix being required. In order to avoid this in the future we should document some expectations around linux-firmware.
I was originally going to write this for drm, but it seems quite generic advice.
v2: rewritten with suggestions from Thorsten Leemhuis v3: rewritten with suggestions from Mauro
Acked-by: Luis Chamberlain mcgrof@kernel.org Acked-by: Rodrigo Vivi rodrigo.vivi@intel.com Acked-by: Daniel Vetter daniel@ffwll.ch Acked-by: Harry Wentland harry.wentland@amd.com Signed-off-by: Dave Airlie airlied@redhat.com --- Documentation/driver-api/firmware/core.rst | 1 + .../firmware/firmware-usage-guidelines.rst | 44 +++++++++++++++++++ 2 files changed, 45 insertions(+) create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst
diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst index 1d1688cbc078..803cd574bbd7 100644 --- a/Documentation/driver-api/firmware/core.rst +++ b/Documentation/driver-api/firmware/core.rst @@ -13,4 +13,5 @@ documents these features. direct-fs-lookup fallback-mechanisms lookup-order + firmware-usage-guidelines
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst new file mode 100644 index 000000000000..fdcfce42c6d2 --- /dev/null +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst @@ -0,0 +1,44 @@ +=================== +Firmware Guidelines +=================== + +Users switching to a newer kernel should *not* have to install newer +firmware files to keep their hardware working. At the same time updated +firmware files must not cause any regressions for users of older kernel +releases. + +Drivers that use firmware from linux-firmware should follow the rules in +this guide. (Where there is limited control of the firmware, +i.e. company doesn't support Linux, firmwares sourced from misc places, +then of course these rules will not apply strictly.) + +* Firmware files shall be designed in a way that it allows checking for + firmware ABI version changes. It is recommended that firmware files 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 firmware version should + be stored in the firmware header, or as an exception, as part of the + firmware file name, in order to let the driver detact any non-ABI + fixes/changes. The firmware files in linux-firmware should be + overwritten with the newest compatible major version. Newer major + version firmware shall remain compatible with all kernels that load + that major number. + +* If the kernel support for the hardware is normally inactive, or the + hardware isn't available for public consumption, 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 that are required by currently supported stable/LTS kernels, + should be updated with the security fix. 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. +
On Thu, 2022-07-21 at 14:43 +1000, Dave Airlie wrote:
+Users switching to a newer kernel should *not* have to install newer +firmware files to keep their hardware working. At the same time updated +firmware files must not cause any regressions for users of older kernel +releases.
That seems sane, and certainly something we've done in wireless in the past.
+* Firmware files shall be designed in a way that it allows checking for
- firmware ABI version changes. It is recommended that firmware files 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 firmware version should
- be stored in the firmware header, or as an exception, as part of the
- firmware file name,
Eh, I went to write a whole paragraph here and then read it again ... Maybe this should say "[t]he _full_ firmware version", to contrast with the previous sentence mentioning the "major version".
in order to let the driver detact any non-ABI
typo - 'detect'
- fixes/changes. The firmware files in linux-firmware should be
- overwritten with the newest compatible major version.
That's also a bit confusing IMHO - did that mean "minor version"? Or something? I mean ... if you overwrite a file that has the major version in the filename then by definition it is the same major version?
- This means no major version bumps without the kernel retaining
- backwards compatibility for the older major versions.
Strictly reading this might require aeons of support for firmware version, if you have a release cadence of them like every 6 weeks for a new _major_ version (yes, because APIs change), then that's rather harsh. In practice we've often done this, but I think some reasonable cut-off could/should be there, such as dropping support after a reasonably long time frame (say a year?)
Often though that's less a question of "does it still work" and rather one of "do I still support that" and the answer for the latter is obviously "no" much quicker than the former.
johannes
participants (2)
-
Dave Airlie -
Johannes Berg