All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-kernel@vger.kernel.org, Prarit Bhargava <prarit@redhat.com>,
	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 16:34:26 +0100	[thread overview]
Message-ID: <20131111153426.GA6630@pd.tnic> (raw)
In-Reply-To: <1384183278-19787-2-git-send-email-tiwai@suse.de>

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?

That could be a nice cleanup ontop though. Other than that:

Acked-by: Borislav Petkov <bp@suse.de>

for all three.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2013-11-11 15:34 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 [this message]
2013-11-11 17:30     ` Takashi Iwai
2013-11-11 19:47       ` Borislav Petkov
2013-11-11 20:05       ` Prarit Bhargava
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=20131111153426.GA6630@pd.tnic \
    --to=bp@alien8.de \
    --cc=amd64-microcode@amd64.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=prarit@redhat.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.