All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Andres Rodriguez <andresx7@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Alex Deucher <alexdeucher@gmail.com>,
	ckoenig.leichtzumerken@gmail.com,
	Kalle Valo <kvalo@codeaurora.org>,
	Arend van Spriel <arend.vanspriel@broadcom.com>
Subject: Re: [PATCH 5/9] firmware: add functions to load firmware without warnings v4
Date: Sat, 21 Apr 2018 08:11:04 -0700	[thread overview]
Message-ID: <CAGXu5jKVv8R1yVcuCCPJb1YD9u8tiZyj86wdz043PKxKPZj4Lg@mail.gmail.com> (raw)
In-Reply-To: <20180421144911.GV14440@wotan.suse.de>

On Sat, Apr 21, 2018 at 7:49 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Sat, Apr 21, 2018 at 04:32:06PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Apr 17, 2018 at 11:33:03AM -0400, Andres Rodriguez wrote:
>> > @@ -755,10 +779,11 @@ static void firmware_request_work_func(struct work_struct *work)
>> >  }
>> >
>> >  /**
>> > - * firmware_request_nowait() - asynchronous version of firmware_request
>> > + * firmware_request_nowait2() - asynchronous version of firmware_request
>> >   * @module: module requesting the firmware
>> >   * @uevent: sends uevent to copy the firmware image if this flag
>> >   * is non-zero else the firmware copy must be done manually.
>> > + * @warn: enable warnings
>> >   * @name: name of firmware file
>> >   * @device: device for which firmware is being loaded
>> >   * @gfp: allocation flags
>> > @@ -778,8 +803,8 @@ static void firmware_request_work_func(struct work_struct *work)
>> >   *         - can't sleep at all if @gfp is GFP_ATOMIC.
>> >   **/
>> >  int
>> > -firmware_request_nowait(
>> > -   struct module *module, bool uevent,
>> > +firmware_request_nowait2(
>> > +   struct module *module, bool uevent, bool warn,
>> >     const char *name, struct device *device, gfp_t gfp, void *context,
>> >     void (*cont)(const struct firmware *fw, void *context))
>> >  {
>> > @@ -799,7 +824,8 @@ firmware_request_nowait(
>> >     fw_work->context = context;
>> >     fw_work->cont = cont;
>> >     fw_work->opt_flags = FW_OPT_NOWAIT |
>> > -           (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
>> > +           (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER) |
>> > +           (warn ? 0 : FW_OPT_NO_WARN);
>> >
>> >     if (!uevent && fw_cache_is_setup(device, name)) {
>> >             kfree_const(fw_work->name);
>> > @@ -818,6 +844,24 @@ firmware_request_nowait(
>> >     schedule_work(&fw_work->work);
>> >     return 0;
>> >  }
>> > +EXPORT_SYMBOL_GPL(firmware_request_nowait2);
>> > +
>> > +/**
>> > + * firmware_request_nowait() - compatibility version of firmware_request_nowait2
>> > + *
>> > + * This is equivalent to calling firmware_request_nowait2 with warnings enabled.
>> > + *
>> > + * Refer to firmware_request_nowait2 for further details.
>> > + **/
>> > +int
>> > +firmware_request_nowait(
>> > +   struct module *module, bool uevent,
>> > +   const char *name, struct device *device, gfp_t gfp, void *context,
>> > +   void (*cont)(const struct firmware *fw, void *context))
>> > +{
>> > +   return firmware_request_nowait2(module, uevent, true, name, device,
>> > +                                   gfp, context, cont);
>> > +}
>> >  EXPORT_SYMBOL(firmware_request_nowait);
>> >
>> >  #ifdef CONFIG_PM_SLEEP
>>
>> Ugh this is precisely the type of naming issue I predicted *years ago*
>> about the unflexibility of the naming scheme we used. Greg, since you had
>> sent us this rabbit hole, any name preference here? Please review what is
>> proposed and also suggest a scheme which you do prefer. I'm done with
>> the bikeshedding and just want to move on, but in a way that scales.
>
> I'll side for now with Kalle's suggestion of having:
>
> firmware_request_nowait_nowarn()
>
> as nasty as it may seem. And this is just because we embarked on
> the path to not have parameters passed to modify the calls site.

What was the objection to using parameters for this? i.e. something
like the gfp flags, but have a behavior flag FW_RQ_NOWAIT,
FW_RQ_NOWARN, etc?

-Kees

-- 
Kees Cook
Pixel Security

  reply	other threads:[~2018-04-21 15:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-17 15:32 [PATCH 0/9] Loading optional firmware v3 Andres Rodriguez
2018-04-17 15:32 ` [PATCH 1/9] firmware: some documentation fixes Andres Rodriguez
2018-04-17 20:59   ` Randy Dunlap
2018-04-17 15:33 ` [PATCH 2/9] firmware: wrap FW_OPT_* into an enum Andres Rodriguez
2018-04-21 13:57   ` Luis R. Rodriguez
2018-04-17 15:33 ` [PATCH 3/9] firmware: add kernel-doc for enum fw_opt Andres Rodriguez
2018-04-21 14:26   ` Luis R. Rodriguez
2018-04-17 15:33 ` [PATCH 4/9] firmware: use () to terminate kernel-doc function names Andres Rodriguez
2018-04-17 20:56   ` Randy Dunlap
2018-04-17 15:33 ` [PATCH 5/9] firmware: add functions to load firmware without warnings v4 Andres Rodriguez
2018-04-20 10:28   ` Kalle Valo
2018-04-21 14:32   ` Luis R. Rodriguez
2018-04-21 14:49     ` Luis R. Rodriguez
2018-04-21 15:11       ` Kees Cook [this message]
2018-04-21 15:32         ` Linus Torvalds
2018-04-21 17:36           ` Luis R. Rodriguez
2018-04-22 20:26             ` Luis R. Rodriguez
2018-04-17 15:33 ` [PATCH 6/9] firmware: print firmware name on fallback path Andres Rodriguez
2018-04-17 15:33 ` [PATCH 7/9] drm/amdgpu: use firmware_request_nowarn to load firmware Andres Rodriguez
2018-04-17 15:33 ` [PATCH 8/9] ath10k: use request_firmware_nowarn " Andres Rodriguez
2018-04-20 10:19   ` Kalle Valo
2018-04-20 10:19     ` Kalle Valo
2018-04-20 10:19     ` Kalle Valo
2018-04-17 15:33 ` [PATCH 9/9] brcmfmac: use request_firmware_nowait2 to load firmware without warnings Andres Rodriguez
2018-04-20 10:26   ` Kalle Valo
2018-04-20 10:26     ` Kalle Valo
2018-04-20 19:33     ` Andres Rodriguez
2018-04-21  7:19       ` Kalle Valo
2018-04-21  7:19         ` Kalle Valo
2018-04-21  8:04     ` Arend van Spriel
2018-04-23 13:54       ` Kalle Valo
2018-04-23 13:54         ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGXu5jKVv8R1yVcuCCPJb1YD9u8tiZyj86wdz043PKxKPZj4Lg@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=alexdeucher@gmail.com \
    --cc=andresx7@gmail.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.