e4c2c0ff00
In some cases the platform's main firmware (e.g. the UEFI fw) may contain an embedded copy of device firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds a new platform fallback mechanism to the firmware loader which will try to lookup a device fw copy embedded in the platform's main firmware if direct filesystem lookup fails. Drivers which need such embedded fw copies can enable this fallback mechanism by using the new firmware_request_platform() function. Note that for now this is only supported on EFI platforms and even on these platforms firmware_fallback_platform() only works if CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers which need this), in all other cases firmware_fallback_platform() simply always returns -ENOENT. Reported-by: Dave Olsthoorn <dave@bewaar.me> Suggested-by: Peter Jones <pjones@redhat.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
81 lines
2.7 KiB
ReStructuredText
81 lines
2.7 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_loader/main.c
|
|
:functions: request_firmware
|
|
|
|
firmware_request_nowarn
|
|
-----------------------
|
|
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
|
:functions: firmware_request_nowarn
|
|
|
|
firmware_request_platform
|
|
-------------------------
|
|
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
|
:functions: firmware_request_platform
|
|
|
|
request_firmware_direct
|
|
-----------------------
|
|
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
|
:functions: request_firmware_direct
|
|
|
|
request_firmware_into_buf
|
|
-------------------------
|
|
.. kernel-doc:: drivers/base/firmware_loader/main.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_loader/main.c
|
|
:functions: request_firmware_nowait
|
|
|
|
Special optimizations on reboot
|
|
===============================
|
|
|
|
Some devices have an optimization in place to enable the firmware to be
|
|
retained during system reboot. When such optimizations are used the driver
|
|
author must ensure the firmware is still available on resume from suspend,
|
|
this can be done with firmware_request_cache() instead of requesting for the
|
|
firmware to be loaded.
|
|
|
|
firmware_request_cache()
|
|
------------------------
|
|
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
|
:functions: firmware_request_cache
|
|
|
|
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.
|