aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2022-11-19arm64: dts: imx8mn-evk: add i2c gpio recovery settingsPeng Fan1-2/+22
Add I2C gpio recovery iomuxc settings Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mn-evk: set off-on-delay-us in regulatorPeng Fan1-0/+1
Some SD Card controller and power circuitry has increased capacitance, so the usual toggling of regulator to power the card off and on is insufficient. According to SD spec, for sd card power reset operation, the sd card supply voltage needs to be lower than 0.5v and keep over 1ms, otherwise, next time power back the sd card supply voltage to 3.3v, sd card can't support SD3.0 mode again. This patch add the off-on-delay-us, make sure the sd power reset behavior is align with the specification. Without this patch, when do quick system suspend/resume test, some sd card can't work at SD3.0 mode after system resume back. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mn-evk: update vdd_soc dvs voltagePeng Fan1-2/+1
Per schematic, BUCK1 is for VDD_SOC&DRAM&PU_0V9. The nxp,dvs-run-voltage and nxp,dvs-standby-voltage need set for BUCK1, not BUCK2. BUCK2 is for A53, which is handled by DVFS, so no need dvs property. nxp,dvs-run-voltage is not needed, since bootloader must configure voltage to make system boot well. Signed-off-by: Peng Fan <[email protected]> Acked-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mp-evk: enable I2C2 nodePeng Fan1-0/+14
Enable I2C node for i.MX8MP-EVK Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mp-evk: enable fspi nor on imx8mp evkHan Xu1-0/+25
enable fspi nor on imx8mp evk dts Reviewed-by: Frank Li <[email protected]> Signed-off-by: Han Xu <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mp-evk: enable uart1/3 portsPeng Fan1-0/+36
Enable uart1/3 ports for evk board. Configure the clock to source from IMX8MP_SYS_PLL1_80M, because the uart could only support max 1.5M buadrate if using OSC_24M as clock source. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19ARM64: dts: imx8mp-evk: add pwm supportClark Wang1-0/+36
Enable pwm1/2/4 support. Enable pwm1 on pin GPIO1_IO01 for DSI_BL_PWM pwm2 on pin GPIO1_IO11 for LVDS_BL_PWM pwm4 on pin SAI5_RXFS for J21-32 Acked-by: Fugang Duan <[email protected]> Signed-off-by: Clark Wang <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mp-evk: correct pcie pad settingsPeng Fan1-3/+3
According to RM bit layout, BIT3 and BIT0 are reserved. 8 7 6 5 4 3 2 1 0 PE HYS PUE ODE FSEL X DSE X Although function is not broken, we should not set reserved bit. Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mp: add mlmix power domainPeng Fan1-0/+8
Add mlmix power domain Signed-off-by: Peng Fan <[email protected]> Acked-by: Marco Felsch <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-19arm64: dts: imx8mq: fix dtschema warning for imx7-csiMartin Kepplinger1-2/+2
According to dtschema for the csi bridge, compatible is an enum and only one must be used. Fixing this removes the following warning: compatible: 'oneOf' conditional failed, one must be fixed Signed-off-by: Martin Kepplinger <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-11-18Merge tag 'arm64-fixes' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Fix a build error with CONFIG_CFI_CLANG + CONFIG_FTRACE when CONFIG_FUNCTION_GRAPH_TRACER is not enabled. - Fix a BUG_ON triggered by the page table checker due to incorrect file_map_count for non-leaf pmd/pud (the arm64 pmd_user_accessible_page() not checking whether it's a leaf entry). * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud arm64: ftrace: Define ftrace_stub_graph only with FUNCTION_GRAPH_TRACER
2022-11-18arm64/mm: fix incorrect file_map_count for non-leaf pmd/pudLiu Shixin1-2/+2
The page table check trigger BUG_ON() unexpectedly when collapse hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:82! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_clear.isra.0+0x258/0x3f0 lr : page_table_check_clear.isra.0+0x240/0x3f0 [...] Call trace: page_table_check_clear.isra.0+0x258/0x3f0 __page_table_check_pmd_clear+0xbc/0x108 pmdp_collapse_flush+0xb0/0x160 collapse_huge_page+0xa08/0x1080 hpage_collapse_scan_pmd+0xf30/0x1590 khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8 khugepaged+0x338/0x518 kthread+0x278/0x2f8 ret_from_fork+0x10/0x20 [...] Since pmd_user_accessible_page() doesn't check if a pmd is leaf, it decrease file_map_count for a non-leaf pmd comes from collapse_huge_page(). and so trigger BUG_ON() unexpectedly. Fix this problem by using pmd_leaf() insteal of pmd_present() in pmd_user_accessible_page(). Moreover, use pud_leaf() for pud_user_accessible_page() too. Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") Reported-by: Denys Vlasenko <[email protected]> Signed-off-by: Liu Shixin <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Acked-by: Pasha Tatashin <[email protected]> Reviewed-by: Kefeng Wang <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2022-11-18arm64: dts: socfpga: Add clk-phase-sd-hs property to the sdmmc nodeDinh Nguyen5-0/+5
The sdmmc controller's CIU(Card Interface Unit) clock's phase can be adjusted through the register in the system manager. Add the binding "altr,sysmgr-syscon" to the SDMMC node for the driver to access the system manager. Add the "clk-phase-sd-hs" property in the SDMMC node to designate the smpsel and drvsel properties for the CIU clock. Signed-off-by: Dinh Nguyen <[email protected]>
2022-11-18arm64: errata: Workaround possible Cortex-A715 [ESR|FAR]_ELx corruptionAnshuman Khandual7-0/+84
If a Cortex-A715 cpu sees a page mapping permissions change from executable to non-executable, it may corrupt the ESR_ELx and FAR_ELx registers, on the next instruction abort caused by permission fault. Only user-space does executable to non-executable permission transition via mprotect() system call which calls ptep_modify_prot_start() and ptep_modify _prot_commit() helpers, while changing the page mapping. The platform code can override these helpers via __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION. Work around the problem via doing a break-before-make TLB invalidation, for all executable user space mappings, that go through mprotect() system call. This overrides ptep_modify_prot_start() and ptep_modify_prot_commit(), via defining HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION on the platform thus giving an opportunity to intercept user space exec mappings, and do the necessary TLB invalidation. Similar interceptions are also implemented for HugeTLB. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: Add Cortex-715 CPU part definitionAnshuman Khandual1-0/+2
Add the CPU Partnumbers for the new Arm designs. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: James Morse <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: defconfig: Enable Renesas R-Car S4-8 Spider Ethernet devicesYoshihiro Shimoda1-1/+3
Enable Renesas "Ethernet Switch", Ethernet SERDES and Marvell 10G PHY drivers to be used by NFS root on the Renesas Spider board. Signed-off-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-11-18arm64: dts: renesas: spider-ethernet: Enable Ethernet Switch and SERDESYoshihiro Shimoda1-0/+90
Enable Ethernet Switch and SERDES for R-Car S4-8 (r8a779f0). Signed-off-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-11-18arm64: dts: renesas: r8a779f0: Add Ethernet Switch and SERDES nodesYoshihiro Shimoda1-0/+110
Add Ethernet Switch and SERDES nodes into R-Car S4-8 (r8a779f0). Signed-off-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-11-18arm64: dts: fvp: Add information about L1 and L2 cachesSudeep Holla1-0/+73
Add the information about L1 and L2 caches on FVP RevC platform. Though the cache size is configurable through the model parameters, having default values in the device tree helps to exercise and debug any code utilising the cache information without the need of real hardware. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]>
2022-11-18arm64/mm: Drop unused restore_ttbr1Anshuman Khandual1-11/+0
restore_ttbr1 procedure is not used anywhere, hence just drop it. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: move on_thread_stack() to <asm/stacktrace.h>Mark Rutland3-6/+7
Currently on_thread_stack() is defined in <asm/processor.h>, depending upon definitiong from <asm/stacktrace.h> despite this header not being included. This ends up being fragile, and any user of on_thread_stack() must include both <asm/processor.h> and <asm/stacktrace.h>. We organised things this way due to header dependencies back in commit: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") ... but now that we no longer use current_top_of_stack(), and given that stackleak includes <asm/stacktrace.h> via <linux/stackleak.h>, we no longer need the definition to live in <asm/processor.h>. Move on_thread_stack() to <asm/stacktrace.h>, where all its dependencies are guaranteed to be defined. This requires having arm64's irq.c explicitly include <asm/stacktrace.h>, and I've taken the opportunity to sort the includes, which were slightly out of order. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Kees Cook <[email protected]> Cc: Will Deacon <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: remove current_top_of_stack()Mark Rutland1-11/+0
We no longer use current_top_of_stack() on arm64, so it can be removed. We introduced current_top_of_stack() for STACKLEAK in commit: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") ... then we figured out the intended semantics were unclear, and reworked it in commit: e85094c31ddb794a ("arm64: stackleak: fix current_top_of_stack()") ... then we removed the only user in commit: 0cfa2ccd285d98ad ("stackleak: rework stack high bound handling") Given that it's no longer used, and it's very easy to misuse, this patch removes current_top_of_stack(). For the moment, on_thread_stack() is left where it is as moving it will change some header dependencies. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Kees Cook <[email protected]> Cc: Will Deacon <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: alternatives: make apply_alternatives_vdso() staticMark Rutland1-1/+1
We define and use apply_alternatives_vdso() within alternative.c, and don't provide a prototype in a header. There's no need for it to be visible outside of alternative.c, so mark it as static. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Joey Gouly <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zonesZhen Lei1-1/+16
For crashkernel=X without '@offset', select a region within DMA zones first, and fall back to reserve region above DMA zones. This allows users to use the same configuration on multiple platforms. Signed-off-by: Zhen Lei <[email protected]> Acked-by: Baoquan He <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: kdump: Provide default size when crashkernel=Y,low is not specifiedZhen Lei1-2/+6
Try to allocate at least 128 MiB low memory automatically for the case that crashkernel=,high is explicitly specified, while crashkenrel=,low is omitted. This allows users to focus more on the high memory requirements of their business rather than the low memory requirements of the crash kernel booting. Signed-off-by: Zhen Lei <[email protected]> Acked-by: Baoquan He <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64/mm: Drop idmap_pg_end[] declarationAnshuman Khandual1-1/+0
idmap_pg_end[] is not used anywhere, hence just drop its declaration. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64/mm: Drop redundant BUG_ON(!pgtable_alloc)Anshuman Khandual1-3/+1
__create_pgd_mapping_locked() expects a page allocator used while mapping a virtual range. This page allocator function propagates down the call chain, while building intermediate levels in the page table. Passed page allocator is a necessary ingredient required to build the page table but its presence can be asserted just once in the very beginning rather than in all the down stream functions. This consolidates BUG_ON(!pgtable_alloc) checks just in a single place i.e __create_pgd_mapping_locked(). Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18ftrace: arm64: move from REGS to ARGSMark Rutland7-123/+184
This commit replaces arm64's support for FTRACE_WITH_REGS with support for FTRACE_WITH_ARGS. This removes some overhead and complexity, and removes some latent issues with inconsistent presentation of struct pt_regs (which can only be reliably saved/restored at exception boundaries). FTRACE_WITH_REGS has been supported on arm64 since commit: 3b23e4991fb66f6d ("arm64: implement ftrace with regs") As noted in the commit message, the major reasons for implementing FTRACE_WITH_REGS were: (1) To make it possible to use the ftrace graph tracer with pointer authentication, where it's necessary to snapshot/manipulate the LR before it is signed by the instrumented function. (2) To make it possible to implement LIVEPATCH in future, where we need to hook function entry before an instrumented function manipulates the stack or argument registers. Practically speaking, we need to preserve the argument/return registers, PC, LR, and SP. Neither of these need a struct pt_regs, and only require the set of registers which are live at function call/return boundaries. Our calling convention is defined by "Procedure Call Standard for the Arm® 64-bit Architecture (AArch64)" (AKA "AAPCS64"), which can currently be found at: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst Per AAPCS64, all function call argument and return values are held in the following GPRs: * X0 - X7 : parameter / result registers * X8 : indirect result location register * SP : stack pointer (AKA SP) Additionally, ad function call boundaries, the following GPRs hold context/return information: * X29 : frame pointer (AKA FP) * X30 : link register (AKA LR) ... and for ftrace we need to capture the instrumented address: * PC : program counter No other GPRs are relevant, as none of the other arguments hold parameters or return values: * X9 - X17 : temporaries, may be clobbered * X18 : shadow call stack pointer (or temorary) * X19 - X28 : callee saved This patch implements FTRACE_WITH_ARGS for arm64, only saving/restoring the minimal set of registers necessary. This is always sufficient to manipulate control flow (e.g. for live-patching) or to manipulate function arguments and return values. This reduces the necessary stack usage from 336 bytes for pt_regs down to 112 bytes for ftrace_regs + 32 bytes for two frame records, freeing up 188 bytes. This could be reduced further with changes to the unwinder. As there is no longer a need to save different sets of registers for different features, we no longer need distinct `ftrace_caller` and `ftrace_regs_caller` trampolines. This allows the trampoline assembly to be simpler, and simplifies code which previously had to handle the two trampolines. I've tested this with the ftrace selftests, where there are no unexpected failures. Co-developed-by: Florent Revest <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Florent Revest <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Deacon <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2022-11-18arm64: dts: fvp: Add SPE to Foundation FVPJames Clark1-0/+5
Add SPE DT node to FVP model. If the model doesn't support SPE (e.g., turned off via parameter), the driver will skip the initialisation accordingly and thus is safe. Signed-off-by: James Clark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]>
2022-11-18crypto: arm64 - Fix unused variable compilation warnings of cpu_featureTianjia Zhang2-2/+2
The cpu feature defined by MODULE_DEVICE_TABLE is only referenced when compiling as a module, and the warning of unused variable will be encountered when compiling with intree. The warning can be removed by adding the __maybe_unused flag. Fixes: 03c9a333fef1 ("crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL") Fixes: ae1b83c7d572 ("crypto: arm64/sm4 - add CE implementation for GCM mode") Reported-by: kernel test robot <[email protected]> Signed-off-by: Tianjia Zhang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-11-18Merge tag 'efi-zboot-direct-for-v6.2' into efi/nextArd Biesheuvel4-88/+13
2022-11-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski4-22/+39
include/linux/bpf.h 1f6e04a1c7b8 ("bpf: Fix offset calculation error in __copy_map_value and zero_map_value") aa3496accc41 ("bpf: Refactor kptr_off_tab into btf_record") f71b2f64177a ("bpf: Refactor map->off_arr handling") https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jakub Kicinski <[email protected]>
2022-11-18random: remove early archrandom abstractionJason A. Donenfeld1-38/+10
The arch_get_random*_early() abstraction is not completely useful and adds complexity, because it's not a given that there will be no calls to arch_get_random*() between random_init_early(), which uses arch_get_random*_early(), and init_cpu_features(). During that gap, crng_reseed() might be called, which uses arch_get_random*(), since it's mostly not init code. Instead we can test whether we're in the early phase in arch_get_random*() itself, and in doing so avoid all ambiguity about where we are. Fortunately, the only architecture that currently implements arch_get_random*_early() also has an alternatives-based cpu feature system, one flag of which determines whether the other flags have been initialized. This makes it possible to do the early check with zero cost once the system is initialized. Reviewed-by: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Jean-Philippe Brucker <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-11-18stackprotector: actually use get_random_canary()Jason A. Donenfeld1-8/+1
The RNG always mixes in the Linux version extremely early in boot. It also always includes a cycle counter, not only during early boot, but each and every time it is invoked prior to being fully initialized. Together, this means that the use of additional xors inside of the various stackprotector.h files is superfluous and over-complicated. Instead, we can get exactly the same thing, but better, by just calling `get_random_canary()`. Acked-by: Guo Ren <[email protected]> # for csky Acked-by: Catalin Marinas <[email protected]> # for arm64 Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-11-18treewide: use get_random_u32_below() instead of deprecated functionJason A. Donenfeld1-1/+1
This is a simple mechanical transformation done by: @@ expression E; @@ - prandom_u32_max + get_random_u32_below (E) Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Acked-by: Darrick J. Wong <[email protected]> # for xfs Reviewed-by: SeongJae Park <[email protected]> # for damon Reviewed-by: Jason Gunthorpe <[email protected]> # for infiniband Reviewed-by: Russell King (Oracle) <[email protected]> # for arm Acked-by: Ulf Hansson <[email protected]> # for mmc Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-11-17Merge tag 'soc-fixes-6.1-3' of ↵Linus Torvalds15-41/+96
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Another set of devicetree and code changes for SoC platforms, notably: - DT schema warning fixes for i.MX - Functional fixes for i.MX tqma8mqml-mba8mx USB and i.MX8M OCOTP - MAINTAINERS updates for Hisilicon and RISC-V, documenting which RISC-V SoC specific patches will now get merged through the SoC tree in the future. - A code fix for at91 suspend, to work around broken hardware - A devicetree fix for lan966x/pcb8291 LED support - Lots of DT fixes for Qualcomm SoCs, mostly fixing minor problems like incorrect register sizes and schema warnings. One fix makes the UFS controller work on sc8280xp, and six fixes address the same regulator problem in a variety of platforms" * tag 'soc-fixes-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (31 commits) MAINTAINERS: repair Microchip corei2c driver entry MAINTAINERS: add an entry for StarFive devicetrees MAINTAINERS: generify the Microchip RISC-V entry name MAINTAINERS: add entries for misc. RISC-V SoC drivers and devicetrees MAINTAINERS: git://github.com -> https://github.com for HiSilicon soc: imx8m: Enable OCOTP clock before reading the register arm64: dts: imx93-pinfunc: drop execution permission arm64: dts: imx8mn: Fix NAND controller size-cells arm64: dts: imx8mm: Fix NAND controller size-cells ARM: dts: imx7: Fix NAND controller size-cells arm64: dts: imx8mm-tqma8mqml-mba8mx: Fix USB DR ARM: at91: pm: avoid soft resetting AC DLL ARM: dts: lan966x: Enable sgpio on pcb8291 arm64: dts: qcom: sm8250: Disable the not yet supported cluster idle state ARM: dts: at91: sama7g5: fix signal name of pin PB2 arm64: dts: qcom: sc7280: Add the reset reg for lpass audiocc on SC7280 arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size arm64: dts: qcom: sc8280xp: drop broken DP PHY nodes arm64: dts: qcom: sc8280xp: fix USB PHY PCS registers arm64: dts: qcom: sc8280xp: fix USB1 PHY RX1 registers ...
2022-11-17arm64: dts: renesas: r9a09g011: Add system controller nodeBiju Das1-0/+5
Add system controller node to RZ/V2M SoC dtsi. Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-11-17arm64: dts: renesas: r8a779g0: Add CA76 operating pointsGeert Uytterhoeven1-0/+31
Add operating points for running the Cortex-A76 CPU cores on R-Car V4H at various speeds, up to the Normal (1.7 GHz) performance mode. Based on a patch in the BSP by Tho Vu. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/8afb32f5dc123ebf2b941703483152ff0992191d.1668429870.git.geert+renesas@glider.be
2022-11-17arm64: dts: renesas: r8a779g0: Add CPU core clocksGeert Uytterhoeven1-0/+4
Describe the clocks for the four Cortex-A76 CPU cores. CA76 Sub-Systems 0/1 (both clusters / all CPU cores) are clocked by Z0φ. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/aa6e9ae21e451ebd40d54d986bd0296571128d5b.1668429870.git.geert+renesas@glider.be
2022-11-17arm64: dts: renesas: r8a779g0: Add CPUIdle supportGeert Uytterhoeven1-0/+17
Support CPUIdle for ARM Cortex-A76 on R-Car V4H. Based on patches in the BSP by Tho Vu and Vincent Bryce. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/f6d4076983eb45cf23595a045747f28cbdcdf4e6.1668429870.git.geert+renesas@glider.be
2022-11-17arm64: dts: renesas: r8a779g0: Add secondary CA76 CPU coresGeert Uytterhoeven1-5/+65
Complete the description of the Cortex-A76 CPU cores and L3 cache controllers on the Renesas R-Car V4H (R8A779G0) SoC, including CPU topology and PSCI support for enabling CPU cores. R-Car V4H has 4 Cortex-A76 cores, grouped in 2 clusters. Based on a patch in the BSP by Takeshi Kihara. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/ccb55458bd87f8ba70d28c61bcc254f22184824c.1668429870.git.geert+renesas@glider.be
2022-11-17arm64: dts: renesas: r8a779g0: Add L3 cache controllerGeert Uytterhoeven1-0/+8
Describe the cache configuration for the first Cortex-A76 CPU core on the Renesas R-Car V4H (R8A779G0) SoC. Extracted from a larger patch in the BSP by Takeshi Kihara. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/dfd743b32198295afb78bc0ac337ef283fa3879a.1668429870.git.geert+renesas@glider.be
2022-11-17arm64: dts: mediatek: mt7986: Add SoC compatibleMatthias Brugger4-2/+6
Missing SoC compatible in the board file causes dt bindings check. Signed-off-by: Matthias Brugger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]>
2022-11-17KVM: arm64: PMU: Simplify setting a counter to a specific valueMarc Zyngier1-1/+4
kvm_pmu_set_counter_value() is pretty odd, as it tries to update the counter value while taking into account the value that is currently held by the running perf counter. This is not only complicated, this is quite wrong. Nowhere in the architecture is it said that the counter would be offset by something that is pending. The counter should be updated with the value set by SW, and start counting from there if required. Remove the odd computation and just assign the provided value after having released the perf event (which is then restarted). Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Add counter_index_to_*reg() helpersMarc Zyngier1-15/+18
In order to reduce the boilerplate code, add two helpers returning the counter register index (resp. the event register) in the vcpu register file from the counter index. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Only narrow counters that are not 64bit wideMarc Zyngier1-8/+6
The current PMU emulation sometimes narrows counters to 32bit if the counter isn't the cycle counter. As this is going to change with PMUv3p5 where the counters are all 64bit, fix the couple of cases where this happens unconditionally. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Reiji Watanabe <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Narrow the overflow checking when requiredMarc Zyngier1-1/+2
For 64bit counters that overflow on a 32bit boundary, make sure we only check the bottom 32bit to generate a CHAIN event. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Reiji Watanabe <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Distinguish between 64bit counter and 64bit overflowMarc Zyngier1-12/+31
The PMU architecture makes a subtle difference between a 64bit counter and a counter that has a 64bit overflow. This is for example the case of the cycle counter, which can generate an overflow on a 32bit boundary if PMCR_EL0.LC==0 despite the accumulation being done on 64 bits. Use this distinction in the few cases where it matters in the code, as we will reuse this with PMUv3p5 long counters. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Always advertise the CHAIN eventMarc Zyngier1-0/+2
Even when the underlying HW doesn't offer the CHAIN event (which happens with QEMU), we can always support it as we're in control of the counter overflow. Always advertise the event via PMCEID0_EL0. Reviewed-by: Reiji Watanabe <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-11-17KVM: arm64: PMU: Align chained counter implementation with architecture ↵Marc Zyngier1-234/+86
pseudocode Ricardo recently pointed out that the PMU chained counter emulation in KVM wasn't quite behaving like the one on actual hardware, in the sense that a chained counter would expose an overflow on both halves of a chained counter, while KVM would only expose the overflow on the top half. The difference is subtle, but significant. What does the architecture say (DDI0087 H.a): - Up to PMUv3p4, all counters but the cycle counter are 32bit - A 32bit counter that overflows generates a CHAIN event on the adjacent counter after exposing its own overflow status - The CHAIN event is accounted if the counter is correctly configured (CHAIN event selected and counter enabled) This all means that our current implementation (which uses 64bit perf events) prevents us from emulating this overflow on the lower half. How to fix this? By implementing the above, to the letter. This largely results in code deletion, removing the notions of "counter pair", "chained counters", and "canonical counter". The code is further restructured to make the CHAIN handling similar to SWINC, as the two are now extremely similar in behaviour. Reported-by: Ricardo Koller <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Reiji Watanabe <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.