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>
21 lines
918 B
ReStructuredText
21 lines
918 B
ReStructuredText
=====================
|
|
Firmware lookup order
|
|
=====================
|
|
|
|
Different functionality is available to enable firmware to be found.
|
|
Below is chronological order of how firmware will be looked for once
|
|
a driver issues a firmware API call.
|
|
|
|
* The ''Built-in firmware'' is checked first, if the firmware is present we
|
|
return it immediately
|
|
* The ''Firmware cache'' is looked at next. If the firmware is found we
|
|
return it immediately
|
|
* The ''Direct filesystem lookup'' is performed next, if found we
|
|
return it immediately
|
|
* The ''Platform firmware fallback'' is performed next, but only when
|
|
firmware_request_platform() is used, if found we return it immediately
|
|
* If no firmware has been found and the fallback mechanism was enabled
|
|
the sysfs interface is created. After this either a kobject uevent
|
|
is issued or the custom firmware loading is relied upon for firmware
|
|
loading up to the timeout value.
|