On Tue, Feb 27, 2018 at 03:28:21PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > This reflects much clearer what is being done. > > > > Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxx> > > --- > > Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +- > > drivers/base/firmware_fallback.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > index 4055ac76b288..f353783ae0be 100644 > > --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst > > +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > @@ -112,7 +112,7 @@ Since a device is created for the sysfs interface to help load firmware as a > > fallback mechanism userspace can be informed of the addition of the device by > > relying on kobject uevents. The addition of the device into the device > > hierarchy means the fallback mechanism for firmware loading has been initiated. > > -For details of implementation refer to _request_firmware_load(), in particular > > +For details of implementation refer to fw_load_sysfs_fallback(), in particular > > on the use of dev_set_uevent_suppress() and kobject_uevent(). > > > > The kernel's kobject uevent mechanism is implemented in lib/kobject_uevent.c, > > diff --git a/drivers/base/firmware_fallback.c b/drivers/base/firmware_fallback.c > > index 13fa5ff2b46c..ce7ccfe82c69 100644 > > --- a/drivers/base/firmware_fallback.c > > +++ b/drivers/base/firmware_fallback.c > > @@ -536,7 +536,7 @@ fw_create_instance(struct firmware *firmware, const char *fw_name, > > } > > > > /* load a firmware via user helper */ > > As long as this is being renamed, maybe add full kern-doc for this function? Sure why not. Luis
