Messages in this thread | | | Subject | Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module | From | Andres Rodriguez <> | Date | Tue, 8 May 2018 14:53:39 -0400 |
| |
On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote: > 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 <mcgrof@kernel.org> > --- > .../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
Just a tiny repeated word here, "which which".
-Andres
> +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: >
| |