aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-04-11x86/fpu: Inline copy_user_to_fpregs_zeroing()Sebastian Andrzej Siewior1-1/+19
Start refactoring __fpu__restore_sig() by inlining copy_user_to_fpregs_zeroing(). The original function remains and will be used to restore from userland memory if possible. 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: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.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-21-bigeasy@linutronix.de
2019-04-11x86/fpu: Update xstate's PKRU value on write_pkru()Sebastian Andrzej Siewior1-2/+19
During the context switch the xstate is loaded which also includes the PKRU value. If xstate is restored on return to userland it is required that the PKRU value in xstate is the same as the one in the CPU. Save the PKRU in xstate during modification. 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-20-bigeasy@linutronix.de
2019-04-11arm64: vdso: use $(LD) instead of $(CC) to link VDSOMasahiro Yamada1-10/+3
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-11arm64: perf_event: Remove wrongfully used inlineRaphael Gault1-2/+2
The functions armv8pmu_read_counter() and armv8pmu_write_counter() are `static inline` while they are only referenced when assigned to a function pointer field in a `struct arm_pmu` instance. The inline keyword is thus counter intuitive and shouldn't be used. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Raphael Gault <raphael.gault@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-11x86/fpu: Prepare copy_fpstate_to_sigframe() for TIF_NEED_FPU_LOADRik van Riel1-1/+11
The FPU registers need only to be saved if TIF_NEED_FPU_LOAD is not set. Otherwise this has been already done and can be skipped. [ bp: Massage a bit. ] 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: Andy Lutomirski <luto@kernel.org> 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: 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-19-bigeasy@linutronix.de
2019-04-11x86/fpu: Always store the registers in copy_fpstate_to_sigframe()Rik van Riel1-5/+14
copy_fpstate_to_sigframe() stores the registers directly to user space. This is okay because the FPU registers are valid and saving them directly avoids saving them into kernel memory and making a copy. However, this cannot be done anymore if the FPU registers are going to be restored on the return to userland. It is possible that the FPU registers will be invalidated in the middle of the save operation and this should be done with disabled preemption / BH. Save the FPU registers to the task's FPU struct and copy them to the user memory later on. 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: Andy Lutomirski <luto@kernel.org> 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: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-18-bigeasy@linutronix.de
2019-04-11x86/entry: Add TIF_NEED_FPU_LOADSebastian Andrzej Siewior2-0/+10
Add TIF_NEED_FPU_LOAD. This flag is used for loading the FPU registers before returning to userland. It must not be set on systems without a FPU. If this flag is cleared, the CPU's FPU registers hold the latest, up-to-date content of the current task's (current()) FPU registers. The in-memory copy (union fpregs_state) is not valid. If this flag is set, then all of CPU's FPU registers may hold a random value (except for PKRU) and it is required to load the content of the FPU registers on return to userland. Introduce it now as a preparatory change before adding the main feature. 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: 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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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: Tim Chen <tim.c.chen@linux.intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-17-bigeasy@linutronix.de
2019-04-11x86/fpu: Eager switch PKRU stateRik van Riel4-4/+31
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 Siewior1-7/+0
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 Siewior1-0/+7
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 Siewior3-5/+11
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 Suzuki1-2/+2
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 Stuebner40-827/+827
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 Stuebner24-473/+473
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. Papadakos1-0/+16
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. Papadakos1-0/+5
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 Kaehlcke1-3/+10
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 Bergmann1-0/+5
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 Perches3-7/+7
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 Bergmann1-1/+2
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 Bergmann1-3/+3
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 Bergmann1-2/+2
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 Bergmann3-6/+9
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 Bergmann1-1/+1
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 Schwidefsky1-9/+9
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 Kaehlcke1-4/+0
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é1-0/+7
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é1-0/+21
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é1-0/+138
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é1-0/+29
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é1-0/+1
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 Fernandez1-0/+4
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 Paillet1-8/+150
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 Paillet1-16/+140
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 Moysan1-0/+13
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 Moysan1-0/+13
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 Gasnier1-0/+13
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 Gasnier1-0/+13
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 Gasnier1-0/+1
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 Dessenne1-0/+4
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 Dessenne1-0/+4
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 Dessenne1-0/+15
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 Barre1-0/+20
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 Barre2-0/+105
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 Barre1-0/+14
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 Barre1-0/+20
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 Barre2-1/+90
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 Barre1-0/+14
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 Huang1-0/+15
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 Stach1-2/+2
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>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.