From patchwork Tue May 8 18:12:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 10386975 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 3FE03602C2 for ; Tue, 8 May 2018 18:13:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1D93028832 for ; Tue, 8 May 2018 18:13:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1047929122; Tue, 8 May 2018 18:13:53 +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 BCAE028832 for ; Tue, 8 May 2018 18:13:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933102AbeEHSNQ (ORCPT ); Tue, 8 May 2018 14:13:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:41460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933328AbeEHSNN (ORCPT ); Tue, 8 May 2018 14:13:13 -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 CB4CD2183C; Tue, 8 May 2018 18:13:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525803192; bh=VVQHSMLEgOO9vG+OOrJYt7RiuktztmoKMGDyPGv62Eg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cLJck5I0EZwXtE5nSYDttYEtyv3pljxSyfOOn9STzw5znJZYYrv+pKBt/Plc3gXEq Dz1AUSTjRB46PN8Bni+jk3lZOfRE4z0j0pRUOeeeObo7i/wIC0vRHDy6fis7ltL3zp Xe0qXf3kmmyE6Bqq7net1ah+DPmIAFDa6B0jVSV0= 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, ast@fb.com, hare@suse.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, khc@pm.waw.pl, davem@davemloft.net, arve@android.com, tkjos@android.com, corbet@lwn.net, mchehab+samsung@kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, "Luis R. Rodriguez" Subject: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module Date: Tue, 8 May 2018 11:12:47 -0700 Message-Id: <20180508181247.19431-14-mcgrof@kernel.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org> References: <20180508181247.19431-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. Signed-off-by: Luis R. Rodriguez Reviewed-by: Mauro Carvalho Chehab --- .../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..a8047be4a96e 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 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 compatibilty with old userspace. To load firmware using the sysfs interface we expose a loading indicator, and a file upload firmware into: