summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-07-30KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP codeFuad Tabba2-25/+15
The vcpu_{read,write}_sys_reg() accessors abstract where a system register lives, but their VHE implementation cannot be linked into the nVHE hypervisor, so exception.c open-codes has_vhe() wrappers instead. Redirect the accessors to the raw context accessors for nVHE hyp builds, where registers are always in memory, and drop the local wrappers. This lets hyp code reuse helpers built on the canonical accessors. No functional change intended. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260729131823.2021516-3-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-30KVM: arm64: Extract MPIDR computation into a shared headerFuad Tabba2-13/+20
Extract the vCPU MPIDR computation embedded in reset_mpidr() into a kvm_calculate_mpidr() inline in sys_regs.h, so it can be computed without duplicating the logic. A follow-up series reuses it to reset protected vCPUs at EL2. No functional change intended. Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260729131823.2021516-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHAREDAneesh Kumar K.V (Arm)4-8/+4
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: 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: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checksAneesh Kumar K.V (Arm)1-14/+16
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-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-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-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 Tan3-6/+33
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 Tan4-2/+76
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-30arm64: dts: qcom: eliza: Add fallback compatible for ADSP remoteprocAbel Vesa1-1/+1
The ADSP found on Eliza SoC is actually fully compatible with the ones from SM8750 class. So add the SM8550 compatible as fallback, just like the rest from the SM8750 class SoCs. Fixes: 88ddafb01ec0 ("arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-2-e1e98ae15533@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30x86/virt: use higher-level allocator APIBrendan Jackman1-1/+1
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-10-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Assisted-by: Gemini:unknown-version Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30KVM: VMX: use higher-level allocator APIBrendan Jackman1-1/+1
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-9-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Assisted-by: Gemini:unknown-version Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30perf/x86/intel: use higher-level allocator APIBrendan Jackman1-3/+3
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-8-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: James Clark <james.clark@linaro.org> Assisted-by: Gemini:unknown-version Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: rename ARCH_ENABLE_THP_MIGRATION to ARCH_HAS_PMD_SOFTLEAVESUsama Arif11-15/+15
CONFIG_ARCH_ENABLE_THP_MIGRATION gates PMD-level migration entries. PMD-level device-private entries use the same migration mechanism and therefore require the same architecture support. Upcoming PMD-level swap entries can use the same PMD softleaf helpers without depending on page migration, so rename the architecture gate to CONFIG_ARCH_HAS_PMD_SOFTLEAVES. This describes the PMD entry capability rather than one current user of it. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged. No functional change intended. Link: https://lore.kernel.org/20260706114320.1643046-7-usama.arif@linux.dev Signed-off-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Chris Li <chrisl@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Nico Pache <npache@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Fix the PCIe ↵Manivannan Sadhasivam1-25/+25
iommu-map entries The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 4559b435f741 ("arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add TC9563 PCIe switch node for PCIe0") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-22-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: qcs6490-rb3gen2: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-9/+9
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 267643b3e3a4 ("arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-21-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: qcs6490-thundercomm-minipc-g1iot: Fix the PCIe iommu-map ↵Manivannan Sadhasivam1-9/+9
entries The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 1cde54c54b83 ("arm64: dts: qcom: qcs6490: Add Thundercomm AI Mini PC G1 IoT") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-20-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-9/+9
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: ef254b12ec60 ("arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-19-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: lemans-evk-ifp-mezzanine: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-9/+9
The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: b64abb26a291 ("arm64: dts: qcom: lemans-evk: Add IFP Mezzanine") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-18-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: monaco-evk-ifp-mezzanine: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-9/+9
The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5a67924d2fc5 ("arm64: dts: qcom: monaco-evk: Add IFP Mezzanine") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-17-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: monaco-monza-som: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-8/+8
The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5238f4e7169f ("arm64: dts: qcom: Add Monaco Monza SoM") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-16-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: monaco: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-15-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: lemans: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider pcie_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-14-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: talos: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 718cc7542a00 ("arm64: dts: qcom: qcs615: enable pcie") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-13-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8750: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 19f1395333f8 ("arm64: dts: qcom: sm8750: Add PCIe PHY and controller node") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-12-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-11-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-10-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 7b09b1b47335 ("arm64: dts: qcom: sm8450: add PCIe0 RC device") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-9-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 6daee40678a0 ("arm64: dts: qcom: sm8350: add PCIe devices") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-8-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-6/+6
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-7-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-6-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-32/+32
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 5c538e09cb19 ("arm64: dts: qcom: sdm845: Add first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-5-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-8/+8
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-4-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sar2130p: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: be9115bfe5bf ("arm64: dts: qcom: sar2130p: add support for SAR2130P") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-3-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: kodiak: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-4/+4
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: f8328b7549e1 ("arm64: dts: qcom: sc7280: Describe the first PCIe controller and PHY") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-2-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: kaanapali: Fix the PCIe iommu-map entriesManivannan Sadhasivam1-2/+2
The IOMMU provider apps_smmu uses '#iommu-cells = <2>', but the PCIe iommu-map entries specify only one cell for the SID, omitting the SID mask. This went unnoticed until the OF core started warning with commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps"): iommu-map has 1-cell entries targeting 2-cell #iommu-cells, treating as 1-cell output So fix the entries to match the provider's '#iommu-cells' property. Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-iommu-map-fix-v1-1-83405d37ba41@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8250-xiaomi-elish: correct the board IDDawid Wróbel1-1/+1
elish declares the same qcom,msm-id and qcom,board-id pair as sm8250-sony-xperia-edo.dtsi, so a bootloader choosing between appended device trees cannot tell the two boards apart. 0x10008 is Sony's value. The downstream device tree for this board, elish-sm8250-overlay.dts, uses qcom,board-id = <47 0>, i.e. platform type 0x2f. Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Dawid Wróbel <me@dawidwrobel.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-elish-board-id-v1-1-92f99e9722ec@dawidwrobel.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: talos: Fix cpu6 1094.4MHz OPP frequency typoImran Shaik1-1/+1
opp-1094400000 in cpu6_opp_table has a typo in opp-hz, missing a trailing zero. Fix it to resolve the following OPP update failures: cpu cpu6: Voltage update failed freq=1094400 cpu cpu6: failed to update OPP for freq=1094400 Fixes: 44562f591890 ("arm64: dts: qcom: qcs615: Add OSM l3 interconnect provider node and CPU OPP tables to scale DDR/L3") Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-talos-cpu6-opp-fix-v1-1-f4886fdff13f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: glymur: Fix PDC IRQ mappingKonrad Dybcio1-3/+7
Some of the sub-ranges are inconsistent with HW docs. Fix them. They are valid for both Glymur and Mahua. Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260729-topic-glymur_pdc-v1-1-8747789e35aa@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: eliza-cqs-som: Add eUSB2 repeater suppliesKonrad Dybcio1-0/+5
Hardware works better when it's powered. Wire up the associated regulators. Fixes: 85a1eb421dfa ("arm64: dts: qcom: eliza: Add Eliza CQS SoM platform") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730-topic-eliza_som_eusb2-v1-1-288bcda1fee2@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-5-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-4-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-3-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodesNeil Armstrong1-0/+277
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS on the system. The thermal nodes are sorted by the sensor channel to be coherent with the system thermal nodes ordering. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-2-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: pmk8550: add VADC nodeNeil Armstrong1-0/+30
Add the VADC node and the initial pmk8550 adc channels. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260721-topic-sm8x50-adc5-gen3-v6-1-a507f4a1e537@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: hamoa-pmics: Add ADC supportAyyagari Ushasreevalli7-0/+164
Add ADC node and define channels for: - Die temperature for PMK8550, PM8550VE* and PMC8380* PMICs. - PM8550: Die temperature, VPH power, and system thermistors. Add io-channels and io-channel-names properties to the temp_alarm nodes so that they can get temperature reading from the ADC die_temp channels. Remove die_temp channel of PMC8380_6 for Purwa boards where this PMIC is not present. Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-4-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: monaco-pmics: Add ADC support for PMM8620AUAyyagari Ushasreevalli1-0/+43
Add ADC nodes for PMM8620AU PMIC instances (SID 0 and SID 2) present on the Monaco platform. Each ADC node exposes the following ADC channels: - DIE_TEMP: PMIC die temperature channel - VPH_PWR: Battery/supply voltage channel Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com> Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260728-adc5_gen3_dt-v4-3-355f0edece77@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-22 11:37:17 +0000