From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: tiwai@suse.de, chunkeey@googlemail.com, leedom@chelsio.com,
cocci@systeme.lip6.fr
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, "Luis R. Rodriguez" <mcgrof@suse.com>
Subject: [PATCH 0/3] drivers: expand usage of request_firmware_direct()
Date: Tue, 24 Jun 2014 15:39:40 -0700 [thread overview]
Message-ID: <1403649583-12707-1-git-send-email-mcgrof@do-not-panic.com> (raw)
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Takashi added request_firmware_direct() via bba3a87e9 through v3.14-rc1
which avoids the unnecessary delay introduced by using the udev firmware
loader in case the first try failed when loading we know loading "firmware"
is optional. The first use case was for microcode update but if drivers are
using it for optional configuration updates, custom EEPROMs, and other
junk other than firmware that should apply as well as good use cases,
specially if the driver already had a first phase in which it loaded
the first required firmware. While reviewing one driver I figured it'd
be best to try to give formalizing a check with SmPL. This isn't perfect
it had 1 false possitive drivers/fmc/fmc-fakedev.c on the entire kernel
run but my hope is this can be extended a bit more to build more
confidence, and then perhaps stuff it as a coccicheck.
I suppose this will not be required once and if we remove
CONFIG_FW_LOADER_USER_HELPER. Is that ever going away for good? I know
there was a recent attempt to remove the udev loader support but
it was unclear if the special alternative helper support would be
removed upstream from the kernel.
@ firmware_not_critical @
expression cf;
expression config_file;
expression dev;
int ret;
identifier l;
statement S;
@@
- ret = request_firmware(&cf, config_file, dev);
+ ret = request_firmware_direct(&cf, config_file, dev);
if (ret < 0) {
... when != goto l;
when != return ret;
when any
} else {
...
release_firmware(cf);
...
}
Luis R. Rodriguez (3):
mmc: vub300: use request_firmware_direct() for pseudo code
cxgb4: make configuration load use request_firmware_direct()
p54: use request_firmware_direct() for optional EEPROM override
drivers/mmc/host/vub300.c | 5 +++--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
--
2.0.0
next reply other threads:[~2014-06-24 22:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 22:39 Luis R. Rodriguez [this message]
2014-06-24 22:39 ` [PATCH 1/3] mmc: vub300: use request_firmware_direct() for pseudo code Luis R. Rodriguez
2014-06-24 22:39 ` [PATCH 2/3] cxgb4: make configuration load use request_firmware_direct() Luis R. Rodriguez
2014-06-24 22:54 ` Casey Leedom
2014-06-25 1:50 ` Luis R. Rodriguez
2014-06-25 17:12 ` Casey Leedom
2014-06-25 17:31 ` Luis R. Rodriguez
2014-06-25 18:58 ` Casey Leedom
2014-06-25 20:05 ` Luis R. Rodriguez
2014-06-24 22:39 ` [PATCH 3/3] p54: use request_firmware_direct() for optional EEPROM override Luis R. Rodriguez
2014-06-25 1:10 ` [RESEND][PATCH " Christian Lamparter
2014-06-25 7:26 ` [PATCH " Arend van Spriel
2014-06-25 8:06 ` Luis R. Rodriguez
2014-06-26 16:18 ` [PATCH 0/3] drivers: expand usage of request_firmware_direct() Takashi Iwai
2014-06-26 19:21 ` Greg KH
2014-07-08 22:25 ` Greg KH
2014-07-08 23:52 ` Luis R. Rodriguez
2014-07-09 0:24 ` Greg KH
2014-07-09 0:46 ` Luis R. Rodriguez
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=1403649583-12707-1-git-send-email-mcgrof@do-not-panic.com \
--to=mcgrof@do-not-panic.com \
--cc=chunkeey@googlemail.com \
--cc=cocci@systeme.lip6.fr \
--cc=gregkh@linuxfoundation.org \
--cc=leedom@chelsio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=netdev@vger.kernel.org \
--cc=tiwai@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).