user/sven/linux.git/Documentation/driver-api/firmware, branch v5.7

Merge branch 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-03-30T23:13:08Z

Pull EFI updates from Ingo Molnar: "The EFI changes in this cycle are much larger than usual, for two (positive) reasons: - The GRUB project is showing signs of life again, resulting in the introduction of the generic Linux/UEFI boot protocol, instead of x86 specific hacks which are increasingly difficult to maintain. There's hope that all future extensions will now go through that boot protocol. - Preparatory work for RISC-V EFI support. The main changes are: - Boot time GDT handling changes - Simplify handling of EFI properties table on arm64 - Generic EFI stub cleanups, to improve command line handling, file I/O, memory allocation, etc. - Introduce a generic initrd loading method based on calling back into the firmware, instead of relying on the x86 EFI handover protocol or device tree. - Introduce a mixed mode boot method that does not rely on the x86 EFI handover protocol either, and could potentially be adopted by other architectures (if another one ever surfaces where one execution mode is a superset of another) - Clean up the contents of 'struct efi', and move out everything that doesn't need to be stored there. - Incorporate support for UEFI spec v2.8A changes that permit firmware implementations to return EFI_UNSUPPORTED from UEFI runtime services at OS runtime, and expose a mask of which ones are supported or unsupported via a configuration table. - Partial fix for the lack of by-VA cache maintenance in the decompressor on 32-bit ARM. - Changes to load device firmware from EFI boot service memory regions - Various documentation updates and minor code cleanups and fixes" * 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits) efi/libstub/arm: Fix spurious message that an initrd was loaded efi/libstub/arm64: Avoid image_base value from efi_loaded_image partitions/efi: Fix partition name parsing in GUID partition entry efi/x86: Fix cast of image argument efi/libstub/x86: Use ULONG_MAX as upper bound for all allocations efi: Fix a mistype in comments mentioning efivar_entry_iter_begin() efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinux efi/x86: Preserve %ebx correctly in efi_set_virtual_address_map() efi/x86: Ignore the memory attributes table on i386 efi/x86: Don't relocate the kernel unless necessary efi/x86: Remove extra headroom for setup block efi/x86: Add kernel preferred address to PE header efi/x86: Decompress at start of PE image load address x86/boot/compressed/32: Save the output address instead of recalculating it efi/libstub/x86: Deal with exit() boot service returning x86/boot: Use unsigned comparison for addresses efi/x86: Avoid using code32_start efi/x86: Make efi32_pe_entry() more readable efi/x86: Respect 32-bit ABI in efi32_pe_entry() efi/x86: Annotate the LOADED_IMAGE_PROTOCOL_GUID with SYM_DATA ...

firmware: Add new platform fallback mechanism and firmware_request_platform()

2020-03-20T13:54:04Z

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 Suggested-by: Peter Jones Acked-by: Luis Chamberlain Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

efi/libstub: Add libstub/mem.c to the documentation tree

2020-03-08T08:58:13Z

Let the description of the efi/libstub/mem.c functions appear in the kernel API documentation in the following chapters: The Linux driver implementer’s API guide Linux Firmware API UEFI Support UEFI stub library functions Acked-by: Jonathan Corbet Signed-off-by: Heinrich Schuchardt Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200221035832.144960-1-xypron.glpk@gmx.de Link: https://lore.kernel.org/r/20200308080859.21568-9-ardb@kernel.org

docs: Fix a misdirected kerneldoc directive

2019-05-24T20:31:50Z

The stratix10 service layer documentation tried to include a kerneldoc comments for a nonexistent struct; leading to a "no structured comments found" message. Switch it to stratix10_svc_command_config_type, which appears at that spot in the sequence and was not included. Signed-off-by: Jonathan Corbet

Documentation: driver-api: add stratix10 service layer

2018-11-26T19:15:07Z

Add Intel Stratix10 service layer driver document Signed-off-by: Richard Gong Signed-off-by: Alan Tull Signed-off-by: Greg Kroah-Hartman

Documentation: update firmware loader fallback reference

2018-07-07T15:45:25Z

The firmware loader has a fallback mechanism, and it now has some proper kdoc, but we forgot to update the Documentation to use the new kdoc. Fix that. Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

Documentation: clarify firmware_class provenance and why we can't rename the module

2018-05-14T14:46:10Z

Clarify the provenance of the firmware loader firmware_class module name and why we cannot rename the module in the future. Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Kees Cook Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

Documentation: fix few typos and clarifications for the firmware loader

2018-05-14T14:44:41Z

Fix a few typos, and clarify a few sentences. Reviewed-by: Kees Cook Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

firmware: add firmware_request_nowarn() - load firmware without warnings

2018-05-14T14:44:41Z

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:20Z

Including: - Fixup outdated kernel-doc paths - Slightly too short title underline - Some typos Signed-off-by: Andres Rodriguez Signed-off-by: Greg Kroah-Hartman