summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2026-04-07firmware: arm_ffa: Use the correct buffer size during RXTX_MAPSebastian Ene
Don't use the discovered buffer size from an FFA_FEATURES call directly since we can run on a system that has the PAGE_SIZE larger than the returned size which makes the alloc_pages_exact for the buffer to be rounded up. Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()") Signed-off-by: Sebastian Ene <sebastianene@google.com> Link: https://patch.msgid.link/20260402113939.930221-1-sebastianene@google.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-04-06Merge tag 'soc-fixes-7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The largest part here are devicetree fixes for Qualcomm, and NXP i.MX, addressing a few regressions and incorrect settings in board and SoC pecific dts files. The largest single commits are a revert of a cleanup patch for i.MX that caused regressions for the NAND flash controller and a fixup for an incomplete cleanup of the PCIe controller on Qualcomm platforms that broke because the state was left incompatible with both the old and new behavior. On the Rockchips, Hisilicon, Renesas, Allwinner and AT91 platforms, only a single simple dts bugfix each was added since the last round of fixes. On the SoC specific device drivers, everything is relatively harmless: three reset controller driver fixes, a compatibility for fix ASpeed soc ID, and error handling fixes for Qualcomm and Microchip. One regression fix on Qualcomm addresses a problem with a previous fix for DisplayPort alt mode" * tag 'soc-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits) arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example firmware: microchip: fail auto-update probe if no flash found arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM arm64: dts: qcom: agatti: Fix IOMMU DT properties dt-bindings: media: venus: Fix iommus property dt-bindings: display: msm: qcm2290-mdss: Fix iommus property arm64: dts: allwinner: sun55i: Fix r-spi DMA reset: spacemit: k3: Decouple composite reset lines reset: gpio: fix double free in reset_add_gpio_aux_device() error path ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity reset: rzg2l-usbphy-ctrl: Fix malformed MODULE_AUTHOR string soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition arm64: dts: qcom: monaco: Reserve full Gunyah metadata region arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower" ...
2026-04-02Merge tag 'qcom-drivers-for-7.1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers Qualcomm driver updates for v7.1 Add ECS LIVA QC710, Glymur CRD, Mahua CRD, Purwa IoT EVK, and Asus Vivobook to the QSEECOM allow-list, to enable UEFI variable access through uefisecapp. Register the Gunyah watchdog device if the SCM driver finds itself running under Gunyah. Clean up some locking using guards. Handle possible cases where AOSS cooling state is given a non-boolean state. Replace LLCC per-slice activation bitmap with reference counting. Also add SDM670 support. Improve probe deferral handling in the OCMEM driver. Add Milos, QCS615, Eliza, Glymur, and Mahua support to the pd-mapper. Add support for SoCCP-based pmic-glink, as found in Glymur and Kaanapali. Add common QMI service ids to the main qmi headerfile, to avoid spreading these constants in various drivers. Add support for version 2 of SMP2P and implement the irqchip state reading support. Add CQ7790, SA8650P, SM7450, SM7450P, and IPQ5210 SoC and the PM7550BA PMIC identifiers to the socinfo driver. Add Eliza and Mahua support to the UBWC driver, introduce helpers for drivers to read out min_acc length and other programmable values, and disable bank swizzling for Glymur. Simplify the logic related to allocation of NV download request in the WCNSS control driver. * tag 'qcom-drivers-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (51 commits) soc: qcom: ubwc: add helpers to get programmable values soc: qcom: ubwc: add helper to get min_acc length firmware: qcom: scm: Register gunyah watchdog device soc: qcom: socinfo: Add SoC ID for SA8650P dt-bindings: arm: qcom,ids: Add SoC ID for SA8650P firmware: qcom: scm: Allow QSEECOM on Mahua CRD soc: qcom: wcnss: simplify allocation of req soc: qcom: pd-mapper: Add support for Eliza soc: qcom: aoss: compare against normalized cooling state soc: qcom: llcc: fix v1 SB syndrome register offset dt-bindings: firmware: qcom,scm: Document ipq9650 SCM soc: qcom: ubwc: Add support for Mahua soc: qcom: pd-mapper: Add support for Glymur and Mahua soc: qcom: ubwc: Add configuration Eliza SoC soc: qcom: ubwc: Remove redundant x1e80100_data dt-bindings: firmware: qcom,scm: document Eliza SCM Firmware Interface soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available soc: qcom: ocmem: register reasons for probe deferrals soc: qcom: ocmem: make the core clock optional soc: qcom: ubwc: disable bank swizzling for Glymur platform ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-02Merge tag 'tegra-for-7.1-firmware' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers firmware: tegra: Changes for v7.1-rc1 This introduces a new API for the BPMP to be pass along a specifier from DT when getting a reference from a phandle. This is used to reference specific instances of the PCI controller on Tegra264. The ABI header for BPMP is updated to the latest version and BPMP APIs now use the more intuitive ENODEV instead of the non SUSV4 ENOTSUPP error code for stub implementations. * tag 'tegra-for-7.1-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: bpmp: Use ENODEV instead of ENOTSUPP firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function soc/tegra: Update BPMP ABI header firmware: tegra: bpmp: Rename Tegra239 to Tegra238 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-02firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini XBjorn Andersson
The Hamoa-based Lenovo IdeaCentre Mini X provides the same UEFI variable access through uefisecapp as other Hamoa devices, add it to the allowlist. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260401-ideacentre-v2-3-5745fe2c764e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01Merge tag 'scmi-updates-7.1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI updates for v7.1 This batch mainly improves SCMI robustness on systems where the SCP does not generate completion interrupts, and includes two small follow-up cleanups in the SCMI core. The main functional change adds support for the new DT property 'arm,no-completion-irq'. When present for mailbox/shared-memory based SCMI implementations, the driver forces SCMI operations into polling mode so affected platforms can continue to operate even with broken firmware interrupt behavior. In addition, it - replaces open-coded size rounding in the base protocol path with round_up() for clarity, with no functional change - updates the SCMI quirk snippet macro implementation so quirk handlers can use break and continue directly when invoked inside loop contexts * tag 'scmi-updates-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Support loop control in quirk code snippets firmware: arm_scmi: Use round_up() for base protocol list size calculation firmware: arm_scmi: Implement arm,no-completion-irq property dt-bindings: firmware: arm,scmi: Document arm,no-completion-irq property Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01x86/CPU/AMD: Print AGESA string from DMI additional information entryYazen Ghannam
Type 40 entries (Additional Information) are summarized in section 7.41 as part of the SMBIOS specification. Generally, these entries aren't interesting to save. However on some AMD Zen systems, the AGESA version is stored here. This is useful to save to the kernel message logs for debugging. It can be used to cross-reference issues. Implement an iterator for the Additional Information entries. Use this to find and print the AGESA string. Do so in AMD code, since the use case is AMD-specific. [ bp: Match only "AGESA". ] Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Co-developed-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Link: https://patch.msgid.link/20260307141024.819807-6-superm1@kernel.org
2026-04-01firmware: dmi: Add pr_fmt() for dmi_scan.cMario Limonciello (AMD)
Several prints inconsistently use DMI: or dmi: or nothing. To make it clear which prints come from dmi_scan.c, add a pr_fmt() macro. Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Link: https://patch.msgid.link/20260307141024.819807-5-superm1@kernel.org
2026-04-01firmware: dmi: Adjust dmi_decode() to use enumsMario Limonciello (AMD)
dmi_decode() has hardcoded values with comments for each DMI entry type. The same information is already in dmi.h though, so drop the comments and use the definitions instead. Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Link: https://patch.msgid.link/20260307141024.819807-3-superm1@kernel.org
2026-04-01Merge tag 'riscv-soc-fixes-for-v7.0-rc6' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V soc fixes for v7.0-rc6 Microchip: More resource leak fixes for unlikely scenarios, and a change to the auto-update "firmware" driver to prevent it probing on systems with engineering silicon where it cannot be used. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-soc-fixes-for-v7.0-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: fail auto-update probe if no flash found soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-04-01firmware: thead: Fix buffer overflow and use standard endian macrosMichal Wilczynski
Addresses two issues in the TH1520 AON firmware protocol driver: 1. Fix a potential buffer overflow where the code used unsafe pointer arithmetic to access the 'mode' field through the 'resource' pointer with an offset. This was flagged by Smatch static checker as: "buffer overflow 'data' 2 <= 3" 2. Replace custom RPC_SET_BE* and RPC_GET_BE* macros with standard kernel endianness conversion macros (cpu_to_be16, etc.) for better portability and maintainability. The functionality was re-tested with the GPU power-up sequence, confirming the GPU powers up correctly and the driver probes successfully. [ 12.702370] powervr ffef400000.gpu: [drm] loaded firmware powervr/rogue_36.52.104.182_v1.fw [ 12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build 6645434 OS) [ 12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on minor 0 Fixes: e4b3cbd840e5 ("firmware: thead: Add AON firmware protocol driver") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/17a0ccce-060b-4b9d-a3c4-8d5d5823b1c9@stanley.mountain/ Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Drew Fustini <fustini@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-04-01memblock, treewide: make memblock_free() handle late freeingMike Rapoport (Microsoft)
It shouldn't be responsibility of memblock users to detect if they free memory allocated from memblock late and should use memblock_free_late(). Make memblock_free() and memblock_phys_free() take care of late memory freeing and drop memblock_free_late(). Link: https://patch.msgid.link/20260323074836.3653702-9-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-03-31BackMerge tag 'v7.0-rc6' into drm-nextDave Airlie
Linux 7.0-rc6 Requested by a few people on irc to resolve conflicts in other tress. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-03-30firmware: qcom: scm: Register gunyah watchdog deviceHrishabh Rajput
To restrict Gunyah watchdog initialization to Qualcomm platforms running under the Gunyah Hypervisor, register the watchdog device in the QCOM SCM driver. When Gunyah is not present or Gunyah emulates MMIO-based watchdog, we expect Qualcomm watchdog or ARM SBSA watchdog device to be present in the devicetree. First, we make sure we're running under the Gunyah Hypervisor. Then we move to check if any of the above mentioned watchdog device nodes are present, if not then we proceed to register the SMC-based Gunyah watchdog device. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com> Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311-gunyah_watchdog-v8-1-4c1c0689de22@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-30firmware: qcom: scm: Allow QSEECOM on Mahua CRDGopikrishna Garmidi
Add Mahua CRD board to the QSEECOM allowlist for enabling access to efivars and uefi bootloader. Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260322-mahua-qcom_scm-support-v1-1-00c50db332ee@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-27firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() functionThierry Reding
Some device tree bindings need to specify a parameter along with a BPMP phandle reference to designate the ID associated with a given controller that needs to interoperate with BPMP. Typically this is specified as an extra cell in the nvidia,bpmp property, so add a helper to parse this ID while resolving the phandle reference. Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-03-26firmware: microchip: fail auto-update probe if no flash foundConor Dooley
There's no point letting the driver probe if there is no flash, as trying to do a firmware upload will fail. Move the code that attempts to get the flash from firmware upload to probe, and let it emit a message to users stating why auto-update is not supported. The code currently could have a problem if there's a flash in devicetree, but the system controller driver fails to get a pointer to it from the mtd subsystem, which will cause mpfs_sys_controller_get_flash() to return an error. Check for errors and null, instead of just null, in the new clause. CC: stable@vger.kernel.org Fixes: ec5b0f1193ad4 ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-03-26BackMerge tag 'v7.0-rc4' into drm-nextDave Airlie
Linux 7.0-rc4 Needed for rust tree. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-03-24ASoc: uda1380: Improve error reportingMark Brown
Wenyuan Li <2063309626@qq.com> says: The driver currently ignores the return values of several I2C operations during register writes, which could lead to silent failures and inconsistent device state. Link: https://patch.msgid.link/tencent_579D057AC557914CF739A2D9EAD045CE7306@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24firmware: arm_scmi: Allow PINCTRL_REQUEST to return EOPNOTSUPPDan Carpenter
The SCMI protocol specification says that the PINCTRL_REQUEST and PINCTRL_RELEASE commands are optional. So if the SCMI server returns -EOPNOTSUPP, then treat that as success and continue. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23firmware: qcom_scm: don't opencode kmemdupMukesh Ojha
Lets not opencode kmemdup which is reported by coccinelle tool. Fix it using kmemdup. cocci warnings: (new ones prefixed by >>) >> drivers/firmware/qcom/qcom_scm.c:916:11-18: WARNING opportunity for kmemdup Fixes: 8b9d2050cfa0 ("firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601142144.HvSlBSI9-lkp@intel.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260310140255.2520230-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18Merge tag 'soc-fixes-7.0' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The firmware drivers for ARM SCMI, FF-A and the Tee subsystem, as well as the reset controller and cache controller subsystem all see small bugfixes for reference ounting errors, ABI correctness, and NULL pointer dereferences. Similarly, there are multiple reference counting fixes in drivers/soc/ for vendor specific drivers (rockchips, microchip), while the freescale drivers get a fix for a race condition and error handling. The devicetree fixes for Rockchips and NXP got held up, so for the moment there is only Renesas fixing problesm with SD card initialization, a boot hang on one board and incorrect descriptions for interrupts and clock registers on some SoCs. The Microchip polarfire gets a dts fix for a boot time warning. A defconfig fix avoids a warning about a conflicting assignment" * tag 'soc-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (21 commits) ARM: multi_v7_defconfig: Drop duplicate CONFIG_TI_PRUSS=m firmware: arm_scmi: Spelling s/mulit/multi/, s/currenly/currently/ firmware: arm_scmi: Fix NULL dereference on notify error path firmware: arm_scpi: Fix device_node reference leak in probe path firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap() arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers arm64: dts: renesas: rzg3s-smarc-som: Set bypass for Versa3 PLL2 arm64: dts: renesas: r9a09g087: Fix CPG register region sizes arm64: dts: renesas: r9a09g077: Fix CPG register region sizes arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodes arm64: dts: renesas: rzv2-evk-cn15-sd: Add ramp delay for SD0 regulator arm64: dts: renesas: rzt2h-n2h-evk: Add ramp delay for SD0 card regulator tee: shm: Remove refcounting of kernel pages reset: rzg2l-usbphy-ctrl: Check pwrrdy is valid before using it soc: fsl: cpm1: qmc: Fix error check for devm_ioremap_resource() in qmc_qe_init_resources() soc: fsl: qbman: fix race condition in qman_destroy_fq soc: rockchip: grf: Add missing of_node_put() when returning cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() cache: starfive: fix device node leak in starlink_cache_init() riscv: dts: microchip: add can resets to mpfs ...
2026-03-18Merge tag 'scmi-fixes-7.0' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI fixes for v7.0 Few fixes to: 1. Address a NULL dereference in the SCMI notify error path by ensurin __scmi_event_handler_get_ops() consistently returns an ERR_PTR on failure, as expected by callers. 2. Fix a device_node reference leak in the SCPI probe path by introducing scope-based cleanup for acquired DT nodes. 3. Correct minor spelling errors. * tag 'scmi-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Spelling s/mulit/multi/, s/currenly/currently/ firmware: arm_scmi: Fix NULL dereference on notify error path firmware: arm_scpi: Fix device_node reference leak in probe path Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-03-18firmware: qcom: scm: Allow QSEECOM on Glymur CRDPankaj Patil
Add glymur-crd to QSEECOM allowlist for enabling access to efivars and uefi bootloader Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260225-qseecom_glymur-v1-1-0cafc709e2ef@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18firmware: qcom: scom: Simplify mutex with guardKrzysztof Kozlowski
Simplify error path unlocking mutex with the guard. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260216091525.107935-6-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18firmware: qcom: uefisecapp: Annotate acquiring locks for context trackingKrzysztof Kozlowski
qcuefi_acquire() and qcuefi_release() end with mutex locked or unlocked respectively, so annotate them so the lock usage will be tracked by context tracking tools. Note that mutex is tracked since commit 370f0a345a70 ("locking/mutex: Support Clang's context analysis"). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260216091525.107935-5-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18firmware: qcom: uefisecapp: Simplify mutex with guardKrzysztof Kozlowski
Simplify error path unlocking mutex with the guard. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260216091525.107935-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-17firmware: arm_scmi: Support loop control in quirk code snippetsGeert Uytterhoeven
Each SCMI firmware quirk contains a code snippet, which handles the quirk, and has full access to the surrounding context. When this context is (part of) a loop body, the code snippet may want to use loop control statements like "break" and "continue". Unfortunately the SCMI_QUIRK() macro implementation contains a dummy loop, taking precedence over any outer loops. Hence quirk code cannot use loop control statements, but has to resort to polluting the surrounding context with a label, and use goto. Fix this by replacing the "do { ... } while (0)" construct in the SCMI_QUIRK() implementation by "({ ... })". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Message-Id: <51de914cddef8fa86c2e7dd5397e5df759c45464.1773675224.git.geert+renesas@glider.be> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-16ASoC: amd: Move to GPIO descriptorsMark Brown
Linus Walleij <linusw@kernel.org> says: After a quick look and test-compile I can determine that all of these drivers include <linux/gpio.h> for no reason whatsoever, so fixing it is low hanging fruit. Link: https://patch.msgid.link/20260314-asoc-amd-v1-0-31afed06e022@kernel.org
2026-03-14Merge tag 'char-misc-7.0-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char / misc / IIO driver fixes from Greg KH: "Here are some char/misc/iio/binder fixes for 7.0-rc4. Nothing major in here, just the usual: - lots of iio driver fixes for reported issues - rust binder fixes for problems found - gpib driver binding to the wrong device fix - firmware driver fix All of these have been in linux-next with no reported issues" * tag 'char-misc-7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (28 commits) gpib: lpvo_usb: fix unintended binding of FTDI 8U232AM devices firmware: stratix10-svc: Add Multi SVC clients support rust_binder: use lock_vma_under_rcu() in use_page_slow() rust_binder: call set_notification_done() without proc lock rust_binder: avoid reading the written value in offsets array rust_binder: check ownership before using vma rust_binder: fix oneway spam detection firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled iio: imu: adis: Fix NULL pointer dereference in adis_init iio: imu: inv_icm45600: fix regulator put warning when probe fails iio: buffer: Fix wait_queue not being removed iio: gyro: mpu3050-core: fix pm_runtime error handling iio: gyro: mpu3050-i2c: fix pm_runtime error handling iio: adc: ad7768-1: Fix ERR_PTR dereference in ad7768_fill_scale_tbl iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas() iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() iio: magnetometer: tlv493d: remove erroneous shift in X-axis data iio: proximity: hx9023s: Protect against division by zero in set_samp_freq iio: proximity: hx9023s: fix assignment order for __counted_by iio: chemical: bme680: Fix measurement wait duration calculation ...
2026-03-12kbuild: Consolidate C dialect optionsNathan Chancellor
Introduce CC_FLAGS_DIALECT to make it easier to update the various places in the tree that rely on the GNU C standard and Microsoft extensions flags atomically. All remaining uses of '-std=gnu11' and '-fms-extensions' are in the tools directory (which has its own build system) and other standalone Makefiles. This will allow the kernel to use a narrower option to enable the Microsoft anonymous tagged structure extension in a simpler manner. Place the CC_FLAGS_DIALECT block after the configuration include (so that a future change can move the selection of the flag to Kconfig) but before the arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available for use in those Makefiles). Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Link: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-03-11efi: libstub: fix type of fdt 32 and 64bit variablesBen Dooks
In update_fdt_memmap() an update_fdt() the fdt values should be of the fd32_t and fdt64_t types. Make the relevant changes to remove the following sparse warnings: drivers/firmware/efi/libstub/fdt.c:97:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:97:19: expected unsigned long long [usertype] fdt_val64 drivers/firmware/efi/libstub/fdt.c:97:19: got restricted __be64 [usertype] drivers/firmware/efi/libstub/fdt.c:157:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:157:19: expected unsigned long long [usertype] fdt_val64 drivers/firmware/efi/libstub/fdt.c:157:19: got restricted __be64 [usertype] drivers/firmware/efi/libstub/fdt.c:163:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:163:19: expected unsigned int [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:163:19: got restricted __be32 [usertype] drivers/firmware/efi/libstub/fdt.c:169:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:169:19: expected unsigned int [addressable] [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:169:19: got restricted __be32 [usertype] drivers/firmware/efi/libstub/fdt.c:175:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:175:19: expected unsigned int [addressable] [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:175:19: got restricted __be32 [usertype] Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-03-11Merge v7.0-rc3 into drm-nextSimona Vetter
Requested by Maxime Ripard for drm-misc-next because renesas people need fb797a70108f ("drm: renesas: rz-du: mipi_dsi: Set DSI divider"). Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2026-03-11Merge tag 'stratix10_svc_fix_for_v7.0' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into char-misc-linus Dinh writes: firmware: stratix10-svc: add multiple svc clients support - Add a dedicated thread for each svc client to fix a timeout issue when the svc driver is handling multiple clients. * tag 'stratix10_svc_fix_for_v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: firmware: stratix10-svc: Add Multi SVC clients support
2026-03-10efi: Enable BGRT loading under XenMarek Marczykowski-Górecki
The BGRT table can be parsed if EFI_PARAVIRT is enabled, even if EFI_MEMMAP is not. Xen will take care of preserving the image even if EfiBootServicesData memory is reclaimed already, or invalidate the table if it didn't preserve it - in both cases accesing the table itself under virt is safe. Also allow the ESRT to be in reclaimable memory, as that is where future Xen versions will put it. This is similar approach as was taken for ESRT table in 01de145dc7fb "efi: Actually enable the ESRT under Xen". Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-03-10efi: make efi_mem_type() and efi_mem_attributes() work on Xen PVMarek Marczykowski-Górecki
Xen doesn't give direct access to the EFI memory map, but provides a hypercall interface for it. efi_mem_desc_lookup() was already adjusted in aca1d27ac38a "efi: xen: Implement memory descriptor lookup based on hypercall" to (optionally) use it. Now make efi_mem_type() and efi_mem_attributes() use common efi_mem_desc_lookup() too. This also reduces code duplication a bit. efi_mem_type() retains separate check for -ENOTSUPP error case (even though no caller seems to rely on this currently). Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> [ardb: Drop erroneous 'const' qualifier] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-03-10firmware: stratix10-svc: Add Multi SVC clients supportMuhammad Amirul Asyraf Mohamad Jamian
In the current implementation, SVC client drivers such as socfpga-hwmon, intel_fcs, stratix10-soc, stratix10-rsu each send an SMC command that triggers a single thread in the stratix10-svc driver. Upon receiving a callback, the initiating client driver sends a stratix10-svc-done signal, terminating the thread without waiting for other pending SMC commands to complete. This leads to a timeout issue in the firmware SVC mailbox service when multiple client drivers send SMC commands concurrently. To resolve this issue, a dedicated thread is now created per channel. The stratix10-svc driver will support up to the number of channels defined by SVC_NUM_CHANNEL. Thread synchronization is handled using a mutex to prevent simultaneous issuance of SMC commands by multiple threads. SVC_NUM_DATA_IN_FIFO is reduced from 32 to 8, since each channel now has its own dedicated FIFO and the SDM processes commands one at a time. 8 entries per channel is sufficient while keeping the total aggregate capacity the same (4 channels x 8 = 32 entries). Additionally, a thread task is now validated before invoking kthread_stop when the user aborts, ensuring safe termination. Timeout values have also been adjusted to accommodate the increased load from concurrent client driver activity. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Cc: stable@vger.kernel.org Signed-off-by: Ang Tien Sung <tien.sung.ang@altera.com> Signed-off-by: Fong, Yan Kei <yankei.fong@altera.com> Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul.asyraf.mohamad.jamian@altera.com> Link: https://lore.kernel.org/all/20260305093151.2678-1-muhammad.amirul.asyraf.mohamad.jamian@altera.com Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-03-10firmware: cs_dsp: Simplify suppressing log messages during KUnit testingRichard Fitzgerald
Rework the way that kernel log messages are rate-limited or suppressed while running the cs_dsp KUnit tests. Under normal conditions cs_dsp doesn't produce an unreasonable number of log messages, and state changes are relatively infrequent. But the KUnit tests run through a very large number of test cases, especially error cases, and this produces an unusually large amount of log output from cs_dsp. The original fix for this in commit 10db9f6899dd ("firmware: cs_dsp: rate-limit log messages in KUnit builds") was effective but not pretty. It involved different definitions of the log macros for KUnit and not-KUnit builds, and exported variables for the KUnit tests to disable log messages. I would have preferred to turn the log macros into real functions that can contain a KUNIT_STATIC_STUB_REDIRECT(), but the dev_xxx() macros don't have a version that take va_args, so they can't be wrapped by a function. This patch enables the use of a KUNIT_STATIC_STUB_REDIRECT() instead of exported variables, and avoids the need for different definitions of the debug macros in KUnit and not-KUnit builds. - A new function cs_dsp_can_emit_message() returns true if the messages can be emitted to the kernel log. In a normal not-KUnit build this function collapses to simply returning true. In KUnit builds it will rate-limit output, and this uses a single static rate limiter so it limits the overall rate across all cs_dsp log messages. The KUnit test can redirect it to change the suppression behavior. - The cs_dsp debug message macros are changed to only call the dev_xxx() if cs_dsp_can_emit_message() returns true. These are still macros so there is no problem wrapping the dev_xxx(). For a normal not-KUnit build cs_dsp_can_emit_message() always returns true so these macros simplify down to being identical to calling dev_xxx() directly. - The KUnit tests that cause a lot of cs_dsp messages now redirect cs_dsp_can_emit_message() to a local function. This returns false to suppress cs_dsp messages, unless DEBUG is defined for that test. I have checked that for a x86_64 production (non-KUnit) build the disassembled cs_dsp.o is identical to what was generated from the original code. So the complier is correctly simplifying the cs_dsp_can_emit_message() and macros down to only the call to dev_xxx(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260310130343.1791951-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-10ASoC: ti: davinci-mcasp: McASP code cleanup and clkMark Brown
Merge series from Sen Wang <sen@ti.com>: Just two minor patches that aim to tidy up the code a little bit, as well as fix the aux_div selection in davinci_mcasp_calc_clk_div() for mid-range dividers (33 <= div <= 4096). Sen Wang (2): ASoC: ti: davinci-mcasp: extract mcasp_is_auxclk_enabled() helper ASoC: ti: davinci-mcasp: improve aux_div selection for mid-range dividers sound/soc/ti/davinci-mcasp.c | 45 +++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 14 deletions(-) -- 2.43.0
2026-03-09firmware: cs_dsp: Fix fragmentation regression in firmware downloadRichard Fitzgerald
Use vmalloc() instead of kmalloc(..., GFP_DMA) to alloc the temporary buffer for firmware download blobs. This avoids the problem that a heavily fragmented system cannot allocate enough physically-contiguous memory for a large blob. The redundant alloc buffer mechanism was removed in commit 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator"). While doing that I was overly focused on the possibility of the underlying bus requiring DMA-safe memory. So I used GFP_DMA kmalloc()s. I failed to notice that the code I was removing used vmalloc(). This creates a regression. Way back in 2014 the problem of fragmentation with kmalloc()s was fixed by commit cdcd7f728753 ("ASoC: wm_adsp: Use vmalloc to allocate firmware download buffer"). Although we don't need physically-contiguous memory, we don't know if the bus needs some particular alignment of the buffers. Since the change in 2014, the firmware download has always used whatever alignment vmalloc() returns. To avoid introducing a new problem, the temporary buffer is still used, to keep the same alignment of pointers passed to regmap_raw_write(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 900baa6e7bb0 ("firmware: cs_dsp: Remove redundant download buffer allocator") Link: https://patch.msgid.link/20260304141250.1578597-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-08firmware: arm_scmi: Use round_up() for base protocol list size calculationPeng Fan
Replace the open-coded size rounding logic with the kernel's round_up() helper to improve readability and align with common kernel practices. The original expression: (1 + (loop_num_ret - 1) / sizeof(u32)) * sizeof(u32) is equivalent to rounding up loop_num_ret to the nearest multiple of sizeof(u32), which is exactly what round_up() does. No functional change. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20260228-scmi-check-v1-1-4935b58bb2db@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-08firmware: arm_scmi: Spelling s/mulit/multi/, s/currenly/currently/Geert Uytterhoeven
Fix misspellings of "multi" and "currently". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Message-Id: <6735401861e0c2f3e5e680533cd6f71c4d6fd5eb.1771581270.git.geert+renesas@glider.be> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-08firmware: arm_scmi: Implement arm,no-completion-irq propertyMarek Vasut
Implement new property arm,no-completion-irq, which sets all SCMI operation into poll mode. This is meant to work around uncooperative SCP implementations, which do not generate completion interrupts. This applies to mbox/shmem based implementations. With this property set, such implementations which do not generate interrupts can be interacted with, until they are fixed to generate interrupts properly. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Message-Id: <20260117010241.186685-2-marek.vasut+renesas@mailbox.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-07firmware: arm_scmi: Fix NULL dereference on notify error pathCristian Marussi
Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") the call chains leading to the helper __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to get an handler for the requested event key, while the current helper can still return a NULL when no handler could be found or created. Fix by forcing an ERR_PTR return value when the handler reference is NULL. Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Message-Id: <20260305131011.541444-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-07firmware: arm_scpi: Fix device_node reference leak in probe pathFelix Gu
A device_node reference obtained from the device tree is not released on all error paths in the arm_scpi probe path. Specifically, a node returned by of_parse_phandle() could be leaked when the probe failed after the node was acquired. The probe function returns early and the shmem reference is not released. Use __free(device_node) scope-based cleanup to automatically release the reference when the variable goes out of scope. Fixes: ed7ecb883901 ("firmware: arm_scpi: Add compatibility checks for shmem node") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Message-Id: <20260121-arm_scpi_2-v2-1-702d7fa84acb@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-06firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap()Yeoreum Yun
According to the FF-A specification (DEN0077, v1.1, §13.7), when FFA_RXTX_UNMAP is invoked from any instance other than non-secure physical, the w1 register must be zero (MBZ). If a non-zero value is supplied in this context, the SPMC must return FFA_INVALID_PARAMETER. The Arm FF-A driver operates exclusively as a guest or non-secure physical instance where the partition ID is always zero and is not invoked from a hypervisor context where w1 carries a VM ID. In this execution model, the partition ID observed by the driver is always zero, and passing a VM ID is unnecessary and potentially invalid. Remove the vm_id parameter from ffa_rxtx_unmap() and ensure that the SMC call is issued with w1 implicitly zeroed, as required by the specification. This prevents invalid parameter errors and aligns the implementation with the defined FF-A ABI behavior. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Message-Id: <20260304120953.847671-1-yeoreum.yun@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-04firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710Val Packett
Allow this machine to access efivars through qseecom/uefisecapp. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/20260120234029.419825-11-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-04firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVKYijie Yang
Add the Purwa-IoT-EVK board to the list to enable access to EFI variables. Guarantee that subsystems relying on SCM services can access secure-world features. This change improves reliability and prevents missing functionality or boot-time issues by making service availability explicit. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260202073555.1345260-2-yijie.yang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-02Support wm_adsp hibernation for runtime suspendMark Brown
Merge series from Stefan Binding <sbinding@opensource.cirrus.com>: When the CS35L41 and CS35L45 drivers suspend, they are put into hibernation, and the regmap goes into cache_only, but the firmware is still running, and wm_adsp is not stopped. If userspace attempts to read a firmware control, it will perform a regmap_raw_read() and this will produce an error in the kernel log. To prevent these spurious errors, add an apis into cs_dsp and wm_adsp to allow wm_adsp to hibernate. In this hibernation mode, reads or writes to the dsp controls would be rejected with -EPERM rather than -EBUSY, and no error will be printed to the kernel log.
2026-03-01firmware: cs_dsp: Add API to hibernate the DSPStefan Binding
For some parts, the DSP is kept running when in low power mode (hibernation), leaving the firmware ALSA controls enabled, but the registers are inaccessible. Attempts to access volatile firmware controls whilst in this state would produce errors in the kernel log due to a regmap_raw_read() into DSP registers whilst the regmap is in cache_only. To remove this error log, add a hibernating flag to indicate that the controls are inaccessible, so we no longer try to read or write to the registers whilst the regmap is in cache_only. This would still produce an error when trying to read or write to these controls, but this would be a different error (-EPERM instead of -EBUSY), and would not produce a spurious error log in the kernel. Upon wake from hibernation, the control caches are re-synced to the hardware, if the DSP is running. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://patch.msgid.link/20260224161821.93365-2-sbinding@opensource.cirrus.com Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>