aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2024-07-09Merge tag 'ti-driver-soc-for-v6.11' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers TI SoC driver updates for v6.11 - Update TISCI protocol URL link which was dead - socinfo: Add j721E SR 2.0 detection support - MAINTAINER list additions: ti,pruss.yaml and ti,j721e-system-controller.yaml - pm33xx: log statement improvement - knav_qmss: minor data structure optimization * tag 'ti-driver-soc-for-v6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: dt-bindings: soc: ti: Move ti,j721e-system-controller.yaml to soc/ti MAINTAINERS: Add entry for ti,pruss.yaml to TI KEYSTONE MULTICORE NAVIGATOR DRIVERS soc: ti: k3-socinfo: Add J721E SR2.0 soc: ti: knav_qmss: Constify struct knav_range_ops firmware: ti_sci: fix TISCI protocol URL link dt-bindings: ti: fix TISCI protocol URL link soc: ti: pm33xx: Fix missing newlines in log statements Link: https://lore.kernel.org/r/20240705151449.s4rngkehjn73favn@stream Signed-off-by: Arnd Bergmann <[email protected]>
2024-07-09Merge tag 'riscv-firmware-for-v6.11' of ↵Arnd Bergmann1-69/+67
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/drivers RISC-V firmware drivers for v6.11 Microchip: Support for writing "bitstream info" to the flash using the auto-update driver. At this point the "bitstream info" is a glorified dtbo wrapper, but there's plans to add more info there in the future. Additionally, rework some allocations in the driver and use scope-based cleanup on them. Signed-off-by: Conor Dooley <[email protected]> * tag 'riscv-firmware-for-v6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: use scope-based cleanup where possible firmware: microchip: move buffer allocation into mpfs_auto_update_set_image_address() firmware: microchip: support writing bitstream info to flash Link: https://lore.kernel.org/r/20240707-lukewarm-film-8a9da40a1c27@spud Signed-off-by: Arnd Bergmann <[email protected]>
2024-07-08firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw filesRichard Fitzgerald1-2/+2
Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-08x86/efistub: Drop redundant clearing of BSSArd Biesheuvel1-3/+0
As it turns out, clearing the BSS was not the right fix for the issue that was ultimately fixed by commit decd347c2a75 ("x86/efistub: Reinstate soft limit for initrd loading"), and given that the Windows EFI loader becomes very unhappy when entered with garbage in BSS, this is one thing that x86 PC EFI implementations can be expected to get right. So drop it from the pure PE entrypoint. The handover protocol entrypoint still needs this - it is used by the flaky distro bootloaders that barely implement PE/COFF at all. Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-08x86/efistub: Avoid returning EFI_SUCCESS on errorArd Biesheuvel1-4/+1
The fail label is only used in a situation where the previous EFI API call succeeded, and so status will be set to EFI_SUCCESS. Fix this, by dropping the goto entirely, and call efi_exit() with the correct error code. Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-08x86/efistub: Call Apple set_os protocol on dual GPU Intel MacsAditya Garg1-3/+68
0c18184de990 ("platform/x86: apple-gmux: support MMIO gmux on T2 Macs") brought support for T2 Macs in apple-gmux. But in order to use dual GPU, the integrated GPU has to be enabled. On such dual GPU EFI Macs, the EFI stub needs to report that it is booting macOS in order to prevent the firmware from disabling the iGPU. This patch is also applicable for some non T2 Intel Macs. Based on this patch for GRUB by Andreas Heider <[email protected]>: https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html Credits also goto Kerem Karabay <[email protected]> for helping porting the patch to the Linux kernel. Cc: Orlando Chamberlain <[email protected]> Signed-off-by: Aditya Garg <[email protected]> [ardb: limit scope using list of DMI matches provided by Lukas and Orlando] Reviewed-by: Lukas Wunner <[email protected]> Tested-by: Aditya Garg <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-08x86/efistub: Enable SMBIOS protocol handling for x86Ard Biesheuvel2-15/+26
The smbios.c source file is not currently included in the x86 build, and before we can do so, it needs some tweaks to build correctly in combination with the EFI mixed mode support. Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-06firmware: qcom: tzmem: blacklist more platforms for SHM BridgeDmitry Baryshkov1-0/+2
The SHM bridge makes the Qualcomm RB3 and SM8150-HDK reset while probing the RMTFS (in qcom_scm_assign_mem()). Blacklist the SHM Bridge on corresponding platforms using SoC-level compat string. If later it's found that the bad behaviour is limited just to the particular boards rather than SoC, the compat strings can be adjusted. Reported-by: Neil Armstrong <[email protected]> Fixes: f86c61498a57 ("firmware: qcom: tzmem: enable SHM Bridge support") Signed-off-by: Dmitry Baryshkov <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Tested-by: Neil Armstrong <[email protected]> # on Qualcomm RB3 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-07-06firmware: qcom: tzmem: simplify returning pointer without cleanupKrzysztof Kozlowski1-1/+1
Use 'return_ptr' helper for returning a pointer without cleanup for shorter code. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-07-04Merge tag 'drm-misc-fixes-2024-07-04' of ↵Daniel Vetter1-4/+8
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.10-rc7: - Add panel quirks. - Firmware sysfb refcount fix. - Another null pointer mode deref fix for nouveau. - Panthor sync and uobj fixes. - Fix fbdev regression since v6.7. - Delay free imported bo in ttm to fix lockdep splat. Signed-off-by: Daniel Vetter <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-03driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman3-7/+7
In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <[email protected]> Reviewed-by: Alex Elder <[email protected]> Acked-by: Sumit Garg <[email protected]> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-07-02firmware: cs_dsp: Don't allow writes to read-only controlsRichard Fitzgerald1-0/+3
Add a check to cs_dsp_coeff_write_ctrl() to abort if the control is not writeable. The cs_dsp code originated as an ASoC driver (wm_adsp) where all controls were exported as ALSA controls. It relied on ALSA to enforce the read-only permission. Now that the code has been separated from ALSA/ASoC it must perform its own permission check. This isn't currently causing any problems so there shouldn't be any need to backport this. If the client of cs_dsp exposes the control as an ALSA control, it should set permissions on that ALSA control to protect it. The few uses of cs_dsp_coeff_write_ctrl() inside drivers are for writable controls. Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-02ARM: 9407/1: Add support for STACKLEAK gcc pluginJinjie Ruan1-1/+2
Add the STACKLEAK gcc plugin to arm32 by adding the helper used by stackleak common code: on_thread_stack(). It initialize the stack with the poison value before returning from system calls which improves the kernel security. Additionally, this disables the plugin in EFI stub code and decompress code, which are out of scope for the protection. Before the test on Qemu versatilepb board: # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT lkdtm: Performing direct entry STACKLEAK_ERASING lkdtm: XFAIL: stackleak is not supported on this arch (HAVE_ARCH_STACKLEAK=n) After: # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT lkdtm: Performing direct entry STACKLEAK_ERASING lkdtm: stackleak stack usage: high offset: 80 bytes current: 280 bytes lowest: 696 bytes tracked: 696 bytes untracked: 192 bytes poisoned: 7220 bytes low offset: 4 bytes lkdtm: OK: the rest of the thread stack is properly erased Signed-off-by: Jinjie Ruan <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
2024-07-02efistub/smbios: Simplify SMBIOS enumeration APIArd Biesheuvel3-9/+7
Update the efi_get_smbios_string() macro to take a pointer to the entire record struct rather than the header. This removes the need to pass the type explicitly, as it can be inferred from the typed pointer. Also, drop 'type' from the prototype of __efi_get_smbios_string(), as it is never referenced. Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-02x86/efi: Drop support for fake EFI memory mapsArd Biesheuvel1-1/+1
Between kexec and confidential VM support, handling the EFI memory maps correctly on x86 is already proving to be rather difficult (as opposed to other EFI architectures which manage to never modify the EFI memory map to begin with) EFI fake memory map support is essentially a development hack (for testing new support for the 'special purpose' and 'more reliable' EFI memory attributes) that leaked into production code. The regions marked in this manner are not actually recognized as such by the firmware itself or the EFI stub (and never have), and marking memory as 'more reliable' seems rather futile if the underlying memory is just ordinary RAM. Marking memory as 'special purpose' in this way is also dubious, but may be in use in production code nonetheless. However, the same should be achievable by using the memmap= command line option with the ! operator. EFI fake memmap support is not enabled by any of the major distros (Debian, Fedora, SUSE, Ubuntu) and does not exist on other architectures, so let's drop support for it. Acked-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Dan Williams <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2024-07-01Merge tag 'amlogic-drivers-for-v6.11' of ↵Arnd Bergmann1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/drivers Amlogic drivers changes for v6.11: - Add S905L & A113X SoC IDs - add missing MODULE_DESCRIPTION() macro for meson_sm driver * tag 'amlogic-drivers-for-v6.11' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: firmware: meson_sm: add missing MODULE_DESCRIPTION() macro soc: amlogic: meson-gx-socinfo: add new A113X SoC id soc: amlogic: meson-gx-socinfo: Add S905L ID Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2024-07-01firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersRichard Fitzgerald1-31/+113
Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-01firmware: cs_dsp: Validate payload length before processing blockRichard Fitzgerald1-21/+15
Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-01firmware: cs_dsp: Return error if block header overflows fileRichard Fitzgerald1-4/+14
Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-01firmware: cs_dsp: Fix overflow checking of wmfw headerRichard Fitzgerald1-7/+18
Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-06-28firmware: cs_dsp: Add write sequence interfaceJames Ogletree1-0/+278
A write sequence is a sequence of register addresses and values executed by some Cirrus DSPs following certain power state transitions. Add support for Cirrus drivers to update or add to a write sequence present in firmware. Reviewed-by: Charles Keepax <[email protected]> Signed-off-by: James Ogletree <[email protected]> Reviewed-by: Jeff LaBundy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-28firmware: sysfb: Fix reference count of sysfb parent deviceThomas Zimmermann1-4/+8
Retrieving the system framebuffer's parent device in sysfb_init() increments the parent device's reference count. Hence release the reference before leaving the init function. Adding the sysfb platform device acquires and additional reference for the parent. This keeps the parent device around while the system framebuffer is in use. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device") Cc: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Helge Deller <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Sui Jingfeng <[email protected]> Cc: <[email protected]> # v6.9+ Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27firmware: ti_sci: fix TISCI protocol URL linkRichard Genoud1-1/+1
The http://processors.wiki.ti.com EOL in january 2021 Fix the old URL with the new one. Signed-off-by: Richard Genoud <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-06-27Merge tag 'ffa-updates-6.11' of ↵Arnd Bergmann4-29/+58
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm FF-A driver updates for v6.11 The main addition is the split of bus and driver into distinct modules The FF-A bus module is initialized at subsys_initcall level when builtin. FF-A drivers initialization is now changed to module_init level so that pKVM ffa proxy is all setup and running in case pKVM hypervisor needs to trap and handle FF-A calls. One of the reason for not having this split from the beginning is the need to workaround the FF-A v1.0 NULL UUID. The FF-A bus layer called into FF-A driver and populated the device UUID if it matches with the driver attempting to match. Moving the workaround away from the FF-A bus layer to the FF-A core driver as a bus notifier will help to remove the dependency. * tag 'ffa-updates-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Split bus and driver into distinct modules firmware: arm_ffa: Move the FF-A v1.0 NULL UUID workaround to bus notifier Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2024-06-27Merge tag 'scmi-updates-6.11' of ↵Arnd Bergmann4-7/+77
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI driver updates for v6.11 The main addition this time is the support for platform to agent(p2a also referred sometimes as notification or Rx) channel completion via interrupt driven method. Currently, the OSPM agent clears or acknowledge the receipt of the norification or delayed response by updating the flags in the shared memory region which the platform is expected to poll. On some platforms that are completely interrupt driven, the OSPM agent is expected to send a response message instead. This change adds the support for the same. Other changes include addition of a separate mailing list specific to SCMI to allow open discussions about the interface itself in addition to the kernel driver updates and support for system suspend via the platform noification used on some systems. * tag 'scmi-updates-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Add support for platform to agent channel completion dt-bindings: firmware: arm,scmi: Add support for notification completion channel firmware: arm_scmi: Add support for system suspend in power control driver MAINTAINERS: Add mailing list for SCMI drivers Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2024-06-26riscv: dmi: Add SMBIOS/DMI supportHaibo Xu1-0/+13
Enable the dmi driver for riscv which would allow access the SMBIOS info through some userspace file(/sys/firmware/dmi/*). The change was based on that of arm64 and has been verified by dmidecode tool. Signed-off-by: Haibo Xu <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Atish Patra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-06-24firmware: qcom: tzmem: export devm_qcom_tzmem_pool_new()Bartosz Golaszewski1-0/+1
EXPORT_SYMBOL_GPL() is missing for devm_qcom_tzmem_pool_new() which causes build failures with randconfig. Add it and fix the issue. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected] Fixes: 84f5a7b67b61 ("firmware: qcom: add a dedicated TrustZone buffer allocator") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-24firmware: meson_sm: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
With ARCH=arm64, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/meson/meson_sm.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240613-md-arm64-drivers-firmware-meson-v1-1-28e4138a8597@quicinc.com Signed-off-by: Neil Armstrong <[email protected]>
2024-06-23firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()Bartosz Golaszewski1-0/+7
The "memory protection" mechanism mentioned in the comment is the SHM Bridge. This is also the reason why we do not convert this call to using the TZ memory allocator. Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: add support for SHM bridge memory carveoutBartosz Golaszewski1-0/+6
Parse the "memory-region" property and - if present - use it to assign the dedicated reserved memory to the underlying DMA callbacks which will then allocate memory for the SCM calls from it. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: tzmem: enable SHM Bridge supportBartosz Golaszewski2-1/+88
SHM Bridge is a safety mechanism allowing to limit the amount of memory shared between the kernel and the TrustZone to regions explicitly marked as such. Add a variant of the tzmem allocator that configures the memory pools as SHM bridges. It also enables the SHM bridge globally so non-SHM bridge memory will no longer work with SCM calls. If enabled at build-time, it will still be checked for availability at run-time. If the architecture doesn't support SHM Bridge, the allocator will fall back to the generic mode. Signed-off-by: Bartosz Golaszewski <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: add support for SHM bridge operationsBartosz Golaszewski2-0/+63
SHM Bridge is a safety mechanism allowing to limit the amount of memory shared between the kernel and the TrustZone to regions explicitly marked as such. Add low-level primitives for enabling SHM bridge support as well as creating and destroying SHM bridges to qcom-scm. Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: qseecom: convert to using the TZ allocatorBartosz Golaszewski2-164/+109
Drop the DMA mapping operations from qcom_scm_qseecom_app_send() and convert all users of it in the qseecom module to using the TZ allocator for creating SCM call buffers. As this is largely a module separate from the SCM driver, let's use a separate memory pool. Set the initial size to 4K and - if we run out - add twice the current amount to the pool. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Elliot Berman <[email protected]> Reviewed-by: Amirreza Zarrabi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ allocatorBartosz Golaszewski1-14/+4
Let's use the new TZ memory allocator to obtain a buffer for this call instead of manually kmalloc()ing it and then mapping to physical space. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Maximilian Luz <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocatorBartosz Golaszewski1-5/+4
Let's use the new TZ memory allocator to obtain a buffer for this call instead of using dma_alloc_coherent(). Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocatorBartosz Golaszewski1-16/+5
Let's use the new TZ memory allocator to obtain a buffer for this call instead of using dma_alloc_coherent(). Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocatorBartosz Golaszewski1-4/+6
Let's use the new TZ memory allocator to obtain a buffer for this call instead of using dma_alloc_coherent(). Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: smc: switch to using the SCM allocatorBartosz Golaszewski3-22/+16
We need to allocate, map and pass a buffer to the trustzone if we have more than 4 arguments for a given SCM call. Let's use the new TrustZone allocator for that memory and shrink the code in process. As this code lives in a different compilation unit than the rest of the SCM code, we need to provide a helper in the form of qcom_scm_get_tzmem_pool() that allows the SMC low-level routines to access the SCM memory pool. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: scm: enable the TZ mem allocatorBartosz Golaszewski2-0/+23
Select the TrustZone memory allocator in Kconfig and create a pool of memory shareable with the TrustZone when probing the SCM driver. This will allow a gradual conversion of all relevant SCM calls to using the dedicated allocator. The policy used for the pool is "on-demand" and the initial size is 0 as - depending on the config - it's possible that no SCM calls needing to allocate memory will be called. The sizes of possible allocations also vary substiantially further warranting the "on-demand" approach. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-23firmware: qcom: add a dedicated TrustZone buffer allocatorBartosz Golaszewski4-0/+423
We have several SCM calls that require passing buffers to the TrustZone on top of the SMC core which allocates memory for calls that require more than 4 arguments. Currently every user does their own thing which leads to code duplication. Many users call dma_alloc_coherent() for every call which is terribly unperformant (speed- and size-wise). Provide a set of library functions for creating and managing pools of memory which is suitable for sharing with the TrustZone, that is: page-aligned, contiguous and non-cachable as well as provides a way of mapping of kernel virtual addresses to physical space. Make the allocator ready for extending with additional modes of operation which will allow us to support the SHM bridge safety mechanism once all users convert. Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <[email protected]> #sa8775p-ride Reviewed-by: Elliot Berman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-22Merge tag 'arm-fixes-6.10' of ↵Linus Torvalds1-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "There are seven oneline patches that each address a distinct problem on the NXP i.MX platform, mostly the popular i.MX8M variant. The only other two fixes are for error handling on the psci firmware driver and SD card support on the milkv duo riscv board" * tag 'arm-fixes-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: firmware: psci: Fix return value from psci_system_suspend() riscv: dts: sophgo: disable write-protection for milkv duo arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc arm64: dts: freescale: imx8mm-verdin: enable hysteresis on slow input pin arm64: dts: imx93-11x11-evk: Remove the 'no-sdio' property arm64: dts: freescale: imx8mp-venice-gw73xx-2x: fix BT shutdown GPIO arm: dts: imx53-qsb-hdmi: Disable panel instead of deleting node arm64: dts: imx8mp: Fix TC9595 input clock on DH i.MX8M Plus DHCOM SoM arm64: dts: freescale: imx8mm-verdin: Fix GPU speed
2024-06-21Merge branch '[email protected]' into ↵Bjorn Andersson2-0/+17
drivers-for-6.11 Merge SMEM and SCM patches related to GPU features through a topic branch to make it possible to share these with the msm-next DRM tree.
2024-06-21firmware: qcom: scm: Add gpu_init_regs callConnor Abbott2-0/+17
This will used by drm/msm to initialize GPU registers that Qualcomm's firmware doesn't make writeable to the kernel. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Connor Abbott <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-20firmware: psci: Fix return value from psci_system_suspend()Sudeep Holla1-1/+3
Currently we return the value from invoke_psci_fn() directly as return value from psci_system_suspend(). It is wrong to send the PSCI interface return value directly. psci_to_linux_errno() provide the mapping from PSCI return value to the one that can be returned to the callers within the kernel. Use psci_to_linux_errno() to convert and return the correct value from psci_system_suspend(). Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") Acked-by: Mark Rutland <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2024-06-18Merge tag 'efi-fixes-for-v6.10-3' of ↵Linus Torvalds1-9/+0
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Another small set of EFI fixes. Only the x86 one is likely to affect any actual users (and has a cc:stable), but the issue it fixes was only observed in an unusual context (kexec in a confidential VM). - Ensure that EFI runtime services are not unmapped by PAN on ARM - Avoid freeing the memory holding the EFI memory map inadvertently on x86 - Avoid a false positive kmemleak warning on arm64" * tag 'efi-fixes-for-v6.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/arm64: Fix kmemleak false positive in arm64_efi_rt_init() efi/x86: Free EFI memory map only when installing a new one. efi/arm: Disable LPAE PAN when calling EFI runtime services
2024-06-15efi/x86: Free EFI memory map only when installing a new one.Ard Biesheuvel1-9/+0
The logic in __efi_memmap_init() is shared between two different execution flows: - mapping the EFI memory map early or late into the kernel VA space, so that its entries can be accessed; - the x86 specific cloning of the EFI memory map in order to insert new entries that are created as a result of making a memory reservation via a call to efi_mem_reserve(). In the former case, the underlying memory containing the kernel's view of the EFI memory map (which may be heavily modified by the kernel itself on x86) is not modified at all, and the only thing that changes is the virtual mapping of this memory, which is different between early and late boot. In the latter case, an entirely new allocation is created that carries a new, updated version of the kernel's view of the EFI memory map. When installing this new version, the old version will no longer be referenced, and if the memory was allocated by the kernel, it will leak unless it gets freed. The logic that implements this freeing currently lives on the code path that is shared between these two use cases, but it should only apply to the latter. So move it to the correct spot. While at it, drop the dummy definition for non-x86 architectures, as that is no longer needed. Cc: <[email protected]> Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") Tested-by: Ashish Kalra <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2024-06-14firmware: arm_scmi: Add support for platform to agent channel completionPeng Fan3-6/+57
On some systems the SCMI platform to agent(p2a) communication can be fully interrupt driven. The notification(p2a) channel needs completion interrupt to drive its notification queue at the platform. Without it, the platform notification will not work as the platform will wait for agent indication of clearing the channel via interrupt unlike few platforms which can poll instead. To support such systems, an optional unidirectional mailbox channel for p2a reply communication. If the platform sets channel INTR flag set indicating that it expects the agent to trigger the interrupt to acknowledge the reciept of the notification or any p2a message, and the completion interrupt channel is provided, send a mailbox message to the platform after the p2a message is read and channel is freed to accept new notifications or p2a messages. Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2024-06-14firmware: arm_scmi: Add support for system suspend in power control driverPeng Fan1-1/+20
SCMI supports system suspend notification from the platform. The suuport for the same can be added in SCMI power control driver. However, currently there is no way to pass suspend level to pm_suspend() call from this driver, so use suspend-to-ram(S2R) will be used. Couple of things to note: 1) The userspace can still configure whatever default behaviour expected for S2R. 2) The userspace needs to keep the wakeup source enabled, otherwise the system may never resume back. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Cristian Marussi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]>
2024-06-11firmware: google: add missing MODULE_DESCRIPTION() macrosJeff Johnson8-0/+8
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/gsmi.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/coreboot_table.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/framebuffer-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-x86-legacy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/cbmem.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/vpd-sysfs.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/20240605-md-drivers-firmware-google-v1-1-18878de97fa5@quicinc.com Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-10ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu1-0/+4
The current arm32 architecture does not yet support the HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in embedded scenarios, and enabling this feature would be beneficial for reducing the size of the kernel image. In order to make this work, we keep the necessary tables by annotating them with KEEP, also it requires further changes to linker script to KEEP some tables and wildcard compiler generated sections into the right place. When using ld.lld for linking, KEEP is not recognized within the OVERLAY command, and Ard proposed a concise method to solve this problem. It boots normally with defconfig, vexpress_defconfig and tinyconfig. The size comparison of zImage is as follows: defconfig vexpress_defconfig tinyconfig 5137712 5138024 424192 no dce 5032560 4997824 298384 dce 2.0% 2.7% 29.7% shrink When using smaller config file, there is a significant reduction in the size of the zImage. We also tested this patch on a commercially available single-board computer, and the comparison is as follows: a15eb_config 2161384 no dce 2092240 dce 3.2% shrink The zImage size has been reduced by approximately 3.2%, which is 70KB on 2.1M. Signed-off-by: Yuntao Liu <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.