summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-14drm/amd/display: program dither on all OPP heads under ODM combineJames Lin
[why] The IGT test kms_plane_alpha_blend@coverage-vs-premult-vs-constant failed on DCN with ODM 2:1 combine enabled. The test compares the CRC of a coverage-blended plane against a premultiplied-blended plane and expects them to be identical. With ODM combine the whole-frame CRC mismatched (left segment matched, right segment differed). Root cause: dc_stream_set_dither_option() iterated the pipe_ctx array and broke out at the first pipe matching the stream (the OTG master / OPP instance 0), then programmed bit-depth reduction (dither) on that single OPP only. Under ODM combine there is more than one OPP head, so the secondary ODM segment (OPP instance 1) was never reprogrammed. When CRC capture requested dither off, only the left OPP got updated while the right OPP kept its previous dither setting, producing a different CRC for the right segment and thus a whole-frame CRC mismatch. [how] Use resource_get_otg_master_for_stream() and resource_get_opp_heads_for_otg_master() to retrieve every OPP head of the stream, then loop over all of them and call transform_set_pixel_storage_depth() and opp_program_bit_depth_reduction() on each. This keeps all OPP heads in sync under ODM combine, so dither is applied (or cleared) identically across every segment and the CRCs match. Reviewed-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: James Lin <PingLei.Lin@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Check dc_link before applying DSC policySrinivasan Shanmugam
apply_dsc_policy_for_stream() decides whether Display Stream Compression (DSC) should be enabled for a display stream based on display capabilities, link bandwidth and user overrides. Smatch reports that apply_dsc_policy_for_stream() dereferences aconnector->dc_link before checking whether it is NULL. Add an early NULL check for aconnector->dc_link before the first dereference and remove the later redundant NULL check in the HDMI_FRL path. Fixes: 0e967e086e75 ("drm/amd/display: Extract connector and encoder code to amdgpu_dm_connector") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Roman Li <roman.li@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Add passive dongle handling in force_to_use_aux caseMatthew Stewart
[why] Need special handling for passive HDMI dongles with I2C over AUX. Reviewed-by: Aurabindo Pillai <Aurabindo.Pillai@amd.com> Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Enable zstate support and fix seamless bootGabe Teeger
[Why & How] Port seamless boot fix from DCN42 to DCN42B and enable zstate support for DCN42B. Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Fix DCN42B null registers & register masksMatthew Stewart
[why] DCN42B is missing some register masks, which are causing errors in dmesg. [how] Make DCN42B reuse the DCN42 register lists, and add the missing defines manually. Fixes: 64142f9d51af ("drm/amd/display: Fix DCN42 null registers & register masks") Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com> Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Enable IPS support for DCN4 VariantGabe Teeger
[Why] DCN4 variant had IPS completely disabled via ips_support = false and dc->config.disable_ips = DMUB_IPS_DISABLE_ALL. Enabling IPS for D3 allows DMUB to manage idle power savings when the display subsystem is inactive, reducing platform power without affecting active display operation. [How] In DCN4 variant resource construct: - Set dc->caps.ips_support = true - Remove dc->config.disable_ips = DMUB_IPS_DISABLE_ALL override This enables DMUB to dynamically manage IPS entry/exit during D3 power state transitions. Also enable zstate by default. Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/gfx12: fix IP dump alloc orderingAlex Deucher
If gfx sysfs init fails, we may leak the ip dump allocations. Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/gfx11: fix IP dump alloc orderingAlex Deucher
If gfx sysfs init fails, we may leak the ip dump allocations. Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/gfx10: fix IP dump alloc orderingAlex Deucher
If gfx sysfs init fails, we may leak the ip dump allocations. Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/gfx9: fix IP dump alloc orderingAlex Deucher
If gfx sysfs init fails, we may leak the ip dump allocations. Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/gfx12.1: Add ip dump supportAlex Deucher
Add support for dumping IP register state. v2: fixes suggested by Mukul Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu: Change system_unbound_wq with system_dfl_wqMarco Crivellari
system_wq (per-CPU) and system_unbound_wq (unbound) are the older workqueue name, replaced by system_{percpu|dfl}_wq. The new workqueues have been introduced by: 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") Usage of older workqueues will now trigger a pr_warn_once() because they are marked as deprecated as per commit: 64d8eae3f895 ("workqueue: Add warnings and fallback if system_{unbound}_wq is used") So change the used workqueue with the newer, keeping the same behavior. Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Enable PSR and Replay on DCN4 variant [Part 2]Gabe Teeger
[Why] Enable PSR and Panel Replay on a DCN4 variant for display power savings. [How] Enable PSR and Replay in the DCN4 variant panel config defaults. Fixes: 68737239e891 ("drm/amd/display: Enable PSR and Replay on DCN4 variant and fix AUX instance") Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Enable CACP on LinuxChenyu Chen
[Why] Enable OLED panels to save more power on the Linux platform by enabling CACP support on Linux. [How] Update abm_feature_support() to return ABM_CACP_SUPPORT for OLED panels. Enable ABM property for all eDP panels including OLED to support CACP via set_abm_level. Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Generalize DMUB memory flushes from hostDillon Varone
[WHY&HOW] Add DMUB service context to aid in platform abstraction when flushing memory from the host. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amd/display: Fix KUnit backlight tests for CACPAlex Hung
[WHY] A change was added in amdgpu_dm_should_create_sysfs() to check link->panel_type instead of caps->aux_support, and removed the OLED exclusion from the ABM property attach path in amdgpu_dm_setup_backlight_device(). This broke three KUnit tests: - dm_test_should_create_sysfs_no_backlight_index and dm_test_should_create_sysfs_pwm_backlight returned false because kzalloc zeroes panel_type but PANEL_TYPE_LCD is 1. - dm_test_setup_backlight_device_oled_success crashed with a NULL pointer dereference in drm_object_attach_property since abm_level_property was NULL. [WHY] Set panel_type to PANEL_TYPE_LCD in the two sysfs tests and skip the ABM property attach path in the OLED setup test by setting amdgpu_dm_abm_level to 0. Cc: Chenyu Chen <chen-yu.chen@amd.com> Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu/discovery: Fix device family for DCN42Roman Li
GC 11.7.0 and 11.7.1 should map to AMDGPU_FAMILY_GC_11_5_4 for DCN42. Fixes: cf591e67c095 ("drm/amdgpu: add support for GC IP version 11.7.0") Fixes: a928d8d81ec5 ("drm/amdgpu: add support for GC IP version 11.7.1") Signed-off-by: Roman Li <Roman.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-14drm/amdgpu: update mmhub 4.2.0 client listAlex Deucher
Update to the proper client list for mmhub 4.2.0. v2: fix typo (Alex) Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-07-15Merge branch 'i2c/i2c-fixes' into i2c/i2c-nextAndi Shyti
2026-07-15i2c: mediatek: fix WRRD for SoCs without auto_restart optionRoman Vivchar
MediaTek mt65xx family SoCs have no auto restart, however, they still support the WRRD mode in the hardware. Because auto_restart is set to 0, the WRRD mode will be never enabled, leading to read errors. Fix this by removing auto_restart check from the WRRD enable path. Fixes: b49218365280 ("i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD") Signed-off-by: Roman Vivchar <rva333@protonmail.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260709-6572-6595-i2c-v2-1-b2fb8510d1d3@protonmail.com
2026-07-14Merge branch 'i2c/i2c-fixes' into i2c/i2c-nextAndi Shyti
2026-07-14i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()Xuanqiang Luo
If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res. Fixes: b5b5b32081cd ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260714150808.85045-1-xuanqiang.luo@linux.dev
2026-07-14firmware: stratix10-svc: fix teardown order in remove to prevent raceAdrian Ng Ho Yin
In stratix10_svc_drv_remove(), stratix10_svc_async_exit() was called before client devices were unregistered. This created a race window where child devices could still be issuing service requests through the async channels after the async infrastructure had already been torn down. Unregister client devices before tearing down the async threads and channels to ensure all in-flight service calls drain before the underlying infrastructure is destroyed. Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-07-14firmware: stratix10-svc: handle NO_RESPONSE in async pollAdrian Ng Ho Yin
Define INTEL_SIP_SMC_STATUS_NO_RESPONSE (0x3) and handle it in stratix10_svc_async_poll() the same way as INTEL_SIP_SMC_STATUS_BUSY, returning -EAGAIN so callers can retry instead of treating the poll as a hard failure. When the Secure Device Manager has not yet produced a response for an asynchronous transaction, ATF is expected to return INTEL_SIP_SMC_STATUS_NO_RESPONSE. Without this handling, the service layer maps the status to -EINVAL and async clients cannot distinguish "not ready yet" from a real error. Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-07-14regulator: adp5055: Fix error code in adp5055_of_parse_cb()Dan Carpenter
This code accidentally returned the wrong variable instead of a negative error code. Return -EINVAL. Fixes: 147b2a96f24e ("regulator: adp5055: Add driver for adp5055") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://patch.msgid.link/alFJVBbiFNxhqa_1@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14spi: bcm2835: make read-only const array pinctrl_compats staticColin Ian King
Don't populate the read-only const array pinctrl_compats on the stack at run time, instead make it static const char * const Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260714164215.183809-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14cxl/features: Clamp Get Feature output size to the remaining bufferRichard Cheng
cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity. Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Signed-off-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260626104102.53892-4-icheng@nvidia.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14cxl/features: Reject Set Features output buffer smaller than the headerRichard Cheng
cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required. Fixes: eb5dfcb9e36d ("cxl: Add support to handle user feature commands for set feature") Signed-off-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260626104102.53892-3-icheng@nvidia.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14cxl/features: Reject Get Feature count larger than the output bufferRichard Cheng
cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating. Fixes: 5908f3ed6dc2 ("cxl: Add support to handle user feature commands for get feature") Reviewed-by: Kai-Heng Feng <kaihengf@nvidia.com> Reviewed-by: Koba Ko <kobak@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260626104102.53892-2-icheng@nvidia.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14firmware: arm_scmi: Fix transport device teardown lookupSudeep Holla
SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails. Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-16-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Fix SCMI device destroy lifetimesSudeep Holla
scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again. Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-15-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unwind P2A receiver mailbox setup failureSudeep Holla
mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: fa8b28ba22d9 ("firmware: arm_scmi: Add support for platform to agent channel completion") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-14-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unwind TX receiver mailbox setup failureSudeep Holla
mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: 9f68ff79ec2c ("firmware: arm_scmi: Add support for unidirectional mailbox channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-13-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Fix OF node reference handlingSudeep Holla
SCMI devices store the DT node in dev.of_node through device_set_node(), but that helper only assigns the fwnode and of_node pointers without taking an OF node reference. Take a reference when assigning the node and release it from the SCMI device release path. With the device owning that reference, remove the separate channel-side get/put pair from the core driver. Fixes: 96da4a99ce50 ("firmware: arm_scmi: Set fwnode for the scmi_device") Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-12-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Clear SystemPower flag on create failureSudeep Holla
__scmi_device_create() reserves the singleton SystemPower protocol device before registering the SCMI device. If any later step fails, a stale reservation can make a later retry reject SystemPower device creation permanently, for example after probe deferral. A plain global boolean is not enough to track the reservation. A delayed final release of an older SystemPower device could clear the boolean after a newer device has already claimed it, breaking the singleton guarantee for the active device. Track the reservation with the scmi_device pointer itself. Claim it with cmpxchg(NULL, scmi_dev) after allocating the device object, and release it with cmpxchg(scmi_dev, NULL) from the common cleanup helper. This lets the create-failure, explicit destroy and final release paths clear only the reservation owned by the device being cleaned up. Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-11-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Drop handle on protocol bind failuresSudeep Holla
The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition. Fixes: 971fc0665f13 ("firmware: arm_scmi: Move handle get/set helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-10-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Protect device request lookup with RCUSudeep Holla
The SCMI device request notifier looks up protocol OF nodes from the active_protocols IDR. The IDR lookup can run concurrently with protocol activation while probe is still registering protocols and creating their SCMI devices. Wrap the lookup in an RCU read-side critical section as required by the IDR API for lockless readers. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-9-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Use channel ID for transport teardownSudeep Holla
SCMI protocols can share the BASE transport channel when firmware does not describe a dedicated channel for the protocol. In that case multiple IDR entries can point at the same scmi_chan_info, whose owning transport device was created with cinfo->id. scmi_chan_destroy() used the IDR iterator key when destroying the transport device. If an alias entry is visited before the owning channel entry, the lookup can miss the device because the iterator key does not match the protocol ID used when the transport device was created. The code then clears cinfo->dev, so the later owning entry skips teardown and leaks the transport device. Destroy the transport device using cinfo->id, which is the protocol ID that owns the channel and was used when creating the transport device. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-8-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Reject out of range DT protocol IDsSudeep Holla
SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-7-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Avoid IDR updates while cleaning channelsSudeep Holla
scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-6-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Free transport channel on IDR failureSudeep Holla
If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-5-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Clean up channels on setup failureSudeep Holla
scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-4-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Quiesce notifications before teardownSudeep Holla
scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts. Fixes: 1e7cbfaa66d3 ("firmware: arm_scmi: Free mailbox channels if probe fails") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-3-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unregister device notifier before IDR teardownSudeep Holla
The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-2-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Publish channel state before callbacksSudeep Holla
Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-1-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14thermal: intel: Add a syscore shutdown callback for kexec rebootRicardo Neri
A kexec reboot may load a kernel that does not support directed package- level thermal interrupts. Without a shutdown callback, the directed interrupt configuration remains enabled across kexec but will not be handled correctly. In particular, if the CPU designated to receive the directed interrupt goes offline, no other CPU in the package will receive it. Add a syscore shutdown callback to disable directed package-level thermal interrupts on all packages before a kexec reboot. If the post-kexec kernel does not enable directed interrupts, it falls back to broadcasting the interrupt to all CPUs. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-6-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-14thermal: intel: Add syscore callbacks for suspend and resumeRicardo Neri
Directed package-level thermal interrupts are serviced by a single CPU per package. These handler CPUs are selected at boot through the CPU hotplug infrastructure. This mechanism is sufficient to restore the directed interrupt configuration when resuming from suspend for non-boot packages. It also keeps the handler-tracking array updated. For the boot package, CPU0 is chosen during boot because its CPU hotplug online callback runs first. However, this callback is not invoked on resume. The directed package-level interrupt configuration for the boot package is not restored. Add a syscore resume callback to re-enable directed package-level interrupts for this package. Disabling directed interrupts during suspend is required to keep the handler-tracking array in a consistent state for the boot package, allowing the correct configuration to be restored on resume. The resume callback must busy-wait for hardware acknowledgment of the directed interrupt setup. Otherwise, the handler-tracking array could be left in an inconsistent state. This implies running with interrupts disabled for up to 15ms, though in practice it takes less than 1ms. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-5-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-14thermal: intel: Enable the Directed Package-level Thermal InterruptRicardo Neri
Package-level thermal interrupts are broadcast to all online CPUs within a package, even though only one CPU needs to service them. This results in unnecessary wakeups, lock contention, and corresponding performance and power-efficiency penalties. When supported by hardware, a CPU requests to receive directed package- level thermal interrupts by setting a designated bit in IA32_THERM_INTERRUPT. The operating system must then verify that hardware has acknowledged this request by checking a designated bit in IA32_PACKAGE_THERM_STATUS. Enable directed package-level thermal interrupts on one CPU per package using the CPU hotplug infrastructure. The first CPU of a package that comes online will handle the interrupt. If the handling CPU goes offline, select a new CPU. Temporarily enable directed interrupts on both the current and new CPU until hardware acknowledges the new selection, then disable them on the outgoing CPU. Systems without directed-interrupt support continue to broadcast the package-level interrupt to all CPUs. Also, add a rollback mechanism in the CPU hotplug online callback to fall back to broadcast mode if the directed-interrupt acknowledgment fails in any package. This is most important during boot, when all CPUs in a package come online and would otherwise keep retrying on faulty hardware. A complete rollback is not needed in the CPU hotplug offline callback since at that point the hardware is known to work. While here, update an inline comment to point to the correct volume of the Intel Software Developer's Manual. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-4-3a26d1e47fc8@linux.intel.com [ rjw: Rebased on top of 7.2-rc2 ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-14iwlwifi: dvm: add missing cleaup for on error pathHaoxiang Li
In iwlagn_tx_agg_start(), call iwlagn_dealloc_agg_txq() to clear bit on error path. Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Link: https://patch.msgid.link/20260401030555.541685-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14soc: apple: Add driver for Apple PMGR misc controlsHector Martin
Apple SoCs have PMGR blocks that control a bunch of power-related features. Besides the existing device power state controls (which are very uniform and handled by apple-pmgr-pwrstate), we also need to manage more random registers such as SoC-wide fabric and memory controller power states, which have a different interface. Add a driver for these kitchen sink controls. Right now it implements fabric and memory controller power state switching on system standby/s2idle, which saves about 1W of power or so on t60xx platforms. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Sven Peter <sven@kernel.org> Co-developed-by: Sasha Finkelstein <k@chaosmail.tech> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260705-pmgr-misc-v3-2-51b75fed6f73@chaosmail.tech Signed-off-by: Sven Peter <sven@kernel.org>