linux-toradex.git/Documentation/driver-api/firmware/request_firmware.rst, branch v5.0

firmware: add firmware_request_nowarn() - load firmware without warnings

2018-05-14T14:44:41+00:00

Currently the firmware loader only exposes one silent path for querying
optional firmware, and that is firmware_request_direct(). This function
also disables the sysfs fallback mechanism, which might not always be the
desired behaviour [0].

This patch introduces a variations of request_firmware() that enable the
caller to disable the undesired warning messages but enables the sysfs
fallback mechanism. This is equivalent to adding FW_OPT_NO_WARN to the
old behaviour.

[0]: https://git.kernel.org/linus/c0cc00f250e1

Signed-off-by: Andres Rodriguez 
Reviewed-by: Kees Cook 
Acked-by: Luis R. Rodriguez 
[mcgrof: used the old API calls as the full rename is not done yet, and
 add the caller for when FW_LOADER is disabled, enhance documentation ]
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

firmware: some documentation fixes

2018-04-25T16:37:20+00:00

Including:
 - Fixup outdated kernel-doc paths
 - Slightly too short title underline
 - Some typos

Signed-off-by: Andres Rodriguez 
Signed-off-by: Greg Kroah-Hartman

firmware: Fix firmware documentation for recent file renames

2018-04-23T11:03:26+00:00

firmware_class.c was split into several files under
drivers/base/firmware_loader. The new main.c has the functions which
/request_firmware.rst references.

Acked-by: Luis R. Rodriguez 
Signed-off-by: Hans de Goede 
Tested-by: Randy Dunlap 
Signed-off-by: Greg Kroah-Hartman

firmware: add firmware_request_cache() to help with cache on reboot

2018-03-22T17:33:26+00:00

Some devices have an optimization in place to enable the firmware to
be retaineed during a system reboot, so after reboot the device can skip
requesting and loading the firmware. This can save up to 1s in load
time. The mt7601u 802.11 device happens to be such a device.

When these devices retain the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

Revert "firmware: add sanity check on shutdown/suspend"

2017-09-11T04:19:06+00:00

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 
Pointed-at-by: Greg Kroah-Hartman 
Tested-by: Gabriel C 
Cc: Luis R. Rodriguez 
Signed-off-by: Linus Torvalds

firmware: add sanity check on shutdown/suspend

2017-06-03T10:15:49+00:00

The firmware API should not be used after we go to suspend
and after we reboot/halt. The suspend/resume case is a bit
complex, so this documents that so things are clearer.

We want to know about users of the API in incorrect places so
that their callers are corrected, so this also adds a warn
for those cases.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

firmware: revamp firmware documentation

2017-01-11T08:42:59+00:00

Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.

v2: typos and small fixes

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman