forked from Minki/linux
f007cad159
This reverts commit 81f9507628.
It causes random failures of firmware loading at resume time (well,
random for me, it seems to be more reliable for others) because the
firmware disabling is not actually synchronous with any particular
resume event, and at least the btusb driver that uses a workqueue to
load the firmware at resume seems to occasionally hit the "firmware
loading is disabled" logic because the firmware loader hasn't gotten the
resume event yet.
Some kind of sanity check for not trying to load firmware when it's not
possible might be a good thing, but this commit was not it.
Greg seems to have silently suffered the same issue, and pointed to the
likely culprit, and Gabriel C verified the revert fixed it for him too.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Pointed-at-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Gabriel C <nix.or.die@gmail.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
57 lines
1.9 KiB
ReStructuredText
57 lines
1.9 KiB
ReStructuredText
====================
|
|
request_firmware API
|
|
====================
|
|
|
|
You would typically load firmware and then load it into your device somehow.
|
|
The typical firmware work flow is reflected below::
|
|
|
|
if(request_firmware(&fw_entry, $FIRMWARE, device) == 0)
|
|
copy_fw_to_device(fw_entry->data, fw_entry->size);
|
|
release_firmware(fw_entry);
|
|
|
|
Synchronous firmware requests
|
|
=============================
|
|
|
|
Synchronous firmware requests will wait until the firmware is found or until
|
|
an error is returned.
|
|
|
|
request_firmware
|
|
----------------
|
|
.. kernel-doc:: drivers/base/firmware_class.c
|
|
:functions: request_firmware
|
|
|
|
request_firmware_direct
|
|
-----------------------
|
|
.. kernel-doc:: drivers/base/firmware_class.c
|
|
:functions: request_firmware_direct
|
|
|
|
request_firmware_into_buf
|
|
-------------------------
|
|
.. kernel-doc:: drivers/base/firmware_class.c
|
|
:functions: request_firmware_into_buf
|
|
|
|
Asynchronous firmware requests
|
|
==============================
|
|
|
|
Asynchronous firmware requests allow driver code to not have to wait
|
|
until the firmware or an error is returned. Function callbacks are
|
|
provided so that when the firmware or an error is found the driver is
|
|
informed through the callback. request_firmware_nowait() cannot be called
|
|
in atomic contexts.
|
|
|
|
request_firmware_nowait
|
|
-----------------------
|
|
.. kernel-doc:: drivers/base/firmware_class.c
|
|
:functions: request_firmware_nowait
|
|
|
|
request firmware API expected driver use
|
|
========================================
|
|
|
|
Once an API call returns you process the firmware and then release the
|
|
firmware. For example if you used request_firmware() and it returns,
|
|
the driver has the firmware image accessible in fw_entry->{data,size}.
|
|
If something went wrong request_firmware() returns non-zero and fw_entry
|
|
is set to NULL. Once your driver is done with processing the firmware it
|
|
can call call release_firmware(fw_entry) to release the firmware image
|
|
and any related resource.
|