path: root/Documentation
diff options
authorLinus Torvalds <torvalds@linux-foundation.org>2017-09-10 21:19:06 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2017-09-10 21:19:06 -0700
commitf007cad159e99fa2acd3b2e9364fbb32ad28b971 (patch)
tree3347b090b27c27082414070a9cbf08a7bb75cbc6 /Documentation
parent64414e5f9896805c2e80583345e9b1745be73aa9 (diff)
Revert "firmware: add sanity check on shutdown/suspend"
This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce. 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>
Diffstat (limited to 'Documentation')
1 files changed, 0 insertions, 11 deletions
diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst
index 1c2c4967cd43..cc0aea880824 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -44,17 +44,6 @@ request_firmware_nowait
.. kernel-doc:: drivers/base/firmware_class.c
:functions: request_firmware_nowait
-Considerations for suspend and resume
-During suspend and resume only the built-in firmware and the firmware cache
-elements of the firmware API can be used. This is managed by fw_pm_notify().
-.. kernel-doc:: drivers/base/firmware_class.c
- :functions: fw_pm_notify
request firmware API expected driver use