summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-04-02crypto: x86/aesni - Rearrange AES key size checkChang S. Bae
aes_expandkey() already includes an AES key size check. If AES-NI is unusable, invoke the function without the size check. Also, use aes_check_keylen() instead of open code. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: linux-crypto@vger.kernel.org Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-04-02crypto: remove CONFIG_CRYPTO_STATSEric Biggers
Remove support for the "Crypto usage statistics" feature (CONFIG_CRYPTO_STATS). This feature does not appear to have ever been used, and it is harmful because it significantly reduces performance and is a large maintenance burden. Covering each of these points in detail: 1. Feature is not being used Since these generic crypto statistics are only readable using netlink, it's fairly straightforward to look for programs that use them. I'm unable to find any evidence that any such programs exist. For example, Debian Code Search returns no hits except the kernel header and kernel code itself and translations of the kernel header: https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1 The patch series that added this feature in 2018 (https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/) said "The goal is to have an ifconfig for crypto device." This doesn't appear to have happened. It's not clear that there is real demand for crypto statistics. Just because the kernel provides other types of statistics such as I/O and networking statistics and some people find those useful does not mean that crypto statistics are useful too. Further evidence that programs are not using CONFIG_CRYPTO_STATS is that it was able to be disabled in RHEL and Fedora as a bug fix (https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947). Even further evidence comes from the fact that there are and have been bugs in how the stats work, but they were never reported. For example, before Linux v6.7 hash stats were double-counted in most cases. There has also never been any documentation for this feature, so it might be hard to use even if someone wanted to. 2. CONFIG_CRYPTO_STATS significantly reduces performance Enabling CONFIG_CRYPTO_STATS significantly reduces the performance of the crypto API, even if no program ever retrieves the statistics. This primarily affects systems with a large number of CPUs. For example, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reported that Lustre client encryption performance improved from 21.7GB/s to 48.2GB/s by disabling CONFIG_CRYPTO_STATS. It can be argued that this means that CONFIG_CRYPTO_STATS should be optimized with per-cpu counters similar to many of the networking counters. But no one has done this in 5+ years. This is consistent with the fact that the feature appears to be unused, so there seems to be little interest in improving it as opposed to just disabling it. It can be argued that because CONFIG_CRYPTO_STATS is off by default, performance doesn't matter. But Linux distros tend to error on the side of enabling options. The option is enabled in Ubuntu and Arch Linux, and until recently was enabled in RHEL and Fedora (see above). So, even just having the option available is harmful to users. 3. CONFIG_CRYPTO_STATS is a large maintenance burden There are over 1000 lines of code associated with CONFIG_CRYPTO_STATS, spread among 32 files. It significantly complicates much of the implementation of the crypto API. After the initial submission, many fixes and refactorings have consumed effort of multiple people to keep this feature "working". We should be spending this effort elsewhere. Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-04-01ARC: Fix typosBjorn Helgaas
Fix typos, most reported by "codespell arch/arc". Only touches comments, no code changes. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2024-04-01ARC: mm: fix new code about cache aliasingVineet Gupta
Manual/partial revert of 8690bbcf3b70 ("Introduce cpu_dcache_is_aliasing() across all architectures") Current generation of ARCv2/ARCv3 based HSxx cores are only PIPT (to software at least). Legacy ARC700 cpus could be VIPT aliasing (based on cache geometry and PAGE_SIZE) [1] however recently that support was ripped out so VIPT aliasing cache is not relevant to ARC anymore. [1] http://lists.infradead.org/pipermail/linux-snps-arc/2023-February/006899.html Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2024-04-01ARC: Fix -Wmissing-prototypes warningsVineet Gupta
| ../arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 'arc_kprobe_handler' [-Wmissing-prototypes] | 193 | int __kprobes arc_kprobe_handler(unsigned long addr, struct pt_regs *regs) | |../arch/arc/kernel/ptrace.c:342:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes] | 342 | asmlinkage int syscall_trace_enter(struct pt_regs *regs) Link: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240325/testrun/23149630/suite/build/test/gcc-9-defconfig/log Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2024-04-01arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK 4C+Folker Schwesinger
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line causing I/O errors in HS400 mode for various eMMC modules. Enable the internal strobe pull-down for the ROCK 4C+ board. Also re-enable HS400 mode, that was replaced with HS200 mode as a workaround for the stability issues in: 2bd1d2dd808c ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+"). Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts") Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240327192641.14220-3-dev@folker-schwesinger.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4Folker Schwesinger
Commit 8b5c2b45b8f0 disabled the internal pull-down for the strobe line causing I/O errors in HS400 mode for various eMMC modules. Enable the internal strobe pull-down for ROCK Pi 4 boards. Also re-enable HS400 mode, that was replaced with HS200 mode as a workaround for the stability issues in: cee572756aa2 ("arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4"). This was tested on ROCK 4SE and ROCK Pi 4B+. Fixes: 8b5c2b45b8f0 ("phy: rockchip: set pulldown for strobe line in dts") Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240327192641.14220-2-dev@folker-schwesinger.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01arm64: dts: rockchip: Enable gpu on Cool Pi 4BAndy Yan
Enable mali gpu node and add the board specific supply-regulator. Signed-off-by: Andy Yan <andyshrk@163.com> Link: https://lore.kernel.org/r/20240330100134.3588223-2-andyshrk@163.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01arm64: dts: rockchip: Enable gpu on Cool Pi CM5Andy Yan
Enable mali gpu node and add the board specific supply-regulator. Signed-off-by: Andy Yan <andyshrk@163.com> Link: https://lore.kernel.org/r/20240330100134.3588223-1-andyshrk@163.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01arm64: dts: rockchip: drop panel port unit address in GRU ScarletKrzysztof Kozlowski
Panel port does not have "reg", thus it should not have unit address, as reported by dtc W=1 warning: rk3399-gru-scarlet.dtsi:666.32-668.7: Warning (unit_address_vs_reg): /dsi@ff960000/panel@0/ports/port@1/endpoint@1: node has a unit name, but no reg or ranges property Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240401140939.97808-1-krzk@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dtsDragan Simic
Remove a redundant node from the Pine64 Pinebook Pro dts, which is intended to provide a value for the delay in PCI Express enumeration, but that isn't supported without additional out-of-tree kernel patches. There were already efforts to upstream those kernel patches, because they reportedly make some PCI Express cards (such as LSI SAS HBAs) usable in Pine64 RockPro64 (which is also based on the RK3399); otherwise, those PCI Express cards fail to enumerate. However, providing the required background and explanations proved to be a tough nut to crack, which is the reason why those patches remain outside of the kernel mainline for now. If those out-of-tree patches eventually become upstreamed, the resulting device-tree changes will almost surely belong to the RK3399 SoC dtsi. Also, the above-mentioned unusable-without-out-of-tree-patches PCI Express devices are in all fairness not usable in a Pinebook Pro without some extensive hardware modifications, which is another reason to delete this redundant node. When it comes to the Pinebook Pro, only M.2 NVMe SSDs can be installed out of the box (using an additional passive adapter PCB sold separately by Pine64), which reportedly works fine with no additional patches. Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/0f82c3f97cb798d012270d13b34d8d15305ef293.1711923520.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-04-01Merge 6.9-rc2 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-01KVM: arm64: Rationalise KVM banner outputMarc Zyngier
We are not very consistent when it comes to displaying which mode we're in (VHE, {n,h}VHE, protected or not). For example, booting in protected mode with hVHE results in: [ 0.969545] kvm [1]: Protected nVHE mode initialized successfully which is mildly amusing considering that the machine is VHE only. We already cleaned this up a bit with commit 1f3ca7023fe6 ("KVM: arm64: print Hyp mode"), but that's still unsatisfactory. Unify the three strings into one and use a mess of conditional statements to sort it out (yes, it's a slow day). Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240321173706.3280796-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01arm64: Fix early handling of FEAT_E2H0 not being implementedMarc Zyngier
Commit 3944382fa6f2 introduced checks for the FEAT_E2H0 not being implemented. However, the check is absolutely wrong and makes a point it testing a bit that is guaranteed to be zero. On top of that, the detection happens way too late, after the init_el2_state has done its job. This went undetected because the HW this was tested on has E2H being RAO/WI, and not RES1. However, the bug shows up when run as a nested guest, where HCR_EL2.E2H is not necessarily set to 1. As a result, booting the kernel in hVHE mode fails with timer accesses being cought in a trap loop (which was fun to debug). Fix the check for ID_AA64MMFR4_EL1.E2H0, and set the HCR_EL2.E2H bit early so that it can be checked by the rest of the init sequence. With this, hVHE works again in a NV environment that doesn't have FEAT_E2H0. Fixes: 3944382fa6f2 ("arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative") Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20240321115414.3169115-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01KVM: arm64: Ensure target address is granule-aligned for range TLBIWill Deacon
When zapping a table entry in stage2_try_break_pte(), we issue range TLB invalidation for the region that was mapped by the table. However, we neglect to align the base address down to the granule size and so if we ended up reaching the table entry via a misaligned address then we will accidentally skip invalidation for some prefix of the affected address range. Align 'ctx->addr' down to the granule size when performing TLB invalidation for an unmapped table in stage2_try_break_pte(). Cc: Raghavendra Rao Ananta <rananta@google.com> Cc: Gavin Shan <gshan@redhat.com> Cc: Shaoqin Huang <shahuang@redhat.com> Cc: Quentin Perret <qperret@google.com> Fixes: defc8cc7abf0 ("KVM: arm64: Invalidate the table entries upon a range") Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240327124853.11206-5-will@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01KVM: arm64: Use TLBI_TTL_UNKNOWN in __kvm_tlb_flush_vmid_range()Will Deacon
Commit c910f2b65518 ("arm64/mm: Update tlb invalidation routines for FEAT_LPA2") updated the __tlbi_level() macro to take the target level as an argument, with TLBI_TTL_UNKNOWN (rather than 0) indicating that the caller cannot provide level information. Unfortunately, the two implementations of __kvm_tlb_flush_vmid_range() were not updated and so now ask for an level 0 invalidation if FEAT_LPA2 is implemented. Fix the problem by passing TLBI_TTL_UNKNOWN instead of 0 as the level argument to __flush_s2_tlb_range_op() in __kvm_tlb_flush_vmid_range(). Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Marc Zyngier <maz@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Fixes: c910f2b65518 ("arm64/mm: Update tlb invalidation routines for FEAT_LPA2") Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240327124853.11206-4-will@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01KVM: arm64: Don't pass a TLBI level hint when zapping table entriesWill Deacon
The TLBI level hints are for leaf entries only, so take care not to pass them incorrectly after clearing a table entry. Cc: Gavin Shan <gshan@redhat.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Quentin Perret <qperret@google.com> Fixes: 82bb02445de5 ("KVM: arm64: Implement kvm_pgtable_hyp_unmap() at EL2") Fixes: 6d9d2115c480 ("KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table") Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240327124853.11206-3-will@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01KVM: arm64: Don't defer TLB invalidation when zapping table entriesWill Deacon
Commit 7657ea920c54 ("KVM: arm64: Use TLBI range-based instructions for unmap") introduced deferred TLB invalidation for the stage-2 page-table so that range-based invalidation can be used for the accumulated addresses. This works fine if the structure of the page-tables remains unchanged, but if entire tables are zapped and subsequently freed then we transiently leave the hardware page-table walker with a reference to freed memory thanks to the translation walk caches. For example, stage2_unmap_walker() will free page-table pages: if (childp) mm_ops->put_page(childp); and issue the TLB invalidation later in kvm_pgtable_stage2_unmap(): if (stage2_unmap_defer_tlb_flush(pgt)) /* Perform the deferred TLB invalidations */ kvm_tlb_flush_vmid_range(pgt->mmu, addr, size); For now, take the conservative approach and invalidate the TLB eagerly when we clear a table entry. Note, however, that the existing level hint passed to __kvm_tlb_flush_vmid_ipa() is incorrect and will be fixed in a subsequent patch. Cc: Raghavendra Rao Ananta <rananta@google.com> Cc: Shaoqin Huang <shahuang@redhat.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Shaoqin Huang <shahuang@redhat.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240327124853.11206-2-will@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-04-01arm64: dts: imx8mp-venice-gw74xx: add ADC rail for VDD_1P0Tim Harvey
The imx8mp-venice-gw74xx revB PCB added an ADC rail for VDD_1P0. Add it to the GSC ADC rails. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-31Merge tag 'kbuild-fixes-v6.9' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Deduplicate Kconfig entries for CONFIG_CXL_PMU - Fix unselectable choice entry in MIPS Kconfig, and forbid this structure - Remove unused include/asm-generic/export.h - Fix a NULL pointer dereference bug in modpost - Enable -Woverride-init warning consistently with W=1 - Drop KCSAN flags from *.mod.c files * tag 'kbuild-fixes-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: Fix typo HEIGTH to HEIGHT Documentation/llvm: Note s390 LLVM=1 support with LLVM 18.1.0 and newer kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries kbuild: make -Woverride-init warnings more consistent modpost: do not make find_tosym() return NULL export.h: remove include/asm-generic/export.h kconfig: do not reparent the menu inside a choice block MIPS: move unselectable FIT_IMAGE_FDT_EPM5 out of the "System type" choice cxl: remove CONFIG_CXL_PMU entry in drivers/cxl/Kconfig
2024-03-31Merge tag 'perf_urgent_for_v6.9_rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 perf fixes from Borislav Petkov: - Define the correct set of default hw events on AMD Zen4 - Use the correct stalled cycles PMCs on AMD Zen2 and newer - Fix detection of the LBR freeze feature on AMD * tag 'perf_urgent_for_v6.9_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/amd/core: Define a proper ref-cycles event for Zen 4 and later perf/x86/amd/core: Update and fix stalled-cycles-* events for Zen 2 and later perf/x86/amd/lbr: Use freeze based on availability x86/cpufeatures: Add new word for scattered features
2024-03-31Merge tag 'x86_urgent_for_v6.9_rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Make sure single object builds in arch/x86/virt/ ala make ... arch/x86/virt/vmx/tdx/seamcall.o work again - Do not do ROM range scans and memory validation when the kernel is running as a SEV-SNP guest as those can get problematic and, before that, are not really needed in such a guest - Exclude the build-time generated vdso-image-x32.o object from objtool validation and in particular the return sites in there due to a warning which fires when an unpatched return thunk is being used - Improve the NMI CPUs stall message to show additional information about the state of each CPU wrt the NMI handler - Enable gcc named address spaces support only on !KCSAN configs due to compiler options incompatibility - Revert a change which was trying to use GB pages for mapping regions only when the regions would be large enough but that change lead to kexec failing - A documentation fixlet * tag 'x86_urgent_for_v6.9_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/build: Use obj-y to descend into arch/x86/virt/ x86/sev: Skip ROM range scans and validation for SEV-SNP guests x86/vdso: Fix rethunk patching for vdso-image-x32.o too x86/nmi: Upgrade NMI backtrace stall checks & messages x86/percpu: Disable named address spaces for KCSAN Revert "x86/mm/ident_map: Use gbpages only where full GB page should be mapped." Documentation/x86: Fix title underline length
2024-03-30arm64: dts: fsl-lx2162a-clearfog: add alias for i2c bus iic6Josua Mayer
SoM dts has enabled i2c bus IIC6 (dts i2c5), but defines no aliases. LX2162A Clearfog dts has aliases for all i2c buses to ensure predictable numbering for userspace. Add an additional alias for this extra bus. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-30arm64: dts: fsl-lx2162a-som: add description for rtcJosua Mayer
SolidRun LX2162A SoM has an RTC on bus IIC6 (dts i2c5). Enable this bus and add description for the rtc. Signed-off-by: Josua Mayer <josua@solid-run.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-30arm64: dts: imx8mp-venice-gw74xx-imx219.dtso: fix dt warningTim Harvey
Fix the following warning from a 'make dtbs W=1': arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx-imx219.dtso:65.10-70.5: Warning (unit_address_vs_reg): /fragment@3/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-30x86/build: Use obj-y to descend into arch/x86/virt/Masahiro Yamada
Commit c33621b4c5ad ("x86/virt/tdx: Wire up basic SEAMCALL functions") introduced a new instance of core-y instead of the standardized obj-y syntax. X86 Makefiles descend into subdirectories of arch/x86/virt inconsistently; into arch/x86/virt/ via core-y defined in arch/x86/Makefile, but into arch/x86/virt/svm/ via obj-y defined in arch/x86/Kbuild. This is problematic when you build a single object in parallel because multiple threads attempt to build the same file. $ make -j$(nproc) arch/x86/virt/vmx/tdx/seamcall.o [ snip ] AS arch/x86/virt/vmx/tdx/seamcall.o AS arch/x86/virt/vmx/tdx/seamcall.o fixdep: error opening file: arch/x86/virt/vmx/tdx/.seamcall.o.d: No such file or directory make[4]: *** [scripts/Makefile.build:362: arch/x86/virt/vmx/tdx/seamcall.o] Error 2 Use the obj-y syntax, as it works correctly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240330060554.18524-1-masahiroy@kernel.org
2024-03-29arm64: dts: qcom: pm6150: correct Type-C compatibleKrzysztof Kozlowski
The first part of the compatible of Type-C node misses ending quote, thus we have one long compatible consisting of two compatible strings leading to dtbs_check warnings: sc7180-idp.dtb: usb-vbus-regulator@1100: compatible:0: 'qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$' sc7180-idp.dtb: /soc@0/spmi@c440000/pmic@0/usb-vbus-regulator@1100: failed to match any schema with compatible: ['qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg'] Reported-by: Rob Herring <robh@kernel.org> Fixes: f81c2f01cad6 ("arm64: dts: qcom: pm6150: define USB-C related blocks") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240328074544.5076-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-03-29x86/bugs: Fix the SRSO mitigation on Zen3/4Borislav Petkov (AMD)
The original version of the mitigation would patch in the calls to the untraining routines directly. That is, the alternative() in UNTRAIN_RET will patch in the CALL to srso_alias_untrain_ret() directly. However, even if commit e7c25c441e9e ("x86/cpu: Cleanup the untrain mess") meant well in trying to clean up the situation, due to micro- architectural reasons, the untraining routine srso_alias_untrain_ret() must be the target of a CALL instruction and not of a JMP instruction as it is done now. Reshuffle the alternative macros to accomplish that. Fixes: e7c25c441e9e ("x86/cpu: Cleanup the untrain mess") Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-03-29Merge tag 'efi-fixes-for-v6.9-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "These address all the outstanding EFI/x86 boot related regressions: - Revert to the old initrd memory allocation soft limit of INT_MAX, which was dropped inadvertently - Ensure that startup_32() is entered with a valid boot_params pointer when using the new EFI mixed mode protocol - Fix a compiler warning introduced by a fix from the previous pull" * tag 'efi-fixes-for-v6.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: x86/efistub: Reinstate soft limit for initrd loading efi/libstub: Cast away type warning in use of max() x86/efistub: Add missing boot_params for mixed mode compat entry
2024-03-29arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as brokenJohan Hovold
Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property. The Bluetooth bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some boot firmware has been providing the address in big-endian order instead. The boot firmware in SC7180 Trogdor Chromebooks is known to be affected so mark the 'local-bd-address' property as broken to maintain backwards compatibility with older firmware when fixing the underlying driver bug. Note that ChromeOS always updates the kernel and devicetree in lockstep so that there is no need to handle backwards compatibility with older devicetrees. Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Cc: stable@vger.kernel.org # 5.10 Cc: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2024-03-29x86/vm86: Make sure the free_vm86(task) definition uses its parameter even ↵Ingo Molnar
in the !CONFIG_VM86 case I ran into a case in new code where free_vm86(task) was the only consumer of the 'task' variable: arch/x86/kernel/process.c: In function ‘exit_thread’: arch/x86/kernel/process.c:118:31: error: unused variable ‘t’ [-Werror=unused-variable] Robustify the definition in the !CONFIG_VM86 case. Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/ZgaFfyHMOdLHEKm+@gmail.com
2024-03-29arm64: dts: mba8mx: Simplify DSI connectionAlexander Stein
With the DSI output label in place, use the phandle directly. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp: Add empty DSI output endpointAlexander Stein
Also add a corresponding label so overlays can reference that node. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mq: Add empty DSI output endpointAlexander Stein
Also add a corresponding label so overlays can reference that node. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mn: Add empty DSI output endpointAlexander Stein
Also add a corresponding label so overlays can reference that node. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mm: Add empty DSI output endpointAlexander Stein
Also add a corresponding label so overlays can reference that node. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29ARM: dts: imx6ull: add seeed studio NPi dev boardParthiban Nallathambi
Add support for Seed Stuidos NPi i.MX6ULL SoM equipped with 512MB RAM and 8GB eMMC or 512MB NAND flash. Development board comes with either eMMC or NAND based SoM with peripheral interfaces like 2 x ethernet, 2 x USB, LCD, CSI and more. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29x86/boot: Move kernel cmdline setup earlier in the boot process (again)Julian Stecklina
When split_lock_detect=off (or similar) is specified in CONFIG_CMDLINE, its effect is lost. The flow is currently this: setup_arch(): -> early_cpu_init() -> early_identify_cpu() -> sld_setup() -> sld_state_setup() -> Looks for split_lock_detect in boot_command_line -> e820__memory_setup() -> Assemble final command line: boot_command_line = builtin_cmdline + boot_cmdline -> parse_early_param() There were earlier attempts at fixing this in: 8d48bf8206f7 ("x86/boot: Pull up cmdline preparation and early param parsing") later reverted in: fbe618399854 ("Revert "x86/boot: Pull up cmdline preparation and early param parsing"") ... because parse_early_param() can't be called before e820__memory_setup(). In this patch, we just move the command line concatenation to the beginning of early_cpu_init(). This should fix sld_state_setup(), while not running in the same issues as the earlier attempt. The order is now: setup_arch(): -> Assemble final command line: boot_command_line = builtin_cmdline + boot_cmdline -> early_cpu_init() -> early_identify_cpu() -> sld_setup() -> sld_state_setup() -> Looks for split_lock_detect in boot_command_line -> e820__memory_setup() -> parse_early_param() Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: linux-kernel@vger.kernel.org
2024-03-29arm64: dts: freescale: imx8mp-venice-gw73xx-2x: fix USB vbus regulatorTim Harvey
When using usb-conn-gpio to control USB role and VBUS, the vbus-supply property must be present in the usb-conn-gpio node. Additionally it should not be present in the phy node as that isn't what controls vbus and will upset the use count. This resolves an issue where VBUS is enabled with OTG in peripheral mode. Fixes: ad9a12f7a522 ("arm64: dts: imx8mp-venice: Fix USB connector description") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: freescale: imx8mp-venice-gw72xx-2x: fix USB vbus regulatorTim Harvey
When using usb-conn-gpio to control USB role and VBUS, the vbus-supply property must be present in the usb-conn-gpio node. Additionally it should not be present in the phy node as that isn't what controls vbus and will upset the use count. This resolves an issue where VBUS is enabled with OTG in peripheral mode. Fixes: ad9a12f7a522 ("arm64: dts: imx8mp-venice: Fix USB connector description") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp-evk: Add PDM micphone sound card supportShengjiu Wang
Add PDM micphone sound card support, configure the pinmux. This sound card supports recording sound from PDM micphone and convert the PDM format data to PCM data. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp-evk: Add HDMI audio sound card supportShengjiu Wang
AUD2HTX works as the cpu dai in HDMI audio sound card. This sound card only support playback/output. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp: Add AUD2HTX device nodeShengjiu Wang
The AUD2HTX is a digital module that provides a bridge between the Audio Subsystem and the HDMI RTX Subsystem. This module includes intermediate storage to queue SDMA transactions prior to being synchronized and passed to the HDMI RTX Subsystem over the Audio Link. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as moduleAdam Ford
The i.MX8M Plus has support for an HDMI transmitter. The video is genereated by lcdif3, routed to the hdmi parallel video interface, then fed to a DW HDMI bridge to support up to 4K video output. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp: add HDMI display pipelineLucas Stach
This adds the DT nodes for all the peripherals that make up the HDMI display pipeline. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Adam Ford <aford173@gmail.com> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp: add HDMI irqsteerLucas Stach
The HDMI irqsteer is a secondary interrupt controller within the HDMI subsystem that maps all HDMI peripheral IRQs into a single upstream IRQ line. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Adam Ford <aford173@gmail.com> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8mp: add HDMI power-domainsLucas Stach
This adds the PGC and HDMI blk-ctrl nodes providing power control for HDMI subsystem peripherals. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8qm-mek: add flexspi0 supportFrank Li
Add flexspi0 support for imx8qm-mek board. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8qm-mek: add lpspi2 supportFrank Li
Add lpspi2 support for imx8qm-mek board. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-03-29arm64: dts: imx8qm-mek: add adc0 supportFrank Li
Add adc0 for imx8qm-mek board. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>