summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2022-12-08Merge patch series "riscv: Fix crash during early errata patching"Palmer Dabbelt
These are fixes, but due to the possible early boot fallout they're going in the merge window to get a bit more time to bake on linux-next. * b4-shazam-merge riscv: Move cast inside kernel_mapping_[pv]a_to_[vp]a riscv: Fix crash during early errata patching Link: https://lore.kernel.org/r/20221126060920.65009-1-samuel@sholland.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08riscv: Move cast inside kernel_mapping_[pv]a_to_[vp]aSamuel Holland
Before commit 44c922572952 ("RISC-V: enable XIP"), these macros cast their argument to unsigned long. That commit moved the cast after an assignment to an unsigned long variable, rendering it ineffectual. Move the cast back, so we can remove the cast at each call site. Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221126060920.65009-2-samuel@sholland.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08riscv: Fix crash during early errata patchingSamuel Holland
The patch function for the T-Head PBMT errata calls __pa_symbol() before relocation. This crashes when CONFIG_DEBUG_VIRTUAL is enabled, because __pa_symbol() forwards to __phys_addr_symbol(), and __phys_addr_symbol() checks against the absolute kernel start/end address. Fix this by checking against the kernel map instead of a symbol address. Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221126060920.65009-1-samuel@sholland.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08riscv: boot: add zstd supportJisheng Zhang
Support build the zstd compressed Image.zst. Similar as other compressed formats, the Image.zst is not self-decompressing and the bootloader still needs to handle decompression before launching the kernel image. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20221123150257.3108-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08Merge patch series "RISC-V interrupt controller select cleanup"Palmer Dabbelt
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> Submitted a patch yesterday defaulting the SiFive PLIC driver to enabled [0], and in the ensuing conversation Marc suggested just doing a select at the arch level and dropping the user selectability completely. * b4-shazam-merge: RISC-V: stop selecting SIFIVE_PLIC at the SoC level irqchip/riscv-intc: remove user selectability of RISCV_INTC irqchip/sifive-plic: remove user selectability of SIFIVE_PLIC Link: https://lore.kernel.org/r/20221118104300.85016-1-conor@kernel.org Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/all/87zgceszp8.wl-maz@kernel.org/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08RISC-V: stop selecting SIFIVE_PLIC at the SoC levelConor Dooley
The SIFIVE_PLIC driver is used by all current RISC-V SoCs & will be, where possible, used for future implementations. Rather than having each driver select the option on a case-by-case basis, do so at the arch level. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221118104300.85016-4-conor@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08Merge patch series "Add PMEM support for RISC-V"Palmer Dabbelt
Anup Patel <apatel@ventanamicro.com> says: The Linux NVDIMM PEM drivers require arch support to map and access the persistent memory device. This series adds RISC-V PMEM support using recently added Svpbmt and Zicbom support. * b4-shazam-merge: RISC-V: Enable PMEM drivers RISC-V: Implement arch specific PMEM APIs RISC-V: Fix MEMREMAP_WB for systems with Svpbmt Link: https://lore.kernel.org/r/20221114090536.1662624-1-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08RISC-V: Enable PMEM driversAnup Patel
We now have PMEM arch support available in RISC-V kernel so let us enable relevant drivers in defconfig. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221114090536.1662624-4-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08RISC-V: Implement arch specific PMEM APIsAnup Patel
The NVDIMM PMEM driver expects arch specific APIs for cache maintenance and if arch does not provide these APIs then NVDIMM PMEM driver will always use MEMREMAP_WT to map persistent memory which in-turn maps as UC memory type defined by the RISC-V Svpbmt specification. Now that the Svpbmt and Zicbom support is available in RISC-V kernel, we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM PMEM driver can use MEMREMAP_WB to map persistent memory. Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221114090536.1662624-3-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08RISC-V: Fix MEMREMAP_WB for systems with SvpbmtAnup Patel
Currently, the memremap() called with MEMREMAP_WB maps memory using the generic ioremap() function which breaks on system with Svpbmt because memory mapped using _PAGE_IOREMAP page attributes is treated as strongly-ordered non-cacheable IO memory. To address this, we implement RISC-V specific arch_memremap_wb() which maps memory using _PAGE_KERNEL page attributes resulting in write-back cacheable mapping on systems with Svpbmt. Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221114090536.1662624-2-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08Merge patch "RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path"Palmer Dabbelt
I'm merging this in as a single patch to make it easier to handle the backports. * b4-shazam-merge: RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08RISC-V: Fix unannoted hardirqs-on in return to userspace slow-pathAndrew Bresticker
The return to userspace path in entry.S may enable interrupts without the corresponding lockdep annotation, producing a splat[0] when DEBUG_LOCKDEP is enabled. Simply calling __trace_hardirqs_on() here gets a bit messy due to the use of RA to point back to ret_from_exception, so just move the whole slow-path loop into C. It's more readable and it lets us use local_irq_{enable,disable}(), avoiding the need for manual annotations altogether. [0]: ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()) WARNING: CPU: 2 PID: 1 at kernel/locking/lockdep.c:5512 check_flags+0x10a/0x1e0 Modules linked in: CPU: 2 PID: 1 Comm: init Not tainted 6.1.0-rc4-00160-gb56b6e2b4f31 #53 Hardware name: riscv-virtio,qemu (DT) epc : check_flags+0x10a/0x1e0 ra : check_flags+0x10a/0x1e0 <snip> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff808edb90>] lock_is_held_type+0x78/0x14e [<ffffffff8003dae2>] __might_resched+0x26/0x22c [<ffffffff8003dd24>] __might_sleep+0x3c/0x66 [<ffffffff80022c60>] get_signal+0x9e/0xa70 [<ffffffff800054a2>] do_notify_resume+0x6e/0x422 [<ffffffff80003c68>] ret_from_exception+0x0/0x10 irq event stamp: 44512 hardirqs last enabled at (44511): [<ffffffff808f901c>] _raw_spin_unlock_irqrestore+0x54/0x62 hardirqs last disabled at (44512): [<ffffffff80008200>] __trace_hardirqs_off+0xc/0x14 softirqs last enabled at (44472): [<ffffffff808f9fbe>] __do_softirq+0x3de/0x51e softirqs last disabled at (44467): [<ffffffff80017760>] irq_exit+0xd6/0x104 ---[ end trace 0000000000000000 ]--- possible reason: unannotated irqs-on. Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> Fixes: 3c4697982982 ("riscv: Enable LOCKDEP_SUPPORT & fixup TRACE_IRQFLAGS_SUPPORT") Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08riscv: mm: notify remote harts about mmu cache updatesSergey Matyukevich
Current implementation of update_mmu_cache function performs local TLB flush. It does not take into account ASID information. Besides, it does not take into account other harts currently running the same mm context or possible migration of the running context to other harts. Meanwhile TLB flush is not performed for every context switch if ASID support is enabled. Patch [1] proposed to add ASID support to update_mmu_cache to avoid flushing local TLB entirely. This patch takes into account other harts currently running the same mm context as well as possible migration of this context to other harts. For this purpose the approach from flush_icache_mm is reused. Remote harts currently running the same mm context are informed via SBI calls that they need to flush their local TLBs. All the other harts are marked as needing a deferred TLB flush when this mm context runs on them. [1] https://lore.kernel.org/linux-riscv/20220821013926.8968-1-tjytimi@163.com/ Signed-off-by: Sergey Matyukevich <sergey.matyukevich@syntacore.com> Fixes: 65d4b9c53017 ("RISC-V: Implement ASID allocator") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/#t Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-08Merge tag 'soc-fixes-6.1-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fix from Arnd Bergmann: "One last build fix came in, addressing a link failure when building without CONFIG_OUTER_CACHE" * tag 'soc-fixes-6.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: at91: fix build for SAMA5D3 w/o L2 cache
2022-12-08Merge tag 'loongarch-fixes-6.1-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Export smp_send_reschedule() for modules use, fix a huge page entry update issue, and add documents for booting description" * tag 'loongarch-fixes-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: docs/zh_CN: Add LoongArch booting description's translation docs/LoongArch: Add booting description LoongArch: mm: Fix huge page entry update for virtual machine LoongArch: Export symbol for function smp_send_reschedule()
2022-12-08arm64: efi: Recover from synchronous exceptions occurring in firmwareArd Biesheuvel
Unlike x86, which has machinery to deal with page faults that occur during the execution of EFI runtime services, arm64 has nothing like that, and a synchronous exception raised by firmware code brings down the whole system. With more EFI based systems appearing that were not built to run Linux (such as the Windows-on-ARM laptops based on Qualcomm SOCs), as well as the introduction of PRM (platform specific firmware routines that are callable just like EFI runtime services), we are more likely to run into issues of this sort, and it is much more likely that we can identify and work around such issues if they don't bring down the system entirely. Since we already use a EFI runtime services call wrapper in assembler, we can quite easily add some code that captures the execution state at the point where the call is made, allowing us to revert to this state and proceed execution if the call triggered a synchronous exception. Given that the kernel and the firmware don't share any data structures that could end up in an indeterminate state, we can happily continue running, as long as we mark the EFI runtime services as unavailable from that point on. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-12-08Revert "ARM: dts: imx7: Fix NAND controller size-cells"Francesco Dolcini
This reverts commit 753395ea1e45c724150070b5785900b6a44bd5fb. It introduced a boot regression on colibri-imx7, and potentially any other i.MX7 boards with MTD partition list generated into the fdt by U-Boot. While the commit we are reverting here is not obviously wrong, it fixes only a dt binding checker warning that is non-functional, while it introduces a boot regression and there is no obvious fix ready. Fixes: 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Marek Vasut <marex@denx.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/ Link: https://lore.kernel.org/all/20221205144917.6514168a@xps-13/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-08Merge tag 'asahi-soc-dt-6.2-v3' of https://github.com/AsahiLinux/linux into ↵Arnd Bergmann
soc/dt Apple SoC DT updates for 6.2 (v3). One final update for 6.2. This includes: * L1/L2 cache topology for t8103 * A bunch of typo, style, and minor functional fixes * tag 'asahi-soc-dt-6.2-v3' of https://github.com/AsahiLinux/linux: arm64: dts: apple: t6002: Fix GPU power domains arm64: dts: apple: t600x-pmgr: Fix search & replace typo arm64: dts: apple: Add t8103 L1/L2 cache properties and nodes arm64: dts: apple: Rename dart-sio* to sio-dart* arch: arm64: apple: t600x: Use standard "iommu" node name arch: arm64: apple: t8103: Use standard "iommu" node name Link: https://lore.kernel.org/r/488ad4e9-04dc-1774-3bbe-d313ef30f14d@marcan.st Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-08MIPS: OCTEON: cvmx-bootmem: use strscpy() to instead of strncpy()Xu Panda
The implementation of strscpy() is more robust and safer. Signed-off-by: Xu Panda <xu.panda@zte.com.cn> Signed-off-by: Yang Yang <yang.yang29@zte.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-12-08MIPS: mscc: jaguar2: Fix pca9545 i2c-mux node namesGeert Uytterhoeven
"make dtbs_check": arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: $nodename:0: 'pca9545@70' does not match '^(i2c-?)?mux' From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3' were unexpected) From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml ... Fix this by renaming PCA9545 nodes to "i2c-mux", to match the I2C bus multiplexer/switch DT bindings and the Generic Names Recommendation in the Devicetree Specification. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-12-08arm64: efi: Execute runtime services from a dedicated stackArd Biesheuvel
With the introduction of PRMT in the ACPI subsystem, the EFI rts workqueue is no longer the only caller of efi_call_virt_pointer() in the kernel. This means the EFI runtime services lock is no longer sufficient to manage concurrent calls into firmware, but also that firmware calls may occur that are not marshalled via the workqueue mechanism, but originate directly from the caller context. For added robustness, and to ensure that the runtime services have 8 KiB of stack space available as per the EFI spec, introduce a spinlock protected EFI runtime stack of 8 KiB, where the spinlock also ensures serialization between the EFI rts workqueue (which itself serializes EFI runtime calls) and other callers of efi_call_virt_pointer(). While at it, use the stack pivot to avoid reloading the shadow call stack pointer from the ordinary stack, as doing so could produce a gadget to defeat it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-12-08LoongArch: mm: Fix huge page entry update for virtual machineHuacai Chen
In virtual machine (guest mode), the tlbwr instruction can not write the last entry of MTLB, so we need to make it non-present by invtlb and then write it by tlbfill. This also simplify the whole logic. Signed-off-by: Rui Wang <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-12-08LoongArch: Export symbol for function smp_send_reschedule()Bibo Mao
Function smp_send_reschedule() is standard kernel API, which is defined in header file include/linux/smp.h. However, on LoongArch it is defined as an inline function, this is confusing and kernel modules can not use this function. Now we define smp_send_reschedule() as a general function, and add a EXPORT_SYMBOL_GPL on this function, so that kernel modules can use it. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-12-08arm64: dts: apple: t6002: Fix GPU power domainsAsahi Lina
On t6002 (M1 Ultra), each die contains a self-contained GPU block. However, only the coprocessor and global management circuitry of the first die are used. This is what is represented by the "gpu" PS (the one in die1 is disabled). Nonetheless, this shared component drives the processing blocks in both dies, and therefore depends on the AFR fabric being powered up on both dies. Add an explicit dependency from the GPU block on die0 to AFR on die1, next to the existing die0 AFR dependency. Fixes: fa86294eb355 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-08arm64: dts: apple: t600x-pmgr: Fix search & replace typoAsahi Lina
It looks like the search-and-replace that happened to add die IDs to the t600x PMGR tree was a little bit too eager on a comment, and nobody noticed! Let's fix that. Fixes: fa86294eb355 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07Merge tag 'qcom-dts-for-6.2-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt More Qualcomm DTS updates for 6.2 This introduces support for the OnePlus One, on MSM8974Pro, and properly marks other Pro devices as compatible thereof. Also on MSM8974, the description of USB devices and their PHYs are cleaned up. On the binding side compatibles for recently added ARM and ARM64 boards are added. * tag 'qcom-dts-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (102 commits) dt-bindings: arm: qcom: Add zombie ARM: dts: qcom: msm8974: Add OnePlus One dt-bindings: arm: qcom: Document oneplus,bacon device ARM: dts: qcom: msm8974: clean up USB nodes arm: dts: qcom: use qcom,msm8974pro for pro devices dt-bindings: arm: qcom: split MSM8974 Pro and MSM8974 ARM: dts: qcom: align LED node names with dtschema dt-bindings: arm: qcom: Document additional sa8540p device dt-bindings: arm: qcom: Add Xperia 5 IV (PDX224) dt-bindings: arm: qcom: Document msm8956 and msm8976 SoC and devices dt-bindings: arm: add xiaomi,sagit board based on msm8998 chip dt-bindings: arm: qcom: add sdm670 and pixel 3a compatible dt-bindings: arm: cpus: add qcom kryo 360 compatible ARM: dts: qcom-msm8960-cdp: align TLMM pin configuration with DT schema ARM: dts: qcom-msm8960: use define for interrupt constants dt-bindings: arm: qcom: Document SM6375 & Xperia 10 IV ARM: dts: qcom-apq8060: align TLMM pin configuration with DT schema ARM: dts: qcom: msm8226: Add MMCC node dt-bindings: arm: qcom: Separate LTE/WIFI SKU for sc7280-evoker dt-bindings: arm: qcom: Document QDU1000/QRU1000 SoCs and boards ... Link: https://lore.kernel.org/r/20221207153201.3233015-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'qcom-arm64-for-6.2-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt More Qualcomm ARM64 DT updates for 6.2 This introduce description of MSM8956 and MSM8976 and based on this adds Sony Xperia X and X Compact. It adds the SA8540P QDrive 3 automotive development board and enables PCIe on the same. Add description of the Vision Mezzanine for the RB5 board and the Navigation Mezzanine for the SDM845 RB3. SC8280XP adds L3 and DDR scaling support, resulting in good performance improvement. PCIe and UFS is marked DMA coherent, resolving data corruption issues. Reference clocks for UFS phy and device are corrected, to resolve issues seen in combinations with some bootloaders where it's not sufficient to rely on the bootloader state. RTC description is added to the SA8295P ADP board. For SM6115 GPI, PRNG, tsens, WCN, cpufreq, I2C/SPI and display blocks are added. On SM6375 QUP blocks are described, allowing the addition of touchscreen and remoteprocs for ADSP and CDSP are introduced. Sony Xperia 10 IV adds description of regulators, allowing enabling SD-card support. SM8250 Coresight components are described It introduces support for the Xiaomi Mi 6 on MSM8998 and adds flash LED to the Xiaomi Redmi 2. The SDHCI block on SM8350 is described and enabled on Sony Xperia 5 III. SM8450 sound and Soundwire blocks are described, and enabled on HDK. CPU supply clock is described, to satisfy the DT binding and the opp-framework. Sony Xperia 5 IV support is added, with touchscreen added. Lastly a range of changes to align DT source with their bindings. * tag 'qcom-arm64-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (98 commits) dt-bindings: iio: adc: qcom,spmi-vadc: fix PM8350 define dt-bindings: iio: adc: qcom,spmi-vadc: extend example arm64: dts: qcom: sc8280xp: fix UFS DMA coherency arm64: dts: qcom: sc7280: Add DT for sc7280-herobrine-zombie arm64: dts: qcom: sm8250-sony-xperia-edo: fix no-mmc property for SDHCI arm64: dts: qcom: sdm845-sony-xperia-tama: fix no-mmc property for SDHCI arm64: dts: qcom: sda660-inforce-ifc6560: fix no-mmc property for SDHCI arm64: dts: qcom: sa8155p-adp: fix no-mmc property for SDHCI arm64: dts: qcom: qrb5165-rb: fix no-mmc property for SDHCI arm64: dts: qcom: sm8450: align MMC node names with dtschema arm64: dts: qcom: sc7180-trogdor: use generic node names arm64: dts: qcom: sm8450-hdk: add sound support arm64: dts: qcom: sm8450: add Soundwire and LPASS arm64: dts: qcom: sm8450: add GPR node arm64: dts: qcom: sa8540p-ride: enable PCIe support arm64: dts: qcom: sm6115: Add smmu fallback to qcom generic compatible arm64: dts: qcom: sm6115: Add WCN node arm64: dts: qcom: sm6115: Add i2c/spi nodes arm64: dts: qcom: sm6115: Add GPI DMA arm64: dts: qcom: sm6115: Add mdss/dpu node ... Link: https://lore.kernel.org/r/20221207152554.3232434-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'socfpga_dts_updates_for_v6.2_part2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into soc/dt SoCFPGA dts updates for v6.2, part 2 - Fix dtschema for LED node - Fix dtschema for i2c-mux * tag 'socfpga_dts_updates_for_v6.2_part2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: dts: socfpga: Fix pca9548 i2c-mux node name ARM: dts: socfpga: align LED node names with dtschema arm64: dts: altera: align LED node names with dtschema Link: https://lore.kernel.org/r/20221206214006.590562-1-dinguyen@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07arm64: efi: Limit allocations to 48-bit addressable physical regionArd Biesheuvel
The UEFI spec does not mention or reason about the configured size of the virtual address space at all, but it does mention that all memory should be identity mapped using a page size of 4 KiB. This means that a LPA2 capable system that has any system memory outside of the 48-bit addressable physical range and follows the spec to the letter may serve page allocation requests from regions of memory that the kernel cannot access unless it was built with LPA2 support and enables it at runtime. So let's ensure that all page allocations are limited to the 48-bit range. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-12-07Merge tag 'v6.1-rc8' into efi/nextArd Biesheuvel
Linux 6.1-rc8
2022-12-07Merge tag 'irqchip-6.2' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates frim Marc Zyngier: - More APCI fixes and improvements for the LoongArch architecture, adding support for the HTVEC irqchip, suspend-resume, and some PCI INTx workarounds - Initial DT support for LoongArch. I'm not even kidding. - Support for the MTK CIRQv2, a minor deviation from the original version - Error handling fixes for wpcm450, GIC... - BE detection for a FSL controller - Declare the Sifive PLIC as wake-up agnostic - Simplify fishing out the device data for the ST irqchip - Mark some data structures as __initconst in the apple-aic driver - Switch over from strtobool to kstrtobool - COMPILE_TEST fixes
2022-12-07ARM: 9279/1: support function error injectionWang Kefeng
This enables HAVE_FUNCTION_ERROR_INJECTION by adding necessary regs_set_return_value() and override_function_with_return(). Simply tested according to Documentation/fault-injection/fault-injection.rst. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-12-07ARM: 9278/1: kfence: only handle translation faultsWang Kefeng
This is a similar fixup like arm64 does, only handle translation faults in case of unexpected kfence report when alignment faults on ARM, see more from commit 0bb1fbffc631 ("arm64: mm: kfence: only handle translation faults"). Fixes: 75969686ec0d ("ARM: 9166/1: Support KFENCE for ARM") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-12-07arm64: dts: apple: Add t8103 L1/L2 cache properties and nodesJanne Grunau
The t8103 CPU nodes are missing the cache hierarchy information. The cache hierarchy on Arm can not be detected and needs to be described in DT. The OS scheduler can make use of this information for scheduling decisions. The cache size information is based on various articles about the processors. There's also an L3 system level cache (SLC). It's not described here because SLCs typically have some MMIO interface which would need to be described. Based on Rob Herring's patch adding cache properties and nodes for t600x. Link: https://lore.kernel.org/asahi/20221122220619.659174-1-robh@kernel.org/ Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arm64: dts: apple: Rename dart-sio* to sio-dart*Hector Martin
All the other DARTs are named foo-dart, so let's keep things consistent. Fixes: 51979fbb7fb8 ("arm64: dts: apple: t600x: Add MCA and its support") Fixes: 8a3df85ad87d ("arm64: dts: apple: t8103: Add MCA and its support") Reviewed-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arch: arm64: apple: t600x: Use standard "iommu" node nameJanne Grunau
The PCIe iommu nodes use "dart" as node names. Replace it with the the standard "iommu" node name as all other iommu nodes. Fixes: 7b0b0191a2c7 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arch: arm64: apple: t8103: Use standard "iommu" node nameJanne Grunau
The PCIe iommu nodes use "dart" as node names. Replace it with the the standard "iommu" node name as all other iommu nodes. Fixes: 3c866bb79577 ("arm64: dts: apple: t8103: Add PCIe DARTs") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-06xtensa: add __umulsidi3 helperMax Filippov
xtensa gcc-13 has changed multiplication handling and may now use __umulsidi3 helper where it used to use __muldi3. As a result building the kernel with the new gcc may fail with the following error: linux/init/main.c:1287: undefined reference to `__umulsidi3' Fix the build by providing __umulsidi3 implementation for xtensa. Cc: stable@vger.kernel.org # 5.18+ Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2022-12-06ARM: dts: socfpga: Fix pca9548 i2c-mux node nameGeert Uytterhoeven
"make dtbs_check": arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70: $nodename:0: 'i2cswitch@70' does not match '^(i2c-?)?mux' From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4', 'i2c@5', 'i2c@6', 'i2c@7' were unexpected) From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml Fix this by renaming the PCA9548 node to "i2c-mux", to match the I2C bus multiplexer/switch DT bindings and the Generic Names Recommendation in the Devicetree Specification. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2022-12-06riscv, bpf: Emit fixed-length instructions for BPF_PSEUDO_FUNCPu Lehui
For BPF_PSEUDO_FUNC instruction, verifier will refill imm with correct addresses of bpf_calls and then run last pass of JIT. Since the emit_imm of RV64 is variable-length, which will emit appropriate length instructions accorroding to the imm, it may broke ctx->offset, and lead to unpredictable problem, such as inaccurate jump. So let's fix it with fixed-length instructions. Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Suggested-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20221206091410.1584784-1-pulehui@huaweicloud.com
2022-12-06Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Revert the dropping of the cache invalidation from the arm64 arch_dma_prep_coherent() as it caused a regression in the qcom_q6v5_mss remoteproc driver. The driver is already buggy but the original arm64 change made the problem obvious. The change will be re-introduced once the driver is fixed" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
2022-12-06Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Unless anything comes from the ARM side, this should be the last pull request for this release - and it's mostly documentation: - Document the interaction between KVM_CAP_HALT_POLL and halt_poll_ns - s390: fix multi-epoch extension in nested guests - x86: fix uninitialized variable on nested triple fault" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: Document the interaction between KVM_CAP_HALT_POLL and halt_poll_ns KVM: Move halt-polling documentation into common directory KVM: x86: fix uninitialized variable use on KVM_REQ_TRIPLE_FAULT KVM: s390: vsie: Fix the initialization of the epoch extension (epdx) field
2022-12-06Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"Will Deacon
This reverts commit c44094eee32f32f175aadc0efcac449d99b1bbf7. Although the semantics of the DMA API require only a clean operation here, it turns out that the Qualcomm 'qcom_q6v5_mss' remoteproc driver (ab)uses the DMA API for transferring the modem firmware to the secure world via calls to Trustzone [1]. Once the firmware buffer has changed hands, _any_ access from the non-secure side (i.e. Linux) will be detected on the bus and result in a full system reset [2]. Although this is possible even with this revert in place (due to speculative reads via the cacheable linear alias of memory), anecdotally the problem occurs considerably more frequently when the lines have not been invalidated, assumedly due to some micro-architectural interactions with the cache hierarchy. Revert the offending change for now, along with a comment, so that the Qualcomm developers have time to fix the driver [3] to use a firmware buffer which does not have a cacheable alias in the linear map. Link: https://lore.kernel.org/r/20221114110329.68413-1-manivannan.sadhasivam@linaro.org [1] Link: https://lore.kernel.org/r/CAMi1Hd3H2k1J8hJ6e-Miy5+nVDNzv6qQ3nN-9929B0GbHJkXEg@mail.gmail.com/ [2] Link: https://lore.kernel.org/r/20221206092152.GD15486@thinkpad [2] Reported-by: Amit Pundir <amit.pundir@linaro.org> Reported-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Will Deacon <will@kernel.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20221206103403.646-1-will@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-12-06arm64: dts: qcom: sc8280xp: fix UFS DMA coherencyJohan Hovold
The SC8280XP UFS controllers are cache coherent and must be marked as such in the devicetree to avoid potential data corruption. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221205100837.29212-3-johan+linaro@kernel.org
2022-12-06arm64: dts: qcom: sc7280: Add DT for sc7280-herobrine-zombieOwen Yang
Add DT for sc7280-herobrine-zombie Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Owen Yang <ecs.taipeikernel@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221205133603.v15.2.I80aa32497bfd67bc8a372c1418ccc443ccf193e4@changeid
2022-12-06arm64: dts: qcom: sm8250-sony-xperia-edo: fix no-mmc property for SDHCIKrzysztof Kozlowski
There is no "no-emmc" property, so intention for SD/SDIO only nodes was to use "no-mmc": qcom/sm8250-sony-xperia-edo-pdx206.dtb: mmc@8804000: Unevaluated properties are not allowed ('no-emmc' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204094438.73288-6-krzysztof.kozlowski@linaro.org
2022-12-06arm64: dts: qcom: sdm845-sony-xperia-tama: fix no-mmc property for SDHCIKrzysztof Kozlowski
There is no "no-emmc" property, so intention for SD/SDIO only nodes was to use "no-mmc": qcom/sdm845-sony-xperia-tama-akatsuki.dtb: mmc@8804000: Unevaluated properties are not allowed ('no-emmc' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204094438.73288-5-krzysztof.kozlowski@linaro.org
2022-12-06arm64: dts: qcom: sda660-inforce-ifc6560: fix no-mmc property for SDHCIKrzysztof Kozlowski
There is no "no-emmc" property, so intention for SD/SDIO only nodes was to use "no-mmc": qcom/sda660-inforce-ifc6560.dtb: mmc@c084000: Unevaluated properties are not allowed ('no-emmc' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204094438.73288-4-krzysztof.kozlowski@linaro.org
2022-12-06arm64: dts: qcom: sa8155p-adp: fix no-mmc property for SDHCIKrzysztof Kozlowski
There is no "no-emmc" property, so intention for SD/SDIO only nodes was to use "no-mmc": qcom/sa8155p-adp.dtb: mmc@8804000: Unevaluated properties are not allowed ('no-emmc' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204094438.73288-3-krzysztof.kozlowski@linaro.org
2022-12-06arm64: dts: qcom: qrb5165-rb: fix no-mmc property for SDHCIKrzysztof Kozlowski
There is no "no-emmc" property, so intention for SD/SDIO only nodes was to use "no-mmc": qcom/qrb5165-rb5.dtb: mmc@8804000: Unevaluated properties are not allowed ('no-emmc' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204094438.73288-2-krzysztof.kozlowski@linaro.org
generated by cgit (git 2.34.1) at 2025-09-13 20:10:40 +0000