summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2024-07-02x86/efi: Drop support for fake EFI memory mapsArd Biesheuvel
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) <bp@alien8.de> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-07-01Merge tag 'amlogic-drivers-for-v6.11' of ↵Arnd Bergmann
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/35093904-c4a8-432d-b010-a994fc1ee536@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-07-01firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersRichard Fitzgerald
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 <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Validate payload length before processing blockRichard Fitzgerald
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 <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Return error if block header overflows fileRichard Fitzgerald
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 <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-07-01firmware: cs_dsp: Fix overflow checking of wmfw headerRichard Fitzgerald
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 <rf@opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-06-28firmware: cs_dsp: Add write sequence interfaceJames Ogletree
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 <ckeepax@opensource.cirrus.com> Signed-off-by: James Ogletree <jogletre@opensource.cirrus.com> Reviewed-by: Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/20240620161745.2312359-2-jogletre@opensource.cirrus.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-28firmware: sysfb: Fix reference count of sysfb parent deviceThomas Zimmermann
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 <tzimmermann@suse.de> Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Helge Deller <deller@gmx.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625081818.15696-1-tzimmermann@suse.de
2024-06-27firmware: ti_sci: fix TISCI protocol URL linkRichard Genoud
The http://processors.wiki.ti.com EOL in january 2021 Fix the old URL with the new one. Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Link: https://lore.kernel.org/r/20240618150933.1824185-3-richard.genoud@bootlin.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-06-27Merge tag 'ffa-updates-6.11' of ↵Arnd Bergmann
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/20240624103451.2870146-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-06-27Merge tag 'scmi-updates-6.11' of ↵Arnd Bergmann
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/20240620093924.375244-3-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-06-26riscv: dmi: Add SMBIOS/DMI supportHaibo Xu
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 <haibo1.xu@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20240613065507.287577-1-haibo1.xu@intel.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-06-24firmware: qcom: tzmem: export devm_qcom_tzmem_pool_new()Bartosz Golaszewski
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 <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406250127.8Pl2kqFp-lkp@intel.com Fixes: 84f5a7b67b61 ("firmware: qcom: add a dedicated TrustZone buffer allocator") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240624190615.36282-1-brgl@bgdev.pl Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-24firmware: meson_sm: add missing MODULE_DESCRIPTION() macroJeff Johnson
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 <quic_jjohnson@quicinc.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240613-md-arm64-drivers-firmware-meson-v1-1-28e4138a8597@quicinc.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-06-23firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()Bartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-13-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: add support for SHM bridge memory carveoutBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-12-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: tzmem: enable SHM Bridge supportBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-11-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: add support for SHM bridge operationsBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Acked-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-10-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: qseecom: convert to using the TZ allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Reviewed-by: Amirreza Zarrabi <quic_azarrabi@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-9-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Maximilian Luz <luzmaximilian@gmail.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-8-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-7-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-6-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-5-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: smc: switch to using the SCM allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-4-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: scm: enable the TZ mem allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-3-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-23firmware: qcom: add a dedicated TrustZone buffer allocatorBartosz Golaszewski
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240527-shm-bridge-v10-2-ce7afaa58d3a@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-22Merge tag 'arm-fixes-6.10' of ↵Linus Torvalds
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 '20240430-a750-raytracing-v3-2-7f57c5ac082d@gmail.com' into ↵Bjorn Andersson
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 Abbott
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 <dmitry.baryshkov@linaro.org> Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20240430-a750-raytracing-v3-2-7f57c5ac082d@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-20firmware: psci: Fix return value from psci_system_suspend()Sudeep Holla
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 <mark.rutland@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20240515095528.1949992-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-06-18Merge tag 'efi-fixes-for-v6.10-3' of ↵Linus Torvalds
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 Biesheuvel
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: <stable@vger.kernel.org> Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") Tested-by: Ashish Kalra <Ashish.Kalra@amd.com> Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-06-14firmware: arm_scmi: Add support for platform to agent channel completionPeng Fan
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 <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20240510-scmi-notify-v2-2-e994cf14ef86@nxp.com Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-06-14firmware: arm_scmi: Add support for system suspend in power control driverPeng Fan
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 <peng.fan@nxp.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240428075105.2187837-1-peng.fan@oss.nxp.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-06-11firmware: google: add missing MODULE_DESCRIPTION() macrosJeff Johnson
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 <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240605-md-drivers-firmware-google-v1-1-18878de97fa5@quicinc.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2024-06-10ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu
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 <liuyuntao12@huawei.com> Tested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-06Merge tag 'efi-fixes-for-v6.10-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: - Ensure that .discard sections are really discarded in the EFI zboot image build - Return proper error numbers from efi-pstore - Add __nocfi annotations to EFI runtime wrappers * tag 'efi-fixes-for-v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Add missing __nocfi annotations to runtime wrappers efi: pstore: Return proper errors on UEFI failures efi/libstub: zboot.lds: Discard .discard sections
2024-06-05firmware: microchip: use scope-based cleanup where possibleConor Dooley
There's a bunch of structs created and freed every time the mailbox is used. Move them to use the scope-based cleanup infrastructure to avoid manually tearing them down. mpfs_auto_update_available() didn't free the memory that it used (albeit it allocated exactly once during probe) so that gets moved over too. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-06-05firmware: microchip: move buffer allocation into ↵Conor Dooley
mpfs_auto_update_set_image_address() This buffer is used exclusively by mpfs_auto_update_set_image_address(), so move the management of it there, employing the recently added cleanup infrastructure to avoid littering the function with gotos. Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-06-05firmware: microchip: support writing bitstream info to flashConor Dooley
Updating the FPGA image might bring with it changes visible to Linux, so it is helpful to also co-locate dt-overlays that describe the new image contents. If these are packaged in a specific format [1] (detected by first 4 bytes being MCHP, since FPGA images have no magic), load the file to the reserved 1 MiB region immediately after the directory in flash. The Beagle-V Fire's "gateware" already creates these files and puts them in flash [2]. Link: https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/how-to/re-programming-the-fpga-from-linux.md#main-header-format Link: https://openbeagle.org/beaglev-fire/gateware/-/blob/main/gateware_scripts/generate_gateware_overlays.py?ref_type=heads [2] Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2024-06-05efi: Add missing __nocfi annotations to runtime wrappersArd Biesheuvel
The EFI runtime wrappers are a sandbox for calling into EFI runtime services, which are invoked using indirect calls. When running with kCFI enabled, the compiler will require the target of any indirect call to be type annotated. Given that the EFI runtime services prototypes and calling convention are governed by the EFI spec, not the Linux kernel, adding such type annotations for firmware routines is infeasible, and so the compiler must be informed that prototype validation should be omitted. Add the __nocfi annotation at the appropriate places in the EFI runtime wrapper code to achieve this. Note that this currently only affects 32-bit ARM, given that other architectures that support both kCFI and EFI use an asm wrapper to call EFI runtime services, and this hides the indirect call from the compiler. Fixes: 1a4fec49efe5 ("ARM: 9392/2: Support CLANG CFI") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-06-04Merge branch 'efi/next' into efi/urgentArd Biesheuvel
2024-06-03firmware: xilinx: Move FIRMWARE_VERSION_MASK to xlnx-zynqmp.hRonak Jain
Move FIRMWARE_VERSION_MASK macro to xlnx-zynqmp.h so that other drivers can use it for verifying the supported firmware version. Signed-off-by: Ronak Jain <ronak.jain@amd.com> Signed-off-by: Anand Ashok Dumbre <anand.ashok.dumbre@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/20240425095913.919390-1-ronak.jain@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-06-03LoongArch: Fix entry point in kernel image headerJiaxun Yang
Currently kernel entry in head.S is in DMW address range, firmware is instructed to jump to this address after loading the kernel image. However kernel should not make any assumption on firmware's DMW setting, thus the entry point should be a physical address falls into direct translation region. Fix by converting entry address to physical and amend entry calculation logic in libstub accordingly. BTW, use ABSOLUTE() to calculate variables to make Clang/LLVM happy. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2024-05-29firmware: arm_ffa: Split bus and driver into distinct modulesSudeep Holla
Make the FF-A bus on its own as a distinct module initialized at subsys_initcall level when builtin. Keep the FF-A driver core stack, together with any configured transport, in a different module initialized as module_init level. FF-A drivers initialization is now changed to module_init level. Acked-by: Sebastian Ene <sebastianene@google.com> Link: https://lore.kernel.org/r/20240515094028.1947976-2-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-05-29firmware: arm_ffa: Move the FF-A v1.0 NULL UUID workaround to bus notifierSudeep Holla
Currently FF-A bus ffa_device_match() handles the workaround for the FF-A v1.0 devices which are not populated with UUID to match. The FF-A bus layer calls into FF-A driver and populates the device UUID if it matches with the driver attempting to match. But this forces to have both FF-A bus and core driver to be bundled into a single module. However, keep it as a single module adds problems for the FF-A driver registrations and their initcall levels. In preparation to split the FF-A bus and the core driver into distinct modules, we need to move the workaround away from the FF-A bus layer. We can add it into the FF-A core driver as a bus notifier. In order to do so, we need to always match any driver with the device if the UUID is NULL and then during the driver binding phase, we can populate the UUID if it matches with the driver UUID table using the bus notifiers. We also need to add a check for NULL UUID before calling the device/driver probe as devices with NULL UUID is possible since we match all for that case. Acked-by: Sebastian Ene <sebastianene@google.com> Link: https://lore.kernel.org/r/20240515094028.1947976-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-05-27firmware: qcom-scm: Remove QCOM_SMC_WAITQ_FLAG_WAKE_ALLUnnathi Chalicheemala
This flag was never supported by firmware, so remove it. Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240514180046.543763-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-26firmware: qcom: uefisecapp: Allow on X1E devicesBjorn Andersson
As with previous platforms, qseecom and the uefisecapp provides access to EFI variables. Add X1E CRD and QCP devices to the allowlist. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240523-x1e-efivarfs-v1-1-5d986265b8e4@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-05-23Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull virtio updates from Michael Tsirkin: "Several new features here: - virtio-net is finally supported in vduse - virtio (balloon and mem) interaction with suspend is improved - vhost-scsi now handles signals better/faster And fixes, cleanups all over the place" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (48 commits) virtio-pci: Check if is_avq is NULL virtio: delete vq in vp_find_vqs_msix() when request_irq() fails MAINTAINERS: add Eugenio Pérez as reviewer vhost-vdpa: Remove usage of the deprecated ida_simple_xx() API vp_vdpa: don't allocate unused msix vectors sound: virtio: drop owner assignment fuse: virtio: drop owner assignment scsi: virtio: drop owner assignment rpmsg: virtio: drop owner assignment nvdimm: virtio_pmem: drop owner assignment wifi: mac80211_hwsim: drop owner assignment vsock/virtio: drop owner assignment net: 9p: virtio: drop owner assignment net: virtio: drop owner assignment net: caif: virtio: drop owner assignment misc: nsm: drop owner assignment iommu: virtio: drop owner assignment drm/virtio: drop owner assignment gpio: virtio: drop owner assignment firmware: arm_scmi: virtio: drop owner assignment ...
2024-05-23efi: pstore: Return proper errors on UEFI failuresGuilherme G. Piccoli
Right now efi-pstore either returns 0 (success) or -EIO; but we do have a function to convert UEFI errors in different standard error codes, helping to narrow down potential issues more accurately. So, let's use this helper here. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>