summaryrefslogtreecommitdiffstats
path: root/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
diff options
context:
space:
mode:
authorJoel Fernandes <joelagnelf@nvidia.com>2026-07-18 13:15:36 -0400
committerPaul E. McKenney <paulmck@kernel.org>2026-07-23 10:39:57 -0700
commit34ff636f322c6d5e4f0a52338fa63a7dff09a495 (patch)
tree7629759c1ec7148b95bc8ab3080df20a5ecd2273 /Documentation/driver-api/firmware/firmware-usage-guidelines.rst
downloadlinux-stable-34ff636f322c6d5e4f0a52338fa63a7dff09a495.tar.gz
linux-stable-34ff636f322c6d5e4f0a52338fa63a7dff09a495.zip
scftorture: Count single_rpc offline failures in statistics outputgrafted
scf_torture_stats_print() aggregates each invoker thread's counters into a local scf_statistics structure before printing, but the n_single_rpc_ofl field is missing from the aggregation loop. As a result, the "single_rpc_ofl" value printed in the statistics line is always zero, even when smp_call_function_single() invocations for the RPC test have failed due to offline CPUs and been counted by the invoker threads. Add the missing accumulation so that the printed value reflects the actual counts. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'Documentation/driver-api/firmware/firmware-usage-guidelines.rst')
-rw-r--r--Documentation/driver-api/firmware/firmware-usage-guidelines.rst49
1 files changed, 49 insertions, 0 deletions
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 000000000..336e91228
--- /dev/null
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -0,0 +1,49 @@
+===================
+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.
+
+* Firmware files that affect the User API (UAPI) shall not introduce
+ changes that break existing userspace programs. Updates to such firmware
+ must ensure backward compatibility with existing userspace applications.
+ This includes maintaining consistent interfaces and behaviors that
+ userspace programs rely on.