kernel/arch/arm/mach-exynos, branch linux-6.2.y

ARM: exynos: Fix refcount leak in exynos_map_pmu

2022-06-06T08:40:57Z

of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. Fixes: fce9e5bb2526 ("ARM: EXYNOS: Add support for mapping PMU base address via DT") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220523145513.12341-1-linmq006@gmail.com Signed-off-by: Krzysztof Kozlowski

Merge tag 'arm-multiplatform-5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2022-05-26T17:43:09Z

Pull ARMv4T/v5 multiplatform support from Arnd Bergmann: "This series has been 12 years in the making, it mostly finishes the work that was started with the founding of Linaro to clean up platform support in the kernel. The largest change here is a cleanup of the omap1 platform, which is the final ARM machine type to get converted to the common-clk subsystem. All the omap1 specific drivers are now made independent of the mach/*.h headers to allow the platform to be part of a generic ARMv4/v5 multiplatform kernel. The last bit that enables this support is still missing here while we wait for some last dependencies to make it into the mainline kernel through other subsystems. The s3c24xx, ixp4xx, iop32x, ep93xx and dove platforms were all almost at the point of allowing multiplatform kernels, this work gets completed here along with a few additional cleanup. At the same time, the s3c24xx and s3c64xx are now deprecated and expected to get removed in the future. The PXA and OMAP1 bits are in a separate branch because of dependencies. Once both branches are merged, only the three Intel StrongARM platforms (RiscPC, Footbridge/NetWinder and StrongARM1100) need separate kernels, and there are no plans to include these" * tag 'arm-multiplatform-5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (61 commits) ARM: ixp4xx: Consolidate Kconfig fixing issue ARM: versatile: Add missing of_node_put in dcscb_init ARM: config: Refresh IXP4xx config after multiplatform ARM: omap1: add back omap_set_dma_priority() stub ARM: omap: fix missing declaration warnings ARM: omap: fix address space warnings from sparse ARM: spear: remove include/mach/ subdirectory ARM: davinci: remove include/mach/ subdirectory ARM: omap2: remove include/mach/ subdirectory integrator: remove empty ap_init_early() ARM: s3c: fix include path MAINTAINERS: omap1: Add Janusz as an additional maintainer ARM: omap1: htc_herald: fix typos in comments ARM: OMAP1: fix typos in comments ARM: OMAP1: clock: Remove noop code ARM: OMAP1: clock: Remove unused code ARM: OMAP1: clock: Fix UART rate reporting algorithm ARM: OMAP1: clock: Fix early UART rate issues ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF ARM: omap1: fix build with no SoC selected ...

pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config

2022-04-21T06:58:54Z

The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build: WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y] Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases. Reported-by: Necip Fazil Yildiran Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20220420141407.470955-1-krzysztof.kozlowski@linaro.org

ARM: rework endianess selection

2022-04-08T15:20:54Z

Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago. The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them. This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx. As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment. For the ARMv6/v7 platforms, there are two ways this could be handled a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point. b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work. Out of these, I picked b) because it seemed slighly more logical to me. Signed-off-by: Arnd Bergmann

Merge tag 'arm-soc-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2022-03-24T01:20:09Z

Pull ARM SoC updates from Arnd Bergmann: "SoC specific code is generally used for older platforms that don't (yet) use device tree to do the same things. - Support is added for i.MXRT10xx, a Cortex-M7 based microcontroller from NXP. At the moment this is still incomplete as other portions are merged through different trees. - Long abandoned support for running NOMMU ARMv4 or ARMv5 platforms gets removed, now the Arm NOMMU platforms are limited to the Cortex-M family of microcontrollers - Two old PXA boards get removed, along with corresponding driver bits. - Continued cleanup of the Intel IXP4xx platforms, removing some remnants of the old board files. - Minor Cleanups and fixes for Orion, PXA, MMP, Mstar, Samsung - CPU idle support for AT91 - A system controller driver for Polarfire" * tag 'arm-soc-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (29 commits) ARM: remove support for NOMMU ARMv4/v5 ARM: PXA: fix up decompressor code soc: microchip: make mpfs_sys_controller_put static ARM: pxa: remove Intel Imote2 and Stargate 2 boards ARM: mmp: Fix failure to remove sram device ARM: mstar: Select ARM_ERRATA_814220 soc: add microchip polarfire soc system controller ARM: at91: Kconfig: select PM_OPP ARM: at91: PM: add cpu idle support for sama7g5 ARM: at91: ddr: fix typo to align with datasheet naming ARM: at91: ddr: align macro definitions ARM: at91: ddr: remove CONFIG_SOC_SAMA7 dependency ARM: ixp4xx: Convert to SPARSE_IRQ and P2V ARM: ixp4xx: Drop all common code ARM: ixp4xx: Drop custom DMA coherency and bouncing ARM: ixp4xx: Remove feature bit accessors net: ixp4xx_hss: Check features using syscon net: ixp4xx_eth: Drop platform data support soc: ixp4xx-npe: Access syscon regs using regmap soc: ixp4xx: Add features from regmap helper ...

Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm

2022-03-24T00:35:57Z

Pull ARM updates from Russell King: "Updates for IRQ stacks and virtually mapped stack support, and ftrace: - Support for IRQ and vmap'ed stacks This covers all the work related to implementing IRQ stacks and vmap'ed stacks for all 32-bit ARM systems that are currently supported by the Linux kernel, including RiscPC and Footbridge. It has been submitted for review in four different waves: - IRQ stacks support for v7 SMP systems [0] - vmap'ed stacks support for v7 SMP systems[1] - extending support for both IRQ stacks and vmap'ed stacks for all remaining configurations, including v6/v7 SMP multiplatform kernels and uniprocessor configurations including v7-M [2] - fixes and updates in [3] - ftrace fixes and cleanups Make all flavors of ftrace available on all builds, regardless of ISA choice, unwinder choice or compiler [4]: - use ADD not POP where possible - fix a couple of Thumb2 related issues - enable HAVE_FUNCTION_GRAPH_FP_TEST for robustness - enable the graph tracer with the EABI unwinder - avoid clobbering frame pointer registers to make Clang happy - Fixes for the above" [0] https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/ [1] https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/ [2] https://lore.kernel.org/linux-arm-kernel/20211206164659.1495084-1-ardb@kernel.org/ [3] https://lore.kernel.org/linux-arm-kernel/20220124174744.1054712-1-ardb@kernel.org/ [4] https://lore.kernel.org/linux-arm-kernel/20220203082204.1176734-1-ardb@kernel.org/ * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: (62 commits) ARM: fix building NOMMU ARMv4/v5 kernels ARM: unwind: only permit stack switch when unwinding call_with_stack() ARM: Revert "unwind: dump exception stack from calling frame" ARM: entry: fix unwinder problems caused by IRQ stacks ARM: unwind: set frame.pc correctly for current-thread unwinding ARM: 9184/1: return_address: disable again for CONFIG_ARM_UNWIND=y ARM: 9183/1: unwind: avoid spurious warnings on bogus code addresses Revert "ARM: 9144/1: forbid ftrace with clang and thumb2_kernel" ARM: mach-bcm: disable ftrace in SMC invocation routines ARM: cacheflush: avoid clobbering the frame pointer ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds ARM: ftrace: enable the graph tracer with the EABI unwinder ARM: unwind: track location of LR value in stack frame ARM: ftrace: enable HAVE_FUNCTION_GRAPH_FP_TEST ARM: ftrace: avoid unnecessary literal loads ARM: ftrace: avoid redundant loads or clobbering IP ARM: ftrace: use trampolines to keep .init.text in branching range ARM: ftrace: use ADD not POP to counter PUSH at entry ARM: ftrace: ensure that ADR takes the Thumb bit into account ARM: make get_current() and __my_cpu_offset() __always_inline ...

ARM: cacheflush: avoid clobbering the frame pointer

2022-02-09T09:13:10Z

Thumb2 uses R7 rather than R11 as the frame pointer, and even if we rarely use a frame pointer to begin with when building in Thumb2 mode, there are cases where it is required by the compiler (Clang when inserting profiling hooks via -pg) However, preserving and restoring the frame pointer is risky, as any unhandled exceptions raised in the mean time will produce a bogus backtrace, and it would be better not to touch the frame pointer at all. This is the case even when CONFIG_FRAME_POINTER is not set, as the unwind directive used by the unwinder may also use R7 or R11 as the unwind anchor, even if the frame pointer is not managed strictly according to the frame pointer ABI. So let's tweak the cacheflush asm code not to clobber R7 or R11 at all, so that we can drop R7 from the clobber lists of the inline asm blocks that call these routines, and remove the code that preserves/restores R11. Signed-off-by: Ard Biesheuvel Reviewed-by: Nick Desaulniers

ARM: exynos: only do SMC_CMD_CPU1BOOT call on Exynos4

2022-01-23T19:12:37Z

On Exynos5 the call is simply ignored by most variants of the trustzone firmware. However, on some devices it instead causes the device to hang, so let's avoid the call for the SoCs where it should not be needed. To see that the call is ignored, we can look into sboot/tzsw. On most of the Exynos{4,5} devices the part of sboot/tzsw that seem to handle the secure monitor calls is quite easy to recognise, the SMC number is compared to known ones, and if equal it branches to the relevant function. In assembly this looks something like: ;-- handle_smc: 0x00000514 650070e3 cmn r0, 0x65 0x00000518 0a00000a beq loc.smc_cmd_reg 0x0000051c 010070e3 cmn r0, 1 0x00000520 6c00000a beq loc.smc_cmd_init 0x00000524 020070e3 cmn r0, 2 0x00000528 6b00000a beq loc.smc_cmd_info 0x0000052c 030070e3 cmn r0, 3 0x00000530 6e00000a beq loc.smc_cmd_sleep 0x00000534 060070e3 cmn r0, 6 0x00000538 ae00000a beq loc.smc_cmd_save_state 0x0000053c 070070e3 cmn r0, 7 0x00000540 b400000a beq loc.smc_cmd_standby 0x00000544 2b01001a bne loc.smc_return_minus1 where above example is from exynos5420-arndale-octa. As can be seen the case where r0 is 4 (i.e. SMC_CMD_CPU1BOOT) is not handled. The annotations are taken from github.com/hsnaves/exynos5410-firmware, where a large part of the exynos5410 trustzone firmware has been reverse-engineered. Signed-off-by: Henrik Grimler Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20220118185746.299832-3-henrik@grimler.se Signed-off-by: Krzysztof Kozlowski

ARM: samsung: Remove HAVE_S3C2410_I2C and use direct dependencies

2021-11-21T16:46:18Z

A separate Kconfig option HAVE_S3C2410_I2C for Samsung SoCs is not really needed and the i2c-s3c24xx driver can depend on Samsung ARM architectures instead. This also enables i2c-s3c2410 for arm64 Exynos SoCs, which is required for example by Exynos850. This is basically continuation of work made in following commits: - commit d96890fca9fd ("rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies") - commit 7dd3cae90d85 ("ARM: samsung: remove HAVE_S3C2410_WATCHDOG and use direct dependencies") Signed-off-by: Sam Protsenko Link: https://lore.kernel.org/r/20211121150558.21801-2-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski

rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies

2021-10-17T17:15:12Z

The config HAVE_S3C_RTC is not really needed since we can simply just add the dependencies directly to RTC_DRV_S3C. Also, one less config to keep track of! Signed-off-by: Will McVicker Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211013212256.3425889-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski