From patchwork Thu May 10 20:08:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 10392377 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 786FF60236 for ; Thu, 10 May 2018 20:10:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 59A3828E53 for ; Thu, 10 May 2018 20:10:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 57AEA28E97; Thu, 10 May 2018 20:10:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A2F0328E53 for ; Thu, 10 May 2018 20:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752490AbeEJUKH (ORCPT ); Thu, 10 May 2018 16:10:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:36086 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343AbeEJUJP (ORCPT ); Thu, 10 May 2018 16:09:15 -0400 Received: from garbanzo.do-not-panic.com (c-73-15-241-2.hsd1.ca.comcast.net [73.15.241.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 54E5C2185F; Thu, 10 May 2018 20:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525982954; bh=c7GmiHj/vGgvxxvS02wh6oKewVC43FS03SEbunSa++M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EdLNaJQ+FzhkKa3AnpkyiYOdj9uzsBwWG9FnUXp3QTZu9EFbRJP+ro21cP9JmAtmt 4bVqeQxp6Vse2TvMbkW+rZQ439s/wdi+uozGxz8dypL7rWjB/W2U6VwNCLs0fc0iM+ EkClahMP4ecYAxWqXwZ8p2ZeGRjgZelGMEQIniYo= From: "Luis R. Rodriguez" To: gregkh@linuxfoundation.org Cc: akpm@linux-foundation.org, keescook@chromium.org, josh@joshtriplett.org, maco@android.com, andy.gross@linaro.org, david.brown@linaro.org, bjorn.andersson@linaro.org, teg@jklm.no, wagi@monom.org, hdegoede@redhat.com, andresx7@gmail.com, zohar@linux.vnet.ibm.com, kubakici@wp.pl, shuah@kernel.org, mfuzzey@parkeon.com, dhowells@redhat.com, pali.rohar@gmail.com, tiwai@suse.de, kvalo@codeaurora.org, arend.vanspriel@broadcom.com, zajec5@gmail.com, nbroeking@me.com, markivx@codeaurora.org, broonie@kernel.org, dmitry.torokhov@gmail.com, dwmw2@infradead.org, torvalds@linux-foundation.org, Abhay_Salunke@dell.com, jewalt@lgsinnovations.com, oneukum@suse.com, cantabile.desu@gmail.com, khc@pm.waw.pl, arve@android.com, tkjos@android.com, corbet@lwn.net, mchehab+samsung@kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-wireless@vger.kernel.org, "Luis R. Rodriguez" Subject: [PATCH v7 14/14] Documentation: clarify firmware_class provenance and why we can't rename the module Date: Thu, 10 May 2018 13:08:50 -0700 Message-Id: <20180510200850.5958-15-mcgrof@kernel.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180510200850.5958-1-mcgrof@kernel.org> References: <20180510200850.5958-1-mcgrof@kernel.org> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Clarify the provenance of the firmware loader firmware_class module name and why we cannot rename the module in the future. Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Kees Cook Signed-off-by: Luis R. Rodriguez --- .../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index a39323ef7d29..d35fed65eae9 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by associating the device used to make the request as the device's parent. The sysfs directory's file attributes are defined and controlled through the new device's class (firmware_class) and group (fw_dev_attr_groups). -This is actually where the original firmware_class.c file name comes from, -as originally the only firmware loading mechanism available was the -mechanism we now use as a fallback mechanism. +This is actually where the original firmware_class module name came from, +given that originally the only firmware loading mechanism available was the +mechanism we now use as a fallback mechanism, which registers a struct class +firmware_class. Because the attributes exposed are part of the module name, the +module name firmware_class cannot be renamed in the future, to ensure backward +compatibility with old userspace. To load firmware using the sysfs interface we expose a loading indicator, and a file upload firmware into: