From: Prarit Bhargava <prarit@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, Ming Lei <ming.lei@canonical.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
x86@kernel.org, amd64-microcode@amd64.org
Subject: Re: [PATCH v2 1/3] firmware: Introduce request_firmware_direct()
Date: Mon, 11 Nov 2013 15:05:36 -0500 [thread overview]
Message-ID: <52813890.8020506@redhat.com> (raw)
In-Reply-To: <s5heh6mx2vz.wl%tiwai@suse.de>
On 11/11/2013 12:30 PM, Takashi Iwai wrote:
> At Mon, 11 Nov 2013 16:34:26 +0100,
> Borislav Petkov wrote:
>>
>> On Mon, Nov 11, 2013 at 04:21:16PM +0100, Takashi Iwai wrote:
>>> When CONFIG_FW_LOADER_USER_HELPER is set, request_firmware() falls
>>> back to the usermode helper for loading via udev when the direct
>>> loading fails. But the recent udev takes way too long timeout (60
>>> seconds) for non-existing firmware. This is unacceptable for the
>>> drivers like microcode loader where they load firmwares optionally,
>>> i.e. it's no error even if no requested file exists.
>>>
>>> This patch provides a new helper function, request_firmware_direct().
>>> It behaves as same as request_firmware() except for that it doesn't
>>> fall back to usermode helper but returns an error immediately if the
>>> f/w can't be loaded directly in kernel.
>>>
>>> Without CONFIG_FW_LOADER_USER_HELPER=y, request_firmware_direct() is
>>> just an alias of request_firmware(), due to obvious reason.
>>>
>>> Tested-by: Prarit Bhargava <prarit@redhat.com>
>>> Acked-by: Ming Lei <ming.lei@canonical.com>
>>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>>> ---
>>> drivers/base/firmware_class.c | 36 +++++++++++++++++++++++++++++++-----
>>> include/linux/firmware.h | 7 +++++++
>>> 2 files changed, 38 insertions(+), 5 deletions(-)
>>
>> I like it, the 60 seconds thing has been a senseless PITA for no good
>> reason. I have always wondered what might change in 60 seconds wrt to us
>> being able to load the firmware...
>>
>>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>>> index eb8fb94ae2c5..7f48a6ffb0df 100644
>>> --- a/drivers/base/firmware_class.c
>>> +++ b/drivers/base/firmware_class.c
>>> @@ -1061,7 +1061,7 @@ static int assign_firmware_buf(struct firmware *fw, struct device *device,
>>> /* called from request_firmware() and request_firmware_work_func() */
>>> static int
>>> _request_firmware(const struct firmware **firmware_p, const char *name,
>>> - struct device *device, bool uevent, bool nowait)
>>> + struct device *device, bool uevent, bool nowait, bool fallback)
>>
>> Just a nitpick: three boolean args in a row starts to slowly look like a
>> function from the windoze API. Can we do:
>>
>> _request_firmware(..., unsigned long flags)
>>
>> instead and have nice bit flags for that?
>
> Sounds like a good idea. How about the patch below?
> (I used unsigned int since there shouldn't be so many different
> behaviors.)
>
>
> thanks,
>
> Takashi
>
> ===
>
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] firmware: Use bit flags instead of boolean combos
>
> More than two boolean arguments to a function are rather confusing and
> error-prone for callers. Let's make the behavior bit flags instead of
> triple combos.
>
> A nice suggestion by Borislav Petkov.
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sure -- looks good.
Acked-by: Prarit Bhargava <prarit@redhat.com>
P.
next prev parent reply other threads:[~2013-11-11 20:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 15:21 [PATCH v2 0/3] Add request_firmware_direct() for microcode loader Takashi Iwai
2013-11-11 15:21 ` [PATCH v2 1/3] firmware: Introduce request_firmware_direct() Takashi Iwai
2013-11-11 15:34 ` Borislav Petkov
2013-11-11 17:30 ` Takashi Iwai
2013-11-11 19:47 ` Borislav Petkov
2013-11-11 20:05 ` Prarit Bhargava [this message]
2013-11-12 2:11 ` Ming Lei
2013-11-11 15:21 ` [PATCH v2 2/3] microcode: Use request_firmware_direct() Takashi Iwai
2013-11-11 15:21 ` [PATCH v2 3/3] firmware: Avoid bogus fallback warning Takashi Iwai
2013-11-12 1:40 ` Ming Lei
2013-11-12 6:26 ` Takashi Iwai
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=52813890.8020506@redhat.com \
--to=prarit@redhat.com \
--cc=amd64-microcode@amd64.org \
--cc=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=tiwai@suse.de \
--cc=x86@kernel.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.