summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-14drm/xe: s/bar2/lmembar/Ville Syrjälä1-8/+8
The local memory BAR has a name (LMEMBAR). Use that instead of referring to it by its BAR register index. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-12-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Check the PTE local memory bit for initial FB in stolenVille Syrjälä1-1/+14
Do the PTE local memory bit check also for the case when the initial FB lives in stolen. We have two cases to worry about here: MTL+ with LMEMBAR, and pre-MTL with stolen being just (slightly special) physical memory. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-11-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Abstract the initial FB PTE checks a bitVille Syrjälä1-3/+14
Add a few helpers that allow us to abstract the xe initial FB PTE check a bit. Still very ad-hoc compared to the nicely abstracted i915 counterpart, but whatever. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-10-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Print a debug message if we have no stolen for the initial FBVille Syrjälä1-2/+6
Inform the poor sop reading the logs why the initial FB was rejected if there is no stolen memory. Technically this should perhaps be an error since the plane is known to be enabled at this point, and if there is no stolen then it clearly can't be scanning out from anywhere. But maybe there are some virtualization passthrough cases and whatnot where we might not be able to get access to stolen, so keep it as debug (same as i915). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-9-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/xe: Do the initial FB size alignment earlierVille Syrjälä1-4/+4
For some reason we've split the alignment of 'base' vs. 'size' to live on separate sides of the xe initial plane PTE readout. There's no reason for this split, so make things less confusing by aligning both at the same time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-7-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
2026-07-14drm/i915: Use drm_dbg_kms() for initial FB debugsVille Syrjälä2-8/+8
The initial FB stuff is ultimately about display stuff, so use the proper display specific debug level for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-6-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Throw away the BIOS fb if has the wrong depth/bppVille Syrjälä1-0/+9
Respect the user's choice of depth/bpp for the fbdev framebuffer and throw out the fb we inherited from the BIOS if it doesn't match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-4-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915/fbdev: Extract bios_fb_ok()Ville Syrjälä1-8/+18
Pull the "is the BIOS FB OK?" checks to a helper function. We'll add other relevant checks there later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-3-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14drm/i915: Disable the plane if initial plane config readout failedVille Syrjälä1-3/+3
Properly turn off the plane if it is enabled but .get_initial_plane_config() failed for whatever reason. The hardware does (or at least did) perform some kind of automagic plane disable when the pipe gets disabled, but we don't rely on that anywhere else either. Also the GGTT/actual memory may get clobbered afterwards, so leaving the plane enabled here could result in visual corruption/GTT faults/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260511214122.8468-2-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-14iommufd: Fix grammar and spelling in commentsxiongweimin2-4/+4
Correct detach kdoc ("device/pasid from"), article use before IOMMUFD_OBJ_*, and "propogated" -> "propagated". Link: https://patch.msgid.link/r/20260714024440.188358-1-15927021679@163.com Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_addPeiyang He1-1/+1
iommu_mock_device_add() first calls iommu_fwspec_init(), which on success allocates both dev->iommu (via dev_iommu_get()) and dev->iommu->fwspec. If the subsequent device_add(dev) call fails, the error path only calls iommu_fwspec_free(dev), which frees fwspec but leaves dev->iommu still allocated. This triggers the following kmemleak report when fuzzing with Syzkaller: BUG: memory leak unreferenced object 0xffff888011e0a200 (size 192): comm "syz.1.1695", pid 24885, jiffies 4295222527 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................ backtrace (crc 25df5bb3): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4575 [inline] slab_alloc_node mm/slub.c:4899 [inline] __kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408 iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087 iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385 mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline] iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline] iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072 iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev) in the device_add() failure path. dev_iommu_free() frees both fwspec and the outer dev_iommu struct and clears dev->iommu. Link: https://patch.msgid.link/r/76AC62D46B998556+20260711055119.1003477-1-peiyang_he@smail.nju.edu.cn Reported-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Fixes: 2a918911ed3d ("iommufd: Register iommufd mock devices with fwspec") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-07-14IB/rdmavt: use kzalloc() to allocate QPN-map pagesMike Rapoport (Microsoft)1-4/+4
get_map_page() allocates bitmap pages using get_zeroed_page(). The bitmaps can be allocated with kmalloc() as there's nothing special about them to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260713-b4-rdma-v2-5-65d2a1a5180c@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14IB/mthca: allocate mthca_array memory with kzalloc()Mike Rapoport (Microsoft)1-3/+3
mthca_array is essentially a sparse array of pointers and there is no need to allocate its memory using page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260713-b4-rdma-v2-4-65d2a1a5180c@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14IB/mthca: mthca_reg_user_mr(): use kmalloc() to allocate addresses arrayMike Rapoport (Microsoft)1-2/+3
mthca_reg_user_mr() allocates an array of DMA addresses during memory registration. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260713-b4-rdma-v2-3-65d2a1a5180c@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14RDMA/mlx5: replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)1-2/+4
mlx5_ib_mr_wqe_pfault_handler() allocates a scratch buffer for parsing work queue entries during page fault handling. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260713-b4-rdma-v2-2-65d2a1a5180c@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14RDMA/umem: ib_umem_get(): use kmalloc() to allocate page arrayMike Rapoport (Microsoft)1-2/+3
ib_umem_get() allocates an array of pointers to struct page for pin_user_pages_fast() calls during memory registration. This array can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260713-b4-rdma-v2-1-65d2a1a5180c@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14dmaengine: dw-edma: Remove struct dw_edma_chunkFrank Li2-112/+63
The current descriptor layout is: struct dw_edma_desc *desc └─ chunk list └─ burst[] Creating a DMA descriptor requires at least two kzalloc() calls because each chunk is allocated as a linked-list node. Since the number of bursts is already known when the descriptor is created, this linked-list layer is unnecessary. Move the burst array directly into struct dw_edma_desc and remove the struct dw_edma_chunk layer entirely. Use start_burst and done_burst to track the current bursts, which current are in the DMA link list. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-10-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Use burst array instead of linked listFrank Li2-103/+26
The current descriptor layout is: struct dw_edma_desc *desc └─ chunk list └─ burst list Creating a DMA descriptor requires at least three kzalloc() calls because each burst is allocated as a linked-list node. Since the number of bursts is already known when the descriptor is created, a linked list is not necessary. Allocate a burst array when creating each chunk to simplify the code and eliminate one kzalloc() call. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-9-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Use common dw_edma_core_start() for both eDMA and HDMAFrank Li4-103/+30
Use common dw_edma_core_start() for both eDMA and HDMA. Remove .start() callback functions at eDMA and HDMA. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-8-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Add non_ll_start() callbackFrank Li2-20/+15
Add a non_ll_start() callback and move the common non-linked-list channel handling into the EDMA core so it can be shared by both the EDMA and HDMA. Prepare for the upcoming reorganization of the burst and chunk structures. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-7-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Add callbacks to fill link list entriesFrank Li3-0/+113
Introduce four new callbacks to fill link list entries in preparation for replacing dw_(edma|hdma)_v0_core_start(). Filling link list entries is expected to become more complex, and without this abstraction both eDMA and HDMA paths would need to duplicate the same logic. Add fill-entry callbacks so the code can be shared cleanly between eDMA and HDMA implementations. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-6-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Add helper dw_(edma|hdma)_v0_core_ch_enable()Frank Li2-89/+93
Move the channel-enable logic into a new helper function, dw_(edma|hdma)_v0_core_ch_enable(), in preparation for supporting dynamic link entry additions. No functional changes. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-5-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Pass down dw_edma_chan to reduce one level of indirectionFrank Li2-24/+21
Some helper functions do not use any information from dw_edma_chunk, so passing a dw_edma_chan pointer directly avoids an unnecessary level of pointer dereferencing and simplifies data access. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-4-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Move ll_region from struct dw_edma_chunk to struct ↵Frank Li4-28/+25
dw_edma_chan ll_region is identical for all chunks belonging to the same DMA channel, so there is no need to copy it into each chunk. Move ll_region to struct dw_edma_chan to avoid redundant copies. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-3-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Add xfer_sz field to struct dw_edma_chunkFrank Li2-2/+3
Reusing ll_region.sz as the transfer size is misleading because ll_region.sz represents the memory size of the EDMA link list, not the amount of data to be transferred. Add a new xfer_sz field to explicitly indicate the total transfer size of a chunk. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-2-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14dmaengine: dw-edma: Move control field update of DMA link to the last stepFrank Li2-8/+12
The control field in a DMA link list entry must be updated as the final step because it includes the CB bit, which indicates whether the entry is ready. Add dma_wmb() to ensure the correct memory write ordering. Currently the driver does not update DMA link entries while the DMA is running, so no visible failure occurs. However, fixing the ordering now prepares the driver for supporting link entry updates during DMA operation. Tested-by: Koichiro Den <den@valinux.co.jp> Tested-By: Devendra Verma <devendra.verma@amd.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713-edma_ll-v7-1-6fb7498c901e@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is enabledSrikanth Boyapally1-4/+8
When use_dma_read is enabled, the IRQ handler unconditionally overwrites irq_status with the return value of get_dma_status(). For write operations, DMA status returns 0 since no DMA read is in progress, causing irq_status to become 0. The subsequent completion signal is never triggered and the write operation times out with -ETIMEDOUT: cadence-qspi f1010000.spi: Indirect write timeout spi-nor spi0.1: operation failed with -110 Fix this by separating the DMA completion path from the write interrupt path. If get_dma_status() indicates DMA read completion, signal completion and return immediately. Otherwise, preserve the original irq_status so that write completion interrupts are correctly recognized and signalled. Fixes: aac733a96636 ("spi: cadence-qspi: Fix style and improve readability") Signed-off-by: Srikanth Boyapally <srikanth.boyapally@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260708045148.2993313-1-srikanth.boyapally@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14spi: altera: Simplify with dev_err_probe()Krzysztof Kozlowski1-8/+5
Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260705172737.120095-6-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14spi: atmel-quadspi: Simplify with dev_err_probe()Krzysztof Kozlowski1-11/+6
Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260705172737.120095-5-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14spi: atmel-quadspi: Simplify probe() with local 'dev' variableKrzysztof Kozlowski1-18/+19
Instead of multiple '&pdev->dev' dereferences, just use a local 'dev' variable which makes multiple function calls shorter thus easier to follow. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260705172737.120095-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14dmaengine: fsl-edma: Add error handling for devm_kasprintfGriffin Kroah-Hartman1-0/+2
Add error handling statement to fls_edma3_irq_init() for the devm_kasprintf call. Assisted-by: gkh_clanker_2000 Cc: stable <stable@kernel.org> Cc: Frank Li <Frank.Li@nxp.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: imx@lists.linux.dev Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/2026070605-frying-fling-b9c5@gregkh Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-14spi: dw-dma: Wait for controller idle before completing TxWang YuWei1-1/+2
dw_spi_dma_wait_tx_done() polls dw_spi_dma_tx_busy(), which only checks DW_SPI_SR_TF_EMPT. An empty TX FIFO merely means the last data word has been moved into the shift register; the transfer is not complete on the bus until DW_SPI_SR_BUSY is also cleared. As a result the wait can return while the controller is still shifting out the final word. Any caller that tears down or reconfigures the controller right after the transfer can then lose the tail of the transfer. The memory-operation path in spi-dw-core.c already waits for both DW_SPI_SR_BUSY == 0 and DW_SPI_SR_TF_EMPT == 1. Use the same completion condition in the DMA path so the transfer is guaranteed to be finished on the bus before the wait returns. Signed-off-by: Wang YuWei <1973615295@qq.com> Link: https://patch.msgid.link/tencent_4EA7B5C94669ED4C38A5F6C1C9126E5D9106@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-14pwm: tegra: Add support for Tegra264Mikko Perttunen1-19/+72
Tegra264 changes the register layout to accommodate wider fields for duty and scale, and adds configurable depth which will be supported in a later patch. The enable bit also moves from CSR_0 to a separate CSR_1 register. To support the new enable register location, introduce an enable_reg field in struct tegra_pwm_soc that identifies which register contains the PWM_ENABLE bit. tegra_pwm_enable() and tegra_pwm_disable() read/write this field accordingly, and tegra_pwm_config() skips OR-ing PWM_ENABLE into its CSR_0 write on SoCs where the enable bit is not in CSR_0. Update the top comment to describe the register layout in more detail. Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com> Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260701-t264-pwm-v6-6-2718f61f411f@nvidia.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-07-14pwm: tegra: Parametrize duty and scale field widthsMikko Perttunen1-13/+17
Tegra264 has wider fields for the duty and scale register fields. Parameterize the scale field width. The depth value becomes disconnected from the duty field width, so define it separately and remove the duty field width definition. Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com> Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260701-t264-pwm-v6-5-2718f61f411f@nvidia.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-07-14pwm: tegra: Modify read/write accessors for multi-register channelMikko Perttunen1-11/+15
On Tegra264, each PWM instance has two registers (per channel, of which there is one). Update the tegra_pwm_readl/tegra_pwm_writel helper functions to take channel (as struct pwm_device *) and offset separately. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260701-t264-pwm-v6-4-2718f61f411f@nvidia.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-07-14pwm: tegra: Avoid hard-coded max clock frequencyYi-Wei Wang1-13/+8
The clock driving the Tegra PWM IP can be sourced from different parent clocks. Hence, let dev_pm_opp_set_rate() set the max clock rate based upon the current parent clock that can be specified via device-tree. After this, the Tegra194 SoC data becomes redundant, so get rid of it. Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260701-t264-pwm-v6-3-2718f61f411f@nvidia.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-07-14pwm: tegra: Prefix driver-local macros and functionsMikko Perttunen1-27/+27
Prefix driver-local defines and functions with tegra_/TEGRA_ to clearly distinguish them from any general PWM related symbols. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260701-t264-pwm-v6-2-2718f61f411f@nvidia.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-07-14can: esd_usb: kill anchored URBs before freeing netdevsFan Wu1-1/+4
esd_usb_disconnect() frees each CAN netdev with free_candev() inside its per-netdev loop and only calls unlink_all_urbs(dev) afterwards. The per-netdev private data (struct esd_usb_net_priv) is embedded in the net_device allocation returned by alloc_candev(), so once free_candev() has run, dev->nets[i] points to freed memory. unlink_all_urbs() then dereferences the freed dev->nets[i] to kill the per-netdev TX anchor (usb_kill_anchored_urbs(&priv->tx_submitted)), clear active_tx_jobs, and reset priv->tx_contexts[]. Reorder the teardown so the anchored URBs are killed before the netdevs are freed, matching other CAN/USB drivers in the same directory such as ems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then free: unregister the netdevs first (which stops their TX queues), call unlink_all_urbs(dev) once, then free the netdevs. This issue was found by an in-house static analysis tool. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260709164159.497640-1-fanwu01@zju.edu.cn Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-07-14can: vxcan: Kconfig: fix description stating no local echo providedAlexander Hölzl1-5/+2
The Kconfig description of the vxcan kernel module erroneously states the the vxcan interface does not provide a local echo of sent can frames. However this behavior changed in commit 259bdba27e32 ("vxcan: enable local echo for sent CAN frames") and vxcan interfaces now provide a local echo. Change the description of the vxcan module in the Kconfig to reflect this change. Signed-off-by: Alexander Hölzl <alexander.hoelzl@gmx.net> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260619090035.17769-1-alexander.hoelzl@gmx.net [mkl: rephrase patch description] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-07-14drm/xe: Hold a dma-buf reference for imported BOsNitin Gote4-6/+25
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8023 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Christian Konig <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710191027.260160-2-nitin.r.gote@intel.com
2026-07-14auxdisplay: panel: Remove unused callback binding codeMiles Krause1-37/+0
panel_bind_callback() has been compiled out with #if 0 since the commit 630231776da4916e ("Staging: panel: remove support for smartcards") in v2.6.29 and now has no callers. Remove the dead function to reduce maintenance burden. No functional change. Signed-off-by: Miles Krause <mileskrause5200@gmail.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Willy Tarreau <willy@haproxy.com> Link: https://patch.msgid.link/20260712-panel-remove-dead-callback-v1-1-1091ce75b8d5@gmail.com [andy: update commit message as suggested by Geert] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2026-07-14RDMA: Remove redundant memset() from query_device callbacksLeon Romanovsky13-19/+0
The core always hands the driver's query_device() callback a zeroed ib_device_attr. There are only two callers of the op and both clear the structure before invoking it: setup_device() memsets &device->attrs, and ib_uverbs_ex_query_device() passes an on-stack structure initialized to {}. The open-coded memset(props, 0, sizeof(*props)) at the top of the driver callbacks is therefore redundant. Remove it from all drivers. Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-14drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCHimal Prasad Ghimiray1-5/+20
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: c1bb69a2e8e2 ("drm/xe/svm: Consult madvise preferred location in prefetch") Cc: Matthew Brost <matthew.brost@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260624174943.2808767-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-07-14RDMA/efa: Add EFA 0xefa4 PCI IDAnas Mousa1-0/+2
Add support for 0xefa4 devices. Reviewed-by: Michael Margolin <mrgolin@amazon.com> Signed-off-by: Anas Mousa <anasmous@amazon.com> Link: https://patch.msgid.link/20260712134413.19226-3-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14RDMA/efa: Extend page-shift field in MR registrationMichael Margolin1-3/+3
Update device interface adding one more bit from reserved to enable >4GB page sizes that can be supported on 0xefa4 devices. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260712134413.19226-2-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-14serial: 8250_hub6: add missing include for hub6_match_port()Hugo Villeneuve1-0/+2
Add missing include to fix compile warning: drivers/tty/serial/8250/8250_hub6.c:44:6: warning: no previous prototype for 'hub6_match_port' [-Wmissing-prototypes] Fixes: 3d406299d882 ("serial: 8250_hub6: add hub6_match_port()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607110715.VGT2dVVz-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607111219.QG9uOW8H-lkp@intel.com/ Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260714012610.576746-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-14cpufreq: brcmstb-avs: Remove redundant dev_err()Pan Chuang1-4/+1
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> [ Viresh: Fixed Subject ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-07-13rpmsg: glink: smem: order FIFO read after availability checkChunkai Deng1-0/+7
glink_smem_rx_peek() reads the RX FIFO payload after the caller has determined data is available via glink_smem_rx_avail(), which reads the remote-updated head index. A control dependency between the head read and the subsequent payload read does not order the two loads, so the CPU may speculatively read the FIFO before observing the head update and consume stale data the remote has not yet published. Add rmb() in glink_smem_rx_peek() before the memcpy_fromio() so the availability (head) read is ordered ahead of the FIFO payload read, matching the consumer pattern in Documentation/core-api/circular-buffers.rst. Fixes: caf989c350e8 ("rpmsg: glink: Introduce glink smem based transport") Cc: stable@vger.kernel.org Signed-off-by: Chunkai Deng <chunkai.deng@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260618-rpmsg-glink-smem-mb-v1-1-68a026453a69@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-13rpmsg: glink: fix deadlock in endpoint destroy during driver detachVishnu Santhosh1-3/+0
During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock. Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com> Tested-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Fixes: a53e356df548 ("rpmsg: glink: fix rpmsg device leak") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260604-rpmsg-glink-fix-deadlock-destroy-ept-v1-1-b8a54ad1e4fd@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-13Input: mms114 - fix Y-resolution configurationDmitry Torokhov1-1/+1
In mms114_setup_regs(), the driver mistakenly uses props->max_x instead of props->max_y when configuring the low bits of the Y resolution (MMS114_Y_RESOLUTION). Fix this by using the correct property. Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver") Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260704060115.353049-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 10:13:07 +0000