summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-14wifi: iwlwifi: mvm: validate sta_id in TLC notifEmmanuel Grumbach1-2/+7
TLC_MNG_UPDATE_NOTIF uses firmware-provided sta_id to index fw_id_to_link_sta[] and fw_id_to_mac_id[]. Validate sta_id before array access to avoid out-of-bounds indexing. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.1ce54794c1f8.I275fd4c1165bf42fb17516c550dd8813a2b8286e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: validate MCC header before n_channelsEmmanuel Grumbach1-7/+36
MCC response parsing read n_channels from v8/v4/v3 response variants before ensuring the payload contained the fixed response header. Add a minimum payload-length check for each response version before reading n_channels, and keep the existing exact-size validation for the channels array payload. Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.cb2cef3d3e7e.Iee7b48614289da576de842157ad3730b7589a4b1@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: parse beacon notif per layoutEmmanuel Grumbach3-14/+15
The beacon TX notification can arrive in different layouts, and fields must be read only after selecting the expected format. Parse gp2 and TSF from the matching notification structure in each branch, and keep using the parsed gp2 for CSA countdown and debug output. Drop the obsolete cached gp2 field. Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.cc8aa937f8e5.I921f8dadcb20cb73e8283e1b8546e1778205411f@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: validate reorder BAIDEmmanuel Grumbach1-1/+6
Reject BAIDs >= IWL_MAX_BAID before indexing fw_id_to_ba. This prevents out-of-bounds access on malformed notifications. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.07ea823b8eea.Ica915fa0cce0427bf5e3420ae933f57118fedf86@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: fix the FCS truncation logic in d3Emmanuel Grumbach1-1/+1
Fix a harmless mistake in the wake packet management code in the d3 wakeup flow. If the FCS is truncated, we want to detect it, but we cleared the icvlen before updating the truncated variable that holds the number of bytes having been truncated. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.369588f93c6b.I1a4d13f276c7e75514ab2032ae387873337470b8@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: don't parse a notif before checking its lengthEmmanuel Grumbach1-2/+8
In order to compure the size of the iwl_mcc_update_resp which has a variable length, we need to know the number of channels. In order to read the number of channels, we must first check the payload is long enough to read at least that. Add this check. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.c2f644919011.Ic579e9935b92a674c96ccc44713140b5b4bc5d10@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: fix an off-by-1 boundary checkEmmanuel Grumbach1-1/+1
Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.336b527e3fc6.I6fe839f4e70d673632fd7ca757e81827af87b029@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: fix an off-by-1 boundary checkEmmanuel Grumbach1-1/+1
Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260714141909.d22bf52a18d0.If0ef6612a67cca671428b06dbdeec68549e50ae6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: verify scan id reported by firmwareAvraham Stern1-1/+5
The scan id reported by firmware in scan complete notification is used as an index to the scan status array. Verify the reported id does not exceed the array size. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Link: https://patch.msgid.link/20260714141909.fdf31f494f1c.I70d01ed2023f6584fb23ea8ab344a93d222cc4c0@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14drm/bridge: sii9234: use dev_err_probe where applicableHenrik Grimler1-13/+8
In case of error during resource acquisition the driver should print an error message only if it is not deferred probe. Use dev_err_probe helper to handle this, which will also record defer probe reason for debugging. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-2-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/bridge: sii9234: fix some typos in comments and messagesHenrik Grimler1-7/+7
Fix spelling and formatting so that the code is easier to follow, and so that it is more searchable. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-1-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/gpusvm: publish dpagemap early to avoid device mapping leak on errorHonglei Huang1-5/+11
drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review. Fixes: f70da6f99d4f ("drm/gpusvm: pull out drm_gpusvm_pages substructure") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-4-honghuan@amd.com
2026-07-14drm/gpusvm: do not route system pages to device_unmap() on IOVA unmapHonglei Huang1-6/+12
In a mixed range: ctx->allow_mixed dpagemap is not NULL while some entries are system pages. The unmap loop used: dma_unmap_page(...); else if (dpagemap && dpagemap->ops->device_unmap) dpagemap->ops->device_unmap(...); When use_iova is true the first condition is false for system pages, so they fall through to device_unmap() and a system DMA address is handed to the device specific unmap callback, risking invalid accesses or state corruption. Key the branch off addr->proto instead: system pages only need an explicit dma_unmap_page() in the non IOVA case, IOVA system pages are already torn down by the single dma_iova_destroy(), and only genuine device pages reach device_unmap(). This issue was found by Sashiko AI review. Fixes: 37ad039fb367 ("drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-3-honghuan@amd.com
2026-07-14drm/gpusvm: free the whole IOVA reservation on unmapHonglei Huang1-5/+14
dma_iova_try_alloc() reserves IOVA for the entire range, but in a mixed range only the system pages are linked (their total size is state_offset) while device pages never touch the IOVA state. dma_iova_destroy() with state_offset only frees the linked part, permanently leaking the IOVA reserved for the device pages and eventually exhausting the IOVA space. Unlink the linked system-page portion and free the whole reserved IOVA instead. On the get_pages() error path state_offset is 0 (no page linked, dma_addr[0] unpopulated), so skip the unlink and just free the reservation; this also avoids reading the uninitialized dma_addr[0].dir there. Allocate the dma_addr array with the zeroing kvzalloc_objs() so every entry has a well-defined value. This issue was found by Sashiko AI review. Fixes: 37ad039fb367 ("drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-2-honghuan@amd.com
2026-07-14drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO movesMatthew Brost5-15/+48
xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260714062440.3421225-1-matthew.brost@intel.com
2026-07-14cxl/port: Restart port enumeration when a sibling adds the dport firstAlison Schofield1-2/+2
Endpoint probes can race while enumerating a shared switch. If a sibling probe adds the dport first, the losing probe finds the dport already present, gets -EBUSY, and fails to enumerate the endpoint. Treat this race the same as the existing port-created case by restarting the port walk, allowing it to find the existing dport and continue enumeration. This race was discovered while testing a cxl_test mixed-granularity topology, where twelve endpoints behind shared switches are probed in parallel during module load. Fixes: 4f06d81e7c6a ("cxl: Defer dport allocation for switch ports") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Tested-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260714020438.1822669-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14cxl/features: Serialize multi-part Get/Set Feature transfersDave Jiang2-0/+4
A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=1 Fixes: 5e5ac21f629d ("cxl/mbox: Add GET_FEATURE mailbox command") Fixes: 14d502cc2718 ("cxl/mbox: Add SET_FEATURE mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Richard Cheng <icheng@nvidia.com> Link: https://patch.msgid.link/20260709155841.1895915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14cxl/pci: Honor -EPROBE_DEFER from component register setupDave Jiang1-2/+5
cxl_pci_setup_regs() for CXL_REGLOC_RBI_COMPONENT can return -EPROBE_DEFER on a Restricted CXL Host (RCD) when the upstream port has not yet been enumerated and the Component Registers must be extracted from the RCRB. cxl_pci_probe() treats every non-zero return from that call as the benign "component registers not found" case, logs a warning, and continues. The rc is then immediately overwritten by the subsequent cxl_pci_type3_init_mailbox() call, so the deferral is silently swallowed. Return -EPROBE_DEFER instead of continuing so the probe is retried once the upstream port is available. Fixes: 733b57f262b0 ("cxl/pci: Early setup RCH dport component registers from RCRB") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://lore.kernel.org/linux-cxl/ajzhsubot_PSYtHQ@MWDK4CY14F/T/#m063bbf76b1c9c293ade52ab311018ae6bba11a44 Link: https://patch.msgid.link/20260706224322.714934-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14cxl/mbox: Break poison list loop on an empty payloadDave Jiang1-0/+5
A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing "Protect against an uncleared _FLAG_MORE" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=3 Fixes: ed83f7ca398b ("cxl/mbox: Add GET_POISON_LIST mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260709155714.1893280-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14drm/bridge: rename drm_for_each_bridge_in_chain_scoped() to ↵Luca Ceresoli4-5/+5
drm_for_each_bridge_in_chain() drm_for_each_bridge_in_chain_scoped() was added in commit e46efc6a7d28 ("drm/bridge: add drm_for_each_bridge_in_chain_scoped()") to provide a safer alternative to drm_for_each_bridge_in_chain(). Following commits converted all users to the _scoped variant. Finally commit 2f08387a444c ("drm/bridge: remove drm_for_each_bridge_in_chain()") removed the old drm_for_each_bridge_in_chain() macro. It's time to rename drm_for_each_bridge_in_chain_scoped() back to the original name. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260630-drm-bridge-alloc-getput-for_each_bridge-2-v2-1-e0a1094cd1eb@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14cxl/memdev: Fix firmware upload exact-fit handlingGuzebing1-1/+1
cxl_fw_prepare() classifies a firmware image as a one-shot transfer only when its Transfer FW input payload is smaller than the mailbox payload size. An image that exactly fills the payload is therefore treated as a multi-part transfer. The firmware loader invokes cxl_fw_write() only once for that image. Since both offset == 0 and remaining == 0, the multi-part action selection sends INITIATE, never sends END, and then attempts to activate the target slot. Include equality in the one-shot classification so exact-fit images use the FULL action. Fixes: 9521875bbe00 ("cxl: add a firmware update mechanism using the sysfs firmware loader") Signed-off-by: Guzebing <Guzebing1612@gmail.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260713112744.2543829-1-guzebing1612@gmail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-07-14drm/xe/nvm: fix writable override for CRIAlexander Usyskin1-2/+7
The witable override should be set when FDO_MODE bit is enabled. Fix the comparison to distingush this case from legacy systems where bit should be disabled to have override. Cc: stable@vger.kernel.org Fixes: 9dde74fd9e65 ("drm/xe/nvm: enable cri platform") Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260714-cri_nvm_fdo_flip-v2-1-14580e71b58e@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLEDPei Xiao1-1/+1
When the interrupt status register reads zero, the handler should return IRQ_NONE instead of IRQ_HANDLED. What the return value actually feeds into is the spurious interrupt accounting in note_interrupt(): falsely claiming IRQ_HANDLED defeats the "irq XX: nobody cared" detection, so a stuck interrupt source would never be caught. Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Cc: <stable@vger.kernel.org> # v6.15+ Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/ef8b623f45d4e430721e46572c2598d882044aed.1783667875.git.xiaopei01@kylinos.cn
2026-07-14drm/i915/display: Fix too few bits in transcoder mask variablesJohn Harrison6-27/+27
New transcoder enum values (for CMTG) were recently added which pushed the maximum transcoder mask beyond 8bits. The patch in question updated the info structure's u8 to u16 but not any of the functions that process transcoder masks. So fix those as well. v2: Fix more instances (found by Sashiko) Signed-off-by: John Harrison <John.Harrison@Igalia.com> Fixes: 789dda6429e0 ("drm/i915/cmtg: Add CMTG transcoder offset in struct _device_info") Cc: Uma Shankar <uma.shankar@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260713234138.3861243-1-John.Harrison@Igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/bridge: fix wording in commentLuca Ceresoli1-1/+1
Fix a comment according to English grammar. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-3-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/bridge: samsung-dsim: fix wording in commentLuca Ceresoli1-1/+1
Fix a comment according to English grammar. Link: https://lore.kernel.org/all/DI9ZFQUNMSBU.214AU8467OK76@bootlin.com/ Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-2-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm: of: fix wording in commentLuca Ceresoli1-1/+1
Fix a comment according to English grammar. Link: https://lore.kernel.org/all/DI9ZFQUNMSBU.214AU8467OK76@bootlin.com/ Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260701-drm-fix-graph-wording-v1-1-295605c5777b@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14Merge 7.2-rc3 into char-misc-nextGreg Kroah-Hartman1803-3496/+4328
Resolves the merge conflicts in: drivers/android/binder/node.rs drivers/android/binder/process.rs As done by linux-next Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-14vfio: Enable cdev noiommu mode under iommufdJacob Pan5-22/+55
Now that devices under noiommu mode can bind with IOMMUFD and perform IOAS operations, lift restrictions on cdev from VFIO side. Use cases are documented in Documentation/driver-api/vfio.rst Link: https://patch.msgid.link/r/fdac3395ecc52f87b722b54a055ced66733dc48f.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd: Add an ioctl to query PA from IOVA for noiommu modeJacob Pan4-0/+135
To support no-IOMMU mode where userspace drivers perform unsafe DMA using physical addresses, introduce a new API to retrieve the physical address of a user-allocated DMA buffer that has been mapped to an IOVA via IOMMU_IOAS_MAP. The mapping is backed by SW-only I/O page tables maintained by the GENERIC_PT framework. Link: https://patch.msgid.link/r/a60a601509688e8552c75e668deb548c93974a3b.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Co-developed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd: Allow binding to a noiommu deviceJason Gunthorpe1-40/+118
Allow iommufd to bind devices without an IOMMU (noiommu mode) by creating a dummy igroup for such devices and skipping hwpt operations. This enables noiommu devices to operate through the same iommufd API as IOMMU- capable devices. Link: https://patch.msgid.link/r/2c6cf6ab1564426050e637863c9b0d3b25541c63.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)Vincent Jardin1-0/+17
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the interrupt-driven block-read state machine rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle of this i2c controller. Accept count=0: NACK the in-flight dummy byte (TXAK) and set msg->len to 2 so i2c_imx_isr_read_continue() emits STOP via its normal last-byte path. The dummy byte is discarded; block-read callers only consume buf[0..count-1]. Reading I2DR has likewise already armed the next byte on the count > I2C_SMBUS_BLOCK_MAX error path, so NACK it (TXAK) before aborting with -EPROTO; otherwise the failing transfer's STOP cannot complete and the bus stays held. The atomic path regressed earlier (v3.16) and is fixed separately; this patch covers only the v6.13 state-machine rework. Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Signed-off-by: Vincent Jardin <vjardin@free.fr> Cc: <stable@vger.kernel.org> # v6.13+ Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-2-073ac9e103a5@free.fr
2026-07-14i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)Vincent Jardin1-3/+16
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support") Signed-off-by: Vincent Jardin <vjardin@free.fr> Cc: <stable@vger.kernel.org> # v3.16+ Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-1-073ac9e103a5@free.fr
2026-07-14iommufd: Move igroup allocation to a functionJason Gunthorpe1-16/+27
So it can be reused in the next patch which allows binding to noiommu device. Link: https://patch.msgid.link/r/6bc8e5eaee89e1dc5f07d13dff69b9670b55923a.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd: Support a HWPT without an iommu driver for noiommuJason Gunthorpe7-6/+158
Create just a little part of a real iommu driver, enough to slot in under the dev_iommu_ops() and allow iommufd to call domain_alloc_paging_flags() and fail everything else. This allows explicitly creating a HWPT under an IOAS. A new Kconfig option IOMMUFD_NOIOMMU is introduced to differentiate from the VFIO group/container based noiommu mode. Link: https://patch.msgid.link/r/8d1ad0b90db0381d4139eda5c126cc8d168d89f8.1783360051.git.jacob.pan@linux.microsoft.com Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Fixes: 2c6cf6ab1564 ("iommufd: Allow binding to a noiommu device") Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICENicolin Chen1-0/+15
arm_vsmmu_vsid_to_sid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP when master->num_streams is not one, rather than mapping it silently. Fixes: d68beb276ba26 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object") Link: https://patch.msgid.link/r/b15f2b73520f389f3f57881da2f040e7bdc18876.1783311134.git.nicolinc@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeedsNicolin Chen1-5/+15
iommufd_vdevice_alloc_ioctl() adds the vDEVICE to the viommu->vdevs xarray with xa_cmpxchg() before the driver's vdevice_init() op runs. That op is where a driver validates the device and may reject it, but the xarray entry is already live by then: a concurrent IOMMU_HWPT_INVALIDATE can look it up with iommufd_viommu_find_dev() and run the driver invalidation path against a device that vdevice_init() would have refused. Reserve the index with xa_insert(): it stores a zero entry that reads back as NULL, and returns -EBUSY on a duplicate virt_id. Run vdevice_init() and store the vDEVICE pointer only once it succeeds. A failed vdevice_init() releases the reservation, so lookups observe the vDEVICE only after it is fully initialized and accepted. Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE support") Link: https://patch.msgid.link/r/1e05999347f4bf583edbc6a1312c857d5548708c.1783311134.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Kevin Tian <kevin.tian@intel.com> Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd/viommu: Release the igroup lock on the vdevice_size error pathNicolin Chen1-1/+1
iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead. Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE support") Link: https://patch.msgid.link/r/e903f775d491296a525097e2a90b3eb6a47cf2ef.1783311134.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Kevin Tian <kevin.tian@intel.com> Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommufd: Simplify iommufd_device_remove_vdev()Jason Gunthorpe3-18/+24
Peiyang reports that this function indirectly includes a fault injection point through iommufd_get_object() that was intended to cover the uAPI use of object IDs, not in places like this that cannot fail. On deeper inspection this can be written using a dedicated helper to obtain a users refcount relying entirely on the xa locking instead of going through the whole get/put scheme. The new helper doesn't need the fault injection point. Fixes: 850f14f5b919 ("iommufd: Destroy vdevice on idevice destroy") Link: https://patch.msgid.link/r/0-v1-719003d53a5b+38b-iommufd_fault_inj_vdev_jgg@nvidia.com Reported-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Closes: https://lore.kernel.org/r/870BB9ADBBEDDD1A+37c5bfab-ad32-4fc5-a302-57c81a8432b5@smail.nju.edu.cn Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14drm/xe/pf: Disable display in admin only PF modeSatyanarayana K V P2-3/+2
Admin-only PF mode does not expose media or 3D execution capabilities to userspace, so display pipelines cannot receive rendered content. Fixes: d88c4bac8c2a ("drm/xe/pf: Restrict device query responses in admin-only PF mode") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20260714053259.504308-2-satyanarayana.k.v.p@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14Merge drm/drm-next into drm-xe-nextRodrigo Vivi6998-127500/+269781
Sync some i915/display changes Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/xe/display: Do not allocate into stolen for new framebuffers.Maarten Lankhorst1-27/+6
Prefer to use system memory for global framebuffers, and reserve the space for FBC use only. Now that multiple CRTC's can use FBC's, the simple heuristic of using less than half of stolen is no longer sufficient. Additionally, there are reports of system hangs when using stolen memory, and there are also various workarounds that are avoided by using system memory instead. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260630135523.1775379-4-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14soundwire: intel_auxdevice: Add cs42l44 to wake_capable_listCharles Keepax1-0/+1
Add cs42l44 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260708122948.1502227-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14soundwire: qcom: add SCP address paging supportJorijn van der Graaf1-0/+14
The Qualcomm controller driver ignores the paging fields of struct sdw_msg. For a paged access (register address >= 0x8000 on a paging-capable peripheral, e.g. the SDCA control space at 0x40000000+) the core sets BIT(15) in the wire address and splits the upper bits into addr_page1/addr_page2, but since the controller never programmed the SCP_AddrPage registers the peripheral resolved every such command against their reset value: reads and writes were silently redirected to addr[14:0] in page 0. Write the two SCP_AddrPage registers through the command FIFO before the transfer, as cadence_master.c (cdns_program_scp_addr) and amd_manager.c (amd_program_scp_addr) do. Like those controllers the pages are programmed on every paged message rather than cached per device; a cache can be a follow-up if the two extra FIFO commands ever matter. No peripheral on a Qualcomm bus sets prop.paging_support in mainline today; the first user is the WCD9378 codec, whose driver is being upstreamed separately - its entire register map, the wcd937x-compatible analog core included, lives in the SDCA address space. Verified on the Fairphone 6 (SM7635): WCD9378 SDCA registers read back their documented reset defaults and audio capture through the codec works end-to-end; without this change every paged access landed in page 0. Assisted-by: Claude:claude-fable-5 Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260706192150.143921-1-jorijnvdgraaf@catcrafts.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14soundwire: dmi-quirks: add a global ghost listBard Liao1-1/+20
Not like other ghost devices, the 0x000000D010010500 ADR doesn't belong to any codec. We should disable it in all devices. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260703011656.2572959-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14drm/i915/display: Fix NV12 ceiling division for bigjoiner caseVidya Srinivas1-20/+13
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") computes the UV (chroma) surface start/size as ceiling(half of Y plane start/size) directly from the U16.16 fixed-point source rectangle: x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1)); For a single pipe the source coordinates are integers, so this is correct. (UV start = ceiling(half of Y plane start)). With bigjoiner + a plane scaler the picture changes. The pipe boundary is a fixed integer destination pixel, but the plane's position and the scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane crossing the seam: master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0 joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884 The luma path floors this to an integer (src.x1 >> 16 = 640), but the UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane then starts at column 640 while the UV plane starts at 321*2 = 642, pushing the chroma read one column past the 640-wide chroma surface on the joiner secondary: [CRTC:382:pipe C] PLANE ATS fault [CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...) The spec "Y plane start" is the integer pixel the luma surface actually programs (640), not the pre-floor fixed-point value (640.27). Convert the Y plane start/size to integer first - matching skl_check_main_surface() - and then apply the ceiling. This is a no-op for the integer (non-joiner) case and yields the correct, in-bounds chroma offset for the fractional joiner seam: before fix after fix master 1B: x=0 w=321 x=0 w=320 -> [0, 320) slave 1C: x=321 w=320 x=320 w=320 -> [320, 640) The two halves now tile the 640-wide chroma plane exactly and the ATS fault is gone. Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com (cherry picked from commit 0c59cc78241c10e5f02d92b28d811b0435e706a7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-14drm/xe: Fix DPT allocation paths.Maarten Lankhorst1-25/+8
Remove the fallback for VRAM to system memory, I tested it and that doesn't work at all, only a black screen with pipe fault errors were observed. On systems with media GT, extra latency is added when accessing stolen memory when the GT is in MC6. Since we additionally aren't counting how much memory is used for stolen and we could in theory fill up the entire stolen area with DPT's, avoid using stolen and only use the default memory region. Using stolen may also result in random system hangs under load. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+") Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristateZhipeng Wang1-4/+7
Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate to allow building as loadable modules. This change is required to support Android devices using Generic Kernel Image (GKI) kernels, where SoC-specific drivers must be built as loadable modules rather than built into the core kernel image. For i.MX8M and i.MX9 devices running Android with GKI kernels, the BLK_CTRL drivers therefore need to be loadable. Without tristate support, power domains cannot be initialized correctly, making these systems non-functional under GKI. Add prompt strings to make these options visible and configurable in menuconfig, keeping them enabled by default on appropriate platforms. Also remove the IMX_GPCV2_PM_DOMAINS dependency from IMX9_BLK_CTRL. This dependency was incorrect from the beginning because i.MX93 uses a different power domain architecture compared to i.MX8M series: - i.MX8M uses GPCv2 (General Power Controller v2) for power domain management, hence IMX8M_BLK_CTRL correctly depends on it. - i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't have GPCv2 at all. Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-14drm/i915: Print the phys_base in addition to the dma_addr for the BIOS FBVille Syrjälä1-3/+3
Print the dma_addr, phys_base and memory region name for the BIOS FB. Should make it a bit easier to see whether everything looks correct or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-15-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Fix BIOS FB memory region name debug printsVille Syrjälä1-3/+3
Apparently we never initialize the name of the struct resource underlying the memory region. Instead we need to look at the name stored directly in the memory region itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-14-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 10:26:42 +0000