From: Takashi Iwai <tiwai@suse.de>
To: Tom Gundersen <teg@jklm.no>
Cc: linux-kernel@vger.kernel.org, Ming Lei <ming.lei@canonical.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Abhay Salunke <Abhay_Salunke@dell.com>, Stefan Roese <sr@denx.de>,
Arnd Bergmann <arnd@arndb.de>, Kay Sievers <kay@vrfy.org>
Subject: Re: [PATCH] firmware loader: allow disabling of udev as firmware loader
Date: Wed, 04 Jun 2014 16:20:16 +0200 [thread overview]
Message-ID: <s5hr43421un.wl%tiwai@suse.de> (raw)
In-Reply-To: <1401733474-1767-1-git-send-email-teg@jklm.no>
At Mon, 2 Jun 2014 20:24:34 +0200,
Tom Gundersen wrote:
>
> Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER,
> which means that distros can't really stop loading firmware through udev
> without breaking other users (though some have).
>
> Ideally we would remove/disable the udev firmware helper in both the kernel
> and in udev, but if we were to disable it in udev and not the kernel, the result
> would be (seemingly) hung kernels as no one would be around to cancel firmware
> requests.
>
> This patch allows udev firmware loading to be disabled while still allowing
> non-udev firmware loading, as done by the dell-rbu driver, to continue
> working. This is achieved by only using the fallback mechanism when the
> uevent is suppressed.
>
> Tested with
> FW_LOADER_USER_HELPER=n
> LATTICE_ECP3_CONFIG=y
> DELL_RBU=y
> and udev without the firmware loading support, but I don't have the hardware
> to test the lattice/dell drivers, so additional testing would be appreciated.
The logic of this patch looks good to me, but the Kconfig items become
confusing by this. Basically what we'd need is a Kconfig item
deciding whether to build the user helper or not, in addition to a
Kconfig item for deciding the fallback mode of request_firmware().
What about the patch like below instead? It's smaller and the meaning
of Kconfig items are clearer. (In the final form, the help text
change you added should be included there, too.)
The only (and biggest) drawback is, however, that the user-selectable
Kconfig would be actually renamed from CONFIG_FW_LOADER_USER_HELPER to
CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
thanks,
Takashi
---
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 8fa8deab6449..195b08f49209 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -144,8 +144,12 @@ config EXTRA_FIRMWARE_DIR
some other directory containing the firmware files.
config FW_LOADER_USER_HELPER
+ bool
+
+config FW_LOADER_USER_HELPER_FALLBACK
bool "Fallback user-helper invocation for firmware loading"
depends on FW_LOADER
+ select FW_LOADER_USER_HELPER
default y
help
This option enables / disables the invocation of user-helper
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index d276e33880be..e98fd78c5c40 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -100,9 +100,14 @@ static inline long firmware_loading_timeout(void)
#define FW_OPT_UEVENT (1U << 0)
#define FW_OPT_NOWAIT (1U << 1)
#ifdef CONFIG_FW_LOADER_USER_HELPER
-#define FW_OPT_FALLBACK (1U << 2)
+#define FW_OPT_USERHELPER (1U << 2)
#else
-#define FW_OPT_FALLBACK 0
+#define FW_OPT_USERHELPER 0
+#endif
+#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
+#define FW_OPT_FALLBACK FW_OPT_USERHELPER
+#else
+#define FW_OPT_FALLBACK 0
#endif
struct firmware_cache {
@@ -1111,7 +1116,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
- if (opt_flags & FW_OPT_FALLBACK) {
+ if (opt_flags & FW_OPT_USERHELPER) {
dev_warn(device,
"Direct firmware load failed with error %d\n",
ret);
@@ -1277,7 +1282,7 @@ request_firmware_nowait(
fw_work->context = context;
fw_work->cont = cont;
fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
- (uevent ? FW_OPT_UEVENT : 0);
+ (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
if (!try_module_get(module)) {
kfree(fw_work);
next prev parent reply other threads:[~2014-06-04 14:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 18:24 Tom Gundersen
2014-06-04 14:20 ` Takashi Iwai [this message]
2014-06-04 14:31 ` Takashi Iwai
2014-06-04 14:35 ` Tom Gundersen
2014-06-04 14:34 ` Tom Gundersen
2014-06-09 13:44 B_B_Singh
[not found] <8B2F6FFD0BD1E448853114367400A37306FCD2E023@BLRX7MCDC203.AMER.DELL.COM>
2014-06-09 13:53 ` Tom Gundersen
2014-06-09 14:01 ` B_B_Singh
2014-06-09 15:50 ` Tom Gundersen
2014-06-10 15:13 ` B_B_Singh
2014-06-16 14:27 ` Tom Gundersen
2014-06-16 14:08 ` B_B_Singh
2014-06-16 14:28 ` Tom Gundersen
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=s5hr43421un.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=Abhay_Salunke@dell.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=sr@denx.de \
--cc=teg@jklm.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®