summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2021-05-26arm64: dts: qcom: sdm845-oneplus-common: enable ipaCaleb Connolly1-0/+6
Enable the ipa node so that we can bring up mobile data. Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210502014146.85642-5-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-05-26arm64: dts: qcom: sdm845-oneplus-common: guard rmtfs-memCaleb Connolly1-0/+12
The rmtfs_mem region is a weird one, downstream allocates it dynamically, and supports a "qcom,guard-memory" property which when set will reserve 4k above and below the rmtfs memory. A common from qcom 4.9 kernel msm_sharedmem driver: /* * If guard_memory is set, then the shared memory region * will be guarded by SZ_4K at the start and at the end. * This is needed to overcome the XPU limitation on few * MSM HW, so as to make this memory not contiguous with * other allocations that may possibly happen from other * clients in the system. */ When the kernel tries to touch memory that is too close the rmtfs region it may cause an XPU violation. Such is the case on the OnePlus 6 where random crashes would occur usually after boot. Reserve 4k above and below the rmtfs_mem to avoid hitting these XPU Violations. This doesn't entirely solve the random crashes on the OnePlus 6/6T but it does seem to prevent the ones which happen shortly after modem bringup. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210502014146.85642-4-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-05-26arm64: dts: qcom: sc7180: add nodes for idp displayHarigovindan P1-0/+65
Add nodes for IDP display. The display is Visionox RM69299. Signed-off-by: Harigovindan P <harigovi@codeaurora.org> Link: https://lore.kernel.org/r/20200629135144.8265-1-harigovi@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-05-25arm64: Rename arm64-internal cache maintenance functionsFuad Tabba25-98/+98
Although naming across the codebase isn't that consistent, it tends to follow certain patterns. Moreover, the term "flush" isn't defined in the Arm Architecture reference manual, and might be interpreted to mean clean, invalidate, or both for a cache. Rename arm64-internal functions to make the naming internally consistent, as well as making it consistent with the Arm ARM, by specifying whether it applies to the instruction, data, or both caches, whether the operation is a clean, invalidate, or both. Also specify which point the operation applies to, i.e., to the point of unification (PoU), coherency (PoC), or persistence (PoP). This commit applies the following sed transformation to all files under arch/arm64: "s/\b__flush_cache_range\b/caches_clean_inval_pou_macro/g;"\ "s/\b__flush_icache_range\b/caches_clean_inval_pou/g;"\ "s/\binvalidate_icache_range\b/icache_inval_pou/g;"\ "s/\b__flush_dcache_area\b/dcache_clean_inval_poc/g;"\ "s/\b__inval_dcache_area\b/dcache_inval_poc/g;"\ "s/__clean_dcache_area_poc\b/dcache_clean_poc/g;"\ "s/\b__clean_dcache_area_pop\b/dcache_clean_pop/g;"\ "s/\b__clean_dcache_area_pou\b/dcache_clean_pou/g;"\ "s/\b__flush_cache_user_range\b/caches_clean_inval_user_pou/g;"\ "s/\b__flush_icache_all\b/icache_inval_all_pou/g;" Note that __clean_dcache_area_poc is deliberately missing a word boundary check at the beginning in order to match the efistub symbols in image-vars.h. Also note that, despite its name, __flush_icache_range operates on both instruction and data caches. The name change here reflects that. No functional change intended. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-19-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Fix cache maintenance function commentsFuad Tabba1-17/+30
Fix and expand comments for the cache maintenance functions in cacheflush.h. Adds comments to functions that weren't described before. Explains what the functions do using Arm Architecture Reference Manual terminology. No functional change intended. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-18-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: sync_icache_aliases to take end parameter instead of sizeFuad Tabba3-13/+12
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-17-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: __clean_dcache_area_pou to take end parameter instead of sizeFuad Tabba3-7/+6
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-16-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: __clean_dcache_area_pop to take end parameter instead of sizeFuad Tabba4-9/+8
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-15-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: __clean_dcache_area_poc to take end parameter instead of sizeFuad Tabba3-12/+11
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. Because the code is shared with __dma_clean_area, it changes the parameters for that as well. However, __dma_clean_area is local to cache.S, so no other users are affected. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-14-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: __flush_dcache_area to take end parameter instead of sizeFuad Tabba14-40/+70
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-13-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: dcache_by_line_op to take end parameter instead of sizeFuad Tabba3-15/+20
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-12-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: __inval_dcache_area to take end parameter instead of sizeFuad Tabba4-13/+12
To be consistent with other functions with similar names and functionality in cacheflush.h, cache.S, and cachetlb.rst, change to specify the range in terms of start and end, as opposed to start and size. Because the code is shared with __dma_inv_area, it changes the parameters for that as well. However, __dma_inv_area is local to cache.S, so no other users are affected. No functional change intended. Reported-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-11-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Fix comments to refer to correct function __flush_icache_rangeFuad Tabba2-3/+3
Many comments refer to the function flush_icache_range, where the intent is in fact __flush_icache_range. Fix these comments to refer to the intended function. That's probably due to commit 3b8c9f1cdfc506e9 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings"), which renamed flush_icache_range() to __flush_icache_range() and added a wrapper. No functional change intended. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-10-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Move documentation of dcache_by_line_opFuad Tabba1-8/+8
The comment describing the macro dcache_by_line_op is placed right before the previous macro of the one it describes, which is a bit confusing. Move it to the macro it describes (dcache_by_line_op). No functional change intended. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-9-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: assembler: remove user_altFuad Tabba1-5/+0
user_alt isn't being used anymore. It's also simpler and clearer to directly use alternative_insn and _cond_extable in-line when needed. Reported-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/linux-arm-kernel/20210520125735.GF17233@C02TD0UTHF1T.local/ Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-8-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Downgrade flush_icache_range to invalidateFuad Tabba1-3/+7
Since __flush_dcache_area is called right before, invalidate_icache_range is sufficient in this case. Rewrite the comment to better explain the rationale behind the cache maintenance operations used here. No functional change intended. Possible performance impact due to invalidating only the icache rather than invalidating and cleaning both caches. Reported-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/linux-arch/20200511110014.lb9PEahJ4hVOYrbwIb_qUHXyNy9KQzNFdb_I3YlzY6A@z/ Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-7-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Do not enable uaccess for invalidate_icache_rangeFuad Tabba2-11/+2
invalidate_icache_range() works on kernel addresses, and doesn't need uaccess. Remove the code that toggles uaccess_ttbr0_enable, as well as the code that emits an entry into the exception table (via the macro invalidate_icache_by_line). Changes return type of invalidate_icache_range() from int (which used to indicate a fault) to void, since it doesn't need uaccess and won't fault. Note that return value was never checked by any of the callers. No functional change intended. Possible performance impact due to the reduced number of instructions. Reported-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/linux-arch/20200511110014.lb9PEahJ4hVOYrbwIb_qUHXyNy9KQzNFdb_I3YlzY6A@z/ Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-6-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Do not enable uaccess for flush_icache_rangeFuad Tabba1-23/+34
__flush_icache_range works on kernel addresses, and doesn't need uaccess. The existing code is a side-effect of its current implementation with __flush_cache_user_range fallthrough. Instead of fallthrough to share the code, use a common macro for the two where the caller specifies an optional fixup label if user access is needed. If provided, this label would be used to generate an extable entry. Simplify the code to use dcache_by_line_op, instead of replicating much of its functionality. No functional change intended. Possible performance impact due to the reduced number of instructions. Reported-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Will Deacon <will@kernel.org> Reported-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/linux-arch/20200511110014.lb9PEahJ4hVOYrbwIb_qUHXyNy9KQzNFdb_I3YlzY6A@z/ Link: https://lore.kernel.org/linux-arm-kernel/20210521121846.GB1040@C02TD0UTHF1T.local/ Signed-off-by: Fuad Tabba <tabba@google.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-5-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Apply errata to swsusp_arch_suspend_exitFuad Tabba1-1/+2
The Arm errata covered by ARM64_WORKAROUND_CLEAN_CACHE require that "dc cvau" instructions get promoted to "dc civac". Reported-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-4-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: assembler: add conditional cache fixupsMark Rutland1-11/+28
It would be helpful if we could use both `dcache_by_line_op` and `invalidate_icache_by_line` for user memory without accidentally fixing up unexpected faults when performing maintenance on kernel addresses. Let's make this possible by having both macros take an optional fixup label, and only generating an extable entry if a label is provided. At the same time, let's clean up the labels used to be globally unique using \@ as we do for other macros. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Cc: Ard Biesheuvel <aedb@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-3-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: assembler: replace `kaddr` with `addr`Mark Rutland1-16/+16
The `__dcache_op_workaround_clean_cache` and `dcache_by_line_op` macros are only expected to be usedc on kernel memory, without a user fault fixup, and so we named their address variables `kaddr` to make this clear. Subseuqent patches will modify these to also work on user memory with an (optional) user fault fixup, where `kaddr` won't make as much sense. To aid the legibility of patches, this patch (only) replaces `kaddr` with `addr` as a preparatory step. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Fuad Tabba <tabba@google.com> Cc: Ard Biesheuvel <aedb@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20210524083001.2586635-2-tabba@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64/mm: Make vmemmap_free() available only with CONFIG_MEMORY_HOTPLUGAnshuman Khandual1-2/+3
vmemmap_free() callsites (mm/sparse.c) and declaration (include/linux/mm.h) are protected with CONFIG_MEMORY_HOTPLUG. This function is not required if CONFIG_MEMORY_HOTPLUG is not enabled. Hence move the config wrapper outside the function definition. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/1621842030-23256-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25kasan: speed up mte_set_mem_tag_rangeEvgenii Stepanov1-26/+67
Use DC GVA / DC GZVA to speed up KASan memory tagging in HW tags mode. The first cacheline is always tagged using STG/STZG even if the address is cacheline-aligned, as benchmarks show it is faster than a conditional branch. Signed-off-by: Evgenii Stepanov <eugenis@google.com> Co-developed-by: Peter Collingbourne <pcc@google.com> Signed-off-by: Peter Collingbourne <pcc@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20210521010023.3244784-1-eugenis@google.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64/mm: Remove [PUD|PMD]_TABLE_BIT from [pud|pmd]_bad()Anshuman Khandual1-3/+2
Semantics wise, [pud|pmd]_bad() have always implied that a given [PUD|PMD] entry does not have a pointer to the next level page table. This had been made clear in the commit a1c76574f345 ("arm64: mm: use *_sect to check for section maps"). Hence explicitly check for a table entry rather than just testing a single bit. This basically redefines [pud|pmd]_bad() in terms of [pud|pmd]_table() making the semantics clear. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/1620644871-26280-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64/mm: Validate CONFIG_PGTABLE_LEVELSAnshuman Khandual1-0/+7
CONFIG_PGTABLE_LEVELS has been statically defined in (arch/arm64/Kconfig) depending on the page size and requested virtual address range. In order to validate this page table levels selection this adds a BUILD_BUG_ON() as per the existing formula ARM64_HW_PGTABLE_LEVELS(). This would help protect any inadvertent changes to CONFIG_PGTABLE_LEVELS selection. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/1620649326-24115-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: Implement stack trace termination recordMadhavan T. Venkataraman4-16/+32
Reliable stacktracing requires that we identify when a stacktrace is terminated early. We can do this by ensuring all tasks have a final frame record at a known location on their task stack, and checking that this is the final frame record in the chain. We'd like to use task_pt_regs(task)->stackframe as the final frame record, as this is already setup upon exception entry from EL0. For kernel tasks we need to consistently reserve the pt_regs and point x29 at this, which we can do with small changes to __primary_switched, __secondary_switched, and copy_process(). Since the final frame record must be at a specific location, we must create the final frame record in __primary_switched and __secondary_switched rather than leaving this to start_kernel and secondary_start_kernel. Thus, __primary_switched and __secondary_switched will now show up in stacktraces for the idle tasks. Since the final frame record is now identified by its location rather than by its contents, we identify it at the start of unwind_frame(), before we read any values from it. External debuggers may terminate the stack trace when FP == 0. In the pt_regs->stackframe, the PC is 0 as well. So, stack traces taken in the debugger may print an extra record 0x0 at the end. While this is not pretty, this does not do any harm. This is a small price to pay for having reliable stack trace termination in the kernel. That said, gdb does not show the extra record probably because it uses DWARF and not frame pointers for stack traces. Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com> Reviewed-by: Mark Brown <broonie@kernel.org> [Mark: rebase, use ASM_BUG(), update comments, update commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20210510110026.18061-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2021-05-25arm64: dts: qcom: sm8350-mtp: enable IPAAlex Elder1-0/+6
Enable IPA for the SM8350 MTP. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20210413170553.1778792-3-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-05-25arm64: dts: qcom: sm8350: add IPA informationAlex Elder1-0/+51
Add IPA-related nodes and definitions to "sm8350.dtsi", which uses IPA v4.9. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20210413170553.1778792-2-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-05-25arm64: mm: don't use CON and BLK mapping if KFENCE is enabledJisheng Zhang1-1/+2
When we added KFENCE support for arm64, we intended that it would force the entire linear map to be mapped at page granularity, but we only enforced this in arch_add_memory() and not in map_mem(), so memory mapped at boot time can be mapped at a larger granularity. When booting a kernel with KFENCE=y and RODATA_FULL=n, this results in the following WARNING at boot: [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/memory.c:2462 apply_to_pmd_range+0xec/0x190 [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc1+ #10 [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO BTYPE=--) [ 0.000000] pc : apply_to_pmd_range+0xec/0x190 [ 0.000000] lr : __apply_to_page_range+0x94/0x170 [ 0.000000] sp : ffffffc010573e20 [ 0.000000] x29: ffffffc010573e20 x28: ffffff801f400000 x27: ffffff801f401000 [ 0.000000] x26: 0000000000000001 x25: ffffff801f400fff x24: ffffffc010573f28 [ 0.000000] x23: ffffffc01002b710 x22: ffffffc0105fa450 x21: ffffffc010573ee4 [ 0.000000] x20: ffffff801fffb7d0 x19: ffffff801f401000 x18: 00000000fffffffe [ 0.000000] x17: 000000000000003f x16: 000000000000000a x15: ffffffc01060b940 [ 0.000000] x14: 0000000000000000 x13: 0098968000000000 x12: 0000000098968000 [ 0.000000] x11: 0000000000000000 x10: 0000000098968000 x9 : 0000000000000001 [ 0.000000] x8 : 0000000000000000 x7 : ffffffc010573ee4 x6 : 0000000000000001 [ 0.000000] x5 : ffffffc010573f28 x4 : ffffffc01002b710 x3 : 0000000040000000 [ 0.000000] x2 : ffffff801f5fffff x1 : 0000000000000001 x0 : 007800005f400705 [ 0.000000] Call trace: [ 0.000000] apply_to_pmd_range+0xec/0x190 [ 0.000000] __apply_to_page_range+0x94/0x170 [ 0.000000] apply_to_page_range+0x10/0x20 [ 0.000000] __change_memory_common+0x50/0xdc [ 0.000000] set_memory_valid+0x30/0x40 [ 0.000000] kfence_init_pool+0x9c/0x16c [ 0.000000] kfence_init+0x20/0x98 [ 0.000000] start_kernel+0x284/0x3f8 Fixes: 840b23986344 ("arm64, kfence: enable KFENCE for ARM64") Cc: <stable@vger.kernel.org> # 5.12.x Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marco Elver <elver@google.com> Tested-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20210525104551.2ec37f77@xhacker.debian Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-05-25arm64: defconfig: Enable usb2_clksel for R-Car Gen3 and RZ/G2Adam Ford1-0/+1
There is a clock driver that's needed when using an external USB reference clock called usb2_clksel. Enable it in the defconfig. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210513114617.30191-3-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: beacon: Fix USB ref clock referencesAdam Ford1-2/+2
The RZ/G2 boards expect there to be an external clock reference for USB2 EHCI controllers. For the Beacon boards, this reference clock is controlled by a programmable versaclock. Because the RZ/G2 family has a special clock driver when using an external clock, the third clock reference in the EHCI node needs to point to this special clock, called usb2_clksel. Since the usb2_clksel does not keep the usb_extal clock enabled, the 4th clock entry for the EHCI nodes needs to reference it to keep the clock running and make USB functional. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210513114617.30191-2-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: beacon: Fix USB extal referenceAdam Ford1-2/+4
The USB extal clock reference isn't associated to a crystal, it's associated to a programmable clock, so remove the extal reference, add the usb2_clksel. Since usb_extal is referenced by the versaclock, reference it here so the usb2_clksel can get the proper clock speed of 50MHz. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210513114617.30191-1-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: eagle: Add x1 clockValentine Barshak1-0/+8
This adds X1 clock which supplies a frequency of 148.5 MHz. This clock is connected to the external dot clock input signal. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> [geert: Verified schematics] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/75a66bae21937da1c69e8024ce61b35aad4ac9b8.1620119570.git.geert+renesas@glider.be
2021-05-25arm64: dts: renesas: v3msk: Fix memory sizeValentine Barshak1-1/+1
The V3MSK board has 2 GiB RAM according to the datasheet and schematics. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> [geert: Verified schematics] Fixes: cc3e267e9bb0ce7f ("arm64: dts: renesas: initial V3MSK board device tree") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210326121050.1578460-1-geert+renesas@glider.be
2021-05-25arm64: dts: renesas: condor: Switch eMMC bus to 1V8Wolfram Sang1-7/+1
The eMMC card has two supplies, VCC and VCCQ. The VCC supplies the NAND array and the VCCQ supplies the bus. On Condor, the VCC is connected to 3.3V rail, while the VCCQ is connected to 1.8V rail. Adjust the pinmux to match the bus, which is always operating in 1.8V mode. While at it, deduplicate the pinmux entries, which are now the same for both default and UHS modes. We still need the two pinctrl entries to match the bindings though. Thanks to Marek Vasut for this description from commit 5f65328df3f5cd25 ("arm64: dts: renesas: Switch eMMC bus to 1V8 on Salvator-X and ULCB"). Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210419143858.39401-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: falcon-csi-dsi: Add GPIO extendersNiklas Söderlund1-0/+21
We need to configure their GPIOs to power on the MAX96712s. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210413181447.2588084-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: beacon kit: Setup AVB refclkAdam Ford1-0/+2
The AVB reference clock assumes an external clock that runs automatically. Because the Versaclock is wired to provide the AVB refclock, the device tree needs to reference it in order for the driver to start the clock. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20210224115146.9131-5-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-25arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names listAdam Ford13-0/+18
The bindings have been updated to support two clocks. Add a clock-names list in the device tree with fck in it. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210224115146.9131-3-aford173@gmail.com [geert: Update new r8a779a0.dtsi] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-05-24arm64: dts: allwinner: pinephone: Set audio card nameArnaud Ferraris1-0/+1
Add the "PinePhone" name to the sound card: this will make upstreaming an ALSA UCM config easier as we can use a unique name. It also avoids an issue where the default card name is truncated. Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com> [Samuel: Split out change, updated commit message] Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210430035859.3487-8-samuel@sholland.org
2021-05-23arm64: dts: freescale: sl28: var1: fix RGMII clock and voltageMichael Walle1-1/+2
During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong, it was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var1.dts. Fixes: 642856097c18 ("arm64: dts: freescale: sl28: add variant 1") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: freescale: sl28: var4: fix RGMII clock and voltageMichael Walle1-3/+2
During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts. Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: zii-ultra: fix 12V_MAIN voltageLucas Stach1-2/+2
As this is a fixed regulator on the board there was no harm in the wrong voltage being specified, apart from a confusing reporting to userspace. Fixes: 4a13b3bec3b4 ("arm64: dts: imx: add Zii Ultra board support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-23arm64: dts: zii-ultra: remove second GEN_3V3 regulator instanceLucas Stach2-19/+10
When adding the sound support a second instance of the GEN_3V3 regulator was added by accident. Remove it and point the consumers to the first instance. Fixes: 663a5b5efa51 ("arm64: dts: zii-ultra: add sound support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-22arm64: defconfig: enable Layerscape EDAC driverMichael Walle1-0/+1
Most Layerscape SoCs support ECC error reporting for the memory controller. Enable the corresponding module. In particular, this will enable EDAC support on the Kontron sl28 board which comes with ECC memory. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-22arm64: dts: ls1028a: fix memory nodeMichael Walle1-2/+2
While enabling EDAC support for the LS1028A it was discovered that the memory node has a wrong endianness setting as well as a wrong interrupt assignment. Fix both. This was tested on a sl28 board. To force ECC errors, you can use the error injection supported by the controller in hardware (with CONFIG_EDAC_DEBUG enabled): # enable error injection $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl # flip lowest bit of the data $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-05-22arm64: dts: ti: k3-am65-iot2050-common: Disable mailbox nodesSuman Anna1-0/+48
There are no sub-mailbox devices defined currently for both the IOT2050 boards. These are usually dictated by the firmwares running on the R5F remote processors and the applications they provide. Defining the actual sub-mailboxes will also dictate the interrupts the clusters will use for interrupts on the Cortex-A53 cores. Disable all of the Mailbox clusters until the sub-mailboxes are defined and used. This fixes the warnings around the missing interrupts with the upcoming conversion of the OMAP Mailbox binding to YAML format. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210514212016.3153-1-s-anna@ti.com
2021-05-21Merge tag 'arm-soc-fixes-5.13-1' of ↵Linus Torvalds16-8/+85
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Only a small number of fixes so far, including some that I had applied during the merge window, so this is based on the original merge of the other branches. - The largest change is a fix for a reference counting bug in the AMD TEE driver. - Neil Armstrong now co-maintains Amlogic SoC support - Two build warning fixes for renesas device tree files - A sign expansion bug for optee - A DT binding fix for a mismerge" * tag 'arm-soc-fixes-5.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: npcm: wpcm450: select interrupt controller driver MAINTAINERS: ARM/Amlogic SoCs: add Neil as primary maintainer tee: amdtee: unload TA only when its refcount becomes 0 dt-bindings: nvmem: mediatek: remove duplicate mt8192 line firmware: arm_scmi: Remove duplicate declaration of struct scmi_protocol_handle firmware: arm_scpi: Prevent the ternary sign expansion bug arm64: dts: renesas: Add port@0 node for all CSI-2 nodes to dtsi arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Fix CSI40 ports
2021-05-21bpf: Fix BPF_JIT kconfig symbol dependencyDaniel Borkmann1-2/+1
Randy reported a randconfig build error recently on i386: ld: arch/x86/net/bpf_jit_comp32.o: in function `do_jit': bpf_jit_comp32.c:(.text+0x28c9): undefined reference to `__bpf_call_base' ld: arch/x86/net/bpf_jit_comp32.o: in function `bpf_int_jit_compile': bpf_jit_comp32.c:(.text+0x3694): undefined reference to `bpf_jit_blind_constants' ld: bpf_jit_comp32.c:(.text+0x3719): undefined reference to `bpf_jit_binary_free' ld: bpf_jit_comp32.c:(.text+0x3745): undefined reference to `bpf_jit_binary_alloc' ld: bpf_jit_comp32.c:(.text+0x37d3): undefined reference to `bpf_jit_prog_release_other' [...] The cause was that b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options") moved BPF_JIT from net/Kconfig into kernel/bpf/Kconfig and previously BPF_JIT was guarded by a 'if NET'. However, there is no actual dependency on NET, it's just that menuconfig NET selects BPF. And the latter in turn causes kernel/bpf/core.o to be built which contains above symbols. Randy's randconfig didn't have NET set, and BPF wasn't either, but BPF_JIT otoh was. Detangle this by making BPF_JIT depend on BPF instead. arm64 was the only arch that pulled in its JIT in net/ via obj-$(CONFIG_NET), all others unconditionally pull this dir in via obj-y. Do the same since CONFIG_NET guard there is really useless as we compiled the JIT via obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o anyway. Fixes: b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
2021-05-20arm64: dts: broadcom: normalize the node name of the UART devicesZhen Lei1-4/+4
Change the node name of the UART devices to match "^serial(@[0-9a-f,]+)*$". Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-05-20Merge tag 'quota_for_v5.13-rc3' of ↵Linus Torvalds1-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull quota fixes from Jan Kara: "The most important part in the pull is disablement of the new syscall quotactl_path() which was added in rc1. The reason is some people at LWN discussion pointed out dirfd would be useful for this path based syscall and Christian Brauner agreed. Without dirfd it may be indeed problematic for containers. So let's just disable the syscall for now when it doesn't have users yet so that we have more time to mull over how to best specify the filesystem we want to work on" * tag 'quota_for_v5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: quota: Disable quotactl_path syscall quota: Use 'hlist_for_each_entry' to simplify code
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 22:52:31 +0300