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.
+
-- 
2.36.1

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