summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2025-03-14arm64: dts: qcom: sm8350: Reenable crypto & cryptobamLuca Weiss1-4/+2
When num-channels and qcom,num-ees is not provided in devicetree, the driver will try to read these values from the registers during probe but this fails if the interconnect is not on and then crashes the system. So we can provide these properties in devicetree (queried after patching BAM driver to enable the necessary interconnect) so we can probe cryptobam without reading registers and then also use the QCE as expected. Fixes: 4d29db204361 ("arm64: dts: qcom: sm8350: fix BAM DMA crash and reboot") Fixes: f1040a7fe8f0 ("arm64: dts: qcom: sm8350: Add Crypto Engine support") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-1-f560889e65d8@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64/kernel: Always use level 2 or higher for early mappingsArd Biesheuvel1-2/+2
The page table population code in map_range() uses a recursive algorithm to create the early mappings of the kernel, the DTB and the ID mapped text and data pages, and this fails to take into account that the way these page tables may be constructed is not precisely the same at each level. In particular, block mappings are not permitted at each level, and the code as it exists today might inadvertently create such a forbidden block mapping if it were used to map a region of the appropriate size and alignment. This never happens in practice, given the limited size of the assets being mapped by the early boot code. Nonetheless, it would be better if this code would behave correctly in all circumstances. So only permit block mappings at level 2, and page mappings at level 3, for any page size, and use table mappings exclusively at all other levels. This change should have no impact in practice, but it makes the code more robust. Cc: Anshuman Khandual <anshuman.khandual@arm.com> Reported-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Link: https://lore.kernel.org/r/20250311073043.96795-2-ardb+git@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-13arm64: dts: qcom: sm8750-qrd: Enable CDSPKrzysztof Kozlowski1-0/+7
Enable the CDSP on QRD8750 board. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-b4-sm8750-cdsp-v4-3-4925d607cea6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750-mtp: Enable CDSPKrzysztof Kozlowski1-0/+7
Enable the CDSP on MPT8750 board. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-b4-sm8750-cdsp-v4-2-4925d607cea6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add CDSPKrzysztof Kozlowski1-0/+194
Add nodes for the CDSP and its SMP2P. These are compatible with earlier SM8650 with difference in one more interrupt. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-b4-sm8750-cdsp-v4-1-4925d607cea6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750-qrd: Enable ADSPKrzysztof Kozlowski1-0/+7
Enable ADSP on QRD8750 board. Reviewed-by: Melody Olvera <quic_molvera@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-sm8750-audio-v3-4-40fbb3e53f95@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750-mtp: Enable ADSPKrzysztof Kozlowski1-0/+7
Enable ADSP on MTP8750 board. Reviewed-by: Melody Olvera <quic_molvera@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-sm8750-audio-v3-3-40fbb3e53f95@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add LPASS macro codecs and pinctrlKrzysztof Kozlowski1-0/+202
Add LPASS macro codecs and LPASS TLMM pin controller on Qualcomm SM8750 for proper sound support. These are fully compatible with earlier SM8550. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-sm8750-audio-v3-2-40fbb3e53f95@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add IPCC, SMP2P, AOSS and ADSPKrzysztof Kozlowski1-0/+140
Add nodes for IPCC mailbox, SMP2P for ADSP, AOSS and the ADSP remoteproc PAS loader (compatible with SM8550). Reviewed-by: Melody Olvera <quic_molvera@quicinc.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250312-sm8750-audio-v3-1-40fbb3e53f95@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: ipq5424: Enable MMCVaradarajan Narayanan2-0/+9
Enable MMC and relevant pinctrl entries. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Link: https://lore.kernel.org/r/20250304113400.2806670-1-quic_varada@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add ICE nodesGaurav Kashyap1-0/+8
Add the SM8750 nodes for the UFS Inline Crypto Engine (ICE). Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250113-sm8750_crypto_master-v1-6-d8e265729848@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add TRNG nodesGaurav Kashyap1-0/+5
Add the SM8750 nodes for the True Random Number Generator (TRNG). Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> Link: https://lore.kernel.org/r/20250113-sm8750_crypto_master-v1-4-d8e265729848@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: sm8750: Add QCrypto nodesGaurav Kashyap1-0/+30
Add the QCE and Crypto BAM DMA nodes. Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> Link: https://lore.kernel.org/r/20250113-sm8750_crypto_master-v1-2-d8e265729848@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-13arm64: dts: qcom: Use recommended MBN firmware pathKrzysztof Kozlowski5-17/+17
All Qualcomm firmwares uploaded to linux-firmware are in MBN format, instead of split MDT. Firmware for boards here is not yet in linux-firmware, but if it gets accepted it will be MBN, not MDT. Change might affect users of DTS which rely on manually placed firmware files, not coming from linux-firmware package. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250108120530.156928-1-krzysztof.kozlowski@linaro.org [bjorn: Updated subject] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-03-12KVM: arm64: Allow userspace to write ID_AA64MMFR0_EL1.TGRAN*_2Sebastian Ott1-4/+17
Allow userspace to write the safe (NI) value for ID_AA64MMFR0_EL1.TGRAN*_2. Disallow to change these fields for NV since kvm provides a sanitized view for them based on the PAGE_SIZE. Signed-off-by: Sebastian Ott <sebott@redhat.com> Link: https://lore.kernel.org/kvmarm/20250306184013.30008-1-sebott@redhat.com/ Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-12arm64: dts: st: add stm32mp215f-dk board supportAmelie Delaunay2-0/+50
Add STM32MP215F Discovery Kit board support. It embeds a STM32MP235FAN SoC, with 2GB of LPDDR4, 1*USB2 peripheral bus powered typeC, 1*ETH, wifi/BT combo, LCD 18bit connector, CSI camera connector, ... Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-10-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64: dts: st: introduce stm32mp21 SoCs familyAlexandre Torgue5-0/+162
STM32MP21 family is composed of 3 SoCs defined as following: -STM32MP211: common part composed of 1*Cortex-A35, common peripherals like SDMMC, UART, SPI, I2C, parallel display, 1*ETH ... -STM32MP213: STM32MP211 + a second ETH, CAN-FD. -STM32MP215: STM32MP213 + Display and CSI2. A second diversity layer exists for security features/ A35 frequency: -STM32MP21xY, "Y" gives information: -Y = A means A35@1.2GHz + no cryp IP and no secure boot. -Y = C means A35@1.2GHz + cryp IP and secure boot. -Y = D means A35@1.5GHz + no cryp IP and no secure boot. -Y = F means A35@1.5GHz + cryp IP and secure boot. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-8-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64: dts: st: add stm32mp235f-dk board supportAmelie Delaunay2-0/+114
Add STM32MP235F Discovery Kit board support. It embeds a STM32MP235FAK SoC, with 4GB of LPDDR4, 2*USB typeA, 1*USB3 typeC, 1*ETH, wifi/BT combo, DSI HDMI, LVDS connector ... Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-7-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64: dts: st: introduce stm32mp23 SoCs familyAlexandre Torgue5-0/+1340
STM32MP23 family is composed of 3 SoCs defined as following: -STM32MP231: common part composed of 1*Cortex-A35, common peripherals like SDMMC, UART, SPI, I2C, parallel display, 1*ETH ... -STM32MP233: STM32MP231 + 1*Cortex-A35 (dual CPU), a second ETH, CAN-FD. -STM32MP235: STM32MP233 + GPU/AI and video encode/decode, DSI and LDVS display. A second diversity layer exists for security features/ A35 frequency: -STM32MP23xY, "Y" gives information: -Y = A means A35@1.2GHz + no cryp IP and no secure boot. -Y = C means A35@1.2GHz + cryp IP and secure boot. -Y = D means A35@1.5GHz + no cryp IP and no secure boot. -Y = F means A35@1.5GHz + cryp IP and secure boot. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-5-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64: Kconfig: expand STM32 Armv8 SoC with STM32MP21/STM32MP23 SoCs familyAmelie Delaunay1-0/+4
Expand config ARCH_STM32 with two new SoCs families: - STM32MP21 SoCs family, which is composed of STM32MP211, STM32MP213 and STM32MP215 SoCs; - STM32MP23 SoCs family, which is composed of STM32MP231, STM32MP233 and STM32MP235 SoCs. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-3-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64: dts: st: add stm32mp257f-dk board supportAlexandre Torgue2-1/+116
Add STM32MP257F Discovery board support. It embeds a STM32MP257FAL SoC, with 4GB of LPDDR4, 2*USB typeA, 1*USB3 typeC, 1*ETH, wifi/BT combo, DSI HDMI, LVDS connector ... Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250225-b4-stm32mp2_new_dts-v2-2-1a628c1580c7@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-03-12arm64/mm: Drop PXD_TABLE_BITAnshuman Khandual1-5/+0
Drop all PXD_TABLE_BIT macros as they are not used any more. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-9-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/mm: Check pmd_table() in pmd_trans_huge()Ryan Roberts1-12/+12
Check for pmd_table() in pmd_trans_huge() rather then just checking for the PMD_TABLE_BIT. But ensure all present-invalid entries are handled correctly by always setting PTE_VALID before checking with pmd_table(). Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-8-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/mm: Check PUD_TYPE_TABLE in pud_bad()Ryan Roberts1-1/+2
pud_bad() is currently defined in terms of pud_table(). Although for some configs, pud_table() is hard-coded to true i.e. when using 64K base pages or when page table levels are less than 3. pud_bad() is intended to check that the pud is configured correctly. Hence let's open-code the same check that the full version of pud_table() uses into pud_bad(). Then it always performs the check regardless of the config. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-7-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/mm: Check PXD_TYPE_TABLE in [p4d|pgd]_bad()Anshuman Khandual1-2/+6
Check page table entries against PXD_TYPE_TABLE on PXD_TYPE_MASK mask bits in [p4d|pgd]_bad() while determining a table entry instead of just checking only for PXD_TABLE_BIT. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-6-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/mm: Clear PXX_TYPE_MASK and set PXD_TYPE_SECT in [pmd|pud]_mkhuge()Anshuman Khandual1-2/+24
Clear PXX_TYPE_MASK in [pmd|pud]_mkhuge() while creating section mappings instead of just the PXX_TABLE_BIT and also set PXD_TYPE_SECT. Also ensure PTE_VALID does not get modified in these helpers, because present-invalid entries should preserve their state across. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-5-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/mm: Clear PXX_TYPE_MASK in mk_[pmd|pud]_sect_prot()Anshuman Khandual1-2/+2
Clear PXX_TYPE_MASK bits in mk_[pmd|pud]_sect_prot() while creating section mappings instead of just clearing the PXX_TABLE_BIT. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-4-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64/ptdump: Test PMD_TYPE_MASK for block mappingAnshuman Khandual1-2/+2
Test given page table entries against PMD_TYPE_SECT on PMD_TYPE_MASK mask bits for identifying block mappings in stage 1 page tables. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-3-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12KVM: arm64: ptdump: Test PMD_TYPE_MASK for block mappingAnshuman Khandual1-2/+2
Test given page table entries against PMD_TYPE_SECT on PMD_TYPE_MASK mask bits for identifying block mappings in stage 2 page tables. Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.linux.dev Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Link: https://lore.kernel.org/r/20250221044227.1145393-2-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-12arm64: dts: rockchip: Add AP6275P wireless support to ArmSoM Sige7Jianfeng Liu1-0/+16
ArmSoM Sige7 uses the PCI-e AP6275P Wi-Fi 6 module. The pcie@0 node can be used as Bridge1, so the wifi@0 node is used as a device under the bridge 1 similar with Khadas Edge 2. Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Link: https://lore.kernel.org/r/20250311142825.2727171-1-liujianfeng1994@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-03-12arm64: dts: rockchip: Enable HDMI audio outputs for Orange Pi 5 PlusJimmy Hon1-0/+16
HDMI audio is available on the Orange Pi 5 Plus HDMI TX ports. Enable it for both ports. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250227235623.1624-5-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-03-12arm64: dts: rockchip: Enable HDMI1 on Orange Pi 5 PlusJimmy Hon1-0/+38
Enable the second HDMI output port on the Orange Pi 5 Plus Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Reviewed-by: Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20250227235623.1624-4-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-03-12arm64: dts: rockchip: Enable HDMI audio outputs for Orange Pi 5 MaxJimmy Hon1-0/+16
HDMI audio is available on the Orange Pi 5 Max HDMI TX ports. Enable it for both ports. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250227235623.1624-3-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-03-12arm64: dts: rockchip: Enable HDMI0 audio output for Orange Pi 5/5BJimmy Hon1-0/+8
HDMI audio is available on the Orange Pi 5 HDMI0 TX port. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250227235623.1624-2-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-03-11arm64: Enable IMP DEF PMUv3 traps on Apple M*Oliver Upton1-0/+44
Apple M1 and M2 CPUs support IMPDEF traps of the PMUv3 sysregs, allowing a hypervisor to virtualize an architectural PMU for a VM. Flip the appropriate bit in HACR_EL2 on supporting hardware. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305203040.428448-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Provide 1 event counter on IMPDEF hardwareOliver Upton1-0/+7
PMUv3 requires that all programmable event counters are capable of counting any event. The Apple M* PMU is quite a bit different, and events have affinities for particular PMCs. Expose 1 event counter on IMPDEF hardware, allowing the guest to do something useful with its PMU while also upholding the requirements of the architecture. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305203021.428366-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Remap PMUv3 events onto hardwareOliver Upton1-1/+24
Map PMUv3 event IDs onto hardware, if the driver exposes such a helper. This is expected to be quite rare, and only useful for non-PMUv3 hardware. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-12-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Advertise PMUv3 if IMPDEF traps are presentOliver Upton1-1/+11
Advertise a baseline PMUv3 implementation when running on hardware with IMPDEF traps of the PMUv3 sysregs. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-11-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Compute synthetic sysreg ESR for Apple PMUv3 trapsOliver Upton2-0/+23
Apple M* CPUs provide an IMPDEF trap for PMUv3 sysregs, where ESR_EL2.EC is a reserved value (0x3F) and a sysreg-like ISS is reported in AFSR1_EL2. Compute a synthetic ESR for these PMUv3 traps, giving the illusion of something architectural to the rest of KVM. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-10-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Move PMUVer filtering into KVM codeOliver Upton2-29/+9
The supported guest PMU version on a particular platform is ultimately a KVM decision. Move PMUVer filtering into KVM code. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-9-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Use guard() to cleanup usage of arm_pmus_lockOliver Upton1-15/+8
Get rid of some goto label patterns by using guard() to drop the arm_pmus_lock when returning from a function. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-8-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Drop kvm_arm_pmu_available static keyOliver Upton3-12/+8
With the PMUv3 cpucap, kvm_arm_pmu_available is no longer used in the hot path of guest entry/exit. On top of that, guest support for PMUv3 may not correlate with host support for the feature, e.g. on IMPDEF hardware. Throw out the static key and just inspect the list of PMUs to determine if PMUv3 is supported for KVM guests. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-7-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Use a cpucap to determine if system supports FEAT_PMUv3Oliver Upton6-7/+45
KVM is about to learn some new tricks to virtualize PMUv3 on IMPDEF hardware. As part of that, we now need to differentiate host support from guest support for PMUv3. Add a cpucap to determine if an architectural PMUv3 is present to guard host usage of PMUv3 controls. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-6-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11drivers/perf: apple_m1: Support host/guest event filteringOliver Upton1-0/+1
The PMU appears to have a separate register for filtering 'guest' exception levels (i.e. EL1 and !ELIsInHost(EL0)) which has the same layout as PMCR1_EL1. Conveniently, there exists a VHE register alias (PMCR1_EL12) that can be used to configure it. Support guest events by programming the EL12 register with the intended guest kernel/userspace filters. Limit support for guest events to VHE (i.e. kernel running at EL2), as it avoids involving KVM to context switch PMU registers. VHE is the only supported mode on M* parts anyway, so this isn't an actual feature limitation. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Always support SW_INCR PMU eventOliver Upton1-0/+2
Support for SW_INCR is unconditional, as KVM traps accesses to PMSWINC_EL0 and emulates the intended event increment. While it is expected that ~all PMUv3 implementations already advertise this event, non-PMUv3 hardware may not. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-5-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11KVM: arm64: Compute PMCEID from arm_pmu's event bitmapsOliver Upton1-11/+36
The PMUv3 driver populates a couple of bitmaps with the values of PMCEID{0,1}, from which the guest's PMCEID{0,1} can be derived. This is particularly convenient when virtualizing PMUv3 on IMP DEF hardware, as reading the nonexistent PMCEID registers leads to a rather unpleasant UNDEF. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-4-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11arm64/fpsimd: Remove unused declaration fpsimd_kvm_prepare()Yue Haibing1-1/+0
Commit fbc7e61195e2 ("KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state") removed the implementation but leave declaration. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250309070723.1390958-1-yuehaibing@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-11arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9Anshuman Khandual1-0/+25
FEAT_PMUv3p9 registers such as PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 access from EL1 requires appropriate EL2 fine grained trap configuration via FEAT_FGT2 based trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2. Otherwise such register accesses will result in traps into EL2. Add a new helper __init_el2_fgt2() which initializes FEAT_FGT2 based fine grained trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2 (setting the bits nPMICNTR_EL0, nPMICFILTR_EL0 and nPMUACR_EL1) to enable access into PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 registers. Also update booting.rst with SCR_EL3.FGTEn2 requirement for all FEAT_FGT2 based registers to be accessible in EL2. Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robh@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kvmarm@lists.linux.dev Fixes: 0bbff9ed8165 ("perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access control") Fixes: d8226d8cfbaf ("perf: arm_pmuv3: Add support for Armv9.4 PMU instruction counter") Tested-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20250227035119.2025171-1-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-11arm64: realm: Use aliased addresses for device DMA to shared buffersSuzuki K Poulose1-0/+11
When a device performs DMA to a shared buffer using physical addresses, (without Stage1 translation), the device must use the "{I}PA address" with the top bit set in Realm. This is to make sure that a trusted device will be able to write to shared buffers as well as the protected buffers. Thus, a Realm must always program the full address including the "protection" bit, like AMD SME encryption bits. Enable this by providing arm64 specific dma_addr_{encrypted, canonical} helpers for Realms. Please note that the VMM needs to similarly make sure that the SMMU Stage2 in the Non-secure world is setup accordingly to map IPA at the unprotected alias. Cc: Will Deacon <will@kernel.org> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 42be24a4178f ("arm64: Enable memory encrypt for Realms") Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250227144150.1667735-4-suzuki.poulose@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-03-11Fix mmu notifiers for range-based invalidatesPiotr Jaroszynski1-10/+12
Update the __flush_tlb_range_op macro not to modify its parameters as these are unexepcted semantics. In practice, this fixes the call to mmu_notifier_arch_invalidate_secondary_tlbs() in __flush_tlb_range_nosync() to use the correct range instead of an empty range with start=end. The empty range was (un)lucky as it results in taking the invalidate-all path that doesn't cause correctness issues, but can certainly result in suboptimal perf. This has been broken since commit 6bbd42e2df8f ("mmu_notifiers: call invalidate_range() when invalidating TLBs") when the call to the notifiers was added to __flush_tlb_range(). It predates the addition of the __flush_tlb_range_op() macro from commit 360839027a6e ("arm64: tlb: Refactor the core flush algorithm of __flush_tlb_range") that made the bug hard to spot. Fixes: 6bbd42e2df8f ("mmu_notifiers: call invalidate_range() when invalidating TLBs") Signed-off-by: Piotr Jaroszynski <pjaroszynski@nvidia.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Raghavendra Rao Ananta <rananta@google.com> Cc: SeongJae Park <sj@kernel.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Nicolin Chen <nicolinc@nvidia.com> Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux.dev Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/r/20250304085127.2238030-1-pjaroszynski@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-16 19:37:53 +0300