summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-15drm/amd/display: Fix preferred link rate for NUTMEGTimur Kristóf
When there is a preferred link rate setting, it needs to be applied to both the current and initial link rate. This was regressed by a "coding style" fix, which caused the current link rate to not respect the preferred value. This commit restores the functionality of NUTMEG, the DP bridge encoder found on old APUs such as Kaveri. Fixes: a62346043a89 ("drm/amd/display: Fix coding style issue") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5465 Cc: Chuanyu Tseng <Chuanyu.Tseng@amd.com> Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-15drm/amd/display: Fix DM I2C teardown raceGeoffrey McRae
DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr Fixes: 5b3eca05cfb0 ("drm/amd/display: Use devm_i2c_add_adapter to simplify i2c cleanup logic") Signed-off-by: Geoffrey McRae <geoffrey.mcrae@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-15drm/amdgpu: deduplicate JPEG v5.0 interrupt routineAndre Luiz Batista Bueno
Both jpeg_v5_0_1.c and jpeg_v5_0_2.c implement identical interrupt processing routines. To avoid code duplication, make the implementation in jpeg_v5_0_1.c non-static and call it directly from jpeg_v5_0_2.c. Signed-off-by: Andre Luiz Batista Bueno <andrebueno.mac@gmail.com> Co-developed-by: Enzo Furegatti Spinella <enzo.spinella@usp.br> Signed-off-by: Enzo Furegatti Spinella <enzo.spinella@usp.br> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-15drm/amdkfd: Do not fail process debugfs setup on debugfs errorsSrinivasan Shanmugam
debugfs is intended for debugging only, and failures to create debugfs entries should not affect normal operation. Remove the check for debugfs_create_dir() in kfd_debugfs_add_process(). If debugfs entries cannot be created, continue without them instead of reporting an unnecessary error. Fixes: 325de6bf3328 ("drm/amdkfd: expose pasid of secondary contexts by debugfs") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Zhu Lingshan <lingshan.zhu@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-15PCI: dwc: Use common speed conversion functionHans Zhang
Replace the private switch-based speed conversion in dw_pcie_link_set_max_speed() with the public pci_bus_speed2lnkctl2() function. This eliminates duplicate conversion logic and ensures consistency with other PCIe drivers, while handling invalid speeds by falling back to hardware capabilities. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260407130450.1489318-4-18255117159@163.com
2026-07-15PCI: Move pci_bus_speed2lnkctl2() to public headerHans Zhang
Move the static array-based pci_bus_speed2lnkctl2() function from bwctrl.c to pci.h as a public inline function. This provides efficient O(1) speed-to-LNKCTL2 value conversion using static array lookup, maintaining optimal performance while enabling code reuse by other PCIe drivers. Signed-off-by: Hans Zhang <18255117159@163.com> [mani: replaced <asm/bug.h> with <linux/bug.h> as per checkpatch] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260407130450.1489318-3-18255117159@163.com
2026-07-15PCI: Add public pcie_valid_speed() for shared validationHans Zhang
Extract the PCIe speed validation logic from bwctrl.c's static pcie_valid_speed() into a public static inline function in pci.h. This allows consistent speed range checks (2.5GT/s to 64.0GT/s) across multiple drivers and functions, avoiding duplicate code and ensuring validation consistency as per PCIe specifications. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260407130450.1489318-2-18255117159@163.com
2026-07-15cpu/hotplug: Remove CPUHP_AP_ARM_CORESIGHT_CTI_STARTINGZenghui Yu
Thestate CPUHP_AP_ARM_CORESIGHT_CTI_STARTING has become unused since commit 59213b4be5c1 ("coresight: cti: Remove CPU power management code"). Remove it as well. Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260711135154.94276-1-zenghui.yu@linux.dev
2026-07-15calibrate: Rework delay timer calibrationThomas Gleixner
The header define in asm/timex,h and the naming of the function to read the delay timer are confusing at best. Convert it to a config switch selected by the archictures which provide the functionality and rename the function to delay_read_timer(), which makes the purpose clear. Move the declaration to linux/delay.h where it belongs. Remove the resulting empty asm/timex.h files as well. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260410120317.978403520@kernel.org
2026-07-15treewide: Remove CLOCK_TICK_RATEThomas Gleixner
This has been scheduled for removal more than a decade ago and the comments related to it have been dutifully ignored. The last dependencies are gone. Remove it along with various now empty asm/timex.h files. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/20260410120317.910770161@kernel.org
2026-07-15x86: Use PIT_TICK_RATE instead of CLOCK_TICK_RATEThomas Gleixner
CLOCK_TICK_RATE is only used in x86 but defined all over the tree for no reason with comments that it's scheduled for removal for more than a decade. Use PIT_TICK_RATE for registering refined jiffies to get rid of the last dependency. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260410120317.843419270@kernel.org
2026-07-15wifi: nxp: add nxpwifi driver for IW61xJeff Chen
Add support for the NXP IW61x wireless devices. The nxpwifi driver implements a full-MAC design and integrates with cfg80211 for configuration and control, supporting both station (STA) and access point (AP) modes. The driver provides a firmware-based command/event interface using TLV messages, with the core handling command processing, event dispatching, and device lifecycle management. A SDIO transport layer is implemented to support IW61x devices. Key features include: - 802.11n/ac/ax (HT/VHT/HE) capability support - Scan, association, and connection management - Data path handling for TX/RX, including aggregation and reorder - WMM QoS support and traffic prioritization - 802.11h (DFS/TPC) support for regulatory compliance - cfg80211 integration for STA and AP operations - Debugfs and ethtool support - Wake-on-LAN support The driver translates cfg80211 configuration into firmware commands and implements required data path processing in software where needed. Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
2026-07-15ASoC: tegra: Simplify error handlingMark Brown
bui duc phuc <phucduc.bui@gmail.com> says: This series contains a few small cleanups for the Tegra ASoC drivers. - Use dev_err_probe() for regmap initialization failures. - Return the original error from snd_soc_add_component_controls(). - Use devm_clk_get_optional() for the optional sync_input clock. Overall, this simplifies the error paths and makes the code more consistent. Link: https://patch.msgid.link/20260715051115.17385-1-phucduc.bui@gmail.com
2026-07-15ASoC: tegra: tegra210: Use devm_clk_get_optional() for sync_input clockbui duc phuc
The existing comment states that the sync_input clock is only needed when another I/O is configured to use the current I2S instance as its input clock, and the current code does not treat its absence as an error. Use devm_clk_get_optional() to match the existing behaviour while still reporting real failures via dev_err_probe(). Update the comment to describe the optional nature of the clock rather than the previous error handling. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260715051115.17385-5-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-15ASoC: tegra: tegra210_amx: Return the original error directlybui duc phuc
snd_soc_add_component_controls() already reports failures internally. Return its error code directly instead of logging the error again in the component probe callback. Also remove the now unnecessary local error variable. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260715051115.17385-4-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-15ASoC: tegra: tegra210_adx: Return the original error directlybui duc phuc
snd_soc_add_component_controls() already reports failures internally. Return its error code directly instead of logging the error again in the component probe callback. Also remove the now unnecessary local error variable. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260715051115.17385-3-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-15ASoC: tegra: tegra20_das: Use dev_err_probe() for error handlingbui duc phuc
Replace the existing dev_err() and PTR_ERR() sequence with dev_err_probe(), preserving the original error code while simplifying the error handling. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260715051115.17385-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-15KVM: riscv: Fix Spectre-v1 in vector register accessZongmin Zhou
User-controlled register indices from the ONE_REG ioctl are used to index into the vector register buffer (v0..v31). Sanitize the calculated offset with array_index_nospec() to prevent speculative out-of-bounds access. Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260715030818.75657-1-min_halo@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-15drm/panthor: Check debugfs GEM lock initializationLinmao Li
drmm_mutex_init() can fail while registering the managed cleanup action. When that happens, drmm_add_action_or_reset() destroys the mutex before returning the error. Continuing initialization would therefore leave the debugfs GEM object list with an unusable lock. Propagate the error as is already done for the other managed mutexes in panthor_device_init(). Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260713082912.321021-1-lilinmao@kylinos.cn Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-07-15drm/panthor: return error on truncated firmwareOsama Abdelkader
panthor_fw_load() detects truncated firmware images, but jumps to the common cleanup path without setting ret. If no previous error was recorded, the function can return 0 and treat the invalid firmware as successfully loaded. Set ret to -EINVAL before leaving the truncated-image path. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260714163056.22329-1-osama.abdelkader@gmail.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-07-15gpiolib: tolerate gpio-hogs lacking a hogging stateDaniel Golle
Commit d1d564ec4992 ("gpio: move hogs into GPIO core") made gpiochip_add_hog() return -EINVAL for hog nodes lacking any of the 'input', 'output-low' or 'output-high' properties. The error is propagated by gpiochip_hog_lines() and fails registration of the whole GPIO chip. The previous OF-specific implementation tolerated such nodes: of_parse_own_gpio() warned "no hogging state specified, bailing out" and of_gpiochip_add_hog() stopped processing the node without failing chip registration. Some boards deliberately ship hog nodes without a hogging state in their base devicetree and supply the state via overlay, e.g. the PCIe slot key selection hogs on the BananaPi R4 Pro added in commit e309fa232d12 ("arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling"), as the polarity set in the base devicetree could not be overridden from an overlay. Booting such a board without an overlay applied now fails to register the gpiochip. On the BananaPi R4 Pro this means the MT7988A pinctrl device fails to probe, all peripherals including the console UART defer forever, and the board finally hangs when clk_disable_unused() gates the clocks of the UART still in use by earlycon: gpiochip_add_data_with_key: GPIOs 512..595 (pinctrl_moore) failed to register, -22 mt7988-pinctrl 1001f000.pinctrl: error -EINVAL: Failed to add gpio_chip ... clk: Disabling unused clocks (hangs) Restore the previous behaviour by warning about hog nodes lacking a hogging state and skipping them instead of failing the registration of the whole GPIO chip. Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core") Cc: stable@vger.kernel.org Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/4c67cf0839ccf57db35a826df6d8fc779531509a.1783974733.git.daniel@makrotopia.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-15gpio: sloppy-logic-analyzer: Fix memory leak in gpio_la_poll_probe()Abdun Nihaal
The memory allocated for priv->blob.data is not freed in the error paths that follow the fops_buf_size_set() call in gpio_la_poll_probe(), as well as in the remove function. Fix that by using device managed action to free the memory on remove. Fixes: 7828b7bbbf20 ("gpio: add sloppy logic analyzer using polling") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20260715075311.527753-1-nihaal@cse.iitm.ac.in Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-15drm/i915/selftests: Fix GT PM sort comparatorsEmre Cecanpunar
Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar <emreleno@gmail.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com
2026-07-15Merge tag 'arm-feature-deprecation-for-7.3' of ↵Alexandre Belloni
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into soc/arm ARM: platform and feature deprecation for 7.3 This is an attempt to bring the source code to the state that we discussed back in 2024, regarding a timeline for deprecating and removing features, in particular platforms and ABIs that are basically unused and are also getting in the way of maintenance. The earlier consensus was to remove these features in 2025 or 2026 after the corresponding LTS kernel release. I would suggest pushing these to early 2027 now, see the patch description for details on each one: - all board files that are still not converted to DT (except for OMAP1 and S3C) - iWMMXt FPU support - ARMv6/ARM1136r0 (not ARMv6K/ARM1136r1/ARM1176) along with the OMAP24xx and i.MX31 SoCs using it - Cortex-M3/M4/M7 based microcontroller support (stm32, imxrt, lpc18xx, samv7) - LSI Axxia platform - OABI, OABI-compat and NWFPE are confined to StrongARM based builds and scheduled for removal once StrongARM is gone. - DEPRECATED_PARAM_STRUCT, which was originally scheduled for removal in 2006 (!) The ARCH_S3C64XX platform was scheduled for removal in 2024, but is still actively used and will get removed once Mark Brown stops using it. The OMAP1 platform has some remaining boardfiles and is expected to get converted to DT. Big-endian ARMv7 CPU support is not scheduled for removal but marked as broken the same way as ARM64 has, to reduce the need for testing unused configurations. This may be removed in the future if arm64 does it as well. Note that big-endian ARMv5 support is can still be enabled since the patches to revive little-endianm mode are still fresh. Regarding actually removing the code, I would suggest linux-7.4 (January 2027), removing both the board files and any drivers that have either become newly unused or were missed in a previous machine removal series, followed by removing support for then unused CPUs a release later. Links to previous discussion: https://lore.kernel.org/linux-arm-kernel/20210109174357.GB1551@shell.armlinux.org.uk/ https://lore.kernel.org/linux-arm-kernel/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/ https://lore.kernel.org/all/20241204102904.1863796-1-arnd@kernel.org/ https://lore.kernel.org/all/20260701212353.2196041-1-arnd@kernel.org/ Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-15soc/tegra: pmc: Don't register sys-off handler for multi-socket devicesJon Hunter
The kernel does not permit a device to register multiple sys-off handlers for non-default priority levels. Hence, for multi-socket Tegra devices, registering the sys-off handler in the Tegra PMC driver (which uses the low priority level) more than once fails. The Tegra PMC sys-off handler is supported for all current generations of the Tegra SoC, however, it is only used as a low priority handler if everything else fails. For example, on Tegra264 the EFI reboot handler is called to restart the device. Therefore, for multi-socket devices, skip the registering of the sys-off handler to because this is not critical. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-07-15staging: rtl8723bs: Remove space after castJason Winter
Remove the unnecessary space after a cast in _rtw_init_recv_priv() to fix a checkpatch.pl coding style warning. Signed-off-by: Jason Winter <jjx@live.nl> Link: https://patch.msgid.link/BESP194MB2832DD527B23F20198ECDD9CB8FB2@BESP194MB2832.EURP194.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-15iommu/amd: Fix nested domain leakTycho Andersen (AMD)
A couple of runs of different AI tools have generated something like the following bug report: In nested_domain_free(), when refcount_dec_and_test() returns false (other nested domains still reference the same gdom_info), the function returns without calling kfree(ndom), leaking the nested_domain structure. This problem wasn't introduced by this patch, but exists in the code from commit 757d2b1fdf5b that the patch modifies. Each nested_domain (ndom) is allocated individually in amd_iommu_alloc_domain_nested() via kzalloc_obj(*ndom). The .free callback is the sole point responsible for freeing this domain. When the refcount is > 0, only the xa_unlock_irqrestore is performed and the function returns, leaving ndom permanently allocated. This leak occurs every time a nested domain sharing a gDomID is destroyed while other domains still use that gDomID. There is a similar leak later in this function in the WARN_ON() test when the mapping is already NULL. Switch to a RAII-based cleanup for ndom, since it should always be freed in this function. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-15iommu/amd: Fix IRQ unsafe locking in gdom allocationTycho Andersen (AMD)
Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-15drm/i915/display: expose blend mode on alpha-capable planesChaitanya Kumar Borah
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The cursor (ARGB8888, all platforms) and the VLV/CHV primary and sprite planes trip this. Userspace has historically assumed premultiplied blending when the property is not attached, so it is safe to assume that planes that did not expose the property already blended with fixed pre-multiplied alpha in hardware. Therefore, expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to match that assumption and silence the warning. The cursor call is unconditional; the primary and sprite calls are gated to VLV/CHV, the only platforms whose format lists include alpha formats. Assisted-by: Claude:claude-opus-4-8 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Leandro Ribeiro <leandro.ribeiro@collabora.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16623 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260715054221.451421-1-chaitanya.kumar.borah@intel.com
2026-07-15selftests/bpf: Fix fib_lookup VLAN tests on hosts with forwarding onAvinash Duduskar
The VLAN tests assume the test namespace starts with IPv4 forwarding off, but a new netns copies conf/all and conf/default from init_net (devinet_init_net(), with net.core.devconf_inherit_init_net at its default), so on a host with net.ipv4.conf.all.forwarding=1 the devices in the netns come up with forwarding already enabled. IPv6 uses compiled defaults at the same sysctl value, so only the IPv4 arms are affected. Two arms break as a result. The arms that expect BPF_FIB_LKUP_RET_FWD_DISABLED see the lookup pass the forwarding check and return SUCCESS instead, so fib_lookup fails: test_fib_lookup:FAIL:fib_lookup_ret unexpected fib_lookup_ret: actual 0 != expected 5 Pin forwarding off in setup_netns() before the devices are created; the existing per-device writes still enable it where the tests need it. The netns arm has the opposite problem. It checks that a VLAN device in another netns is not resolved and expects NOT_FWDED. The lookup runs against the caller's FIB, which had no route to the destination, so a kernel that resolved the moved device anyway also returned NOT_FWDED and the arm passed regardless of the namespace check. On a forwarding-on host, where the resolved device clears the forwarding gate, this makes the arm a tautology. Add a route so a resolved device returns SUCCESS and the arm can tell the two apart. Verified by deleting the netns check from bpf_fib_vlan_input_dev(): with the fix the arm fails on both a forwarding-off host (actual 5) and a forwarding-on host (actual 0), where before it passed on the latter. The real kernel passes the full suite on both. Fixes: e54a87872e34 ("selftests/bpf: Add bpf_fib_lookup() VLAN flag tests") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260713163826.D70201F000E9@smtp.kernel.org/ Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com> Link: https://lore.kernel.org/bpf/20260715100349.2684391-1-avinash.duduskar@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15drm/etnaviv: check MMUv2 status after resetLucas Stach
A full GPU reset is the only way to disable the MMUv2 and the driver depends on the MMU being disabled after a reset to be able to properly restart the GPU. Validate this assumption by checking that the reset actually did disable the MMU. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patch.msgid.link/20260511085148.652256-2-l.stach@pengutronix.de Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2026-07-15drm/etnaviv: check all modules for idle after resetLucas Stach
While the FE is an important part of the GPU, which needs to be idle after reset, all other modules should be idle after a proper reset. Check all present modules for being idle to determine whether the reset was successful. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Link: https://patch.msgid.link/20260511085148.652256-1-l.stach@pengutronix.de Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2026-07-15KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid guest stateSean Christopherson
Put all vmcs12 pages if KVM synthesizes a nested VM-Exit due to invalid guest while emulating VMLAUNCH or VMRESUME. The invalid guest state path doesn't use nested_vmx_vmexit() as that API is intended to be used if and only if L2 is active, and the open coded equivalent neglects to put the vmcs12 pages. Failure to put the vmcs12 pages leaks any pinned pages (and/or mappings) if L1 retries VMLAUNCH/VMRESUME. Note, the !from_vmenter scenario doesn't suffer the same problem, as vmx_get_nested_state_pages() only gets/pins/maps the vmcs12 pages if L2 is active, i.e. if a "full" VM-Exit is guaranteed before KVM will retry getting vmcs12 pages. Fixes: 96c66e87deee ("KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page") Fixes: 3278e0492554 ("KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt descriptor table") Fixes: fe1911aa443e ("KVM: nVMX: Use kvm_vcpu_map() to get/pin vmcs12's APIC-access page") Reported-by: Minh Nguyen <minhnguyen.080505@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-15Merge tag 'kvm-s390-master-7.2-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: Fixes for 7.2 - more gmap KVM memory management fixes - PCI passthru fixes
2026-07-15Merge tag 'kvm-x86-fixes-7.2-rc4' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM x86 fixes for 7.2-rcN - Fix a bug where KVM will trigger a UAF if updating IOMMU IRTEs fails when registering an IRQ-bypass producer. - Ignore pending PV EOI instead of BUG()ing the host if the feature was disabled by the guest. - Fix nVMX bugs where KVM would run L1 with an L1-controlled CR3 after a failed "late" consistency check when KVM is NOT using EPT. - Disallow intra-host migration/mirroring of SNP VMs as KVM doesn't yet support moving/mirroring SNP state. - Fix a TOCTOU bug in KVM's handling of the "trusted" CPUID for TDX guests. - Fix a NULL pointer deref in trace_kvm_inj_exception() where a change to the core infrastructure missed KVM's unique (ab)use of __print_symbolic().
2026-07-15Merge tag 'kvmarm-fixes-7.2-2' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.2, take #2 - Move locking for kvm_io_bus_get_dev() into the caller, ensuring race-free checks that the returned object is of the correct type - Fix initialisation of the page-table walk level when relaxing permissions - Correctly update the XN attribute when relaxing permissions - Fix the sign extension of loads from emulated MMIO regions - Assorted collection of fixes for pKVM's FFA proxy, together with a couple of FFA driver adjustments
2026-07-15Merge tag 'kvmarm-fixes-7.2-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.2, take #1 - Fix an accounting buglet when reclaiming pages from a protected guest - Fix a bunch of architectural compliance issues when injecting a synthesised exception, most of which were missing the PSTATE.IL bit indicating a 32bit-wide instruction - Another set of fixes addressing issues with translation of VNCR_EL2, including corner cases where the guest point that register at a RO page... - Don't warn when trapping accesses to ZCR_EL2 from an L2 guest, as that's not unexpected at all - Address a bunch of races with LPI migration vs LPIs being disabled - Fix a total howler of a bug combining FEAT_MOPS and NV, resulting in exception returning in the wrong place... - Coerce Fuad Tabba into a reviewer role, and may his Inbox catch fire!
2026-07-15Merge branch 'bpf-reject-negative-const-offsets-for-buffer-pointers'Eduard Zingerman
Sun Jian says: ==================== bpf: Reject negative const offsets for buffer pointers Reject negative effective offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses. Calculate the effective access start using signed arithmetic to prevent unsigned access-end accounting from wrapping, and cover both load-time rejection and the raw tracepoint writable attach-time path. --- Changes in v5: - Simplify __check_buffer_access() to reject a negative effective start after confirming that var_off is constant. Validate the combined offset instead of rejecting negative instruction offsets separately. Drop the duplicate BPF_MAX_VAR_OFF check because pointer arithmetic already bounds constant offsets, and remove the redundant size < 0 check. - Switch the raw tracepoint writable attach tests from nbd_send_request to bpf_testmod_test_writable_bare_tp, avoiding the NBD configuration dependency and its false-pass condition. - Split the attach coverage into named subtests and require bpf_raw_tracepoint_open() to return -EINVAL. - Add verifier coverage for a negative constant PTR_TO_BUF offset. Changes in v4: - Correct the Fixes tag to point to 022ac0750883, where pointer offsets were folded into reg->var_off. - Drop the end > U32_MAX check, which is unreachable after bounding const var_off with BPF_MAX_VAR_OFF while keeping instruction offsets and access sizes bounded. Changes in v3: - Check constant var_off against +/-BPF_MAX_VAR_OFF before computing the effective access range, matching the existing verifier pointer offset convention. - Keep explicit rejection of negative instruction offsets and keep bounded negative constant var_off valid when the effective offset is non-negative. Changes in v2: - Split the kernel fix and selftests into separate patches. - Add an attach-time raw tracepoint writable test that exercises max_tp_access against nbd_send_request's writable size. - Adjust selftest formatting to use the 100 character line width. Tested: - ./test_progs -v -t verifier_raw_tp_writable - ./test_progs -v -t verifier_ptr_to_buf - ./test_progs -v -t raw_tp_writable_reject_bad_access - ./test_progs -v -t raw_tp_writable_test_run v4: https://lore.kernel.org/bpf/20260708090151.151729-1-sun.jian.kdev@gmail.com/ v3: https://lore.kernel.org/bpf/20260708040715.116680-1-sun.jian.kdev@gmail.com/ v2: https://lore.kernel.org/bpf/20260707060804.93561-1-sun.jian.kdev@gmail.com/ v1: https://lore.kernel.org/bpf/20260703035137.109608-1-sun.jian.kdev@gmail.com/ ==================== Link: https://patch.msgid.link/20260714093846.18159-1-sun.jian.kdev@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-15selftests/bpf: Cover negative buffer pointer offsetsSun Jian
Add verifier coverage for constant negative offsets on PTR_TO_TP_BUFFER and PTR_TO_BUF pointers. Both programs adjust the buffer pointer by -8 and access it at offset zero, so the negative effective start must be rejected at load time. Switch the raw tracepoint writable attach checks from nbd_send_request to bpf_testmod_test_writable_bare_tp, avoiding a dependency on the NBD tracepoint. Keep the existing past-end case and add a case with a negative var_off compensated by a positive instruction offset. The effective start remains non-negative, so the program loads, but its access end exceeds the writable context size and bpf_raw_tracepoint_open() must return -EINVAL. Cc: stable@vger.kernel.org # 5.2.0 Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Link: https://patch.msgid.link/20260714093846.18159-3-sun.jian.kdev@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-15bpf: Reject negative const offsets for buffer pointersSun Jian
The verifier rejects variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses, but it currently accepts a constant negative offset produced by pointer arithmetic. Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") moved constant pointer offsets from reg->off to reg->var_off. However, __check_buffer_access() continued to check only the instruction offset. An access with reg->var_off equal to -8 and an instruction offset of zero therefore passes verification. For writable raw tracepoints, the access end is also calculated from the unsigned reg->var_off.value. An eight-byte access starting at -8 wraps the calculated end to zero, allowing the program to load and attach without increasing max_tp_access. After ensuring that reg->var_off is constant, calculate the effective access start using signed arithmetic and reject it when it is negative. Use the validated start to calculate the access end for both PTR_TO_TP_BUFFER and PTR_TO_BUF. Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers") Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Cc: stable@vger.kernel.org # 5.2.0 Link: https://patch.msgid.link/20260714093846.18159-2-sun.jian.kdev@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-15Merge branch 'bpf-sockmap-fix-fionread-for-sockets-without-a-verdict-program'Kumar Kartikeya Dwivedi
Mattia Meleleo says: ==================== bpf, sockmap: Fix FIONREAD for sockets without a verdict program Sockets added to a sockmap/sockhash with no stream/skb verdict program attached answer FIONREAD with 0 even when unread data is pending in sk_receive_queue. Fix tcp_bpf_ioctl() to account for the receive queue in that case, and add a selftest. Changes in v3: - Remove unused sk_psock_msg_inq() - Link to v2: https://patch.msgid.link/20260708-fionread-no-verdict-v2-0-29dd293621c7@coralogix.com Changes in v2: - Split the fix and the selftest into separate patches - Use READ_ONCE() to read the verdict program pointers - Link to v1: https://patch.msgid.link/20260707-fionread-no-verdict-v1-1-ce94a72357ec@coralogix.com Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com> --- ==================== Link: https://patch.msgid.link/20260708-fionread-no-verdict-v3-0-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15selftests/bpf: Test FIONREAD on a sockmap socket without a verdict programMattia Meleleo
Add a test validating that FIONREAD on a TCP socket in a sockmap without a verdict program reports data pending in sk_receive_queue. Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260708-fionread-no-verdict-v3-2-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf, sockmap: Account for receive queue in FIONREAD without a verdict programMattia Meleleo
tcp_bpf_ioctl() answers SIOCINQ from psock->msg_tot_len, which only counts bytes in ingress_msg. Without a stream/skb verdict program nothing is diverted there: data stays in sk_receive_queue, so FIONREAD returns 0 even though read() returns data. Add tcp_inq() to the reported value when the psock has no verdict program. The two queues are disjoint, so bytes redirected into ingress_msg from other sockets stay correctly accounted through msg_tot_len. Remove unused sk_psock_msg_inq(). Fixes: 929e30f93125 ("bpf, sockmap: Fix FIONREAD for sockmap") Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260708-fionread-no-verdict-v3-1-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15mmc: Merge branch fixes into nextUlf Hansson
Merge the mmc fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the mmc changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15mmc: dw_mmc: move declaration of dw_mci_pmopsBen Dooks
The dw_mci_pmops is exported out of dw_mmc.c so move the declaration of ton dw_mmc.h from dw_mmc-pltfm.h to fix the following sparse warning: drivers/mmc/host/dw_mmc.c:3512:25: warning: symbol 'dw_mci_pmops' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-15drm/i915/bw: introduce the peak bandwidth thresholdVinod Govindapillai
On Xe3+, the SoC can lower the fabric frequency when the display needs less bandwidth than the minimum GV point. This threshold is defined as 20 GB/s. The driver can choose to request this threshold when the required data rate falls below it. Add an extra QGV entry, with both peak bw and derated bw set to 20 GB/s, to the bandwidth info when all of the following hold: 1. The platform is Xe3+. 2. There is at least one existing QGV point. 3. The number of QGV points is below 8 (the maximum). Once a plane group is found, the driver iterates over all QGV points in that group to find the best match for the required data rate. If the required data rate is below 20 GB/s, it selects the peak bw from this new QGV point (20 GB/s). v2: add the peak bandwidth threshold as an additional QGV entry v3: drm_warn switched to drm_dbg_kms (Suraj) Removed log in case of no sagv and some tweak in the log message if the system has already the maximum number of QGV points Bspec: 68880 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260615203355.218578-8-vinod.govindapillai@intel.com
2026-07-15Merge branch 'unify-helper-and-kfunc-call_arg_meta'Kumar Kartikeya Dwivedi
Amery Hung says: ==================== Unify helper and kfunc call_arg_meta Hi all, I am working toward unifying helper and kfunc handling in the verifier. Historically, kfunc verification was mostly done separately from helper. This causes code/logic duplication and may introduce subtle bugs as the same checks are implemnented differently. To address this, I plan to unify function call verification, which will operate on a common function call descriptor bpf_func_proto. As the first step, this patchset merges bpf_{kfunc_}call_arg_meta of kfunc and helepr. The structure is used as a scratch pad for different helper/kfunc verification mechanisms. The previous object tracking refactor patchset has unified some of them. This patch handles the rest and finally merge the two different structures. The next step will be generating bpf_func_proto for kfunc before the main verification loop and align kfunc and helper argument types. Then hopefully helper and kfunc can go throguh the same call verification path. Changelog v1 -> v2 - Fix patch 2: ARG_PTR_TO_MAP_VALUE | MEM_UNINIT should also accept raw mode - Add patch 3: making check_func_arg() less verbose - Add patch 5: a selftest testing a preexisting OOB access bug when 0 is passed to a kfunc's {rdwr,rdonly}_buf_size argument - Add patch 6: dropping pkt_access from bpf_call_arg_meta ==================== Link: https://patch.msgid.link/20260715064047.1793790-1-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf: Unify helper and kfunc call argument metaAmery Hung
Helper and kfunc argument checking carried two separate meta structs: the verifier-local struct bpf_call_arg_meta and bpf_kfunc_call_arg_meta. Merge them into a single struct bpf_call_arg_meta. This is groundwork for sharing argument checking between helpers and kfuncs. While merging, drop the btf_id field from the helper meta since it is never used. No functional change. Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-8-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15bpf: Drop redundant pkt_access from bpf_call_arg_metaAmery Hung
meta->pkt_access is only ever a copy of fn->pkt_access, assigned once in check_helper_call() and read back in may_access_direct_pkt_data(). Have may_access_direct_pkt_data() take the bpf_func_proto and read fn->pkt_access directly, and drop the meta field along with its assignment. The only non-NULL caller, check_func_arg(), already has fn in scope; the remaining callers pass NULL and are unaffected. No functional change intended. Suggested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-7-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-15selftests/bpf: Test kfunc returning zero-sized allocation bufferAmery Hung
Add a test passing an explicit rdwr_buf_size of 0 to bpf_kfunc_call_test_get_rdwr_mem() and then reading the returned R0. R0 should be a zero-sized PTR_TO_MEM, so the access must be rejected with "min value is outside of the allowed memory range". This covers the pre-existing bug where a zero size argument was treated as "no size argument": the verifier fell through to btf_resolve_size() and sized R0 after the pointed-to return type, wrongly allowing the read. Suggested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/bpf/20260715064047.1793790-6-ameryhung@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-29 08:33:53 +0000