summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-04-11x86/fpu: Eager switch PKRU stateRik van Riel
While most of a task's FPU state is only needed in user space, the protection keys need to be in place immediately after a context switch. The reason is that any access to userspace memory while running in kernel mode also needs to abide by the memory permissions specified in the protection keys. The "eager switch" is a preparation for loading the FPU state on return to userland. Instead of decoupling PKRU state from xstate, update PKRU within xstate on write operations by the kernel. For user tasks the PKRU should be always read from the xsave area and it should not change anything because the PKRU value was loaded as part of FPU restore. For kernel threads the default "init_pkru_value" will be written. Before this commit, the kernel thread would end up with a random value which it inherited from the previous user task. [ bigeasy: save pkru to xstate, no cache, don't use __raw_xsave_addr() ] [ bp: update commit message, sort headers properly in asm/fpu/xstate.h ] Signed-off-by: Rik van Riel <riel@surriel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aubrey Li <aubrey.li@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Juergen Gross <jgross@suse.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-16-bigeasy@linutronix.de
2019-04-11x86/pkeys: Don't check if PKRU is zero before writing itSebastian Andrzej Siewior
write_pkru() checks if the current value is the same as the expected value. So instead of just checking if the current and new value is zero (and skip the write in such a case) we can benefit from that. Remove the zero check of PKRU, __write_pkru() provides such a check now. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-15-bigeasy@linutronix.de
2019-04-11x86/fpu: Only write PKRU if it is different from currentSebastian Andrzej Siewior
According to Dave Hansen, WRPKRU is more expensive than RDPKRU. It has a higher cycle cost and it's also practically a (light) speculation barrier. As an optimisation read the current PKRU value and only write the new one if it is different. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Juergen Gross <jgross@suse.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-14-bigeasy@linutronix.de
2019-04-11x86/pkeys: Provide *pkru() helpersSebastian Andrzej Siewior
Dave Hansen asked for __read_pkru() and __write_pkru() to be symmetrical. As part of the series __write_pkru() will read back the value and only write it if it is different. In order to make both functions symmetrical, move the function containing only the opcode asm into a function called like the instruction itself. __write_pkru() will just invoke wrpkru() but in a follow-up patch will also read back the value. [ bp: Convert asm opcode wrapper names to rd/wrpkru(). ] Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Juergen Gross <jgross@suse.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-13-bigeasy@linutronix.de
2019-04-11arm64: dts: rockchip: fix cts, rts pin assign of UART3 for rk3399Katsuhiro Suzuki
This patch fixes pin assign of cts and rts signal of UART3. Currently GPIO3_C2 and C3 pins are assigned but TRM says that GPIO3_C0 and C1 are correct. Refer: RK3399 TRM v1.4 - Table 19-1 UART Interface Description Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11ARM: dts: rockchip: bulk convert gpios to their constant counterpartsHeiko Stuebner
Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11arm64: dts: rockchip: bulk convert gpios to their constant counterpartsHeiko Stuebner
Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-11arm64: dts: rockchip: enable display nodes on rk3328-roc-ccLeonidas P. Papadakos
Enable necessary nodes to get output on the hdmi port of the board. This is a port of Heiko's patch for the rock64. Signed-off-by: Leonidas P. Papadakos <papadakospan@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11arm64: dts: rockchip: eMMC additions for rk3328-roc-ccLeonidas P. Papadakos
The eMMC 5.x that Libre Computer provide for their boards supports HS200 mode. The support is already included in the dts for their newest board: La Frite (AML-S805X-AC) dts: arch/arm64/boot/dts/amlogic/meson-gxl-s805x-libretech-ac.dts That same eMMC is supported in the ROC-RK3328-CC: https://www.loverpi.com/products/libre-computer-board-emmc-5-x-module This increases the speed of the eMMC significantly. Signed-off-by: Leonidas P. Papadakos <papadakospan@gmail.com> [added supplies as suggested by Leonidas] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11ARM: dts: rockchip: Add BT_EN to the power sequence for veyronMatthias Kaehlcke
Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the Bluetooth/WiFi module. On devices with a Broadcom module the signal needs to be asserted to use Bluetooth. Note that BT_ENABLE_L is a misnomer in the schematics, the signal actually is active-high. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11s390: avoid __builtin_return_address(n) on clangArnd Bergmann
llvm on s390 has problems with __builtin_return_address(n), with n>0, this results in a somewhat cryptic error message: fatal error: error in backend: Unsupported stack frame traversal count To work around it, use the direct return address directly. This is probably not ideal here, but gets things to compile and should only lead to inferior reporting, not to misbehavior of the generated code. Link: https://bugs.llvm.org/show_bug.cgi?id=41424 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: Convert IS_ENABLED uses to __is_definedJoe Perches
IS_ENABLED should be reserved for CONFIG_<FOO> uses so convert the uses of IS_ENABLED with a #define to __is_defined. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: make chkbss work with clangArnd Bergmann
llvm skips an empty .bss section entirely, which makes the check fail with an unexpected error: /tmp/binutils-multi-test/bin/s390x-linux-gnu-objdump: section '.bss' mentioned in a -j option, but not found in any input file error: arch/s390/boot/compressed/decompressor.o .bss section is not empty ../arch/s390/scripts/Makefile.chkbss:20: recipe for target 'arch/s390/boot/compressed/decompressor.o.chkbss' failed Change the check so we first see if a .bss section exists before trying to read its size. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: make __load_psw_mask work with clangArnd Bergmann
clang fails to use the %O and %R inline assembly modifiers the same way as gcc, leading to build failures with every use of __load_psw_mask(): /tmp/nmi-4a9f80.s: Assembler messages: /tmp/nmi-4a9f80.s:571: Error: junk at end of line: `+8(160(%r11))' /tmp/nmi-4a9f80.s:626: Error: junk at end of line: `+8(160(%r11))' Replace these with a more conventional way of passing the addresses that should work with both clang and gcc. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: syscall_wrapper: avoid clang warningArnd Bergmann
Building system calls with clang results in a warning about an alias from a global function to a static one: ../fs/namei.c:3847:1: warning: unused function '__se_sys_mkdirat' [-Wunused-function] SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode) ^ ../include/linux/syscalls.h:219:36: note: expanded from macro 'SYSCALL_DEFINE3' #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__) ^ ../include/linux/syscalls.h:228:2: note: expanded from macro 'SYSCALL_DEFINEx' __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) ^ ../arch/s390/include/asm/syscall_wrapper.h:126:18: note: expanded from macro '__SYSCALL_DEFINEx' asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \ ^ <scratch space>:31:1: note: expanded from here __se_sys_mkdirat ^ The only reference to the static __se_sys_mkdirat() here is the alias, but this only gets evaluated later. Making this function global as well avoids the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: don't build vdso32 with clangArnd Bergmann
clang does not support 31 bit object files on s390, so skip the 32-bit vdso here, and only build it when using gcc to compile the kernel. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: remove -fno-strength-reduce flagArnd Bergmann
This was added as a workaround for really old compilers, and it prevents building with clang now. I can see no reason for keeping it, as it has already been removed for most architectures in the pre-git era, so let's remove it everywhere, rather than only for clang. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11s390: fine-tune stack switch helperMartin Schwidefsky
The CALL_ON_STACK helper currently does not work with clang and for calls without arguments. It does not initialize r2 although the constraint is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work with clang and produce optimal code in all cases. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-11ARM: dts: rockchip: Remove unnecessary setting of UART0 SCLK rate on veyronMatthias Kaehlcke
Some veyron devices have a Bluetooth controller connected on UART0. The UART needs to operate at a high speed, however setting the clock rate at initialization has no practical effect. During initialization user space adjusts the UART baudrate multiple times, which ends up changing the SCLK rate. After a successful initiatalization the clk is running at the desired speed (48MHz). Remove the unnecessary clock rate configuration from the DT. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-11ARM: dts: stm32: enable cec on stm32mp157a-dk1 boardYannick Fertré
Enable CEC (Consumer Electronics Control) device. Signed-off-by: Yannick Fertré <yannick.fertre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add cec pins muxing on stm32mp157Yannick Fertré
Add a new pin muxing for cec. Signed-off-by: Yannick Fertré <yannick.fertre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add ltdc pins muxing on stm32mp157Yannick Fertré
Add ltdc pins muxing on stm32mp157. Signed-off-by: Yannick Fertré <yannick.fertre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add I2C sleep pins muxing on stm32mp157Yannick Fertré
Add I2C sleep pins muxing for low power mode. Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by: Yannick Fertré <yannick.fertre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add power supply of otm8009a on stm32mp157c-dk2Yannick Fertré
This patch adds a new property (power-supply) to panel otm8009a (orisetech) on stm32mp157c-dk2 & regulator v3v3. Signed-off-by: Yannick Fertré <yannick.fertre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: Enable STM32F769 clock driverGabriel Fernandez
This patch enables clocks for STM32F769 boards. Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add stpmic1 support on stm32mp157a dk1 boardPascal Paillet
This patch adds stpmic1 support on stm32mp157a dk1 board. The STPMIC1 is a PMIC from STMicroelectronics. The STPMIC1 integrates 10 regulators, 3 power switches, a watchdog and an input for a power on key. The DMAs are disabled because the PMIC generates a very few traffic and DMA channels may lack for other usage. Signed-off-by: Pascal Paillet <p.paillet@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add stpmic1 support on stm32mp157c ed1 boardPascal Paillet
This patch adds stpmic1 support on stm32mp157c ed1 board. The STPMIC1 is a PMIC from STMicroelectronics. The STPMIC1 integrates 10 regulators, 3 power switches, a watchdog and an input for a power on key. The DMAs are disabled because the PMIC generates a very few traffic and DMA channels may lack for other usage. Signed-off-by: Pascal Paillet <p.paillet@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add spdfirx pins to stm32mp157cOlivier Moysan
This patch adds spdifrx support on stm32mp157c eval board. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add spdifrx support on stm32mp157cOlivier Moysan
This patch adds support of STM32 SPDIFRX on stm32mp157c. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: Add romem and temperature calibration on stm32f429Fabrice Gasnier
Add & enable stm32 factory-programmed memory. Describe temperature sensor calibration cells. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: Add romem and temperature calibration on stm32mp157cFabrice Gasnier
Add & enable stm32 factory-programmed memory. Describe temperature sensor calibration cells. Non-volatile calibration data is made available by stm32mp157c bootrom in bsec_dataX registers. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: Add clock on stm32mp157c syscfgFabrice Gasnier
STM32 syscfg needs a clock to access registers. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: enable IPCC mailbox support on STM32MP157a-dk1Fabien Dessenne
Enable STM32 IPCC mailbox driver for STM32MP157a-dk1 board. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: enable IPCC mailbox support on STM32MP157c-ed1Fabien Dessenne
Enable STM32 IPCC mailbox driver for STM32MP157c-ed1 board. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add IPCC mailbox support on STM32MP157cFabien Dessenne
Add configuration on DT for IPCC mailbox driver. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32mp157a dk1 boardLudovic Barre
This patch adds sdmmc1 support on stm32mp157a dk1 board. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32mp157c ed1 boardLudovic Barre
This patch adds sdmmc1 support on stm32mp157c ed1 board. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32mp157cLudovic Barre
This patch adds support of sdmmc1 on stm32mp157c. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32h743i disco boardLudovic Barre
This patch adds sdmmc1 support on stm32h743i disco board. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32h743i eval boardLudovic Barre
This patch adds sdmmc1 support on stm32h743i eval board. This board has an external driver to control signal direction polarity. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: stm32: add sdmmc1 support on stm32h743Ludovic Barre
This patch adds support of sdmmc1 on stm32h743. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2019-04-11ARM: dts: imx6dl-sabreauto: update opp table for auto partAnson Huang
Update i.MX6DL automotive part's opp table according to i.MX6DL automotive datasheet Rev.9, 11/2018, it adds 996MHz set-point support as below: LDO enabled(min value): 996MHz: VDDARM: 1.275V, VDDSOC: 1.175V; 792MHz: VDDARM: 1.150V, VDDSOC: 1.150V; 396MHz: VDDARM: 1.125V, VDDSOC: 1.150V; Adding 25mV to cover board IR drop, for LDO enabled mode of 996MHz, as the max value of LDO output can NOT exceed 1.3V, so 25mV is NOT added for VDDARM. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq: fix higher CPU operating pointLucas Stach
According to the datasheet both industrial and consumer variants support at least 1.3GHz CPU frequency at 1.0V. Only the OPP at 1.5GHz is unavailable on some SKUs and thus need further fuse reading support. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq-evk: Enable PCIE0 interfaceAndrey Smirnov
Enable PCIE0 interface connected to BCM4356 WiFi/Bluetooth module. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq: Add nodes for PCIe IP blocksAndrey Smirnov
Add nodes for two PCIe controllers found on i.MX8MQ. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq: Combine PCIE power domainsAndrey Smirnov
According to NXP's FAE feedback and a comment in ATF firmware, PCIE1 and PCIE2 power domains can't really be used independently. Due to shared reset line both power domains have to be turned on at the same time. Account for that quirk by combining PCIE power domains into a single 'pgc_pcie' power domain. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq: Add a node for SRC IP blockAndrey Smirnov
Add a node for reset controller IP block found on i.MX8MQ. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8mq: Mark iomuxc_gpr as i.MX6Q compatibleAndrey Smirnov
Mark iomuxc_gpr as compatible with "fsl,imx6q-iomuxc-gpr" in order for to allow i.MX6 PCIe driver to use it. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Acked-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: "A.s. Dong" <aisheng.dong@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11arm64: dts: imx8qxp: Add lpuart1/lpuart2/lpuart3 nodesDaniel Baluta
lpuart nodes are part of the ADMA subsystem. See Audio DMA memory map in iMX8 QXP RM [1] This patch is based on the dtsi file initially submitted by Teo Hall in i.MX NXP internal tree. [1] https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf Signed-off-by: Teo Hall <teo.hall@nxp.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-04-11ARM: dts: imx: Use generic node names for Zii dtsFabio Estevam
The devicetree specification recommends using generic node names. Some Zii dts files already follow such recommendation, but some don't, so use generic node names for consistency among the Zii dts files. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>