summaryrefslogtreecommitdiffstats
path: root/Documentation/driver-api/firmware/fallback-mechanisms.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-api/firmware/fallback-mechanisms.rst')
-rw-r--r--Documentation/driver-api/firmware/fallback-mechanisms.rst14
1 files changed, 9 insertions, 5 deletions
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index f353783ae0be5..d35fed65eae97 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:
@@ -83,7 +86,7 @@ and a file upload firmware into:
* /sys/$DEVPATH/data
To upload firmware you will echo 1 onto the loading file to indicate
-you are loading firmware. You then cat the firmware into the data file,
+you are loading firmware. You then write the firmware into the data file,
and you notify the kernel the firmware is ready by echo'ing 0 onto
the loading file.
@@ -136,7 +139,8 @@ by kobject uevents. This is specially exacerbated due to the fact that most
distributions today disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
Refer to do_firmware_uevent() for details of the kobject event variables
-setup. Variables passwdd with a kobject add event:
+setup. The variables currently passed to userspace with a "kobject add"
+event are:
* FIRMWARE=firmware name
* TIMEOUT=timeout value