Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

2018-02-27 Thread Luis R. Rodriguez
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  wrote:
> > This reflects much clearer what is being done.
> >
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  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


Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

2018-02-27 Thread Kees Cook
On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez  wrote:
> This reflects much clearer what is being done.
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  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?

-Kees

> -static int _request_firmware_load(struct fw_sysfs *fw_sysfs,
> +static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
>   unsigned int opt_flags, long timeout)
>  {
> int retval = 0;
> @@ -621,7 +621,7 @@ static int fw_load_from_user_helper(struct firmware 
> *firmware,
> }
>
> fw_sysfs->fw_priv = firmware->priv;
> -   ret = _request_firmware_load(fw_sysfs, opt_flags, timeout);
> +   ret = fw_load_sysfs_fallback(fw_sysfs, opt_flags, timeout);
>
> if (!ret)
> ret = assign_fw(firmware, device, opt_flags);
> --
> 2.16.2
>



-- 
Kees Cook
Pixel Security


[RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

2018-02-27 Thread Luis R. Rodriguez
This reflects much clearer what is being done.

Signed-off-by: Luis R. Rodriguez 
---
 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 */
-static int _request_firmware_load(struct fw_sysfs *fw_sysfs,
+static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
  unsigned int opt_flags, long timeout)
 {
int retval = 0;
@@ -621,7 +621,7 @@ static int fw_load_from_user_helper(struct firmware 
*firmware,
}
 
fw_sysfs->fw_priv = firmware->priv;
-   ret = _request_firmware_load(fw_sysfs, opt_flags, timeout);
+   ret = fw_load_sysfs_fallback(fw_sysfs, opt_flags, timeout);
 
if (!ret)
ret = assign_fw(firmware, device, opt_flags);
-- 
2.16.2