summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-19RDMA/core: Do not read wild stack memory in uverbs_get_handler_fn()Jason Gunthorpe
Sashiko points out the legacy write path in ib_uverbs_write() does allocate a struct uverbs_attr_bundle, but it doesn't wrap it in a bundle_priv so downcasting here isn't safe. Instead lift the method_elm out of the bundle_priv and use it for the debug function. The legacy write path will leave it set as NULL since the write method_elm uses a different type. Cc: stable@vger.kernel.org Fixes: 1de9287ece44 ("RDMA: Add ib_copy_validate_udata_in()") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-05-19RDMA/core: Move the _ib_copy_validate_udata* functions to ib_core_uverbsJason Gunthorpe
It was incorrect to place them in uverbs_ioctl because that makes every driver depends on ib_uverbs.ko, which is undesired. ib_core_uverbs.c is for functions used by alot of drivers that are linked into ib_core instead. Fixes: 1de9287ece44 ("RDMA: Add ib_copy_validate_udata_in()") Link: https://patch.msgid.link/r/1-v1-045258567bd6+9fe-ib_uverbs_support_ko_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-05-19hfs: disable the updating of file access times (atime)Viacheslav Dubeyko
The xfstests' test-case generic/003 fails with errors: sudo ./check generic/003 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #18 SMP PREEMPT_DYNAMIC Fri Mar 13 17:54:19 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch output mismatch QA output created by 003 ERROR: access time has changed for file1 after remount ERROR: access time has changed after modifying file1 ERROR: change time has not been updated after changing file1 ERROR: access time has changed for file in read-only filesystem Silence is golden This patch fixes the issue with change time by adding inode_set_ctime_current() and mark_inode_dirty() in hfs_rename(). Also, it reworks hfs_inode_setattr() by changing simple_inode_init_ts() on inode_set_mtime_to_ts() and inode_set_ctime_current() calls. HFS hasn't any field in on-disk layout that can keep the file/folder access times (atime). It was added setting of SB_NOATIME in SB_NOATIME. Finally, we have only atime related errors in generic/003 output: sudo ./check generic/003 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #52 SMP PREEMPT_DYNAMIC Wed May 13 15:04:37 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 003 ERROR: access time has not been updated after accessing file1 first time ERROR: access time has not been updated after accessing file2 ERROR: access time has not been updated after accessing file3 second time ERROR: access time has not been updated after accessing file3 third time Silence is golden The generic/003 test-case needs to be disabled for HFS case because it cannot support the file/folder access times (atime). Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/3 cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260514195630.354206-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-05-19hfs: fix incorrect inode ID assignment in hfs_new_inode()Viacheslav Dubeyko
The xfstests' test-case generic/003 reveals the HFS volume corruption: sudo ./check generic/003 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #18 SMP PREEMPT_DYNAMIC Fri Mar 13 17:54:19 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/003 51s ... _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent sudo fsck.hfs -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. invalid MDB drNxtCNID Master Directory Block needs minor repair (1, 0) Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The reason of corruption is incorrect value of drNxtCNID (next CNID) in the MDB or superblock. The generic/003 test-case creates several new inodes: kernel: run fstests generic/003 hfs: hfs_mdb_get():179 next_id 16 hfs: hfs_mdb_get():179 next_id 16 hfs: hfs_new_inode():208 next_id 17 hfs: hfs_new_inode():208 next_id 18 hfs: hfs_mdb_commit():307 next_id 18 hfs: hfs_mdb_get():179 next_id 18 hfs: hfs_new_inode():208 next_id 19 hfs: hfs_new_inode():208 next_id 20 hfs_mdb_commit():307 next_id 20 hfs: hfs_mdb_get():179 next_id 20 hfs: hfs_new_inode():208 next_id 21 hfs: hfs_mdb_commit():307 next_id 21 hfs: hfs_mdb_get():179 next_id 21 The final assigned CNID was 21 but fsck correct it on 22. It is possible to see that the reason of the issue is incrementing the next_id value at first and assigning already incremented value to the inode->i_ino: struct inode *hfs_new_inode(...) { <skipped> next_id = atomic64_inc_return(&HFS_SB(sb)->next_id); <skipped> inode->i_ino = (u32)next_id; <skipped> } This patch fixes the issue by assigning the decremented value to inode->i_ino. Fixes: a06ec283e125 ("hfs: add logic of correcting a next unused CNID") cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260514195518.354108-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-05-19PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000 seriesZiyao Li
Older steppings of the Loongson-3C6000 series incorrectly report the supported link speeds on their PCIe bridges (device IDs 0x3c19, 0x3c29) as only 2.5 GT/s, despite the upstream bus supporting speeds from 2.5 GT/s up to 16 GT/s. As a result, since commit 774c71c52aa4 ("PCI/bwctrl: Enable only if more than one speed is supported"), bwctrl will be disabled if there's only one 2.5 GT/s value in vector 'supported_speeds'. Manually override the 'supported_speeds' field for affected PCIe bridges with those found on the upstream bus to correctly reflect the supported link speeds. Updating the speeds to reflect what the hardware actually supports avoids quirks in drivers consuming the speed information. This commit was originally found from AOSC OS[1]. Fixes: cd89edda4002 ("PCI: loongson: Add ACPI init support") Signed-off-by: Ayden Meng <aydenmeng@yeah.net> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> [Ziyao Li: move from drivers/pci/quirks.c to drivers/pci/controller/pci-loongson.c] Signed-off-by: Ziyao Li <liziyao@uniontech.com> [Xi Ruoyao: Fixed falling through logic, added debug log, Fixes tag and rebased to 7.0-rc7] Signed-off-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log, https://lore.kernel.org/all/9d815df3b33a63223112b97440c01247935363c1.camel@xry111.site] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Lain Fearyncess Yang <fsf@live.com> Tested-by: Ayden Meng <aydenmeng@yeah.net> Tested-by: Mingcong Bai <jeffbai@aosc.io> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Cc: stable@vger.kernel.org Link: https://github.com/AOSC-Tracking/linux/commit/4392f441363abdf6fa0a0433d73175a17f493454 Link: https://github.com/AOSC-Tracking/linux/pull/2 #1 Link: https://patch.msgid.link/20260412101731.107059-1-xry111@xry111.site
2026-05-19arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supplySherry Sun
The vpcie-supply property should reference the regulator that controls the actual M.2 power supply, not the W_DISABLE1# signal. On imx95-19x19-evk: - reg_pcie0 controls M.2 W_DISABLE1# signal - reg_m2_pwr controls the actual M.2 power supply Fix the vpcie-supply to use reg_m2_pwr for proper power control in PCIe endpoint mode. Fixes: 58bea81052d0 ("arm64: dts: imx95: add pcie1 ep overlay file and create pcie-ep dtb files") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supplySherry Sun
For PCIe endpoint mode, only M.2 power supply needs to be ensured. On imx8qxp-mek, the M.2 power is always on and cannot be controlled, while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the unnecessary vpcie-supply property from pcie0_ep node. Fixes: 1c9b0c6044c2 ("arm64: dts: imx8: use common imx-pcie0-ep.dtso to enable PCI ep function") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP propertiesSherry Sun
For PCIe endpoint mode, only M.2 power supply needs to be ensured. On imx8dxl-evk, the M.2 power is always on and cannot be controlled, while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the unnecessary vpcie-supply property from pcie0_ep node. Also remove reset-gpio as PCIe endpoint mode doesn't require reset control. Fixes: c1c4820b60d7 ("arm64: dts: imx8dxl-evk: Add pcie0-ep node and use unified pcie0 label") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx95-toradex-smarc: replace deprecated gpio propertyAntoine Gouby
Replace deprecated "gpio" property with "gpios" in regulator-vmmc-usdhc2 fixed regulator node. Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19ACPI: battery: Fix system wakeup on critical battery statusRafael J. Wysocki
Commit 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") changed the parent of the battery wakeup source to the platform device used for driver binding, but it forgot to update the acpi_pm_wakeup_event() call in acpi_battery_update() accordingly. Do it now to unbreak waking up the system on critical battery status during suspend-to-idle and during transitions to ACPI S3/S4. Fixes: 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 7.0+ <stable@vger.kernel.org> # 7.0+ Link: https://patch.msgid.link/12898712.O9o76ZdvQC@rafael.j.wysocki
2026-05-19Merge tag 'lsm-pr-20260519' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull lsm fix from Paul Moore: "A single LSM patch to add a missing credential mutex lock to the lsm_set_self_attr(2) syscall so it behaves similar to the associated procfs API and avoids issues with ptrace" * tag 'lsm-pr-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: lsm: hold cred_guard_mutex for lsm_set_self_attr()
2026-05-19x86/sev: Remove redundant ghcbs_initialized checks around __sev_{get,put}_ghcb()Nikunj A Dadhania
After 3645eb7e3915 ("x86/fred: Fix early boot failures on SEV-ES/SNP guests"), __sev_{get,put}_ghcb() handle the early-boot GHCB fallback internally, making the ghcbs_initialized guards in __set_pages_state() and svsm_perform_call_protocol() redundant. Remove them. Also initialize state->ghcb to NULL in the early-boot path of __sev_get_ghcb() so that the ghcb_state is well-defined for all callers, even though __sev_put_ghcb() currently returns early before reading it. No functional change intended. Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Nikunj A Dadhania <nikunj@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260518102230.3394603-1-nikunj@amd.com
2026-05-19Merge tag 'ata-7.1-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Make sure that the issuing of a deferred non-NCQ command via workqueue feature is only used when mixing NCQ and non-NCQ commands to the same link (i.e. return value ATA_DEFER_LINK), and nothing else. This way we will not incorrectly try to use the feature for e.g. PATA drivers - The deferred non-NCQ command was stored in a per-port struct. When using Port Multipliers with FIS-Based Switching, we would thus needlessly defer commands to all other links. Store the deferred QC in a per-link struct, such that Port Multipliers with FBS will get the same performance as before - The issuing of a deferred non-NCQ command via workqueue feature broke support for Port Multipliers using Command-Based Switching. The issuing of a deferred non-NCQ command via workqueue feature is not compatible with the use of ap->excl_link, which PMPs with CBS use for fairness (using implicit round robin) * tag 'ata-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-scsi: do not needlessly defer commands when using PMP with FBS ata: libata-scsi: do not use the deferred QC feature on PMPs with CBS ata: libata-scsi: do not use the deferred QC feature for ATA_DEFER_PORT ata: libata-scsi: improve readability of ata_scsi_qc_issue()
2026-05-19arm64: dts: freescale: imx{91,93}-phycore-som: Improve USDHC signalsChristoph Stoidner
Apply improved drive-strength values and pull-up/down configurations as devised from hardware measurements to improve signal quality on PHYTEC phyCORE-i.MX 91/93 SoM based boards. Also improve eMMC HS400 mode by setting property "fsl,strobe-dll-delay-target" which shifts the strobe DLL sampling window to the optimal position. Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx{91,93}-phycore-som: Adjust PHY RST drive-strengthPrimoz Fiser
According to measurements, the PHY reset signal shows an overshoot on the rising edge that exceeds the specified limits (max 2.1V) when using X4 strength on ENET2_RXC. Reduce drive-strength to X1 to decrease the overshoot and bring signal within specification limits. Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx{91,93}-phycore-som: Set BUCK5 in FPWM modePrimoz Fiser
Set PMIC BUCK5 mode to forced PWM (Pulse Width Modulation) mode instead of the default automatic PFM and PWM transition mode. FPWM mode produces less ripple on the output voltage rail under light load conditions. And since BUCK5 supplies SoC internal ADC reference voltage we need to keep voltage ripple to a minimum. This solves issues with the occasional ADC calibration procedure failures on phyCORE-i.MX91/93 SoM based boards. Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19x86/kvm/vmx: Fix VMX vs hrtimer_rearm_deferred()Peter Zijlstra
Vishal reported that KVM unit test 'x2apic' started failing after commit 0e98eb14814e ("entry: Prepare for deferred hrtimer rearming"). The reason is that KVM/VMX is injecting interrupts while it has interrupts disabled, for a context that will enable interrupts, this means that regs->flags.X86_EFLAGS_IF == 0 and irqentry_exit() will not do the right thing. Notably, irqentry_exit() must not call hrtimer_rearm_deferred() when the return context does not have IF set, because this will cause problems vs NMIs. Therefore, fix up the state after the injection. Fixes: 0e98eb14814e ("entry: Prepare for deferred hrtimer rearming") Reported-by: "Verma, Vishal L" <vishal.l.verma@intel.com> Suggested-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: "Verma, Vishal L" <vishal.l.verma@intel.com> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://patch.msgid.link/20260423155936.957351833@infradead.org Closes: https://lore.kernel.org/r/70cd3e97fbb796e2eb2ff8cd4b7614ada05a5f24.camel%40intel.com
2026-05-19x86/kvm/vmx: Move IRQ/NMI dispatch from KVM into x86 corePeter Zijlstra
Move the VMX interrupt dispatch magic into the x86 core code. This isolates KVM from the FRED/IDT decisions and reduces the amount of EXPORT_SYMBOL_FOR_KVM(). Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: "Verma, Vishal L" <vishal.l.verma@intel.com> Tested-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Binbin Wu <binbin.wu@linxu.intel.com> Acked-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260508091829.GO3126523@noisy.programming.kicks-ass.net
2026-05-19drm/i915/dmc_wl: Remove macro HAS_DMC_WAKELOCK()Gustavo Sousa
The macro HAS_DMC_WAKELOCK() is currently only used inside intel_dmc_wl.c and doesn't need to be exposed to the rest of the driver. Furthermore, there is a distinction between the display IP having support for the feature and the driver actually using it, so using HAS_DMC_WAKELOCK() outside of intel_dmc_wl.c would potentially be wrong anyway. Let's drop that macro. If other part of the driver needs to check if the driver is using the DMC wakelock feature, we would need actually to expose the function __intel_dmc_wl_supported(). Since HAS_DMC_WAKELOCK() was kind of self-documenting in the sense that it tells us what display IPs have support for the feature and we are now dropping it, let's also take this opportunity to add a documentation note on the subject. Reviewed-by: Daniel Charles <daniel.charles@intel.com> Link: https://patch.msgid.link/20260429-drop-has_dmc_wakelock-v1-1-62cb6fab1da0@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19arm64: dts: freescale: moduline-display-av123z7m-n17: add backlightMaud Spierings
Add the missing backlight. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: moduline-display-av101hdt-a10: add backlightMaud Spierings
Add the missing backlight driver. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panelLiu Ying
Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB. Move the common parts from imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso into imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi for reuse by the tm050rdh03 overlay file. The panel connects with the QSB board through an adapter board[1] designed by NXP. Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1] Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx: Add common imx-m2-pcie.dtso to enable PCIe on M.2 connectorSherry Sun
Some i.MX boards (i.MX8MP EVK and i.MX95-15x15 EVK) have M.2 connectors that are physically wired to both USDHC and PCIe controllers. The default device tree enables USDHC for SDIO WiFi modules and disables PCIe to avoid regulator conflicts. Add a common imx-m2-pcie.dtso that can be applied to enable PCIe and disable USDHC when a PCIe module is installed in the M.2 connector. This creates the following DTB files: - imx8mp-evk-pcie.dtb: i.MX8MP EVK with PCIe enabled - imx95-15x15-evk-pcie.dtb: i.MX95-15x15 EVK with PCIe enabled Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dtsSherry Sun
Disable the PCIe bus in the default device tree to avoid shared regulator conflicts between SDIO and PCIe buses. The non-deterministic probe order between these two buses can break the PCIe initialization sequence, causing PCIe devices to fail detection intermittently. On i.MX95-15x15 EVK board, the M.2 connector is physically wired to both USDHC3 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so enable SDIO WiFi in the default imx95-15x15-evk.dts. Add 'm2_usdhc' label to USDHC3 to support device tree overlay for PCIe modules. Users who need PCIe can use imx95-15x15-evk-pcie.dtb (added in a follow-up patch) which applies an overlay to enable PCIe and disable USDHC3. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx8mp-evk: Disable PCIe bus in the default dtsSherry Sun
Disable the PCIe bus in the default device tree to avoid shared regulator conflicts between SDIO and PCIe buses. The non-deterministic probe order between these two buses can break the PCIe initialization sequence, causing PCIe devices to fail detection intermittently. On i.MX8MP EVK board, the M.2 connector is physically wired to both USDHC1 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so enable the SDIO WiFi in the default imx8mp-evk.dts. Add 'm2_usdhc' label to USDHC1 to support device tree overlay for PCIe modules. Users who need PCIe can use imx8mp-evk-pcie.dtb (added in a follow-up patch) which applies an overlay to enable PCIe and disable USDHC1. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx943-evk: Add pcie[0,1] and pcie-ep[0,1] supportRichard Zhu
Add pcie[0,1] and pcie-ep[0,1] support. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx943: Add pcie1 and pcie1-ep supportsRichard Zhu
Add pcie1 and pcie1-ep supports. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx94: Add pcie0 and pcie0-ep supportsRichard Zhu
Add pcie0 and pcie0-ep supports. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx8mn: Sort ifm VHIP4 EvalBoard Makefile entriesMarek Vasut
Sort the Makefile entries alphabetically. No functional change. Signed-off-by: Marek Vasut <marex@nabladev.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx95-verdin-ivy: fix RS485 RTS polarityFrancesco Dolcini
Fix the RS485 functionality, the RS485 RTS signal is active high on Ivy. Fixes: f33a1f9a942c ("arm64: dts: freescale: imx95-verdin: Add Ivy carrier board") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx95-verdin: Add ZinniaFrancesco Dolcini
Add Zinnia Carrier Board mated with Verdin iMX95. It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O, 2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector for a modem, USB and SD card interfaces. Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl groupFrancesco Dolcini
Some carrier board reuse the UART_2 control signals as GPIO, split the pinctrl RTS/CTS in separated nodes to maximize flexibility. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx8mp-verdin: Add ZinniaFrancesco Dolcini
Add Zinnia Carrier Board mated with Verdin iMX8M Plus. It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O, 2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector for a modem, USB and SD card interfaces. Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl groupFrancesco Dolcini
Some carrier board reuse the UART_2 control signals as GPIO, split the pinctrl RTS/CTS in separated nodes to maximize flexibility. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx8mm-verdin: Add ZinniaFrancesco Dolcini
Add Zinnia Carrier Board mated with Verdin iMX8M Mini. It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O, 1 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector for a modem, USB and SD card interfaces. Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl groupFrancesco Dolcini
Some carrier board reuse the UART_2 control signals as GPIO, split the pinctrl RTS/CTS in separated nodes to maximize flexibility. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia boardFrancesco Dolcini
Add Toradex Verdin Zinnia carrier board mated with Verdin iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95. Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flagsKrzysztof Kozlowski
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED. Correct the Type-C int-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19firmware: arm_ffa: Honor partition info descriptor sizeJamie Nguyen
FFA_PARTITION_INFO_GET_REGS reports the size of each partition information descriptor in x2[63:48]. However, __ffa_partition_info_get_regs() walks the returned register payload with a hardcoded 24-byte stride (regs += 3), even though the size is already read into buf_sz. That works for the FF-A v1.1/v1.2 24-byte descriptor layout, where each descriptor consumes three registers. Newer FF-A revisions can extend the descriptor while keeping the existing fields at the front. For example, a 48-byte descriptor consumes six registers, so advancing by only three registers desynchronises the parser and can make it read subsequent entries from the middle of a descriptor. Use the advertised descriptor size to derive the register stride. Validate that the size is register-aligned, large enough for the fields parsed by the driver, and that the requested number of descriptors fits in the returned x3..x17 register window. The driver still copies only the fields it understands, but now skips over any trailing descriptor fields correctly. Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Suggested-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Link: https://patch.msgid.link/20260518203116.42624-1-jamien@nvidia.com (sudeep.holla: Minor rewordng of the commit message and subject) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-19bio-integrity-fs: pass data iter to bio_integrity_verify()Caleb Sander Mateos
bio_integrity_verify() expects the passed struct bvec_iter to be an iterator over bio data, not integrity. So construct a separate data bvec_iter without the bio_integrity_bytes() conversion and pass it to bio_integrity_verify() instead of bip_iter. Fixes: 0bde8a12b554 ("block: add fs_bio_integrity helpers") Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260513182924.1753582-1-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-19ipmi: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. While touching these arrays, unify usage of whitespace in the list terminator. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Message-ID: <20260519150156.1590826-2-u.kleine-koenig@baylibre.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19drm/i915/bw: Extract get_display_bw_params()Gustavo Sousa
Just like it is done for the platform-specific bandwidth parameters, use a separate function named get_display_bw_params() to return the display IP-specific parameters. This simplifies intel_bw_init_hw() by having just one call for each of the *_get_bw_info() functions. v2: - Prefer to call get_display_bw_params() only once in intel_bw_init_hw() instead of having multiple calls in each of the affected *_get_bw_info() functions. (Jani) v3: - Call get_display_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Return &gen11_bw_params only if display version is 11. (Matt) v4: - Like done with get_soc_bw_params(), drop drm_WARN() when no display IP is matched. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-5-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Rename struct intel_sa_info to intel_display_bw_paramsGustavo Sousa
To align with struct intel_platform_bw_params, rename struct intel_sa_info to intel_display_bw_params. Also add comments to contrast their purposes. v2: - Use gen11 and gen12 as prefixes for ICL's and TGL's display-specific parameters variables. (Matt) - Prefer to use "display" instead of "disp" in variable names. (Jani) - Drop the redundant "disp" from the variable names. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-4-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Deduplicate intel_sa_info instancesGustavo Sousa
Now that intel_sa_info contains bandwidth parameters specific to the display IP, we can drop many duplicates and reuse from previous releases. Let's do that and also simplify intel_bw_init_hw() while at it. v2: - Drop rkl_sa_info and reuse icl_sa_info. (Matt) - Add comment explaining RKL's display's peculiarity on using ICL's parameters. (Matt) - Don't rename xelpdp_sa_info to mtl_sa_info. Renaming of instances to use IP names will be done in upcoming changes. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-3-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Extract platform-specific parametersGustavo Sousa
We got confirmation from the hardware team that the bandwidth parameters deprogbwlimit and derating are platform-specific and not tied to the display IP. As such, let's make sure that we use platform checks for those. The rest of the members of struct intel_sa_info are tied to the display IP and we will deal with them as a follow-up. v2: - Use good old if-ladder instead of weird-looking pattern "assign ret, check platform, then return ret". (Jani, Matt) - Have a single call site for get_platform_bw_params() and pass the result as parameter to the *_get_bw_info() functions. (Jani) - Avoid using "plat" as abbreviation for "platform". (Jani) - s/_plat_bw_params/_bw_params/, since all of the instances are prefixed with platform names. (Jani) - s/struct intel_platform_bw_params/struct intel_soc_bw_params/. (Matt) - Do not return a default value; prefer to return NULL and intentionally cause a NULL pointer dereference if a platform is missing. (Gustavo) v3: - Call get_soc_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Combine if-ladder branches for adl_s_bw_params into a single one. (Matt) - Flatten if-ladder by checking for WCL before PTL (as opposed to checking for WCL inside the brace for PTL). (Matt) - Bail out of intel_bw_init_hw() if display version is below 11. (Gustavo) v4: - Drop drm_WARN() when no platform was matched to avoid special-casing DG2 and any other platform that doesn't use SoC-specific parameters. (Jani) - Pass dram_info to get_soc_bw_params() to keep a single call to intel_dram_info(). (Jani) - Don't use 2 separate if-ladders (one for client and another for discrete platforms) and keep a single one for simplicity. (Gustavo) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-2-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Don't call intel_dram_info() too earlyGustavo Sousa
If we end-up bailing early from intel_bw_init_hw() due to !HAS_DISPLAY(display), the call to intel_dram_info() to initialize dram_info will be meaningless. Move the call to be done after that check. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-1-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19dmaengine: Move MODULE_DEVICE_TABLE next to the table itselfKrzysztof Kozlowski
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it exports, because this is easier to read and verify. It also makes more sense since #ifdef for ACPI or OF could hide both of them. Most of the drivers already have this correctly placed, so adjust the missing ones. No functional impact. Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260514060525.9253-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dt-bindings: dma: qcom,gpi: Document the Eliza GPI DMA engineAbel Vesa
Document the GPI DMA engine found on the Eliza SoC. It is fully compatible with the GPI DMA engine found on SM6350, thus using qcom,sm6350-gpi-dma as fallback compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Link: https://patch.msgid.link/20260515-eliza-gpi-dma-v2-1-1255b43d5ca9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dmaengine: mmp_pdma: add SpacemiT K3 supportGuodong Xu
SpacemiT K3 reuses most of the PDMA IP design found on K1, with one difference being the extended DRCMR base address. Add "spacemit,k3-pdma" compatible string and define a new mmp_pdma_ops for K3 PDMA. Signed-off-by: Guodong Xu <guodong@riscstar.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260518-k3-pdma-v6-3-67fdf319a8f8@linux.spacemit.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dmaengine: mmp_pdma: refactor DRCMR access with helper functionGuodong Xu
Refactor the DRCMR macro into a helper function mmp_pdma_get_drcmr() to support variable extended DRCMR base addresses across different PDMA implementations, such as SpacemiT K3. Signed-off-by: Guodong Xu <guodong@riscstar.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260518-k3-pdma-v6-2-67fdf319a8f8@linux.spacemit.com Signed-off-by: Vinod Koul <vkoul@kernel.org>