summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31dma-direct: set decrypted flag for remapped DMA allocationsAneesh Kumar K.V (Arm)1-12/+44
Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use. Fix dma_direct_alloc() and dma_direct_free() to apply set_memory_*() to the linear-map alias of the backing pages instead of the remapped CPU address. Also disallow highmem pages for __DMA_ATTR_ALLOC_CC_SHARED, because highmem buffers do not provide a usable linear-map address. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-19-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHAREDAneesh Kumar K.V (Arm)5-30/+34
Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED. Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent. Update the arm64, x86, s390 and powerpc secure-guest setup to not use swiotlb force option Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-18-aneesh.kumar@kernel.org [mszyprow: rebased onto latest changes in arch/arm64/mm/init.c] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-30KVM: arm64: selftests: Add a userspace watchpoint testFuad Tabba1-0/+41
debug-exceptions covers guest self-hosted debug and userspace single-step, but not a userspace (KVM_GUESTDBG_USE_HW) watchpoint, whose KVM_EXIT_DEBUG reports the accessed address in debug.arch.far. Add a test that installs a host-directed write watchpoint and checks that the reported address matches the accessed variable. Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260726143643.303456-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Flush external_mdscr_el1 to the pKVM hyp vCPUFuad Tabba1-2/+8
flush_debug_state() propagates the guest's debug_owner and the owner-selected debug register state to the hyp vCPU, but not external_mdscr_el1. While the host owns the debug registers, the world switch loads MDSCR_EL1 from external_mdscr_el1 (ctxt_mdscr_el1()), where the host's KDE/MDE/SS bits live. A non-protected guest under KVM_GUESTDBG_USE_HW or single-step therefore runs with MDSCR_EL1.MDE/SS clear in hardware, and its watchpoints, breakpoints and single-step never fire. Propagate external_mdscr_el1 to the hyp vCPU alongside the host-owned debug state. Fixes: 4ad3a0b87f2ec ("KVM: arm64: Don't hijack guest context MDSCR_EL1") Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260726143643.303456-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31dma-direct: Move dma_direct_map_phys() to dma/direct.cAneesh Kumar K.V (Arm)2-53/+56
dma_direct_map_phys() is too large to benefit from being inlined. Move its implementation to direct.c and leave the declaration in direct.h. No functional change in this patch Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-17-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checksAneesh Kumar K.V (Arm)5-22/+32
Teach dma_capable() about DMA_ATTR_CC_SHARED so the capability check can reject encrypted DMA addresses for devices that require unencrypted/shared DMA. Also propagate DMA_ATTR_CC_SHARED in swiotlb_map() when the selected SWIOTLB pool is decrypted so the capability check sees the correct DMA address attribute. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-16-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHAREDAneesh Kumar K.V (Arm)2-9/+15
Fold encrypted/decrypted pgprot selection into dma_pgprot() so callers do not need to adjust the page protection separately. Update dma_pgprot() to apply pgprot_decrypted() when DMA_ATTR_CC_SHARED or __DMA_ATTR_ALLOC_CC_SHARED is set and pgprot_encrypted() otherwise Convert the dma-direct mmap paths to pass DMA_ATTR_CC_SHARED instead of open-coding force_dma_unencrypted() handling around dma_pgprot(). Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-15-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHAREDAneesh Kumar K.V (Arm)4-48/+162
Teach swiotlb to distinguish between encrypted and decrypted bounce buffer pools, and make allocation and mapping paths select a pool whose state matches the requested DMA attributes. Add a cc_shared flag to io_tlb_mem, initialize it for the default and restricted pools, and propagate __DMA_ATTR_ALLOC_CC_SHARED into swiotlb pool allocation. Reject swiotlb alloc/map requests when the selected pool does not match the required encrypted/decrypted state. Also return DMA addresses with the matching phys_to_dma_{encrypted, unencrypted} helper so the DMA address encoding stays consistent with the chosen pool. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-14-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: pass mapping attributes by referenceAneesh Kumar K.V (Arm)4-6/+6
Change swiotlb_tbl_map_single() to take the DMA mapping attributes by reference and update the direct callers accordingly. This is a preparatory change for a follow-up patch which updates the attributes based on the selected swiotlb pool. Keeping the signature change separate makes the follow-up patch easier to review. No functional change in this patch. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-13-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-pool: track decrypted atomic pools and select them via attrsAneesh Kumar K.V (Arm)5-74/+139
Teach the atomic DMA pool code to distinguish between encrypted and unencrypted pools, and make pool allocation select the matching pool based on DMA attributes. Introduce a dma_gen_pool wrapper that records whether a pool is unencrypted, initialize that state when the atomic pools are created, and use it when expanding and resizing the pools. Update dma_alloc_from_pool() to take attrs and skip pools whose encrypted state does not match __DMA_ATTR_ALLOC_CC_SHARED. Update dma_free_from_pool() accordingly. Also pass __DMA_ATTR_ALLOC_CC_SHARED from the swiotlb atomic allocation path so decrypted swiotlb allocations are taken from the correct atomic pool. Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-12-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free pathsAneesh Kumar K.V (Arm)2-9/+42
Propagate force_dma_unencrypted() into __DMA_ATTR_ALLOC_CC_SHARED in the dma-direct allocation path and use the attribute to drive the related decisions. This updates dma_direct_alloc(), dma_direct_free(), and dma_direct_alloc_pages() to fold the forced unencrypted case into attrs. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-11-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-mapping: Add internal shared allocation attributeAneesh Kumar K.V (Arm)3-1/+39
DMA_ATTR_CC_SHARED describes an existing DMA mapping whose backing memory is already shared, or decrypted, for confidential computing. It is a mapping attribute: callers use it to request a shared DMA address encoding for memory that has already been prepared for shared DMA. Allocation paths need a related but different state. Once the DMA core decides that an allocation must use shared backing pages, the lower-level allocation helpers need to select shared pools, decrypt newly allocated pages, derive the DMA address with the shared-memory translation and restore encryption on free. That state is internal to the DMA-mapping implementation and should not be passed by drivers to dma_alloc_attrs(). Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-10-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31coco: arm64: s390: powerpc: Mark secure guests with CC_ATTR_GUEST_MEM_ENCRYPTAneesh Kumar K.V (Arm)3-0/+3
arm64 Realms, powerpc secure guests and s390 protected virtualization guests currently report CC_ATTR_MEM_ENCRYPT, but not CC_ATTR_GUEST_MEM_ENCRYPT. These environments are all secure guest configurations. Their force_dma_unencrypted() implementations also treat the same secure guest state as requiring unencrypted DMA. Report CC_ATTR_GUEST_MEM_ENCRYPT for the same condition so generic confidential-computing code can distinguish guest memory encryption from host memory encryption instead of relying only on CC_ATTR_MEM_ENCRYPT. Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-9-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pagesAneesh Kumar K.V (Arm)3-18/+65
Move swiotlb allocation out of __dma_direct_alloc_pages() and handle it in dma_direct_alloc() / dma_direct_alloc_pages(). This is needed for follow-up changes that simplify the handling of memory encryption/decryption based on the DMA attribute flags. swiotlb backing pages are already mapped decrypted by swiotlb_update_mem_attributes() and rmem_swiotlb_device_init(), so dma-direct should not call dma_set_decrypted() on allocation nor dma_set_encrypted() on free for swiotlb-backed memory. Update alloc/free paths to detect swiotlb-backed pages and skip encrypt/decrypt transitions for those paths. Keep the existing highmem rejection in dma_direct_alloc_pages() for swiotlb allocations. Only for "restricted-dma-pool", we currently set `for_alloc = true`, while rmem_swiotlb_device_init() decrypts the whole pool up front. This pool is typically used together with "shared-dma-pool", where the shared region is accessed after remap/ioremap and the returned address is suitable for decrypted memory access. So existing code paths remain valid. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-8-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31s390: Expose protected virtualization through cc_platform_has()Aneesh Kumar K.V (Arm)2-0/+15
Protected virtualization guests use memory encryption, so advertise that to the rest of the kernel through cc_platform_has(CC_ATTR_MEM_ENCRYPT). s390 already forces DMA mappings to be unencrypted for protected virtualization guests through force_dma_unencrypted(). Add ARCH_HAS_CC_PLATFORM and provide the matching cc_platform_has() implementation Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Matthew Rosato <mjrosato@linux.ibm.com> Cc: Jaehoon Kim <jhkim@linux.ibm.com> Tested-by: Jaehoon Kim <jhkim@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-7-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31swiotlb: Preserve allocation virtual address for dynamic poolsAneesh Kumar K.V (Arm)1-12/+19
swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator. Fixes: 79636caad361 ("swiotlb: if swiotlb is full, fall back to a transient memory pool") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-6-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: free atomic pool pages by physical addressAneesh Kumar K.V (Arm)3-2/+64
dma_direct_alloc_pages() may satisfy atomic allocations from the coherent atomic pools. The pool allocation is keyed by the virtual address stored in the gen_pool, but the pages API returns only the backing struct page. On architectures with CONFIG_DMA_DIRECT_REMAP, atomic pool chunks are added to the gen_pool using their remapped virtual address. dma_direct_free_pages() reconstructs a linear-map address with page_address(page) and passes that to dma_free_from_pool(). That address does not match the gen_pool virtual range, so the pool lookup can fail and the code can fall through to freeing a pool-owned page through the normal page allocator path. Add a page-based pool free helper that looks up the owning pool chunk by physical address, translates it back to the gen_pool virtual address, and frees that address to the pool. Use it from dma_direct_free_pages() while keeping the existing virtual-address helper for coherent allocation frees. Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-5-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31iommu/dma: Check atomic pool allocation result directlyAneesh Kumar K.V (Arm)1-5/+8
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping. Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-4-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-pool: fix page leak in atomic_pool_expand() cleanupAneesh Kumar K.V (Arm)1-3/+7
atomic_pool_expand() frees the allocated pages from the remove_mapping error path only when CONFIG_DMA_DIRECT_REMAP is enabled. When CONFIG_DMA_DIRECT_REMAP is disabled, failures after page allocation, such as gen_pool_add_virt(), jump to remove_mapping and return without freeing the pages. Move __free_pages(page, order) out of the CONFIG_DMA_DIRECT_REMAP block so that cleanup paths always release the allocation. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-3-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: return struct page from dma_direct_alloc_from_pool()Aneesh Kumar K.V (Arm)1-8/+10
Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller. Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") Cc: stable@vger.kernel.org Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-2-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31ALSA: hda: Add hda_append_suffix() local helperTakashi Iwai3-3/+10
As strlcat() shall be deprecated in future, provide an alternative just for a simple purpose -- append a suffix string to the given string buffer -- and use it at appropriate places. The code isn't really efficient, but we don't ask for speed here, so let it be. Link: https://lore.kernel.org/amolHJpiluNmBsDU@dev Reviewed-by: Ian Bridges <icb@fastmail.org> Tested-by: Ian Bridges <icb@fastmail.org> Link: https://patch.msgid.link/20260730161518.641254-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-30KVM: arm64: Optimize protected mode with FWB and DICMostafa Saleh1-0/+7
KVM opportunistically enables FWB if supported by the system for guest VMs, which allows it to elude cache maintenance for data as they are forced to be cacheable from stage-2. In that case, __clean_dcache_guest_page() will immediately return. However in protected mode, before calling __clean_dcache_guest_page() it loops over the range and fix_map/unmap it, issuing TLB invalidations, dsb() and isb() unnecessarily. This can be optimized by returning early if FWB is supported, kvm_pgtable_stage2_map() already issues dsb() and tlb invalidation functions issue dsb() for the unmap path. Similarly for DIC, we can omit the call in invalidate_icache_guest_page() No isb() needed as ERET is context synchronization event. Signed-off-by: Mostafa Saleh <smostafa@google.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260723162002.3848054-1-smostafa@google.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU featureCongkai Tan6-8/+54
Introduce a new vCPU feature KVM_ARM_VCPU_PMU_V3_STRICT. When set, KVM does not create a default PMU when initializing the vCPU, and userspace must select one explicitly via KVM_ARM_VCPU_PMU_V3_SET_PMU before the first KVM_RUN. The flag forces the VMM to be aware of the PMU implementation of the guest to be created, so that certain information about the PMU becomes deterministic (if on a heterogeneous system) and becomes safe to be exposed to the guest. It can be used as an umbrella flag to gate future PMUv3 UAPI changes. When no default PMU is created, kvm->arch.arm_pmu stays NULL until SET_PMU runs, so kvm_arm_pmu_v3_init() now refuses to run if kvm->arch.arm_pmu is NULL. Signed-off-by: Congkai Tan <congkai@amazon.com> Reviewed-by: Geoff Blake <blakgeof@amazon.com> Reviewed-by: Haris Okanovic <harisokn@amazon.com> Reviewed-by: Stanislav Spassov <stanspas@amazon.de> Co-developed-by: Oliver Upton <oupton@kernel.org> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Tested-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260722202702.4165917-5-congkai@amazon.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Ignore writes to PMCR_EL0.N when using strict UAPIOliver Upton1-0/+1
KVM allows userspace to configure the number of event counters by writing to PMCR_EL0.N. While this makes a bit of sense prior to NV, the value of the field is context-dependent whether or not the vCPU is at EL2 or EL1. As such, the vCPU attribute was added afterwards and made mandatory for NV. As we're in the process of papering over old mistakes, force userspace to use the vCPU attribute if KVM_ARM_VCPU_PMU_V3_STRICT is set. Reviewed-by: Geoff Blake <blakgeof@amazon.com> Reviewed-by: Haris Okanovic <harisokn@amazon.com> Signed-off-by: Congkai Tan <congkai@amazon.com> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Tested-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260722202702.4165917-4-congkai@amazon.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Advertise STALL_SLOT* in PMCEID1 under strict PMUv3 UAPICongkai Tan1-12/+13
Skip masking STALL_SLOT, STALL_SLOT_FRONTEND and STALL_SLOT_BACKEND out of PMCEID1 when KVM_ARM_VCPU_PMU_V3_STRICT is set, because this is when PMMIR_EL1.SLOTS is exposed to guests, making these events meaningful for collection. Change the parameter of compute_pmceid1() from arm_pmu to kvm_vcpu, to check if KVM_ARM_VCPU_PMU_V3_STRICT is set. Also updated the signature of compute_pmceid0() for consistency. Signed-off-by: Congkai Tan <congkai@amazon.com> Reviewed-by: Geoff Blake <blakgeof@amazon.com> Reviewed-by: Haris Okanovic <harisokn@amazon.com> Reviewed-by: Stanislav Spassov <stanspas@amazon.de> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Tested-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260722202702.4165917-3-congkai@amazon.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Expose PMMIR_EL1.SLOTS under strict PMUv3 UAPICongkai Tan6-2/+81
Introduce a new field pmmir_slots in struct kvm_arch to store PMMIR_EL1.SLOTS. It only saves the actual hardware PMU value when the VMM explicitly selects a PMU under KVM_ARM_VCPU_PMU_V3_STRICT. Otherwise, it stays 0 after allocation. Use this field to implement guest access, userspace get, and userspace set for PMMIR_EL1: - access_pmmir(): uses the value in kvm->arch.pmmir_slots directly. If the VMM selected a PMU and KVM_ARM_VCPU_PMU_V3_STRICT is set, the guest can correctly read the underlying core's SLOTS. Otherwise, it continues to read 0 since the true SLOTS value can be nondeterministic. - get_pmmir(): same as access_pmmir(). - set_pmmir(): only the SLOTS field is writable; a value setting any other bit is rejected with -EINVAL, since get_pmmir() returns SLOTS zero-extended. A value of 0 resets kvm->arch.pmmir_slots to 0 for backward compatibility, as the register is RAZ in older KVM, a value matching the current SLOTS is accepted as a no-op, and anything else is rejected with -EINVAL. Once the VM has run PMMIR_EL1 is immutable, so a mismatching write then returns -EBUSY. The register is now exposed via KVM_GET_REG_LIST for PMUv3 vCPUs, so add it to the get-reg-list selftest's PMU register list. Signed-off-by: Congkai Tan <congkai@amazon.com> Reviewed-by: Geoff Blake <blakgeof@amazon.com> Reviewed-by: Haris Okanovic <harisokn@amazon.com> Reviewed-by: Stanislav Spassov <stanspas@amazon.de> Co-developed-by: Oliver Upton <oupton@kernel.org> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Tested-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260722202702.4165917-2-congkai@amazon.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31Merge tag 'amd-drm-next-7.3-2026-07-29' of ↵Dave Airlie291-3526/+16569
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-07-29: amdgpu: - VCN 5.3 fix - UserQ fixes - GEM close optimization - HDMI AV mute fix - UML build fixes - GFXOFF residency metrics fixes - SMU 15 fixes - debug_vm fix - PSP 15 fixes - NBIO 7.11.5 fix - pptable use after free fix - gpu metrics fetch fix - DC viewport fix - DML2.1 fix - i2c retimer spam fix - UMD profile pstate fix - Power metrics format cleanup - GTT size fix on APUs - DC context logging fix - Misc fixes - IB pool clean up and fixes - DCN 4.2 updates - Old BUG() and BUG_ON() removal - RAS updates - PASID management updates - DC MCIF ARB updates - More DC KUNIT tests - Refactor dc_validation_set - Introduce dc_state_get_status unified status accessor - Apple Studio Display fixes - DML updates - DC writeback fixes - MES updates - PTL updates - DC code restructuring - DC FRL fixes - Add modifiers for GFX6-8 - Resume fix for MacBookPro15,1 amdkfd: - Various bounds checking fixes - Mutex locking fix - Clean up debug runlist printing - SR-IOV fixes - Avoid topology_lock in kfd_mmap - Fix signal reset event - SVM eviction fixes radeon: - Fix for unset CONFIG_ACPI Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260729201801.4073097-1-alexander.deucher@amd.com
2026-07-31wifi: mm81x: prevent timers from outliving teardownLinmao Li3-3/+3
The three timer teardown paths call timer_delete_sync_try() and ignore its return value. If a callback is running on another CPU it returns -1 without waiting, and it does not prevent a later rearm even when it does deactivate a pending timer. mm81x_skbq_tx_complete() can rearm the stale-status timer, and the rc and yaps callbacks queue work that rearms their timers. Teardown can therefore continue with a callback still running or the timer rearmed, so it fires after the associated state has been freed. Use timer_shutdown_sync() for these permanent teardowns: it waits for an in-flight callback and prevents any future rearm. In mm81x_rc_deinit() shut the timer down before cancel_work_sync() so the work can no longer recreate the timer/work cycle. Fixes: b1906cea00b0 ("wifi: mm81x: add mm81x Wi-Fi HaLow driver") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Dan Callaghan <dan.callaghan@morsemicro.com> Link: https://patch.msgid.link/20260723113927.2370301-1-lilinmao@kylinos.cn Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
2026-07-31md: do overflow check for sb->bblog_shift in super_1_load()Coly Li1-0/+7
In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant. Fixes: 2699b67223ac ("md: load/store badblock list from v1.x metadata") Fixes: 1726c7746783 ("badblocks: improve badblocks_set() for multiple ranges handling") Cc: stable@vger.kernel.org Cc: Ramesh Adhikari <adhikari.resume@gmail.com> Signed-off-by: Coly Li <colyli@fygo.io> Reviewed-by: Yu Kuai <yukuai@fygo.io> Link: https://patch.msgid.link/20260720111400.2120834-1-colyli@fygo.io Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31md: scope memalloc_noio to allocation critical sectionsChen Cheng4-23/+48
Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write. Link: https://github.com/chencheng-fnnas/reproducer/blob/main/repro-md-noio-token-leak.sh Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Chen Cheng <chencheng@fnnas.com> Reviewed-by: Yu Kuai <yukuai@fygo.io> Link: https://patch.msgid.link/20260718084218.417895-1-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31md/bitmap: resume array on backlog_store() error pathChen Cheng1-1/+1
backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states. Fixes: 58226942ad3d ("md: use new apis to suspend array before mddev_create/destroy_serial_pool") Signed-off-by: Chen Cheng <chencheng@fnnas.com> Reviewed-by: Yu Kuai <yukuai@fygo.io> Link: https://patch.msgid.link/20260718034236.4119093-1-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31Merge tag 'drm-intel-fixes-2026-07-30' of ↵Dave Airlie4-1/+38
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes One DP DSC fix and one HDMI 2.0 fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/amvIvqJehP7uaUgx@intel.com
2026-07-31Merge tag 'amd-drm-fixes-7.2-2026-07-30' of ↵Dave Airlie2-34/+57
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-30: amdgpu: - PM sysfs fix for APUs - Follow on pageflip timeout fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260730150018.801791-1-alexander.deucher@amd.com
2026-07-31Merge tag 'drm-xe-fixes-2026-07-30' of ↵Dave Airlie1-5/+8
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Check no-DMA huge-pte cases before DMA segment test (Himal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/amtk7ZddR12dgg-A@intel.com
2026-07-31md/raid5: complete discard bios while reshape is activeGenjian Zhang1-2/+6
make_discard_request() returns without completing the bio when reshape is in progress. Discard callers block in submit_bio_wait() waiting for a completion that never arrives. The caller hangs in uninterruptible sleep, and this does not resolve when reshape finishes. Complete the bio with BLK_STS_AGAIN so userspace can retry after reshape, consistent with the existing policy of not processing discard during reshape. Tested on a loop-backed RAID5 array during mdadm --grow: without this patch, blkdiscard hangs in bio_await() and remains in uninterruptible sleep after md reports "reshape done"; with this patch it returns -EAGAIN instead. Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Reviewed-by: Yu Kuai <yukuai@fygo.io> Link: https://patch.msgid.link/20260711161326.962336-1-zhanggenjian@126.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31Merge tag 'drm-misc-fixes-2026-07-30' of ↵Dave Airlie18-65/+230
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fies for v7.2-rc6: - vmwgfx: - Improve various size checks and limit checks. - Fix oops when submitting invalid execbuf ioctl. - Correctly lock in vmfwgx fence signaling path. - More validation of execbuf ioctl. - Fix oops in vmwgfx vkms init failure path. - Overflow handling in shader path. - Improve firmware validation in panthor. - Fix small leak in bridge/display-connector - Improve imagination trace points. - Fix QAIC transaction length check. - Restrict some DP bandwidth calculations to HDMI DFP. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/178a513f-2d7f-4e3a-811b-cd0d9dc309eb@linux.intel.com
2026-07-31Merge tag 'amd-drm-fixes-7.2-2026-07-29' of ↵Dave Airlie63-254/+818
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-29: amdgpu: - VCN 5.3 fix - UserQ fixes - GEM close optimization - HDMI AV mute fix - UML build fixes - GFXOFF residency metrics fixes - SMU 15 fixes - debug_vm fix - PSP 15 fixes - NBIO 7.11.5 fix - pptable use after free fix - gpu metrics fetch fix - DC viewport fix - DML2.1 fix - i2c retimer spam fix - UMD profile pstate fix - Power metrics format cleanup - GTT size fix on APUs - DC context logging fix amdkfd: - Various bounds checking fixes - Mutex locking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260729182209.4072227-1-alexander.deucher@amd.com
2026-07-31Merge tag 'mediatek-drm-fixes-20260729' of ↵Dave Airlie5-16/+21
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20260729 1. Check CRTC state before freeing 2. mtk_hdmi: Fix DDC adapter double put in v2 3. mtk_hdmi_common: take i2c adapter module reference 4. mtk_dsi: Enable HS clock only at pre-enable 5. ovl_adaptor: balance component registrations Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260729131701.4158-1-chunkuang.hu@kernel.org
2026-07-30clk: qcom: Return expected ENOMEM error on dynamic allocation failureVladimir Zapolskiy1-2/+2
If a dynamic memory allocation fails, the returned error code in clock controller driver probe functions on a few legacy platforms should be set to -ENOMEM instead of -EINVAL. Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly") Signed-off-by: Vladimir Zapolskiy <vz@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629162127.3910603-1-vz@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: apss-ipq-pll: Add IPQ5210 supportVaradarajan Narayanan1-0/+19
The Application Processor Subsystem on the IPQ5210 platform sources its clock from the Huayra PLL. Add the configuration data necessary to set it up. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260703-apss-clk-v3-2-4785e89a9c58@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom,a53pll: Add IPQ5210 compatibleVaradarajan Narayanan1-0/+1
Add the qcom,ipq5210-a53pll compatible for the A53 PLL found on IPQ5210 SoCs. Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260703-apss-clk-v3-1-4785e89a9c58@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add support for videocc driver on Qualcomm Maili SoCJagadeesh Kona3-0/+671
Add support for Qualcomm Maili video clock controller driver for video clients to be able to request for videocc clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260717-maili_videocc-v3-2-6656694b06a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Qualcomm Maili video clock controllerJagadeesh Kona2-0/+52
Add device tree bindings for the video clock controller on Qualcomm Maili SoC. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260717-maili_videocc-v3-1-6656694b06a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Qualcomm Shikra GPU clock controllerImran Shaik1-1/+3
The Qualcomm Shikra GPU clock controller is similar to QCM2290 GPUCC hardware block, with same set of clocks and minor other differences. Hence reuse the QCM2290 header file for Shikra and document the Qualcomm Shikra GPUCC compatible. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-14-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Qualcomm Shikra Display clock controllerImran Shaik1-1/+7
The Qualcomm Shikra Display clock controller has clocks same as QCM2290. Hence, add support to use the QCM2290 DISPCC compatible as fallback for Shikra DISPCC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-13-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disableImran Shaik1-1/+1
The RCG's clk src has to be parked at XO while disabling as per hardware team's recommendation, hence use clk_rcg2_shared_ops to achieve the same. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-11-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probeImran Shaik1-15/+1
Drop modelling of gpu_cc_ahb_clk and keep it always enabled from probe similar to other critical clocks, since marking it as CLK_IS_CRITICAL causes the clock framework to invoke clk_pm_runtime_get() during prepare, which prevents the associated power domains from collapsing. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-10-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Move to the latest common qcom_cc_probe() modelImran Shaik1-30/+20
Update the QCM2290 GPUCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-9-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Drop pm_clk handlingImran Shaik1-11/+0
Drop the pm_clk handling from QCM2290 GPUCC driver as the required GCC AHB clocks are kept always enabled by the GCC driver during probe. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-8-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: qcm2290: Update DISPCC and GPUCC GDSC *wait_val valuesImran Shaik2-0/+9
Update the QCM2290 DISPCC and GPUCC GDSC wait_val fields to match the hardware default values. Incorrect settings can cause the GDSC FSM to stuck, leading to power on/off failures. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-7-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 06:35:45 +0000