aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
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 <neil.armstrong@linaro.org> Fixes: f86c61498a57 ("firmware: qcom: tzmem: enable SHM Bridge support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Qualcomm RB3 Link: https://lore.kernel.org/r/20240704-shmbridge-blacklist-v1-1-14b027b3b2dc@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <krzysztof.kozlowski@linaro.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240703083046.95811-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ffba0c63-2798-40b6-948d-361cd3b14e9f@linux.intel.com
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 <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20240702110809.16836-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
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 <ruanjinjie@huawei.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
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 <ardb@kernel.org>
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) <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 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/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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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/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 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/20240620093924.375244-3-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 <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 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 '20240430-a750-raytracing-v3-2-7f57c5ac082d@gmail.com' 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 <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 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 <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 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: <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 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 <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 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 <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 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 <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 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 <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 Torvalds3-11/+11
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 Dooley1-43/+16
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 Dooley1-19/+13
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 Dooley1-8/+39
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 Biesheuvel1-7/+6
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 Biesheuvel2-4/+5
2024-06-03firmware: xilinx: Move FIRMWARE_VERSION_MASK to xlnx-zynqmp.hRonak Jain1-3/+0
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>
Powered by cgit, Gruvboxed by Blaster4385.