[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180105120041.7759-1-standby24x7@gmail.com>
Date: Fri, 5 Jan 2018 21:00:41 +0900
From: Masanari Iida <standby24x7@...il.com>
To: mcgrof@...nel.org, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org
Cc: Masanari Iida <standby24x7@...il.com>
Subject: [PATCH] linux-next: firmware: Fix a typo in fallback-mechanisms.rst
This patch fix a spelling typo found in fallback-mechanisms.rst
Signed-off-by: Masanari Iida <standby24x7@...il.com>
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index d19354794e67..4055ac76b288 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -71,7 +71,7 @@ via fw_create_instance(). This call creates a new struct device named after
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 (firmare_class) and group (fw_dev_attr_groups).
+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.
--
2.15.1.433.g936d1b989416
Powered by blists - more mailing lists