summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
12 daysdrm/amd/pm: disable OD_FAN_CURVE if temp or pwm range invalid for smu v13Yang Wang
Forcibly disable the OD_FAN_CURVE feature when temperature or PWM range is invalid, otherwise PMFW will reject this configuration on smu v13.0.x example: $ sudo cat /sys/bus/pci/devices/<BDF>/gpu_od/fan_ctrl/fan_curve OD_FAN_CURVE: 0: 0C 0% 1: 0C 0% 2: 0C 0% 3: 0C 0% 4: 0C 0% OD_RANGE: FAN_CURVE(hotspot temp): 0C 0C FAN_CURVE(fan speed): 0% 0% $ echo "0 50 40" | sudo tee fan_curve kernel log: [ 756.442527] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! [ 777.345800] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! Closes: https://github.com/ROCm/amdgpu/issues/208 Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 470891606c5a97b1d0d937e0aa67a3bed9fcb056) Cc: stable@vger.kernel.org
12 daysdrm/amd/pm: Return -EOPNOTSUPP for unsupported OD_MCLK on smu_v13_0_6Asad Kamal
When SET_UCLK_MAX capability is absent, return -EOPNOTSUPP from smu_v13_0_6_emit_clk_levels() for OD_MCLK instead of 0. This makes unsupported OD_MCLK reporting consistent with other clock types and allows callers to skip the entry cleanly. Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d82e0a72d9189e8acd353988e1a57f85ce479e37) Cc: stable@vger.kernel.org
12 daysdrm/amd/pm: Skip redundant UCLK restore in smu_v13_0_6Asad Kamal
Only reapply UCLK soft limits during PP_OD_RESTORE_DEFAULT when the current max differs from the DPM table max. This avoids redundant SMC updates and prevents -EINVAL on restore when no change is needed. Fixes: b7a900344546 ("drm/amd/pm: Allow setting max UCLK on SMU v13.0.6") Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 17f11bbbc76c8e83c8474ea708316b1e3631d927)
12 daysdrm/amd/display: Fix drm_edid leak in amdgpu_dmAlex Hung
[WHAT] When a sink is connected, aconnector->drm_edid was overwritten without freeing the previous allocation, causing a memory leak on resume. [HOW] Free the previous drm_edid before updating it. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Chuanyu Tseng <chuanyu.tseng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: prevent immediate PASID reuse caseEric Huang
PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: fix strsep() corrupting lockup_timeout on multi-GPU (v3)Ruijing Dong
amdgpu_device_get_job_timeout_settings() passes a pointer directly to the global amdgpu_lockup_timeout[] buffer into strsep(). strsep() destructively replaces delimiter characters with '\0' in-place. On multi-GPU systems, this function is called once per device. When a multi-value setting like "0,0,0,-1" is used, the first GPU's call transforms the global buffer into "0\00\00\0-1". The second GPU then sees only "0" (terminated at the first '\0'), parses a single value, hits the single-value fallthrough (index == 1), and applies timeout=0 to all rings — causing immediate false job timeouts. Fix this by copying into a stack-local array before calling strsep(), so the global module parameter buffer remains intact across calls. The buffer is AMDGPU_MAX_TIMEOUT_PARAM_LENGTH (256) bytes, which is safe for the stack. v2: wrap commit message to 72 columns, add Assisted-by tag. v3: use stack array with strscpy() instead of kstrdup()/kfree() to avoid unnecessary heap allocation (Christian). This patch was developed with assistance from Claude (claude-opus-4-6). Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 94d79f51efecb74be1d88dde66bdc8bfcca17935) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: Do not skip unrelated mode changes in DSC validationYussuf Khalil
Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5004 Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check") Signed-off-by: Yussuf Khalil <dev@pp3345.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)
12 daysspi: meson-spicc: Fix double-put in remove pathFelix Gu
meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put. Fixes: 8311ee2164c5 ("spi: meson-spicc: fix memory leak in meson_spicc_remove") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260322-rockchip-v1-1-fac3f0c6dad8@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
12 daysspi: sn-f-ospi: Use devm_mutex_init() to simplify codeFelix Gu
Switch to devm_mutex_init() to handle mutex destruction automatically. This simplifies the error paths in probe() and removes the need for an explicit mutex_destroy() in remove() callback. Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260319-sn-f-v1-2-33a6738d2da8@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
12 daysspi: sn-f-ospi: Fix resource leak in f_ospi_probe()Felix Gu
In f_ospi_probe(), when num_cs validation fails, it returns without calling spi_controller_put() on the SPI controller, which causes a resource leak. Use devm_spi_alloc_host() instead of spi_alloc_host() to ensure the SPI controller is properly freed when probe fails. Fixes: 1b74dd64c861 ("spi: Add Socionext F_OSPI SPI flash controller driver") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260319-sn-f-v1-1-33a6738d2da8@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
12 daysdrm/xe/pf: Fix use-after-free in migration restoreMichał Winiarski
When an error is returned from xe_sriov_pf_migration_restore_produce(), the data pointer is not set to NULL, which can trigger use-after-free in subsequent .write() calls. Set the pointer to NULL upon error to fix the problem. Fixes: 1ed30397c0b92 ("drm/xe/pf: Add support for encap/decap of bitstream to/from packet") Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7230 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260217154118.176902-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 4f53d8c6d23527d734fe3531d08e15cb170a0819) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
12 dayspinctrl: sunxi: fix gpiochip_lock_as_irq() failure when pinmux is unknownMichal Piekos
Fixes kernel hang during boot due to inability to set up IRQ on AXP313a. The issue is caused by gpiochip_lock_as_irq() which is failing when gpio is in uninitialized state. Solution is to set pinmux to GPIO INPUT in sunxi_pinctrl_irq_request_resources() if it wasn't initialized earlier. Tested on Orange Pi Zero 3. Fixes: 01e10d0272b9 ("pinctrl: sunxi: Implement gpiochip::get_direction()") Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Signed-off-by: Linus Walleij <linusw@kernel.org>
12 dayspinctrl: sunxi: pass down flags to pinctrl routinesAndre Przywara
Recent changes in the Allwinner pinctrl/GPIO IP made us add some quirks, which the new SoCs (A523 family) need to use. We now have a comfortable "flags" field on the per-SoC setup side, to tag those quirks we need, but were translating those flag bits into specific fields for runtime use, in the init routine. Now the newest Allwinner GPIO IP adds even more quirks and exceptions, some of a boolean nature. To avoid inventing various new boolean flags for the runtime struct sunxi_pinctrl, let's just directly pass on the flags variable used by the setup code, so runtime can check for those various quirk bits directly. Rename the "variant" member to "flags", and directly copy the value from the setup code into there. Move the variant masking from the init routine to the functions which actually use the "variant" value. This mostly paves the way for the new A733 IP generation, which needs more quirks to be checked at runtime. Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Signed-off-by: Linus Walleij <linusw@kernel.org>
12 daysplatform/x86: intel-hid: disable wakeup_mode during hibernationDavid McFarland
Add a freeze handler which clears wakeup_mode. This fixes aborted hibernation on Dell Precision 3880. Wakeup event detected during hibernation, rolling back This system sends power button events during hibernation, even when triggered by software. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218634 Fixes: 0c4cae1bc00d ("PM: hibernate: Avoid missing wakeup events during hibernation") Signed-off-by: David McFarland <corngood@gmail.com> Link: https://patch.msgid.link/20260205231629.1336348-1-corngood@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: asus-armoury: add support for GZ302EA and GZ302EACMatthew Schwartz
Add TDP data for tablet models GZ302EA and GZ302EAC. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260313004939.4103835-1-matthew.schwartz@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP GZ302EACMatthew Schwartz
The ASUS ROG Flow Z13-KJP GZ302EAC model uses sys_vendor name ASUS rather than ASUSTeK COMPUTER INC., but it needs the same folio quirk as the other ROG Flow Z13. To keep things simple, just match on sys_vendor ASUS since it covers both. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260312212246.1608080-1-matthew.schwartz@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86/amd/hsmp: Fix typo in error messageAlok Tiwari
Fix a typo in the HSMP error message where "tmeout" should be "timeout". Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/20260310125307.700108-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/olpc: olpc-xo175-ec: Fix overflow error message to print inlenAlok Tiwari
The command length check validates inlen (> 5), but the error message incorrectly printed resp_len. Print inlen so the log reflects the actual command length. Fixes: 0c3d931b3ab9e ("Platform: OLPC: Add XO-1.75 EC driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Acked-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260310130138.700687-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: lenovo: wmi-gamezone: Drop gz_chain_headNathan Chancellor
The gz_chain_head variable has been unused since the driver's initial addition to the tree. Its use was eliminated between v3 and v4 during development but due to the reference of gz_chain_head's wait_list member, the compiler could not warn that it was unused. After a (tip) commit ("locking/rwsem: Remove the list_head from struct rw_semaphore"), which removed a reference to the variable passed to __RWSEM_INITIALIZER(), certain configurations show an unused variable warning from the Lenovo wmi-gamezone driver: drivers/platform/x86/lenovo/wmi-gamezone.c:34:31: warning: 'gz_chain_head' defined but not used [-Wunused-variable] 34 | static BLOCKING_NOTIFIER_HEAD(gz_chain_head); | ^~~~~~~~~~~~~ include/linux/notifier.h:119:39: note: in definition of macro 'BLOCKING_NOTIFIER_HEAD' 119 | struct blocking_notifier_head name = \ | ^~~~ Remove the variable to prevent the warning from showing up. Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/20260313-lenovo-wmi-gamezone-remove-gz_chain_head-v1-1-ce5231f0c6fa@kernel.org [ij: reorganized the changelog] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: ISST: Check HWP support before MSR accessLi RongQing
On some systems, HWP can be explicitly disabled in the BIOS settings When HWP is disabled by firmware, the HWP CPUID bit is not set, and attempting to read MSR_PM_ENABLE will result in a General Protection (GP) fault. unchecked MSR access error: RDMSR from 0x770 at rIP: 0xffffffffc33db92e (disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core]) Call Trace: <TASK> ? ex_handler_msr+0xf6/0x150 ? fixup_exception+0x1ad/0x340 ? gp_try_fixup_and_notify+0x1e/0xb0 ? exc_general_protection+0xc9/0x390 ? terminate_walk+0x64/0x100 ? asm_exc_general_protection+0x22/0x30 ? disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core] isst_if_def_ioctl+0xece/0x1050 [isst_tpmi_core] ? ioctl_has_perm.constprop.42+0xe0/0x130 isst_if_def_ioctl+0x10d/0x1a0 [isst_if_common] __se_sys_ioctl+0x86/0xc0 do_syscall_64+0x8a/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f36eaef54a7 Add a check for X86_FEATURE_HWP before accessing the MSR. If HWP is not available, return true safely. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260303074635.2218-1-lirongqing@baidu.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: hp-wmi: Add support for Omen 16-k0xxx (8A4D)Krishna Chomal
The HP Omen 16-k0xxx (board ID: 8A4D) has the same WMI interface as other Victus S boards, but requires additional quirks for correctly switching thermal profile. Create a new quirk omen_v1_legacy_thermal_params which allows a board to use Omen V1 thermal values, but rely on the older legacy HP_OMEN_EC_THERMAL_PROFILE_OFFSET. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to the newly added quirk. Testing on board 8A4D confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Qinfeng Wu <qwqgong@gmail.com> Reported-by: Qinfeng Wu <qwqgong@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221150 Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260302073525.71037-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C76)Krishna Chomal
The HP Omen 16-wf1xxx (board ID: 8C76) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile (similar to board 8C78). Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_thermal_params. Testing on board 8C76 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: WJ Enderlava <jie7172585@gmail.com> Reported-by: WJ Enderlava <jie7172585@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149 Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260227154106.226809-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: hp-wmi: Add Omen 16-xf0xxx (8BCA) supportRaed
The HP Omen 16-xf0xxx board 8BCA uses the same Victus-S fan and thermal WMI path as other recently supported Omen/Victus boards, but it requires Omen v1 thermal profile parameters for correct platform profile behavior. Add board 8BCA to victus_s_thermal_profile_boards[] and map it to omen_v1_thermal_params. Validated on HP Omen 16-xf0xxx (board 8BCA): - /sys/firmware/acpi/platform_profile exposes low-power/balanced/performance - fan RPM reporting works (fan1_input/fan2_input) - manual fan control works through hp-wmi hwmon (pwm1/pwm1_enable) Signed-off-by: Raed <thisisraed@outlook.com> Link: https://patch.msgid.link/20260311131338.965249-1-youaretalkingtoraed@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: asus-armoury: add support for G614FPDenis Benato
Add TDP data for laptop model G614FP. Signed-off-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260309183559.433555-3-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform/x86: asus-armoury: add support for GA503QMDenis Benato
Add TDP data for laptop model GA503QM. Signed-off-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260309183559.433555-2-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 dayscpufreq: conservative: Reset requested_freq on limits changeViresh Kumar
A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by resetting the cached requested_freq to policy->cur on detecting a change in policy limits. Reported-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/d846a141a98ac0482f20560fcd7525c0f0ec2f30.1773999467.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 dayscpufreq: Don't skip cpufreq_frequency_table_cpuinfo()Viresh Kumar
The commit 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") unintentionally made a change where cpufreq_frequency_table_cpuinfo() isn't getting called anymore for old policies getting re-initialized. This leads to potentially invalid values of policy->max and policy->cpuinfo_max_freq. Fix the issue by reverting the original commit and adding the condition for just the sorting function. Fixes: 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 6.19+ <stable@vger.kernel.org> # 6.19+ Link: https://patch.msgid.link/65ba5c45749267c82e8a87af3dc788b37a0b3f48.1773998611.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 daysgpio: qixis-fpga: Fix error handling for devm_regmap_init_mmio()Felix Gu
devm_regmap_init_mmio() returns an ERR_PTR() on failure, not NULL. The original code checked for NULL which would never trigger on error, potentially leading to an invalid pointer dereference. Use IS_ERR() and PTR_ERR() to properly handle the error case. Fixes: e88500247dc3 ("gpio: add QIXIS FPGA GPIO controller") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260320-qixis-v1-1-a8efc22e8945@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
12 daysgpio: shared: handle pins shared by child nodes of devicesBartosz Golaszewski
Shared GPIOs may be assigned to child nodes of device nodes which don't themselves bind to any struct device. We need to pass the firmware node that is the actual consumer to gpiolib-shared and compare against it instead of unconditionally using the fwnode of the consumer device. Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/all/921ba8ce-b18e-4a99-966d-c763d22081e2@nvidia.com/ Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260318-gpio-shared-xlate-v2-2-0ce34c707e81@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
12 daysgpio: shared: call gpio_chip::of_xlate() if setBartosz Golaszewski
OF-based GPIO controller drivers may provide a translation function that calculates the real chip offset from whatever devicetree sources provide. We need to take this into account in the shared GPIO management and call of_xlate() if it's provided and adjust the entry->offset we initially set when scanning the tree. To that end: modify the shared GPIO API to take the GPIO chip as argument on setup (to avoid having to rcu_dereference() it from the GPIO device) and protect the access to entry->offset with the existing lock. Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/all/921ba8ce-b18e-4a99-966d-c763d22081e2@nvidia.com/ Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260318-gpio-shared-xlate-v2-1-0ce34c707e81@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
12 daysdrm/i915: Unlink NV12 planes earlierVille Syrjälä
unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. Cc: stable@vger.kernel.org Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/ Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Fixes: 6a01df2f1b2a ("drm/i915: Remove pointless visible check in unlink_nv12_plane()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
12 daysdrm/i915: Order OP vs. timeout correctly in __wait_for()Ville Syrjälä
Put the barrier() before the OP so that anything we read out in OP and check in COND will actually be read out after the timeout has been evaluated. Currently the only place where we use OP is __intel_wait_for_register(), but the use there is precisely susceptible to this reordering, assuming the ktime_*() stuff itself doesn't act as a sufficient barrier: __intel_wait_for_register(...) { ... ret = __wait_for(reg_value = intel_uncore_read_notrace(...), (reg_value & mask) == value, ...); ... } Cc: stable@vger.kernel.org Fixes: 1c3c1dc66a96 ("drm/i915: Add compiler barrier to wait_for") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260313110740.24620-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a464bace0482aa9a83e9aa7beefbaf44cd58e6cf) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
12 daysdrm/i915/gmbus: fix spurious timeout on 512-byte burst readsSamasth Norway Ananda
When reading exactly 512 bytes with burst read enabled, the extra_byte_added path breaks out of the inner do-while without decrementing len. The outer while(len) then re-enters and gmbus_wait() times out since all data has been delivered. Decrement len before the break so the outer loop terminates correctly. Fixes: d5dc0f43f268 ("drm/i915/gmbus: Enable burst read") Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260316231920.135438-2-samasth.norway.ananda@oracle.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 4ab0f09ee73fc853d00466682635f67c531f909c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
13 daysi2c: tegra: Don't mark devices with pins as IRQ safeMikko Perttunen
I2C devices with associated pinctrl states (DPAUX I2C controllers) will change pinctrl state during runtime PM. This requires taking a mutex, so these devices cannot be marked as IRQ safe. Add PINCTRL as dependency to avoid build errors. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/all/E1vsNBv-00000009nfA-27ZK@rmk-PC.armlinux.org.uk/ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
13 daysMerge tag 'i2c-for-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - fix broken I2C communication on Armada 3700 with recovery - fix device_node reference leak in probe (fsi) - fix NULL-deref when serial string is missing (cp2615) * tag 'i2c-for-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: pxa: defer reset on Armada 3700 when recovery is used i2c: fsi: Fix a potential leak in fsi_i2c_probe() i2c: cp2615: fix serial string NULL-deref at probe
13 daysMerge tag 'irq-urgent-2026-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix a mailbox channel leak in the riscv-rpmi-sysmsi irqchip driver" * tag 'irq-urgent-2026-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/riscv-rpmi-sysmsi: Fix mailbox channel leak in rpmi_sysmsi_probe()
13 daysdrm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_registerLuca Leonardo Scorcia
The call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind, which uses dev_get_drvdata to retrieve the mtk_dsi struct, so this structure needs to be stored inside the driver data before invoking it. As drvdata is currently uninitialized it leads to a crash when registering the DSI DRM encoder right after acquiring the mode_config.idr_mutex, blocking all subsequent DRM operations. Fixes the following crash during mediatek-drm probe (tested on Xiaomi Smart Clock x04g): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [...] Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper panel_simple [...] Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320 __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+0x5c/0xa4 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x240 driver_register+0x68/0x130 __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0 __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80) Fixes: e4732b590a77 ("drm/mediatek: dsi: Register DSI host after acquiring clocks and PHY") Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260225094047.76780-1-l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
14 dayszram: do not slot_free() written-back slotsSergey Senozhatsky
slot_free() basically completely resets the slots by clearing all of its flags and attributes. While zram_writeback_complete() restores some of flags back (those that are necessary for async read decompression) we still lose a lot of slot's metadata. For example, slot's ac-time, or ZRAM_INCOMPRESSIBLE. More importantly, restoring flags/attrs requires extra attention as some of the flags are directly affecting zram device stats. And the original code did not pay that attention. Namely ZRAM_HUGE slots handling in zram_writeback_complete(). The call to slot_free() would decrement ->huge_pages, however when zram_writeback_complete() restored the slot's ZRAM_HUGE flag, it would not get reflected in an incremented ->huge_pages. So when the slot would finally get freed, slot_free() would decrement ->huge_pages again, leading to underflow. Fix this by open-coding the required memory free and stats updates in zram_writeback_complete(), rather than calling the destructive slot_free(). Since we now preserve the ZRAM_HUGE flag on written-back slots (for the deferred decompression path), we also update slot_free() to skip decrementing ->huge_pages if ZRAM_WB is set. Link: https://lkml.kernel.org/r/20260320023143.2372879-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20260319034912.1894770-1-senozhatsky@chromium.org Fixes: d38fab605c667 ("zram: introduce compressed data writeback") Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Acked-by: Minchan Kim <minchan@kernel.org> Cc: Brian Geffon <bgeffon@google.com> Cc: Richard Chang <richardycc@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
14 daysMerge tag 'driver-core-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Generalize driver_override in the driver core, providing a common sysfs implementation and concurrency-safe accessors for bus implementations - Do not use driver_override as IRQ name in the hwmon axi-fan driver - Remove an unnecessary driver_override check in sh platform_early - Migrate the platform bus to use the generic driver_override infrastructure, fixing a UAF condition caused by accessing the driver_override field without proper locking in the platform_match() callback * tag 'driver-core-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: driver core: platform: use generic driver_override infrastructure sh: platform_early: remove pdev->driver_override check hwmon: axi-fan: don't use driver_override as IRQ name docs: driver-model: document driver_override driver core: generalize driver_override in struct device
14 daysMerge tag 'hwmon-for-v7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - max6639: Fix pulses-per-revolution implementation - Several PMBus drivers: Add missing error checks * tag 'hwmon-for-v7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (max6639) Fix pulses-per-revolution implementation hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit() hwmon: (pmbus/ina233) Add error check for pmbus_read_word_data() return value hwmon: (pmbus/mp2869) Check pmbus_read_byte_data() before using its return value hwmon: (pmbus/mp2975) Add error check for pmbus_read_word_data() return value hwmon: (pmbus/hac300s) Add error check for pmbus_read_word_data() return value
2026-03-20virt: tdx-guest: Fix handling of host controlled 'quote' buffer lengthZubin Mithra
Validate host controlled value `quote_buf->out_len` that determines how many bytes of the quote are copied out to guest userspace. In TDX environments with remote attestation, quotes are not considered private, and can be forwarded to an attestation server. Catch scenarios where the host specifies a response length larger than the guest's allocation, or otherwise races modifying the response while the guest consumes it. This prevents contents beyond the pages allocated for `quote_buf` (up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace, and possibly forwarded in attestation requests. Recall that some deployments want per-container configs-tsm-report interfaces, so the leak may cross container protection boundaries, not just local root. Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS") Cc: stable@vger.kernel.org Signed-off-by: Zubin Mithra <zsm@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2026-03-20net: bcmasp: fix double disable of clkJustin Chen
Switch to devm_clk_get_optional() so we can manage the clock ourselves. We dynamically control the clocks depending on the state of the interface for power savings. The default state is clock disabled, so unbinding the driver causes a double disable. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260319234813.1937315-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: bcmasp: fix double free of WoL irqJustin Chen
We do not need to free wol_irq since it was instantiated with devm_request_irq(). So devres will free for us. Fixes: a2f0751206b0 ("net: bcmasp: Add support for WoL magic packet") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260319234813.1937315-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: macb: Protect access to net_device::ip_ptr with RCU lockKevin Hao
Access to net_device::ip_ptr and its associated members must be protected by an RCU lock. Since we are modifying this piece of code, let's also move it to execute only when WAKE_ARP is enabled. To minimize the duration of the RCU lock, a local variable is used to temporarily store the IP address. This change resolves the following RCU check warning: WARNING: suspicious RCU usage 7.0.0-rc3-next-20260310-yocto-standard+ #122 Not tainted ----------------------------- drivers/net/ethernet/cadence/macb_main.c:5944 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 5 locks held by rtcwake/518: #0: ffff000803ab1408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008090bf088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 stack backtrace: CPU: 3 UID: 0 PID: 518 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #122 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 lockdep_rcu_suspicious+0x134/0x1d8 macb_suspend+0xd8/0x4c0 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 0cb8de39a776 ("net: macb: Add ARP support to WOL") Signed-off-by: Kevin Hao <haokexin@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20260318-macb-irq-v2-2-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20net: macb: Move devm_{free,request}_irq() out of spin lock areaKevin Hao
The devm_free_irq() and devm_request_irq() functions should not be executed in an atomic context. During device suspend, all userspace processes and most kernel threads are frozen. Additionally, we flush all tx/rx status, disable all macb interrupts, and halt rx operations. Therefore, it is safe to split the region protected by bp->lock into two independent sections, allowing devm_free_irq() and devm_request_irq() to run in a non-atomic context. This modification resolves the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 0 7 locks held by rtcwake/501: #0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 #5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48 #6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558 irq event stamp: 8682 hardirqs last enabled at (8681): [<ffff8000813c7d7c>] _raw_spin_unlock_irqrestore+0x44/0x88 hardirqs last disabled at (8682): [<ffff8000813c7b58>] _raw_spin_lock_irqsave+0x38/0x98 softirqs last enabled at (7322): [<ffff8000800f1b4c>] handle_softirqs+0x52c/0x588 softirqs last disabled at (7317): [<ffff800080010310>] __do_softirq+0x20/0x2c CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #125 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 __might_resched+0x200/0x218 __might_sleep+0x38/0x98 __mutex_lock_common+0x7c/0x1378 mutex_lock_nested+0x38/0x50 free_irq+0x68/0x2b0 devm_irq_release+0x24/0x38 devres_release+0x40/0x80 devm_free_irq+0x48/0x88 macb_suspend+0x298/0x558 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 558e35ccfe95 ("net: macb: WoL support for GEM type of Ethernet controller") Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-20Merge tag 'drm-fixes-2026-03-21' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Regular weekly pull request, from sunny San Diego. Usual suspects in xe/i915/amdgpu with small fixes all over, then some minor fixes across a few other drivers. It's probably a bit on the heavy side, but most of the fix seem well contained, core: - drm_dev_unplug UAF fix pagemap: - lock handling fix xe: - A number of teardown fixes - Skip over non-leaf PTE for PRL generation - Fix an uninitialized variable - Fix a missing runtime PM reference i915/display: - Fix #15771: Screen corruption and stuttering on P14s w/ 3K display - Fix for PSR entry setup frames count on rejected commit - Fix OOPS if firmware is not loaded and suspend is attempted - Fix unlikely NULL deref due to DC6 on probe amdgpu: - Fix gamma 2.2 colorop TFs - BO list fix - LTO fix - DC FP fix - DisplayID handling fix - DCN 2.01 fix - MMHUB boundary fixes - ISP fix - TLB fence fix - Hainan pm fix radeon: - Hainan pm fix vmwgfx: - memory leak fix - doc warning fix imagination: - deadlock fix - interrupt handling fixes dw-hdmi-qp: - multi channel audio fix" * tag 'drm-fixes-2026-03-21' of https://gitlab.freedesktop.org/drm/kernel: (40 commits) drm/xe: Fix missing runtime PM reference in ccs_mode_store drm/xe: Open-code GGTT MMIO access protection drm/xe/lrc: Fix uninitialized new_ts when capturing context timestamp drm/xe/oa: Allow reading after disabling OA stream drm/xe: Skip over non leaf pte for PRL generation drm/xe/guc: Ensure CT state transitions via STOP before DISABLED drm/xe: Trigger queue cleanup if not in wedged mode 2 drm/xe: Forcefully tear down exec queues in GuC submit fini drm/xe: Always kill exec queues in xe_guc_submit_pause_abort drm/xe/guc: Fail immediately on GuC load error drm/i915/gt: Check set_default_submission() before deferencing drm/radeon: apply state adjust rules to some additional HAINAN vairants drm/amdgpu: apply state adjust rules to some additional HAINAN vairants drm/amdgpu: rework how we handle TLB fences drm/bridge: dw-hdmi-qp: fix multi-channel audio output drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug drm/amdgpu: Fix ISP segfault issue in kernel v7.0 drm/amdgpu/gmc9.0: add bounds checking for cid drm/amdgpu/mmhub4.2.0: add bounds checking for cid drm/amdgpu/mmhub4.1.0: add bounds checking for cid ...
2026-03-20hwmon: (max6639) Fix pulses-per-revolution implementationGuenter Roeck
The valid range for the pulses-per-revolution devicetree property is 1..4. The current code checks for a range of 1..5. Fix it. Declare the variable used to retrieve pulses per revolution from devicetree as u32 (unsigned) to match the of_property_read_u32() API. The current code uses a postfix decrement when writing the pulses per resolution into the chip. This has no effect since the value is evaluated before it is decremented. Fix it by decrementing before evaluating the value. Fixes: 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property") Cc: Naresh Solanki <naresh.solanki@9elements.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-03-20Merge tag 'tty-7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty/vt and serial driver fixes for 7.0-rc5. Included in here are: - 8250 driver fixes for reported problems - serial core lockup fix - uartlite driver bugfix - vt save/restore bugfix All of these have been in linux-next for over a week with no reported problems" * tag 'tty-7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: vt: save/restore unicode screen buffer for alternate screen serial: 8250_dw: Ensure BUSY is deasserted serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling serial: 8250: Add serial8250_handle_irq_locked() serial: 8250_dw: Avoid unnecessary LCR writes serial: 8250: Protect LCR write in shutdown serial: 8250_pci: add support for the AX99100 serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN serial: uartlite: fix PM runtime usage count underflow on probe serial: 8250: always disable IRQ during THRE test serial: 8250: Fix TX deadlock when using DMA
2026-03-20Merge tag 'spi-fix-v7.0-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "There's a couple of core fixes here from Johan, fixing a race condition and an error handling path, plus a bunch of driver specific fixups. The Qualcomm issues could be nasty if you ran into them, especially the DMA ordering one" * tag 'spi-fix-v7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: geni-qcom: Check DMA interrupts early in ISR spi: fix statistics allocation spi: fix use-after-free on controller registration failure spi: geni-qcom: Fix CPHA and CPOL mode change detection spi: axiado: Fix double-free in ax_spi_probe() spi: amlogic-spisg: Fix memory leak in aml_spisg_probe() spi: amlogic: spifc-a4: Remove redundant clock cleanup
2026-03-20Merge tag 'pmdomain-v7.0-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: - bcm: increase ASB control timeout for bcm2835 - mediatek: fix power domain count * tag 'pmdomain-v7.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: bcm: bcm2835-power: Increase ASB control timeout pmdomain: mediatek: Fix power domain count
generated by cgit v1.2.3 (git 2.0.4) at 2026-04-04 15:24:39 +0000