From patchwork Tue Jul 19 06:53:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Airlie X-Patchwork-Id: 12922169 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 880F9C43334 for ; Tue, 19 Jul 2022 06:55:19 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id CEDF9169C; Tue, 19 Jul 2022 08:54:26 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz CEDF9169C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1658213716; bh=seP5OYHOj4rNTr0bzmcwfBkcRTnYXt1BVGo5nDysIJY=; h=From:To:Subject:Date:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=sHpswVa4Q79pStR78sdpI8Rw3RhnhC0aMnjEGV1024EvAdifzQatR3N2T3F4L5T/c HToxEQAZtyD5pMasR01VfLRL8kJyQUvQuASdmC1Ixdg/ZVfegYiC+jnsIgSu4UxmUt bKtd6vkLvtaNWgJ34B/PUR2+Gap48CJLqVMIvqkc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 223F7F8016D; Tue, 19 Jul 2022 08:54:26 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5C3CDF801EC; Tue, 19 Jul 2022 08:54:24 +0200 (CEST) Received: from us-smtp-delivery-44.mimecast.com (us-smtp-delivery-44.mimecast.com [205.139.111.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id B8E71F80169 for ; Tue, 19 Jul 2022 08:54:16 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz B8E71F80169 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-550-h5d0l6MvOry9tQjiREc1Yw-1; Tue, 19 Jul 2022 02:54:06 -0400 X-MC-Unique: h5d0l6MvOry9tQjiREc1Yw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A57641857F06; Tue, 19 Jul 2022 06:54:05 +0000 (UTC) Received: from dreadlord.bne.redhat.com (fdacunha.bne.redhat.com [10.64.0.157]) by smtp.corp.redhat.com (Postfix) with ESMTP id 45023141511F; Tue, 19 Jul 2022 06:54:01 +0000 (UTC) From: Dave Airlie To: torvalds@linux-foundation.org, Jonathan Corbet , linux-doc@vger.kernel.org, gregkh@linuxfoundation.org, Daniel Vetter , mcgrof@kernel.org Subject: [PATCH] docs: driver-api: firmware: add driver firmware guidelines. (v2) Date: Tue, 19 Jul 2022 16:53:57 +1000 Message-Id: <20220719065357.2705918-1-airlied@gmail.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 Cc: alsa-devel@alsa-project.org, netdev@vger.kernel.org, Rodrigo Vivi , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, dri-devel@lists.sf.net, Dave Airlie , linux-media@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" From: Dave Airlie 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. Acked-by: Luis Chamberlain Acked-by: Rodrigo Vivi Signed-off-by: Dave Airlie Acked-by: Harry Wentland --- Documentation/driver-api/firmware/core.rst | 1 + .../firmware/firmware-usage-guidelines.rst | 34 +++++++++++++++++++ 2 files changed, 35 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..34d2412e78c6 --- /dev/null +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst @@ -0,0 +1,34 @@ +=================== +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. +