summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2021-01-14riscv: Separate memory init from paging initAtish Patra
Currently, we perform some memory init functions in paging init. But, that will be an issue for NUMA support where DT needs to be flattened before numa initialization and memblock_present can only be called after numa initialization. Move memory initialization related functions to a separate function. Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14numa: Move numa implementation to common codeAtish Patra
ARM64 numa implementation is generic enough that RISC-V can reuse that implementation with very minor cosmetic changes. This will help both ARM64 and RISC-V in terms of maintanace and feature improvement Move the numa implementation code to common directory so that both ISAs can reuse this. This doesn't introduce any function changes for ARM64. Signed-off-by: Atish Patra <atish.patra@wdc.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14arm64, numa: Change the numa init functions name to be genericAtish Patra
This is a preparatory patch for unifying numa implementation between ARM64 & RISC-V. As the numa implementation will be moved to generic code, rename the arm64 related functions to a generic one. Signed-off-by: Atish Patra <atish.patra@wdc.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add Canaan Kendryte K210 reset controllerDamien Le Moal
Add a reset controller driver for the Canaan Kendryte K210 SoC. This driver relies on its syscon compatible parent node (sysctl) for its register mapping. Default this driver compilation to y when the SOC_CANAAN option is selected. The MAINTAINERS file is updated, adding the entry "CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER" with myself listed as maintainer for this driver. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Fix Canaan Kendryte K210 device treeDamien Le Moal
Remove the clocks property from the cpu and clint nodes as these are ignored. Also remove the clock-frequency property from the cpu nodes as riscv relies on the timebase-frequency property. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Use vendor name for K210 SoC supportDamien Le Moal
Rename configuration options and directories related to the Kendryte K210 SoC to use the SoC vendor name (canaan) instead of the "kendryte" branding name. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14ARM: dts: stm32: Disable KS8851 and FMC on PicoITX boardMarek Vasut
The PicoITX has only one ethernet routed out, so the KS8851 is not used at all. Disable the KS8851 and the entire FMC controller. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Fix schema warnings for pwm-leds on lxa-mc1Alexander Dahl
The node names for devices using the pwm-leds driver follow a certain naming scheme (now). Parent node name is not enforced, but recommended by DT project. DTC arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml CHECK arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml /home/alex/build/linux/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml: led-rgb: 'led-blue', 'led-green', 'led-red' do not match any of the regexes: '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+' From schema: /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml Signed-off-by: Alexander Dahl <post@lespocky.de> Acked-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Disable SDMMC1 CKIN feedback clock on DHCOMMarek Vasut
The STM32MP1 DHCOM SoM can be built with either bus voltage level shifter or without one on the SDMMC1 interface. Because the SDMMC1 interface is limited to 50 MHz and hence SD high-speed anyway, disable the SD feedback clock to permit operation of the same U-Boot image on both SoM with and without voltage level shifter. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Enable internal pull-ups for SDMMC1 on DHCOM SoMMarek Vasut
The default state of SD bus and clock line is logical HI. SD card IO is open-drain and pulls the bus lines LO. Always enable the SD bus pull ups to guarantee this behavior on DHCOM SoM. Note that on SoMs with SD bus voltage level shifter, the pull ups are built into the level shifter, however that has no negative impact. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02Marek Vasut
The GPIO hog flags are ignored by gpiolib-of.c now, set the flags to 0. Since GPIO_ACTIVE_HIGH is defined as 0, this change only increases the correctness of the DT. Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Fix GPIO hog flags on DHCOM PicoITXMarek Vasut
The GPIO hog flags are ignored by gpiolib-of.c now, set the flags to 0. Due to a change in gpiolib-of.c, setting flags to GPIO_ACTIVE_LOW and using output-low DT property leads to the GPIO being set high instead. Fixes: ac68793f49de ("ARM: dts: stm32: Add DHCOM based PicoITX board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Fix GPIO hog names on DHCOMMarek Vasut
The GPIO hog node name should match regex '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$', make it so and fix the following two make dtbs_check warnings: arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dt.yaml: hog-usb-port-power: $nodename:0: 'hog-usb-port-power' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$' arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dt.yaml: hog-usb-hub: $nodename:0: 'hog-usb-hub' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$' Fixes: ac68793f49de ("ARM: dts: stm32: Add DHCOM based PicoITX board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14arm64: allow LTO to be selectedSami Tolvanen
Allow CONFIG_LTO_CLANG to be enabled. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-17-samitolvanen@google.com
2021-01-14arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGSSami Tolvanen
DYNAMIC_FTRACE_WITH_REGS uses -fpatchable-function-entry, which makes running recordmcount unnecessary as there are no mcount calls in object files, and __mcount_loc doesn't need to be generated. While there's normally no harm in running recordmcount even when it's not strictly needed, this won't work with LTO as we have LLVM bitcode instead of ELF objects. This change selects FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY, which disables recordmcount when patchable function entries are used instead. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-16-samitolvanen@google.com
2021-01-14arm64: vdso: disable LTOSami Tolvanen
Disable LTO for the vDSO by filtering out CC_FLAGS_LTO, as there's no point in using link-time optimization for the small amount of C code. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-15-samitolvanen@google.com
2021-01-14kbuild: lto: fix module versioningSami Tolvanen
With CONFIG_MODVERSIONS, version information is linked into each compilation unit that exports symbols. With LTO, we cannot use this method as all C code is compiled into LLVM bitcode instead. This change collects symbol versions into .symversions files and merges them in link-vmlinux.sh where they are all linked into vmlinux.o at the same time. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-4-samitolvanen@google.com
2021-01-14kbuild: add support for Clang LTOSami Tolvanen
This change adds build system support for Clang's Link Time Optimization (LTO). With -flto, instead of ELF object files, Clang produces LLVM bitcode, which is compiled into native code at link time, allowing the final binary to be optimized globally. For more details, see: https://llvm.org/docs/LinkTimeOptimization.html The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, which defaults to LTO being disabled. To use LTO, the architecture must select ARCH_SUPPORTS_LTO_CLANG and support: - compiling with Clang, - compiling all assembly code with Clang's integrated assembler, - and linking with LLD. While using CONFIG_LTO_CLANG_FULL results in the best runtime performance, the compilation is not scalable in time or memory. CONFIG_LTO_CLANG_THIN enables ThinLTO, which allows parallel optimization and faster incremental builds. ThinLTO is used by default if the architecture also selects ARCH_SUPPORTS_LTO_CLANG_THIN: https://clang.llvm.org/docs/ThinLTO.html To enable LTO, LLVM tools must be used to handle bitcode files, by passing LLVM=1 and LLVM_IAS=1 options to make: $ make LLVM=1 LLVM_IAS=1 defconfig $ scripts/config -e LTO_CLANG_THIN $ make LLVM=1 LLVM_IAS=1 To prepare for LTO support with other compilers, common parts are gated behind the CONFIG_LTO option, and LTO can be disabled for specific files by filtering out CC_FLAGS_LTO. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-3-samitolvanen@google.com
2021-01-14x86/entry: Emit a symbol for register restoring thunkNick Desaulniers
Arnd found a randconfig that produces the warning: arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at offset 0x3e when building with LLVM_IAS=1 (Clang's integrated assembler). Josh notes: With the LLVM assembler not generating section symbols, objtool has no way to reference this code when it generates ORC unwinder entries, because this code is outside of any ELF function. The limitation now being imposed by objtool is that all code must be contained in an ELF symbol. And .L symbols don't create such symbols. So basically, you can use an .L symbol *inside* a function or a code segment, you just can't use the .L symbol to contain the code using a SYM_*_START/END annotation pair. Fangrui notes that this optimization is helpful for reducing image size when compiling with -ffunction-sections and -fdata-sections. I have observed on the order of tens of thousands of symbols for the kernel images built with those flags. A patch has been authored against GNU binutils to match this behavior of not generating unused section symbols ([1]), so this will also become a problem for users of GNU binutils once they upgrade to 2.36. Omit the .L prefix on a label so that the assembler will emit an entry into the symbol table for the label, with STB_LOCAL binding. This enables objtool to generate proper unwind info here with LLVM_IAS=1 or GNU binutils 2.36+. [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com> Suggested-by: Borislav Petkov <bp@alien8.de> Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lkml.kernel.org/r/20210112194625.4181814-1-ndesaulniers@google.com Link: https://github.com/ClangBuiltLinux/linux/issues/1209 Link: https://reviews.llvm.org/D93783 Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 [1]
2021-01-14ARM: dts: stm32: Disable optional TSC2004 on DRC02 boardMarek Vasut
The DRC02 has no use for the on-SoM touchscreen controller, and the on-SoM touchscreen controller may not even be populated, which then results in error messages in kernel log. Disable the touchscreen controller in DT. Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Disable WP on DHCOM uSD slotMarek Vasut
The uSD slot has no WP detection, disable it. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Connect card-detect signal on DHCOMMarek Vasut
The DHCOM SoM uSD slot card detect signal is connected to GPIO PG1, describe it in the DT. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detectMarek Vasut
The uSD card detect signal on the DH DRC02 is active-high, with a default pull down resistor on the board. Invert the polarity. Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org -- Note that this could not be tested on prototype SoMs, now that it is tested, this issue surfaced, so it needs to be fixed. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-01-14arm64: dts: ti: k3-j7200-som-p0: Add DDR carveout memory nodes for R5FsSuman Anna
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within both the MCU and MAIN domains on the TI J7200 EVM boards. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc device, and the second region will furnish the static carveout regions for the firmware memory. An additional reserved memory node is also added to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The current carveout addresses and sizes are defined statically for each device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables either to allocate the memory for firmware memory segments. NOTE: 1. The R5F1 carveouts are needed only if the R5F cluster is running in Split (non-LockStep) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. 2. The J7200 SoCs have no DSPs and one less R5F cluster compared to J721E SoCs. So, while the carveout memories reserved for the R5F clusters present on the SoC match to those on J721E, the overall memory map reserved for firmwares is quite different. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-4-s-anna@ti.com
2021-01-14arm64: dts: ti: k3-j7200-som-p0: Add mailboxes to R5FsSuman Anna
Add the required 'mboxes' property to all the R5F processors for the TI J7200 common processor board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The nodes are therefore added in the common k3-j7200-som-p0.dtsi file so that all of these can be co-located. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-3-s-anna@ti.com
2021-01-14arm64: dts: ti: k3-j7200: Add R5F cluster nodesSuman Anna
The J7200 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS) subsystems/clusters. One R5F cluster is present within the MCU domain (MCU_R5FSS0), and the other one is present within the MAIN domain (MAIN_R5FSS0). Each of these can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in LockStep-mode to provide a larger 128 KB of memory, but otherwise are functionally similar to those on J721E SoCs. Add the DT nodes for both the MCU and MAIN domain R5F cluster/subsystems, the two R5F cores are added as child nodes to each of the R5F cluster nodes. The clusters are configured to run in LockStep mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MCU R5FSS0 Core0: j7200-mcu-r5f0_0-fw (both in LockStep and Split modes) MCU R5FSS0 Core1: j7200-mcu-r5f0_1-fw (needed only in Split mode) MAIN R5FSS0 Core0: j7200-main-r5f0_0-fw (both in LockStep & Split modes) MAIN R5FSS0 Core1: j7200-main-r5f0_1-fw (needed only in Split mode) Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210111184554.6748-2-s-anna@ti.com
2021-01-14arm64: dts: allwinner: Pine H64: Enable HS200 eMMC modeAndre Przywara
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-9-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Pine64-LTS/SoPine: Enable HS200 eMMC modeAndre Przywara
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-8-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: A64: Limit MMC2 bus frequency to 150 MHzAndre Przywara
In contrast to the H6 (and later) manuals, the A64 datasheet does not specify any limitations in the maximum possible frequency for eMMC controllers. However experimentation has found that a 150 MHz limit similar to other SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist for the MMC2 controller. Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi. The Pinebook seems to be the an odd exception, since it apparently seems to work with 200 MHz as well, so overwrite this in its board .dts file. Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works. Fixes: 22be992faea7 ("arm64: allwinner: a64: Increase the MMC max frequency") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: H6: Allow up to 150 MHz MMC bus frequencyAndre Przywara
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus frequency of the MMC controllers. So far we had no explicit limits in the DT, which limited eMMC to the spec defined frequencies, or whatever the driver defines (both Linux and FreeBSD use 52 MHz here). Put those maximum frequencies in the SoC .dtsi, to allow higher speed modes (which still would need to be explicitly enabled, per board). Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed 200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably. Fixes: 8f54bd1595b3 ("arm64: allwinner: h6: add device tree nodes for MMC controllers") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-6-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD cardAndre Przywara
The SD card on the SoPine SoM module is somewhat concealed, so was originally defined as "non-removable". However there is a working card-detect pin (tested on two different SoM versions), and in certain SoM base boards it might be actually accessible at runtime. Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the non-removable flag, even though the SD card slot is perfectly accessible and usable there. (It turns out that just *my* board has a broken card detect switch, so I originally thought CD wouldn't work on the LTS.) Drop the "non-removable" flag to describe the SD card slot properly. Fixes: c3904a269891 ("arm64: allwinner: a64: add DTSI file for SoPine SoM") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-5-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: Pine64-LTS: Add status LEDAndre Przywara
The Pine64-LTS board features a blue status LED on pin PL7. Describe it in the DT. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-4-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: H6: properly connect USB PHY to port 0Andre Przywara
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the H6 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: eabb3d424b6d ("arm64: dts: allwinner: h6: add USB2-related device nodes") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-3-andre.przywara@arm.com
2021-01-14arm64: dts: allwinner: A64: properly connect USB PHY to port 0Andre Przywara
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the A64 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. Remove the part from the Pinebook DTS which already had this property. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przywara@arm.com
2021-01-14x86/topology: Make __max_die_per_package available unconditionallyBorislav Petkov
Move it outside of CONFIG_SMP in order to avoid ifdeffery at the usage sites. Fixes: 76e2fc63ca40 ("x86/cpu/amd: Set __max_die_per_package on AMD") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210114111814.5346-1-bp@alien8.de
2021-01-14arm64: dts: renesas: r8a779a0: Add SYS-DMAC nodesGeert Uytterhoeven
Add device nodes for the Direct Memory Access Controller for System (SYS-DMAC) instances on the Renesas R-Car V3U (r8a779a0) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210107182045.1948037-1-geert+renesas@glider.be
2021-01-14arm64: dts: renesas: r8a779a0: Add GPIO nodesGeert Uytterhoeven
Add device nodes for the General Purpose Input/Output (GPIO) block on the Renesas R-Car V3U (r8a779a0) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210114111117.2214281-1-geert+renesas@glider.be
2021-01-14KVM: arm64: Use the reg_to_encoding() macro instead of sys_reg()Alexandru Elisei
The reg_to_encoding() macro is a wrapper over sys_reg() and conveniently takes a sys_reg_desc or a sys_reg_params argument and returns the 32 bit register encoding. Use it instead of calling sys_reg() directly. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210106144218.110665-1-alexandru.elisei@arm.com
2021-01-14KVM: arm64: Allow PSCI SYSTEM_OFF/RESET to returnDavid Brazdil
The KVM/arm64 PSCI relay assumes that SYSTEM_OFF and SYSTEM_RESET should not return, as dictated by the PSCI spec. However, there is firmware out there which breaks this assumption, leading to a hyp panic. Make KVM more robust to broken firmware by allowing these to return. Signed-off-by: David Brazdil <dbrazdil@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201229160059.64135-1-dbrazdil@google.com
2021-01-14KVM: arm64: Simplify handling of absent PMU system registersMarc Zyngier
Now that all PMU registers are gated behind a .visibility callback, remove the other checks against an absent PMU. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-01-14KVM: arm64: Hide PMU registers from userspace when not availableMarc Zyngier
It appears that while we are now able to properly hide PMU registers from the guest when a PMU isn't available (either because none has been configured, the host doesn't have the PMU support compiled in, or that the HW doesn't have one at all), we are still exposing more than we should to userspace. Introduce a visibility callback gating all the PMU registers, which covers both usrespace and guest. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-01-14arm64: dts: renesas: r8a779a0: Add pinctrl device nodeUlrich Hecht
This patch adds the pinctrl device node for the R8A779A0 (V3U) SoC. Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu> Link: https://lore.kernel.org/r/20210112165948.31162-1-uli+renesas@fpond.eu Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-01-14perf/x86/intel/uncore: With > 8 nodes, get pci bus die id from NUMA infoSteve Wahl
The registers used to determine which die a pci bus belongs to don't contain enough information to uniquely specify more than 8 dies, so when more than 8 dies are present, use NUMA information instead. Continue to use the previous method for 8 or fewer because it works there, and covers cases of NUMA being disabled. Signed-off-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lkml.kernel.org/r/20210108153549.108989-3-steve.wahl@hpe.com
2021-01-14perf/x86/intel/uncore: Store the logical die id instead of the physical die id.Steve Wahl
The phys_id isn't really used other than to map to a logical die id. Calculate the logical die id earlier, and store that instead of the phys_id. Signed-off-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lkml.kernel.org/r/20210108153549.108989-2-steve.wahl@hpe.com
2021-01-14crypto: x86 - use local headers for x86 specific shared declarationsArd Biesheuvel
The Camellia, Serpent and Twofish related header files only contain declarations that are shared between different implementations of the respective algorithms residing under arch/x86/crypto, and none of their contents should be used elsewhere. So move the header files into the same location, and use local #includes instead. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-14crypto: x86 - remove glue helper moduleArd Biesheuvel
All dependencies on the x86 glue helper module have been replaced by local instantiations of the new ECB/CBC preprocessor helper macros, so the glue helper module can be retired. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-14crypto: x86/twofish - drop dependency on glue helperArd Biesheuvel
Replace the glue helper dependency with implementations of ECB and CBC based on the new CPP macros, which avoid the need for indirect calls. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-14crypto: x86/cast6 - drop dependency on glue helperArd Biesheuvel
Replace the glue helper dependency with implementations of ECB and CBC based on the new CPP macros, which avoid the need for indirect calls. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-14crypto: x86/cast5 - drop dependency on glue helperArd Biesheuvel
Replace the glue helper dependency with implementations of ECB and CBC based on the new CPP macros, which avoid the need for indirect calls. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-14crypto: x86/serpent - drop dependency on glue helperArd Biesheuvel
Replace the glue helper dependency with implementations of ECB and CBC based on the new CPP macros, which avoid the need for indirect calls. Acked-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit (git 2.34.1) at 2025-09-24 12:52:57 +0000