summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-16drm/msm/a3xx: Drain VBIF before GPU suspendAlexandre MINETTE2-1/+37
A3xx hangs after every runtime suspend on the Samsung Galaxy S4 GT-I9505. Even simple GPU workloads, such as drawing a single triangle, hang reliably once the GPU has been suspended by runtime PM. The generic MSM GPU suspend path disables clocks/power, but A3xx also needs to ensure that pending VBIF transactions are drained before that happens. Add an A3xx-specific pm_suspend callback. Wait for the GPU to become idle, halt all VBIF XIN clients, wait for the corresponding acknowledgment, and only then enter the generic MSM GPU suspend path. This fixes reliable A3xx GPU hangs observed after runtime PM on the Samsung Galaxy S4 GT-I9505, codename jflte. The failure is reported as: mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: hangcheck detected gpu lockup rb 0! mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: completed fence: 4294967041 mdp4 5100000.display-controller: [drm:hangcheck_handler] *ERROR* 3.2.0.2: submitted fence: 4294967049 mdp4 5100000.display-controller: [drm:recover_worker] *ERROR* 3.2.0.2: hangcheck recover! Link: https://github.com/freedreno-zz/freedreno/issues/12 Signed-off-by: Alexandre MINETTE <contact@alex-min.fr> Patchwork: https://patchwork.freedesktop.org/patch/731919/ Message-ID: <20260610-mainline-fix-a3xx-gpu-hang-sending-v1-1-9282182840b5@alex-min.fr> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/msm/adreno: fix use after free on error path in a6xx_gpu_init()Dan Carpenter1-1/+2
The a6xx_destroy() function frees "a6xx_gpu" and so "adreno_gpu" points to freed memory. Preserve the error code before freeing the memory to avoid a use after free. Fixes: d158886cba08 ("drm/msm/adreno: Trust the SSoT UBWC config") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/732275/ Message-ID: <aiqNktNfXiaPhje3@stanley.mountain> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-16drm/tegra: vic: Add Tegra264 supportMikko Perttunen3-27/+75
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based Falcon microcontroller instead of the traditional Falcon previously, and has the TRANSCFG register in a different place. The .version field is set to 0x264 rather than 0x26 to allow distinguishing between different VIC capabilities between minor version variations of some chips. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> [treding@nvidia.com: fix checkpatch warnings] Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-6-ff7364d9ff7b@nvidia.com
2026-07-16PCI: spacemit: Add missing MODULE_DEVICE_TABLE()Pengpeng Hou1-0/+1
The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260704122538.92830-1-pengpeng@iscas.ac.cn
2026-07-16Input: snvs_pwrkey - use local device pointer to simple codeJoy Zou1-20/+21
Use local struct device pointer to avoid reference the platform_device pointer every time. No functional change. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20260715-b4-pwrkey-v5-3-07e7353c319e@oss.nxp.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-07-16Input: snvs_pwrkey - propagate error code of platform_get_irq()Joy Zou1-1/+1
Hardcoding -EINVAL discards the actual error code, which breaks probe deferral (-EPROBE_DEFER) and loses critical diagnostic information needed for proper kernel error handling. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20260715-b4-pwrkey-v5-2-07e7353c319e@oss.nxp.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-07-16Input: snvs_pwrkey - make use of dev_err_probe()Joy Zou1-28/+16
Add dev_err_probe() at return path of probe() to support users to identify issues easier. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://patch.msgid.link/20260715-b4-pwrkey-v5-1-07e7353c319e@oss.nxp.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-07-16drm/tegra: falcon: Add support for RISC-V external bootMikko Perttunen2-10/+79
Add support for loading and booting RISC-V firmwares on Falcons with RISC-V hardware. The flow is mostly the same as for traditional Falcons, with a few different registers and different firmware layout. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-5-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Add Tegra264 supportSantosh BS10-6/+352
Add device data and chip headers for Tegra264. Signed-off-by: Santosh BS <santoshb@nvidia.com> Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-4-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Correctly parse linear ranges of context devicesMikko Perttunen1-2/+11
The previous parsing of the iommu-map property assumed each context device has its own one-length entry in the device tree. This has worked fine so far, but on Tegra264 larger numbers of context devices are usable, so it's better to support linear ranges as well. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260622-t264-host1x-v2-3-ff7364d9ff7b@nvidia.com
2026-07-16gpu: host1x: Annotate intentional syncpoint wrap-aroundMikko Perttunen5-8/+20
Host1x syncpoints are 32-bit counters that roll over by design. To make that explicit in the code, use wrapping_* functions whenever arithmetic is done on syncpoint values. Atomic operations cannot be updated but a comment is added. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-6-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Change pin_job() return type to intMikko Perttunen1-1/+1
pin_job() returns negative errno values on error paths (-EINVAL, -ENOMEM, PTR_ERR() of mapping) but was declared as unsigned int. The caller would immediately cast back to int, so there was no functional issue, but it still warrants fixing. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-5-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Avoid stack over-read in debug output helpersMikko Perttunen1-2/+2
host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written. Fixes: 6236451d83a7 ("gpu: host1x: Add debug support") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-4-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Fix offset calculation in trace_write_gatherMikko Perttunen1-3/+2
When a gather longer than 2*TRACE_MAX_LENGTH (256) words is traced through host1x_cdma_push_gather, the reported BO offset drifts from the third iteration onward. Fix the calculation by properly calculating the value on each loop rather than accumulating. In reality, gathers tend to be pretty short so this is unlikely to ever have been observed. Fixes: b40d02bf96e0 ("gpu: host1x: Use struct host1x_bo pointers in traces") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-3-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Avoid double device_add when clients already presentMikko Perttunen1-1/+1
host1x_device_add looks through the idle clients list to populate subdevs, and any matches entries are moved from the subdevs list to the active list. If all subdevs are populated, device_add will be called on the device. The secondary "subdevs list empty" check will then incorrectly again call device_add. However, this would require a convoluted scenario since clients don't typically end up on the idle clients list. Fix by checking whether the device was already added before adding again. Fixes: fab823d82ee5 ("gpu: host1x: Allow loading tegra-drm without enabled engines") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-2-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Wait for timeout worker completion on channel freeMikko Perttunen1-1/+1
cdma_timeout_destroy() used cancel_delayed_work() to cancel pending timeout work when destroying the CDMA. Usually this is fine, but there is a narrow race condition where the timeout handler has started execution but has not taken cdma->lock; the channel is freed causing cdma_stop to take cdma->lock and flush the channel; host1x_cdma_deinit then proceeds with deinitializing cdma while the handler is waiting to take cdma->lock. Therefore change cdma_timeout_destroy to use cancel_delayed_work_sync instead to ensure any pending timeout work completes before proceeding. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-1-7c1131c0b3ad@nvidia.com
2026-07-16gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappingsMikko Perttunen1-2/+2
__host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead. Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-tegra/ah6ErK6f4kVudVIA@stanley.mountain/T/#u Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260603-host1x-bocache-leak-fix-v1-1-494101dbfd30@nvidia.com
2026-07-16wifi: iwlwifi: adapt ND match notif sizing to fixed matches arrayEmmanuel Grumbach2-5/+8
Switch iwl_scan_offload_match_info::matches to a fixed-size array and adjust D3 netdetect size handling accordingly. In MVM D3 paths, compute expected payload size as offsetof(struct iwl_scan_offload_match_info, matches) + matches_len to preserve previous behavior after the struct layout change. In MLD D3 netdetect handling, keep the simple full-notification size assumption and validate against sizeof(*notif) before accessing data. This keeps scan offload / netdetect functionality unchanged while making length checks consistent with the new struct definition. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.4c4346140bcc.I44313ac41daca352e6aecdba09a1c3570c3eea06@changeid
2026-07-16wifi: iwlwifi: mvm: fix a possible underflowEmmanuel Grumbach1-4/+15
We shouldn't trust the firmware about the length of the wowlan packet. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.fbd989cc85e2.If68de403bfa4943732c025961154c20b01b09e83@changeid
2026-07-16wifi: iwlwifi: mvm: copy the correct TK length for rangingAvraham Stern1-17/+38
When setting the TK for ranging with an associated peer, 32 bytes of TK are copied from the vif key without verifying the actual key length which may be only 16 bytes if CCMP-128 is used. Fix it by setting the copy length according to the key cipher. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.e339570086bd.Iafff5aaf0e25f7d29e06f0ef456107c4062bbc7d@changeid
2026-07-16wifi: iwlwifi: mvm: add a check on the tid coming from the firmwareEmmanuel Grumbach1-0/+3
ba_notif->tid is a firmware-controlled u8 that is used directly as an array index into tid_data[] without any validation. Add a bounds check against IWL_MAX_TID_COUNT before dereferencing the array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.d7c3e75d47af.If88948108cfc8b5fb3ce5531d927855d1b3b6b30@changeid
2026-07-16wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notifEmmanuel Grumbach1-1/+7
mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.919edee567eb.Ie85c350e3afe2b39709d0039072740d86660f8ae@changeid
2026-07-16wifi: iwlwifi: pcie: validate FW section counts in iwl_pcie_init_fw_secEmmanuel Grumbach1-1/+6
iwl_pcie_init_fw_sec() iterates over LMAC, UMAC, and paging firmware sections and writes to ctxt_dram->lmac_img[i], ctxt_dram->umac_img[i], and ctxt_dram->virtual_img[i] without first verifying that the counts derived from the firmware image do not exceed the array size. An oversized firmware image could cause out-of-bounds writes into the fixed-size context-info DRAM arrays. Add explicit WARN_ON checks for all three section counts and return -EINVAL if any is exceeded. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.34db46ca12f3.I1aa225492a62f25293c147aa7293afa80a5d4215@changeid
2026-07-16wifi: iwlwifi: mvm: ptp: free response on success pathEmmanuel Grumbach1-1/+3
Release CMD_WANT_SKB response buffer after successful timestamp parsing to avoid leaking response allocations. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.31b38bef398b.Ib6a5a8bdd800779c8911da6859fd450d3d19c9e9@changeid
2026-07-16wifi: iwlwifi: mvm: fix read in wake packet notification handlerShahar Tzarfati1-1/+2
In iwl_mvm_wowlan_store_wake_pkt(), packet_len was initialized from notif->wake_packet_length before the explicit check that len >= sizeof(*notif). Move the assignment of packet_len to after the size check so that notif->wake_packet_length is only accessed once the payload length has been validated. Fixes: 219ed58feda9 ("wifi: iwlwifi: mvm: Add support for wowlan wake packet notification") Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.99d5cf85a528.Ic4aa736011d4fe88e0cd19723d1d48bb24642198@changeid
2026-07-16wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fnEmmanuel Grumbach1-1/+8
iwl_pnvm_complete_fn() casts pkt->data directly to struct iwl_pnvm_init_complete_ntfy and reads the status field without first verifying that the firmware notification payload is large enough to contain that structure. Add a WARN_ON_ONCE check against sizeof(*pnvm_ntf) and return early without reading uninitialised memory if the payload is too short. Fixes: b3e4c0f34c17 ("iwlwifi: move PNVM implementation to common code") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.7f2a669e5c75.I00465dcfcbccb250ae9af2d9bb305e24de1ba394@changeid
2026-07-16wifi: iwlwifi: fix pointer arithmetic in iwl_add_mcc_to_tas_block_listEmmanuel Grumbach1-1/+1
The expression list[*size++] increments the pointer 'size' rather than the u8 value it points to (operator precedence: ++ binds to the pointer before the dereference). As a result the block-list entry is written at the correct index but *size is never incremented, so the caller's count stays at zero and subsequent calls overwrite slot 0 every time. Change to list[(*size)++] so that the value pointed to by size is incremented after use as the array index. Fixes: 5f4656610edb ("wifi: iwlwifi: extend TAS_CONFIG cmd support for v5") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.d2cd92242582.Ife4140a4e27be2a1cd9f886c5a9b376ce182a019@changeid
2026-07-16wifi: iwlwifi: fw: validate SMEM response sizeShahar Tzarfati1-5/+23
The SMEM parsers cast firmware response payloads directly to shared memory configuration structures. A short response can leave fields outside the received payload while the driver still dereferences them. Check the response payload length before reading the base fields in both parser variants. Require the full legacy extended layout before reading internal TX FIFO data. Valid responses keep the same parsed values. Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.fbdb0016a91d.I5f6c6e04589a24a233559191170ccb43372dee63@changeid
2026-07-16wifi: iwlwifi: mvm: validate SAR GEO response payload sizePagadala Yesu Anjaneyulu1-0/+10
The SAR GEO command response is cast to iwl_geo_tx_power_profiles_resp without verifying the payload length. A malformed or unexpected firmware response can lead to reading an invalid structure layout. Add an explicit size check before accessing the response data and return -EIO when the payload size is wrong. Fixes: f604324eefec ("iwlwifi: remove iwl_validate_sar_geo_profile() export") Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.7e749b7d374a.I4ef54548bff6c6e7c7a57bee771ac12508aad677@changeid
2026-07-16wifi: iwlwifi: mvm: validate TX_CMD response layoutEmmanuel Grumbach1-0/+34
TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload. For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.0474ee89bab9.I84f151aabecb8921b587da092f29f78c47128f0f@changeid
2026-07-16wifi: iwlwifi: add support for additional channels in NVM_GET_INFOEmmanuel Grumbach4-26/+74
We need to expect more channels on devices that support UNII-9. Since iwl_ext_nvm_channels and iwl_uhb_nvm_channels are just a prefix of iwl_unii9_nvm_channels just use iwl_unii9_nvm_channels and modify the number of channels if the device does not support UNII-9 channels. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.473f48e6135d.I0e93cda753558aa4d9e3efcdd52cbc2eb9302c4a@changeid
2026-07-16wifi: iwlwifi: mld: validate txq_id in TX response handlerEmmanuel Grumbach1-0/+4
Validate txq_id from TX response notification before passing to iwl_trans_reclaim(). Other reclaim paths in this file perform this check to prevent out-of-bounds access on malformed notifications. Assisted-by: GitHubCopilot:claude-haiku-4.5 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715215523.b938c2dcf08d.I8a88ec359e229f1c41ac9c49fd9ce28a2b62b274@changeid
2026-07-16wifi: iwlwifi: mei: pass correct argument to functionAvraham Stern1-1/+1
The first argument to iwl_mei_write_cyclic_buf() should be the cldev but the q_head pointer is passed instead. Fix it. Fixes: 652291601459 ("iwlwifi: mei: don't rely on the size from the shared area") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.24cea60c6428.I42301010c31487b1458faa967b22c8320b0cfd23@changeid
2026-07-16wifi: iwlwifi: mld: Do not cleanup FW state when the device is deadIlan Peer1-2/+4
When a channel context is unassigned, there is a path to cleanup the FW state in case of NON MLO connection: remove the link and add it again. However, when the transport is dead, e.g., during device removal etc., this flow will fail and as a result the mld_vif->link[0] would be set to NULL. Later, when the interface is removed, iwl_mld_remove_link() would warn as the link is NULL. Fix this by not doing the cleanup when the device is dead. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.89a0c44a72a3.I45cca8b84a25943d5771199af6b0155dbac77b58@changeid
2026-07-16wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragmentsEmmanuel Grumbach1-1/+7
Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well. Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.60121deecf2c.Iebc891c95a7bd1b2a093b0bb88532db446a758ee@changeid
2026-07-16wifi: iwlwifi: mei: skip data read if length is too shortAvraham Stern1-6/+14
When calculating the SAP data length, the code subtracts sizeof(*ethhdr) from len. If the SAP data header indicates a length that is shorter than ethernet header length, this will result in an unsigned underflow which will lead to a kernel panic when trying to put the data into the SKB. Fix it by skipping a message if the indicated length is too short. In addition, if the message type is not SAP_MSG_DATA_PACKET or skb allocation fails, the loop skips to the next message but without reading the message payload. This may result in reading the payload as the next message header, which will lead to errors in parsing the next messages. Fix it by skipping the message payload as well. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.f66b10736047.I4a1dde517c36561d41358dd82a5cec8b6c886c14@changeid
2026-07-16wifi: iwlwifi: mei: check SAP message length before reading itAvraham Stern1-0/+6
Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow. Fixes: bcd68b3dbe78 ("wifi: iwlwifi: mei: fix tx DHCP packet for devices with new Tx API") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.f0026ce26218.I00a856d3aacae1caac605c708f7362689b734234@changeid
2026-07-16wifi: iwlwifi: mld: fix read in wake packet notification handlerShahar Tzarfati1-1/+2
In iwl_mld_handle_wake_pkt_notif(), expected_size was initialized from notif->wake_packet_length before the IWL_FW_CHECK that validates the payload covers sizeof(*notif). Move the assignment of expected_size to after the size check so that notif->wake_packet_length is only accessed once the payload length has been validated. Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.94c526d2c66e.I065a19a9dcc7f45a7457667c0f625fcd2c7bf6b6@changeid
2026-07-16wifi: iwlwifi: mld: add PNVM_INIT_COMPLETE_NTFY to the hcmd namesMiri Korenblit1-0/+1
Add it to the array of host command name so it will be printed with iwl_get_cmd_string Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.e8da467f1883.I75ab56a022f31365042d29aff5484e4329b0f6ce@changeid
2026-07-16wifi: iwlwifi: mvm: add LARI_CONFIG_EXTENSION commandPagadala Yesu Anjaneyulu3-0/+63
There is a new UHB extension bitmap that is part of the LARI configuration, which needs to be sent to the FW - also frozen ones. But in frozen FWs we cannot increase the version of an API, since the driver assumes a specific version, depending on the core number. In case of a (new) FW that expects the new version and a (old) driver that doesn't support that new version, the driver will send a default old version, causing a fw assert about its bad size. To mitigate this, there is a special command which will be supported only on those frozen FWs. Old drivers will simply not support/send it, and new driver will send it if supported by fw. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.551f40ee2de3.I3e32a5d5c9aa13cbb0e599bef630cdb8e3b031c4@changeid
2026-07-16wifi: iwlwifi: mld: honor FW puncturing capability in MCC responsePagadala Yesu Anjaneyulu4-11/+67
New MCC response versions expose puncturing support directly in the regulatory capability flags. Propagate that information from NVM MCC parsing to MLD MCC handling and fall back to legacy FM/WH MCC-specific policy when puncturing status is unknown. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.47d1389fa134.I5c7921d6e3c065e3962c5927991498c2d277fd8f@changeid
2026-07-16wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiserEmmanuel Grumbach1-1/+1
iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised. Fixes: 12d60c1efc29 ("iwlwifi: mvm: scrub key material in firmware dumps") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.355998ec4fbe.I40f3427657b897e911bdf4ebf8e494745508d126@changeid
2026-07-16wifi: iwlwifi: mld: fix validation fallback in iwl_mld_notif_is_validEmmanuel Grumbach1-1/+1
When a firmware notification version is not in the handler's size table, iwl_mld_notif_is_valid() falls back to comparing against the last known structure size but the comparison is wrong: 'return size < last_known_size' returns true (accept) for undersized payloads and false (reject) for payloads that are large enough. Instead of trying to accept notifications that are large enough, just refuse the notification. We shouldn't ever get a notification that is longer than what we expect. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.e0b91efe689d.I7d7604be6819da263e9091370892e6b6f4c57913@changeid
2026-07-16wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logsEmmanuel Grumbach1-1/+1
The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc. Fixes: 2b69d242e29b ("wifi: iwlwifi: fw: print PC register value instead of address") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.a61c65f34e87.Ie5f1a7ca43e0cc5a0ddc8305b0448ddffc09cd18@changeid
2026-07-16wifi: iwlwifi: mvm/mld: fix PPE threshold debug print loopJohannes Berg2-6/+4
The loop should print all bandwidths, the extra * results in calculating the wrong ARRAY_SIZE() here (of the array inside the per-bandwidth, not the per-bandwidth array.) Fix that, and also clarify the array variable assignment. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.5e1d3448bfca.I6919627382d46605b41b0c6a6f34deedfd45523c@changeid
2026-07-16wifi: iwlwifi: mld: validate WoWLAN notif headerEmmanuel Grumbach1-19/+38
Validate fixed wowlan_info_notif header size first. Only then read num_mlo_link_keys from pkt->data. Apply this to v5 and v6 parsing paths. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.9c33c20194ad.I691d019927cc56898f2516fcf5795c8b1fae362c@changeid
2026-07-16wifi: iwlwifi: mld: support aborting an ongoing ftm requestAvraham Stern3-0/+32
Add support for aborting an ongoing FTM request. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260715220243.340040bdc6a3.Ifbbf70021e42bf1d59db6ec45a73f1806a1c2289@changeid
2026-07-16nvme: fix cdev lifetimeJohn Garry2-20/+9
Sashiko bot reported a potential problem for the cdev lifetime in [0] - the code there is heavily based on the NVMe code. Currently the NS head .open and .release file_operations methods take and put a reference to the nvme_ns_head to ensure that this structure does not disappear while we open fds for that cdev. In multipath mode, when we teardown the NS head, we call nvme_cdev_del() -> cdev_device_del() -> cdev_del(). However after cdev_del() returns, cdevs already open will remain and their fops will still be callable. As such, we can still reference the cdev after the nvme_ns_head reference count drops to 0 (and is freed). This can be shown with an application which delays between opening the cdev and issuing the ioctl while the NS head is being torn down: # ./ioctl_file /dev/ng1n1 & # waiting 10 seconds .... # ./ini_nvme_teardown.sh [ 21.221718] nvme nvme1: Removing ctrl: NQN "nvme-test-target" [ 21.274609] nvme nvme2: Removing ctrl: NQN "nvme-test-target" # now going to issue ioctl .... [ 26.549285] ================================================================== [ 26.550841] BUG: KASAN: slab-use-after-free in cdev_put.part.0+0x3d/0x40 [ 26.552352] Read of size 8 at addr ffff88811e7fa170 by task ioctl_file/237 [ 26.553805] [ 26.554227] CPU: 3 UID: 0 PID: 237 Comm: ioctl_file Not tainted 7.2.0-rc1-00004-g6852a10e32d4 #921 PREEMPT(lazy) [ 26.554236] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 26.554241] Call Trace: [ 26.554245] <TASK> [ 26.554248] dump_stack_lvl+0x68/0xa0 [ 26.554266] print_report+0x10d/0x5d0 [ 26.554276] ? __virt_addr_valid+0x21d/0x3f0 [ 26.554287] ? cdev_put.part.0+0x3d/0x40 [ 26.554292] kasan_report+0x96/0xd0 [ 26.554300] ? cdev_put.part.0+0x3d/0x40 [ 26.554307] cdev_put.part.0+0x3d/0x40 [ 26.554313] __fput+0x7bc/0xa70 [ 26.554322] fput_close_sync+0xd8/0x190 [ 26.554328] ? __pfx_fput_close_sync+0x10/0x10 [ 26.554337] __x64_sys_close+0x79/0xd0 [ 26.554344] do_syscall_64+0x117/0x6b0 [ 26.554351] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 26.554358] RIP: 0033:0x7f938c067727 [ 26.554364] Code: 48 89 fa 4c 89 df e8 28 ad 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5bf [ 26.554369] RSP: 002b:00007fff49f05980 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 [ 26.554376] RAX: ffffffffffffffda RBX: 00007f938bfd7780 RCX: 00007f938c067727 [ 26.554380] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [ 26.554383] RBP: 00007fff49f05a10 R08: 0000000000000000 R09: 0000000000000000 [ 26.554386] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 26.554389] R13: 00007fff49f05b40 R14: 00007f938c207000 R15: 000055c148471d78 [ 26.554397] </TASK> [ 26.554399] [ 26.575612] Allocated by task 100: [ 26.575871] kasan_save_stack+0x24/0x50 [ 26.576157] kasan_save_track+0x14/0x30 [ 26.576418] __kasan_kmalloc+0x7f/0x90 [ 26.576668] __kmalloc_noprof+0x281/0x6c0 [ 26.576938] nvme_alloc_ns+0x7f7/0x3170 [ 26.577206] nvme_scan_ns+0x508/0x880 [ 26.577449] async_run_entry_fn+0x8c/0x350 [ 26.577723] process_scheduled_works+0xb6f/0x1a00 [ 26.578034] worker_thread+0x4ad/0xb40 [ 26.578283] kthread+0x34f/0x450 [ 26.578501] ret_from_fork+0x563/0x800 [ 26.578752] ret_from_fork_asm+0x1a/0x30 [ 26.579012] [ 26.579124] Freed by task 237: [ 26.579335] kasan_save_stack+0x24/0x50 [ 26.579596] kasan_save_track+0x14/0x30 [ 26.579855] kasan_save_free_info+0x3a/0x60 [ 26.580131] __kasan_slab_free+0x43/0x70 [ 26.580388] kfree+0x321/0x500 [ 26.580591] nvme_ns_head_chr_release+0x39/0x50 [ 26.580883] __fput+0x352/0xa70 [ 26.581095] fput_close_sync+0xd8/0x190 [ 26.581350] __x64_sys_close+0x79/0xd0 [ 26.581595] do_syscall_64+0x117/0x6b0 [ 26.581842] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 26.582176] [ 26.582286] Last potentially related work creation: [ 26.582593] kasan_save_stack+0x24/0x50 [ 26.582841] kasan_record_aux_stack+0x89/0xa0 [ 26.583210] insert_work+0x22/0x170 [ 26.583442] __queue_work+0x7b1/0xfa0 [ 26.583682] queue_work_on+0x77/0x80 [ 26.583921] kblockd_schedule_work+0x18/0x20 [ 26.584207] nvme_mpath_put_disk+0x42/0xa0 [ 26.584632] nvme_free_ns_head+0x1c/0x160 [ 26.584904] nvme_ns_head_chr_release+0x39/0x50 [ 26.585208] __fput+0x352/0xa70 [ 26.585420] fput_close_sync+0xd8/0x190 [ 26.585677] __x64_sys_close+0x79/0xd0 [ 26.585924] do_syscall_64+0x117/0x6b0 [ 26.586173] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 26.586505] [ 26.586616] Second to last potentially related work creation: [ 26.586991] kasan_save_stack+0x24/0x50 [ 26.587246] kasan_record_aux_stack+0x89/0xa0 [ 26.587538] insert_work+0x22/0x170 [ 26.587770] __queue_work+0x7b1/0xfa0 [ 26.588010] queue_work_on+0x77/0x80 [ 26.588247] kblockd_schedule_work+0x18/0x20 [ 26.588529] nvme_remove_head+0x3d/0xb0 [ 26.588787] nvme_ns_remove+0x4b2/0x930 [ 26.589040] nvme_remove_namespaces+0x29c/0x410 [ 26.589340] nvme_do_delete_ctrl+0xf3/0x190 [ 26.589611] nvme_delete_ctrl_sync+0x71/0x90 [ 26.589889] nvme_sysfs_delete+0x91/0xb0 [ 26.590151] kernfs_fop_write_iter+0x2fb/0x4a0 [ 26.590452] vfs_write+0x929/0xfc0 [ 26.590688] ksys_write+0xf2/0x1d0 [ 26.590923] do_syscall_64+0x117/0x6b0 [ 26.591171] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 26.591498] [ 26.591605] The buggy address belongs to the object at ffff88811e7fa000 [ 26.591605] which belongs to the cache kmalloc-4k of size 4096 [ 26.592409] The buggy address is located 368 bytes inside of [ 26.592409] freed 4096-byte region [ffff88811e7fa000, ffff88811e7fb000) [ 26.593205] [ 26.593321] The buggy address belongs to the physical page: [ 26.593701] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e7f8 [ 26.594250] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 26.594743] flags: 0x200000000000040(head|node=0|zone=2) [ 26.595093] page_type: f5(slab) [ 26.595312] raw: 0200000000000040 ffff888100043040 dead000000000122 0000000000000000 [ 26.595810] raw: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000 [ 26.596309] head: 0200000000000040 ffff888100043040 dead000000000122 0000000000000000 [ 26.596806] head: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000 [ 26.597313] head: 0200000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff [ 26.597813] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 26.598317] page dumped because: kasan: bad access detected [ 26.598676] [ 26.598784] Memory state around the buggy address: [ 26.599093] ffff88811e7fa000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 26.599559] ffff88811e7fa080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 26.600023] >ffff88811e7fa100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 26.600485] ^ [ 26.600921] ffff88811e7fa180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 26.601390] ffff88811e7fa200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 26.601855] ================================================================== [ 26.602374] Disabling lock debugging due to kernel taint When all fds for the cdev disappear, the cdev removal path puts a reference to the parent object, which is the nvme_ns_head.cdev_device - see cdev_default_release() -> kobject_put(parent). Fix the lifetime for the cdev by making adding the cdev add take a reference to the NS head and drop that reference in the nvme_ns_head.cdev_device release function. The same problem exists for the NS cdev lifetime, so resolve that issue through a similar method by taking a reference to the NS for the lifetime of the cdev. Note that nvme_ns_chr_open() -> nvme_ns_open() also takes a reference to the NS. Now that should not be needed, but that code is common to bdev ioctl, so keep as is. [0] https://lore.kernel.org/linux-scsi/20260703102918.3723667-1-john.g.garry@oracle.com/T/#m67265e2906d617acd2743c0a00809246d0cfc506 Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-07-16nvme: add nvme_get_ns_head()John Garry3-1/+7
Add a wrapper for getting a reference to the NS head. This would be used in scenarios when we know that getting a reference would not fail. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-07-16PCI: starfive: Fix resource leaks on error paths in host_init()Ali Tariq1-2/+11
starfive_pcie_host_init() acquires the PHY, clocks/resets, and an optional regulator in sequence, but does not correctly unwind these resources when a later step fails. If starfive_pcie_clk_rst_init() fails after the PHY has already been successfully enabled, the function returns directly without disabling the PHY, leaking it and leaving it powered. If regulator_enable() fails for the optional vpcie3v3 regulator, the failure is only logged; the function falls through and returns success, leaving the driver believing the regulator is enabled while continuing to configure PCIe hardware that may be unpowered. This also leaves the clocks and PHY enabled with nothing to clean them up. Disable the PHY on the clk/reset failure path, and disable the clocks/resets and PHY, then return the error, if the regulator fails to enable. Build-tested and boot-tested on StarFive VisionFive 2 v1.2A Fixes: 05a75df4182e ("PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots") Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Signed-off-by: Ali Tariq <alitariq45892@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260716102053.185276-1-alitariq45892@gmail.com
generated by cgit (git 2.54.0.dirty) at 2026-09-30 07:04:36 +0000