aboutsummaryrefslogtreecommitdiffstats
path: root/arch (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-16arm64: probes: Add GCS support to bl/blr/retJeremy Linton1-9/+35
The arm64 probe simulation doesn't currently have logic in place to deal with GCS and this results in core dumps if probes are inserted at control flow locations. Fix-up bl, blr and ret to manipulate the shadow stack as needed. While we manipulate and validate the shadow stack correctly, the hardware provides additional security by only allowing GCS operations against pages which are marked to support GCS. For writing there is gcssttr() which enforces this, but there isn't an equivalent for reading. This means that uprobe users should be aware that probing on control flow instructions which require reading the shadow stack (ex: ret) offers lower security guarantees than what is achieved without the uprobe active. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: uaccess: Add additional userspace GCS accessorsJeremy Linton1-0/+54
Uprobes need more advanced read, push, and pop userspace GCS functionality. Implement those features using the existing gcsstr() and copy_from_user(). Its important to note that GCS pages can be read by normal instructions, but the hardware validates that pages used by GCS specific operations, have a GCS privilege set. We aren't validating this in load_user_gcs because it requires stabilizing the VMA over the read which may fault. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> [will: Add '__force' to gcspr cast in pop_user_gcs()] Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64/fpsimd: simplify sme_setup()Yury Norov (NVIDIA)1-2/+3
The function checks info->vq_map for emptiness right before calling find_last_bit(). We can use the find_last_bit() output and save on bitmap_empty() call, which is O(N). Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: qcs615: Enable TSENS support for QCS615 SoCGaurav Kohli1-1/+205
Add TSENS and thermal devicetree node for QCS615 SoC. Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.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/20250702082311.4123461-3-quic_gkohli@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16KVM: x86: hyper-v: Use guard() instead of mutex_lock() to simplify codeLiao Yuanhong1-7/+5
Use guard(mutex) instead of mutex_lock/mutex_unlock pair to simplify the error handling when setting up the TSC page for a Hyper-V guest. No functional change intended. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250901131604.646415-1-liaoyuanhong@vivo.com [sean: tweak changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: x86: Use guard() instead of mutex_lock() to simplify codeLiao Yuanhong1-10/+7
Use guard(mutex) instead of mutex_lock/mutex_unlock pair to simplify the error handling when allocating the APIC access page. No functional change intended. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250901131822.647802-1-liaoyuanhong@vivo.com [sean: add blank link to isolate guard(), tweak changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: x86/pmu: Correct typo "_COUTNERS" to "_COUNTERS"Dapeng Mi2-7/+7
Fix typos. "_COUTNERS" -> "_COUNTERS". Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Link: https://lore.kernel.org/r/20250718001905.196989-2-dapeng1.mi@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: TDX: Reject fully in-kernel irqchip if EOIs are protected, i.e. for TDX VMsSagi Shahar3-0/+15
Reject KVM_CREATE_IRQCHIP if the VM type has protected EOIs, i.e. if KVM can't intercept EOI and thus can't faithfully emulate level-triggered interrupts that are routed through the I/O APIC. For TDX VMs, the TDX-Module owns the VMX EOI-bitmap and configures all IRQ vectors to have the CPU accelerate EOIs, i.e. doesn't allow KVM to intercept any EOIs. KVM already requires a split irqchip[1], but does so during vCPU creation, which is both too late to allow userspace to fallback to a split irqchip and a less-than-stellar experience for userspace since an -EINVAL on KVM_VCPU_CREATE is far harder to debug/triage than failure exactly on KVM_CREATE_IRQCHIP. And of course, allowing an action that ultimately fails is arguably a bug regardless of the impact on userspace. Link: https://lore.kernel.org/lkml/20250222014757.897978-11-binbin.wu@linux.intel.com [1] Link: https://lore.kernel.org/lkml/aK3vZ5HuKKeFuuM4@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sagi Shahar <sagis@google.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/r/20250827011726.2451115-1-sagis@google.com [sean: massage shortlog+changelog, relocate setting has_protected_eoi] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16arm64/Kconfig: Remove CONFIG_RODATA_FULL_DEFAULT_ENABLEDHuang Shijie2-15/+1
Now that 'rodata=full' has been removed in favour of parity with x86, CONFIG_RODATA_FULL_DEFAULT_ENABLED no longer serves a useful purpose. Remove it. Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Rework the 'rodata=' optionsHuang Shijie1-2/+2
As per admin guide documentation, "rodata=on" should be the default on platforms. Documentation/admin-guide/kernel-parameters.txt describes these options as rodata= [KNL,EARLY] on Mark read-only kernel memory as read-only (default). off Leave read-only kernel memory writable for debugging. full Mark read-only kernel memory and aliases as read-only [arm64] But on arm64 platform, RODATA_FULL_DEFAULT_ENABLED is enabled by default, so "rodata=full" is the default instead. For parity with other architectures, namely x86, rework 'rodata=on' to match the current "full" behaviour and replace 'rodata=full' with a new 'rodata=noalias' option which retains writable aliases in the direct map for memory regions outside of the kernel image. Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Represent physical memory with phys_addr_t and resource_size_tSam Edwards5-36/+42
This is a type-correctness cleanup to MMU/boot code that replaces several instances of void * and u64 with phys_addr_t (to represent addresses) and resource_size_t (to represent sizes) to emphasize that the code in question concerns physical memory specifically. The rationale for this change is to improve clarity and readability in a few modules that handle both types (physical and virtual) of address and differentiation is essential. I have left u64 in cases where the address may be either physical or virtual, where the address is exclusively virtual but used in heavy pointer arithmetic, and in cases I may have overlooked. I do not necessarily consider u64 the ideal type in those situations, but it avoids breaking existing semantics in this cleanup. This patch provably has no effect at runtime: I have verified that .text of vmlinux is identical after this change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Make map_fdt() return mapped pointerSam Edwards1-6/+7
Currently map_fdt() accepts a physical address and relies on the caller to keep using the same value after mapping, since the implementation happens to install an identity mapping. This obscures the fact that the usable pointer is defined by the mapping, not by the input value. Since the mapping determines pointer validity, it is more natural to produce the pointer at mapping time. Change map_fdt() to return a void * pointing to the mapped FDT. This clarifies the data flow, removes the implicit identity assumption, and prepares for making map_fdt() accept a phys_addr_t in a follow-up change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Cast start/end markers to char *, not u64Sam Edwards1-3/+3
There are a few memset() calls in map_kernel.c that cast marker-symbol addresses to u64 in order to perform pointer subtraction (range size computation). Cast them with (char *) instead, aligning with idiomatic C pointer arithmetic. This patch provably has no effect at runtime: I have verified that .text of vmlinux is identical after this change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-enchilada: Add notification LEDAntonio Rische1-0/+28
Add the notification LED for the device. The R/G/B channels are controlled by the PMI8998 LPG. Signed-off-by: Antonio Rische <nt8r@protonmail.com> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904-enchilada-led-v1-1-dcf936ea7795@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: apq8016-sbc: Drop redundant HDMI bridge statusKrzysztof Kozlowski1-2/+0
New device nodes are enabled by default, so status is redundant. No functional impact, verified with dtx_diff. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904084421.82985-4-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: apq8016-sbc: Correct HDMI bridge #sound-dai-cellsKrzysztof Kozlowski1-2/+2
HDMI bridge has only one sound DAI and bindings already expect that (dtbs_check): apq8016-sbc.dtb: bridge@39 (adi,adv7533): #sound-dai-cells: 0 was expected Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904084421.82985-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16riscv: dts: starfive: add Milk-V Mars CM Lite system-on-moduleE Shattow2-0/+26
Milk-V Mars CM Lite is a System-on-Module based on the Milk-V Mars CM without the onboard eMMC storage component populated and configured instead for SD3.0 Card Slot on that interface via 100-pin connector. Link to Milk-V Mars CM Lite schematics: https://github.com/milkv-mars/mars-files/tree/main/Mars-CM_Hardware_Schematices Link to StarFive JH7110 Technical Reference Manual: https://doc-en.rvspace.org/JH7110/TRM/index.html Link to Raspberry Pi CM4IO datasheet: https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Add the devicetree file to make use of StarFive JH7110 common supported features PMIC, EEPROM, UART, I2C, GPIO, PCIe, QSPI Flash, PWM, and Ethernet. Also configure the eMMC interface mmc0 for SD Card use and configure the common SD Card interface mmc1 for onboard SDIO BT+WiFi. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16riscv: dts: starfive: add Milk-V Mars CM system-on-moduleE Shattow2-0/+13
Milk-V Mars CM is a System-on-Module based on the StarFive VisionFive 2 board and Radxa CM3 System-on-Module compatible with the Raspberry Pi CM4IO Classic IO Board. Mars CM SoM features: - StarFive JH7110 System on Chip with RV64GC up to 1.5GHz - AXP15060 Power Management Unit - LPDDR4 2GB / 4GB / 8GB DRAM memory - BL24C04F 4K bits (512 x 8) EEPROM - GigaDevice 25LQ128EWIG QSPI NOR Flash 16M or SoC ROM UART loader for boot (selectable by GPIO) - eMMC5.0 8GB / 16GB / 32GB flash storage onboard - AP6256 via SDIO 2.0 onboard wireless connectivity WiFi 5 + Bluetooth 5.2 (optional, present in models with WiFi feature) - 1x Motorcomm YT8531C Gigabit Ethernet PHY - IMG BXE-4-32 Integrated GPU with 3D Acceleration: - H.264 & H.265 4K@60fps Decoding - H.265 1080p@30fps Encoding - JPEG encoder / decoder Additional features available via 2x 100-pin connectors for CM4IO Board: - 1x HDMI 2.0 - 1x MIPI DSI (4-lanes) - 1x 2CH Audio out (via GPIO) - 1x MIPI CSI (2x2-lanes or 1x4-lanes) - 1x USB 2.0 - 1x PCIe 1-lane Host, Gen 2 (5Gbps) - Up to 28x GPIO, supporting 3.3V - UART x6 - PWM x8 - I2C x7 - SPI - I2S Link to Milk-V Mars CM schematics: https://github.com/milkv-mars/mars-files/tree/main/Mars-CM_Hardware_Schematices Link to StarFive JH7110 Technical Reference Manual: https://doc-en.rvspace.org/JH7110/TRM/index.html Link to Raspberry Pi CM4IO datasheet: https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Add the devicetree file to make use of StarFive JH7110 common supported features PMIC, EEPROM, UART, I2C, GPIO, eMMC, PCIe, QSPI Flash, PWM, and Ethernet. Also configure the common SD Card interface mmc1 for onboard SDIO BT+WiFi. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16riscv: dts: starfive: add common board dtsi for Milk-V Mars CM variantsE Shattow1-0/+159
Add a common board dtsi for use by Milk-V Mars CM and Milk-V Mars CM Lite. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16arm64: uaccess: Move existing GCS accessors definitions to gcs.hJeremy Linton2-41/+36
We are going to add some additional GCS access helpers to gcs.h in order to avoid some forward reference problems with uaccess. In preparation for that, lets move the existing gcssttr() and put_user_gcs() routines into gcs.h where it makes sense to keep all the accessors together. Further, the code which uses them already includes gcs.h and there is an existing CONFIG_ARM64_GCS check we can reuse. The GCSSTTR instruction description comment is corrected during the move. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: probes: Break ret out from bl/blrJeremy Linton3-5/+15
Prepare for GCS by breaking RET out into its own function, where it makes more sense to encapsulate the new behavior independent from the branch instructions. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: lemans: Add PCIe lane equalization preset propertiesZiyue Zhang1-0/+6
Add PCIe lane equalization preset properties with all values set to 5 for 8.0 GT/s and 16.0 GT/s data rates to enhance link stability. Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20250904065225.1762793-4-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64/hwcap: Add hwcap for FEAT_LSFEMark Brown4-0/+5
FEAT_LSFE (Large System Float Extension), providing atomic floating point memory operations, is optional from v9.5. This feature adds no new architectural stare and we have no immediate use for it in the kernel so simply provide a hwcap for it to support discovery by userspace. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: sm8450: enable camera clock controller by defaultVladimir Zapolskiy1-1/+0
Enable camera clock controller on Qualcomm SM8450 boards by default due to a reasonable agreement of having all clock controllers enabled. Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250909235547.787396-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: qcm2290: Add CCI nodeLoic Poulain1-0/+50
Add Camera Control Interface (CCI), supporting two I2C masters. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250911212102.470886-2-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Add IMX577-based camera overlayWenmeng Liu2-0/+101
Enable IMX577 via CCI1 on LeMans EVK Core Kit. The LeMans EVK board does not include a camera sensor by default, this overlay reflects the possibility of attaching an optional camera sensor. For this reason, the camera sensor configuration is placed in lemans-evk-camera.dtso, rather than modifying the base lemans-evk.dts. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <quic_wenmliu@qualcomm.com> Link: https://lore.kernel.org/r/20250912-camss_rb8-v6-3-c9a6c3d67392@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans: Add CCI definitionsWenmeng Liu1-0/+268
Qualcomm SA8775P SoC contains 4 Camera Control Interface controllers. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <quic_wenmliu@qualcomm.com> Link: https://lore.kernel.org/r/20250912-camss_rb8-v6-2-c9a6c3d67392@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16MIPS: PCI: Use pci_enable_resources()Ilpo Järvinen1-36/+2
pci-legacy.c under MIPS has a copy of pci_enable_resources() named as pcibios_enable_resources(). Having own copy of same functionality could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. The check for !r->start && r->end is already covered by the more generic checks done in pci_enable_resources(). Call pci_enable_resources() from MIPS's pcibios_enable_device() and remove pcibios_enable_resources(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://patch.msgid.link/20250829131113.36754-4-ilpo.jarvinen@linux.intel.com
2025-09-16sparc/PCI: Remove pcibios_enable_device() as they do nothing extraIlpo Järvinen3-81/+0
Under arch/sparc/ there are multiple copies of pcibios_enable_device() but none of those seem to do anything extra beyond what pci_enable_resources() is supposed to do. These functions could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. Remove all pcibios_enable_device() from arch/sparc/ so that PCI core can simply call into pci_enable_resources() instead using its __weak version of pcibios_enable_device(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250829131113.36754-3-ilpo.jarvinen@linux.intel.com
2025-09-16m68k/PCI: Use pci_enable_resources() in pcibios_enable_device()Ilpo Järvinen1-28/+11
m68k has a resource enable (check) loop in its pcibios_enable_device() which for some reason differs from pci_enable_resources(). This could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. The check for !r->start && r->end is already covered by the more generic checks done in pci_enable_resources(). The entire pcibios_enable_device() suspiciously looks copy-paste from some other arch as also indicated by the preceding comment. However, it also enables PCI_COMMAND_IO | PCI_COMMAND_MEMORY always for bridges. It is not clear why that is being done as the commit e93a6bbeb5a5 ("m68k: common PCI support definitions and code") introducing this code states "Nothing specific to any PCI implementation in any m68k class CPU hardware yet". Replace the resource enable loop with a call to pci_enable_resources() and adjust the Command Register afterwards as it's unclear if that is necessary or not so keep it for now. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250829131113.36754-2-ilpo.jarvinen@linux.intel.com
2025-09-16arm64: dts: qcom: lemans: Add support for camssVikram Sharma1-0/+185
Add changes to support the camera subsystem on the lemans. Co-developed-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250814101615.1102795-10-quic_vikramsa@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-starqltechn: add slpi supportDzmitry Sankouski1-0/+29
Add support for Qualcomm sensor low power island. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250912-starqltechn_slpi-v2-2-5ca5ddbbe7b4@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-starqltechn: fix slpi reserved memDzmitry Sankouski1-1/+1
When adding adsp reserved mem, slpi reserved memory was shrunk according to vendor kernel log: `Removed memory: created DMA memory pool at 0x0000000096700000, size 15 M` However, kernel failed to load firmware with 15MiB reserved region: `[ 14.885885] qcom_q6v5_pas 5c00000.remoteproc: segment outside memory range` Increase slpi reserved region to 16MiB. Fixes: 58782c229e3e ("arm64: dts: qcom: sdm845-starqltechn: add initial sound support") Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250912-starqltechn_slpi-v2-1-5ca5ddbbe7b4@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: add initial support for Samsung Galaxy S22Eric Gonçalves2-0/+146
Add new device support for the Samsung Galaxy S22 (SM-S901E) phone What works: - SimpleFB - USB Signed-off-by: Eric Gonçalves <ghatto404@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250912202603.7312-2-ghatto404@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: qcs8300: Flatten usb controller nodesKrishna Kurapati3-61/+40
Flatten usb controller nodes and update to using latest bindings and flattened driver approach. Enumeration of ADB has been tested on EVK Platform. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250913182318.3547789-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-hp-x14: Add support for X1P42100 HP Omnibook X14Jens Glathe2-0/+35
These laptops are the same as the already known 14-fe0xxx models, but with a Purwa SoC, SKU number 14-fe1xxx. [1] The supported features are the same as for the original Omnibook X14: - Keyboard (no function keys though) - Display - PWM brightness control - Touchpad - Touchscreen - PCIe ports (pcie4, pcie6a) - USB type-c, type-a - WCN6855 Wifi-6E - WCN6855 Bluetooth - ADSP and CDSP - X1 GPU - GPIO Keys (Lid switch) - Audio definition (works via USB and with internal speakers) [1]: https://www.hp.com/us-en/shop/pdp/hp-omnibook-x-laptop-next-gen-ai-pc-14-fe100-14-a4nd1av-1#techSpecs Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-3-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-hp-x14: Unify HP Omnibook X14 device tree structureJens Glathe2-1540/+1548
Extract common elements into a shared .dtsi file for HP Omnibook X14 to support both Hamoa (x1e*/x1p6*) and Purwa (x1p4*/x1*) variants. Required because the device trees are not compatible. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-2-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16ARM: at91: pm: Remove 2.5V regulatorRyan Wanner1-29/+0
Remove 2.5V regulator since enabling and disabling this regulator is no longer supported. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/a6785a40648b315a07152bca261a42bbf0f356af.1757519351.git.Ryan.Wanner@microchip.com Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-09-16arm64: dts: qcom: ipq5018: add QUP3 I2C nodeVandhiadevan Karunamoorthy1-0/+15
Add node to support I2C bus inside of IPQ5018. Signed-off-by: Vandhiadevan Karunamoorthy <vkarunam@codeaurora.org> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20250915-ipq5018-i2c-v1-1-46bbf27396d6@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-xps13-9345: Enable IRISStephan Gerhold1-0/+5
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/xps13-9345/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-9-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-latitude-7455: Enable IRISStephan Gerhold1-0/+5
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/latitude-7455/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-8-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-inspiron-14-plus-7441: Enable IRISStephan Gerhold1-0/+5
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/inspiron-14-plus-7441/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-7-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Enable IRISStephan Gerhold1-0/+5
IRIS firmware for the Lenovo Yoga Slim 7x is already upstream in linux-firmware at qcom/x1e80100/LENOVO/83ED/qcvss8380.mbn, so enable IRIS for the Slim 7x with the corresponding firmware-name property. Tested-by: Anthony Ruhier <aruhier@mailbox.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-6-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: Enable IRISStephan Gerhold1-0/+5
IRIS firmware for the Lenovo ThinkPad T14s is already upstream in linux-firmware at qcom/x1e80100/LENOVO/21N1/qcvss8380.mbn, so enable IRIS for the T14s with the corresponding firmware-name property. Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-5-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-crd: Enable IRIS video codecStephan Gerhold1-0/+4
IRIS firmware for x1e80100-crd is already upstream in linux-firmware in the default path, so enable IRIS for the CRD to accelerate video decoding. It looks like the X1P CRD might need a different IRIS firmware (possibly even changes in the Linux kernel driver), so keep it local to the X1E CRD for now. Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-4-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-el2: Disable IRIS for nowStephan Gerhold1-0/+5
The reset and IOMMU management for remoteprocs like IRIS is implemented in the hypervisor for older targets such as X1E [1]. When booting Linux/KVM directly in EL2, this functionality is missing and the PAS interface normally used by IRIS to boot the video firmware is not working. The Venus driver supports starting the video firmware without using the PAS interface. The same code also works for X1E when using KVM. However, for the new IRIS dt-bindings it was decided to avoid using the dummy "video-firmware" node in the device tree to describe the IOMMU [2]. Discussion is still ongoing how to describe this properly [3]. To avoid regressions when running using KVM, add a TODO in x1-el2.dtso for now and disable IRIS even when it was enabled by the board. [1]: https://resources.linaro.org/en/resource/sF8jXifdb9V1mUefdbfafa [2]: https://lore.kernel.org/r/20250823155349.22344-2-krzysztof.kozlowski@linaro.org/ [3]: https://lore.kernel.org/r/20250819165447.4149674-12-mukesh.ojha@oss.qualcomm.com/ Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-3-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100: Add IRIS video codecStephan Gerhold1-0/+87
Add the IRIS video codec to accelerate video decoding/encoding. Copied mostly from sm8550.dtsi, only the opp-table is slightly different for X1E. For opp-240000000, we need to vote for a higher OPP on one of the power domains, because the voltage requirements for the PLL and the derived clocks differ (sm8550.dtsi has the same). Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Inspiron 14p Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Tested-by: Anthony Ruhier <aruhier@mailbox.org> # Lenovo Slim 7x Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-2-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sm8550/sm8650: Fix typo in IRIS commentStephan Gerhold2-2/+2
It should be "enable on boards", not "enable in boards". Reported-by: Alexey Klimov <alexey.klimov@linaro.org> Closes: https://lore.kernel.org/r/DCQ8G73ISXHC.3V03MOGB6NDZE@linaro.org/ Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-1-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: msm8916: Add SDCC resetsStephan Gerhold1-0/+2
Add the missing resets for the two SDCC controllers to allow fully resetting previous hardware state from the bootloader. Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-3-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: msm8939: Add missing MDSS resetStephan Gerhold1-0/+2
On most MSM8939 devices, the bootloader already initializes the display to show the boot splash screen. In this situation, MDSS is already configured and left running when starting Linux. To avoid side effects from the bootloader configuration, the MDSS reset can be specified in the device tree to start again with a clean hardware state. The reset for MDSS is currently missing in msm8939.dtsi, which causes errors when the MDSS driver tries to re-initialize the registers: dsi_err_worker: status=6 dsi_err_worker: status=6 dsi_err_worker: status=6 ... It turns out that we have always indirectly worked around this by building the MDSS driver as a module. Before v6.17, the power domain was temporarily turned off until the module was loaded, long enough to clear the register contents. In v6.17, power domains are not turned off during boot until sync_state() happens, so this is no longer working. Even before v6.17 this resulted in broken behavior, but notably only when the MDSS driver was built-in instead of a module. Cc: stable@vger.kernel.org Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-2-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-09 22:51:47 +0000