- 05 1月, 2019 13 次提交
-
-
由 Christoph Hellwig 提交于
Some non-generic ia64 configs don't build swiotlb, and thus should not pull in the generic non-coherent DMA infrastructure. Fixes: 68c60834 ("swiotlb: remove dma_mark_clean") Reported-by: NTony Luck <tony.luck@gmail.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This has been broken forever, and nobody ever really noticed because it's purely a performance issue. Long long ago, in commit 6175ddf0 ("x86: Clean up mem*io functions") Brian Gerst simplified the memory copies to and from iomem, since on x86, the instructions to access iomem are exactly the same as the regular instructions. That is technically true, and things worked, and nobody said anything. Besides, back then the regular memcpy was pretty simple and worked fine. Nobody noticed except for David Laight, that is. David has a testing a TLP monitor he was writing for an FPGA, and has been occasionally complaining about how memcpy_toio() writes things one byte at a time. Which is completely unacceptable from a performance standpoint, even if it happens to technically work. The reason it's writing one byte at a time is because while it's technically true that accesses to iomem are the same as accesses to regular memory on x86, the _granularity_ (and ordering) of accesses matter to iomem in ways that they don't matter to regular cached memory. In particular, when ERMS is set, we default to using "rep movsb" for larger memory copies. That is indeed perfectly fine for real memory, since the whole point is that the CPU is going to do cacheline optimizations and executes the memory copy efficiently for cached memory. With iomem? Not so much. With iomem, "rep movsb" will indeed work, but it will copy things one byte at a time. Slowly and ponderously. Now, originally, back in 2010 when commit 6175ddf0 was done, we didn't use ERMS, and this was much less noticeable. Our normal memcpy() was simpler in other ways too. Because in fact, it's not just about using the string instructions. Our memcpy() these days does things like "read and write overlapping values" to handle the last bytes of the copy. Again, for normal memory, overlapping accesses isn't an issue. For iomem? It can be. So this re-introduces the specialized memcpy_toio(), memcpy_fromio() and memset_io() functions. It doesn't particularly optimize them, but it tries to at least not be horrid, or do overlapping accesses. In fact, this uses the existing __inline_memcpy() function that we still had lying around that uses our very traditional "rep movsl" loop followed by movsw/movsb for the final bytes. Somebody may decide to try to improve on it, but if we've gone almost a decade with only one person really ever noticing and complaining, maybe it's not worth worrying about further, once it's not _completely_ broken? Reported-by: NDavid Laight <David.Laight@aculab.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This actually enables the __put_user_goto() functionality in unsafe_put_user(). For an example of the effect of this, this is the code generated for the unsafe_put_user(signo, &infop->si_signo, Efault); in the waitid() system call: movl %ecx,(%rbx) # signo, MEM[(struct __large_struct *)_2] It's just one single store instruction, along with generating an exception table entry pointing to the Efault label case in case that instruction faults. Before, we would generate this: xorl %edx, %edx movl %ecx,(%rbx) # signo, MEM[(struct __large_struct *)_3] testl %edx, %edx jne .L309 with the exception table generated for that 'mov' instruction causing us to jump to a stub that set %edx to -EFAULT and then jumped back to the 'testl' instruction. So not only do we now get rid of the extra code in the normal sequence, we also avoid unnecessarily keeping that extra error register live across it all. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This is finally the actual reason for the odd error handling in the "unsafe_get/put_user()" functions, introduced over three years ago. Using a "jump to error label" interface is somewhat odd, but very convenient as a programming interface, and more importantly, it fits very well with simply making the target be the exception handler address directly from the inline asm. The reason it took over three years to actually do this? We need "asm goto" support for it, which only became the default on x86 last year. It's now been a year that we've forced asm goto support (see commit e501ce95 "x86: Force asm-goto"), and so let's just do it here too. [ Side note: this commit was originally done back in 2016. The above commentary about timing is obviously about it only now getting merged into my real upstream tree - Linus ] Sadly, gcc still only supports "asm goto" with asms that do not have any outputs, so we are limited to only the put_user case for this. Maybe in several more years we can do the get_user case too. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Helge Deller 提交于
The alternative coding patch for parisc in kernel 4.20 broke booting machines with PA8500-PA8700 CPUs. The problem is, that for such machines the parisc kernel automatically utilizes huge pages to access kernel text code, but the set_kernel_text_rw() function, which is used shortly before applying any alternative patches, didn't used the correctly hugepage-aligned addresses to remap the kernel text read-writeable. Fixes: 3847dab7 ("parisc: Add alternative coding infrastructure") Cc: <stable@vger.kernel.org> [4.20] Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Masahiro Yamada 提交于
Enable the UniPhier MIO DMAC driver. This is used as the DMA engine for accelerating the SD/eMMC controller drivers. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Davidlohr Bueso 提交于
This is already done for us internally by the signal machinery. Link: http://lkml.kernel.org/r/20181116002713.8474-4-dave@stgolabs.netSigned-off-by: NDavidlohr Bueso <dave@stgolabs.net> Reviewed-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joel Fernandes (Google) 提交于
Moving page-tables at the PMD-level on x86 is known to be safe. Enable this option so that we can do fast mremap when possible. Link: http://lkml.kernel.org/r/20181108181201.88826-4-joelaf@google.comSigned-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org> Suggested-by: NKirill A. Shutemov <kirill@shutemov.name> Acked-by: NKirill A. Shutemov <kirill@shutemov.name> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Michal Hocko <mhocko@kernel.org> Cc: William Kucharski <william.kucharski@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joel Fernandes (Google) 提交于
Android needs to mremap large regions of memory during memory management related operations. The mremap system call can be really slow if THP is not enabled. The bottleneck is move_page_tables, which is copying each pte at a time, and can be really slow across a large map. Turning on THP may not be a viable option, and is not for us. This patch speeds up the performance for non-THP system by copying at the PMD level when possible. The speedup is an order of magnitude on x86 (~20x). On a 1GB mremap, the mremap completion times drops from 3.4-3.6 milliseconds to 144-160 microseconds. Before: Total mremap time for 1GB data: 3521942 nanoseconds. Total mremap time for 1GB data: 3449229 nanoseconds. Total mremap time for 1GB data: 3488230 nanoseconds. After: Total mremap time for 1GB data: 150279 nanoseconds. Total mremap time for 1GB data: 144665 nanoseconds. Total mremap time for 1GB data: 158708 nanoseconds. If THP is enabled the optimization is mostly skipped except in certain situations. [joel@joelfernandes.org: fix 'move_normal_pmd' unused function warning] Link: http://lkml.kernel.org/r/20181108224457.GB209347@google.com Link: http://lkml.kernel.org/r/20181108181201.88826-3-joelaf@google.comSigned-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org> Acked-by: NKirill A. Shutemov <kirill@shutemov.name> Reviewed-by: NWilliam Kucharski <william.kucharski@oracle.com> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Michal Hocko <mhocko@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joel Fernandes (Google) 提交于
Patch series "Add support for fast mremap". This series speeds up the mremap(2) syscall by copying page tables at the PMD level even for non-THP systems. There is concern that the extra 'address' argument that mremap passes to pte_alloc may do something subtle architecture related in the future that may make the scheme not work. Also we find that there is no point in passing the 'address' to pte_alloc since its unused. This patch therefore removes this argument tree-wide resulting in a nice negative diff as well. Also ensuring along the way that the enabled architectures do not do anything funky with the 'address' argument that goes unnoticed by the optimization. Build and boot tested on x86-64. Build tested on arm64. The config enablement patch for arm64 will be posted in the future after more testing. The changes were obtained by applying the following Coccinelle script. (thanks Julia for answering all Coccinelle questions!). Following fix ups were done manually: * Removal of address argument from pte_fragment_alloc * Removal of pte_alloc_one_fast definitions from m68k and microblaze. // Options: --include-headers --no-includes // Note: I split the 'identifier fn' line, so if you are manually // running it, please unsplit it so it runs for you. virtual patch @pte_alloc_func_def depends on patch exists@ identifier E2; identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; type T2; @@ fn(... - , T2 E2 ) { ... } @pte_alloc_func_proto_noarg depends on patch exists@ type T1, T2, T3, T4; identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; @@ ( - T3 fn(T1, T2); + T3 fn(T1); | - T3 fn(T1, T2, T4); + T3 fn(T1, T2); ) @pte_alloc_func_proto depends on patch exists@ identifier E1, E2, E4; type T1, T2, T3, T4; identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; @@ ( - T3 fn(T1 E1, T2 E2); + T3 fn(T1 E1); | - T3 fn(T1 E1, T2 E2, T4 E4); + T3 fn(T1 E1, T2 E2); ) @pte_alloc_func_call depends on patch exists@ expression E2; identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; @@ fn(... -, E2 ) @pte_alloc_macro depends on patch exists@ identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$"; identifier a, b, c; expression e; position p; @@ ( - #define fn(a, b, c) e + #define fn(a, b) e | - #define fn(a, b) e + #define fn(a) e ) Link: http://lkml.kernel.org/r/20181108181201.88826-2-joelaf@google.comSigned-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org> Suggested-by: NKirill A. Shutemov <kirill@shutemov.name> Acked-by: NKirill A. Shutemov <kirill@shutemov.name> Cc: Michal Hocko <mhocko@kernel.org> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: William Kucharski <william.kucharski@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Matthew Wilcox 提交于
When testing in userspace, UBSAN pointed out that shifting into the sign bit is undefined behaviour. It doesn't really make sense to ask for the highest set bit of a negative value, so just turn the argument type into an unsigned int. Some architectures (eg ppc) already had it declared as an unsigned int, so I don't expect too many problems. Link: http://lkml.kernel.org/r/20181105221117.31828-1-willy@infradead.orgSigned-off-by: NMatthew Wilcox <willy@infradead.org> Acked-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Originally, the rule used to be that you'd have to do access_ok() separately, and then user_access_begin() before actually doing the direct (optimized) user access. But experience has shown that people then decide not to do access_ok() at all, and instead rely on it being implied by other operations or similar. Which makes it very hard to verify that the access has actually been range-checked. If you use the unsafe direct user accesses, hardware features (either SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged Access Never - on ARM) do force you to use user_access_begin(). But nothing really forces the range check. By putting the range check into user_access_begin(), we actually force people to do the right thing (tm), and the range check vill be visible near the actual accesses. We have way too long a history of people trying to avoid them. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
These two architectures actually had an intentional use of the 'type' argument to access_ok() just to avoid warnings. I had actually noticed the powerpc one, but forgot to then fix it up. And I missed the sparc32 case entirely. This is hopefully all of it. Reported-by: NMathieu Malaterre <malat@debian.org> Reported-by: NGuenter Roeck <linux@roeck-us.net> Fixes: 96d4f267 ("Remove 'type' argument from access_ok() function") Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 1月, 2019 10 次提交
-
-
由 Will Deacon 提交于
Commit 73aeb2cb ("ARM: 8787/1: wire up io_pgetevents syscall") hooked up the io_pgetevents() system call for 32-bit ARM, so we can do the same for the compat wrapper on arm64. Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Will Deacon 提交于
The syscall number may have been changed by a tracer, so we should pass the actual number in from the caller instead of pulling it from the saved r7 value directly. Cc: <stable@vger.kernel.org> Cc: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Will Deacon 提交于
The ARM Linux kernel handles the EABI syscall numbers as follows: 0 - NR_SYSCALLS-1 : Invoke syscall via syscall table NR_SYSCALLS - 0xeffff : -ENOSYS (to be allocated in future) 0xf0000 - 0xf07ff : Private syscall or -ENOSYS if not allocated > 0xf07ff : SIGILL Our compat code gets this wrong and ends up sending SIGILL in response to all syscalls greater than NR_SYSCALLS which have a value greater than 0x7ff in the bottom 16 bits. Fix this by defining the end of the ARM private syscall region and checking the syscall number against that directly. Update the comment while we're at it. Cc: <stable@vger.kernel.org> Cc: Dave Martin <Dave.Martin@arm.com> Reported-by: NPi-Hsun Shih <pihsun@chromium.org> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Dave Martin 提交于
Currently, <uapi/asm/sigcontext.h> provides common definitions for describing SVE context structures that are also used by the ptrace definitions in <uapi/asm/ptrace.h>. For this reason, a #include of <asm/sigcontext.h> was added in ptrace.h, but it this turns out that this can interact badly with userspace code that tries to include ptrace.h on top of the libc headers (which may provide their own shadow definitions for sigcontext.h). To make the headers easier for userspace to consume, this patch bounces the common definitions into an __SVE_* namespace and moves them to a backend header <uapi/asm/sve_context.h> that can be included by the other headers as appropriate. This should allow ptrace.h to be used alongside libc's sigcontext.h (if any) without ill effects. This should make the situation unambiguous: <asm/sigcontext.h> is the header to include for the sigframe-specific definitions, while <asm/ptrace.h> is the header to include for ptrace-specific definitions. To avoid conflicting with existing usage, <asm/sigcontext.h> remains the canonical way to get the common definitions for SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the kernel: relying on these being defined as a side effect of including just <asm/ptrace.h> was never intended to be safe. Signed-off-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Dave Martin 提交于
SVE_PT_REGS_OFFSET is supposed to indicate the offset for skipping over the ptrace NT_ARM_SVE header (struct user_sve_header) to the start of the SVE register data proper. However, currently SVE_PT_REGS_OFFSET is defined in terms of struct sve_context, which is wrong: that structure describes the SVE header in the signal frame, not in the ptrace regset. This patch fixes the definition to use the ptrace header structure struct user_sve_header instead. By good fortune, the two structures are the same size anyway, so there is no functional or ABI change. Signed-off-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Mathieu Malaterre 提交于
In commit 05a4ab82 ("powerpc/uaccess: fix warning/error with access_ok()") an attempt was made to remove a warning by referencing the variable `type`. However in commit 96d4f267 ("Remove 'type' argument from access_ok() function") the variable `type` has been removed, breaking the build: arch/powerpc/include/asm/uaccess.h:66:32: error: ‘type’ undeclared (first use in this function) This essentially reverts commit 05a4ab82 ("powerpc/uaccess: fix warning/error with access_ok()") to fix the error. Fixes: 96d4f267 ("Remove 'type' argument from access_ok() function") Signed-off-by: NMathieu Malaterre <malat@debian.org> [mpe: Reword change log slightly.] Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Masahiro Yamada 提交于
Use the standard obj-$(CONFIG_...) syntex. The behavior is still the same. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Linus Torvalds 提交于
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Yueyi Li 提交于
When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), the top 4K of kernel virtual address space may be mapped to physical addresses despite being reserved for ERR_PTR values. Fix the randomization of the linear region so that we avoid mapping the last page of the virtual address space. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Nliyueyi <liyueyi@live.com> [will: rewrote commit message; merged in suggestion from Ard] Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Mark Rutland 提交于
In commit: 3b714275 ("arm64: convert native/compat syscall entry to C") ... we moved the syscall invocation code from assembly to C, but left behind a number of register aliases which are now unused. Let's remove them before they confuse someone. Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: NDave Martin <Dave.Martin@arm.com> Signed-off-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
- 03 1月, 2019 1 次提交
-
-
由 Shaokun Zhang 提交于
For arm64: updates for 4.21, there is a compilation error: arch/arm64/kernel/head.S: Assembler messages: arch/arm64/kernel/head.S:824: Error: missing ')' arch/arm64/kernel/head.S:824: Error: missing ')' arch/arm64/kernel/head.S:824: Error: missing ')' arch/arm64/kernel/head.S:824: Error: unexpected characters following instruction at operand 2 -- `mov x2,#(2)|(2U<<(8))' scripts/Makefile.build:391: recipe for target 'arch/arm64/kernel/head.o' failed make[1]: *** [arch/arm64/kernel/head.o] Error 1 GCC version is gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 Let's fix it using the UL() macro. Fixes: 66f16a24 ("arm64: smp: Rework early feature mismatched detection") Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Tested-by: NJohn Stultz <john.stultz@linaro.org> Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com> [will: consistent use of UL() for all shifts in asm constants] Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
- 02 1月, 2019 1 次提交
-
-
由 Guo Ren 提交于
This adds basic perf support for all C-SKY CPUs. Hardware events are only supported by 807/810/860. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
- 01 1月, 2019 7 次提交
-
-
由 Stefan Wahren 提交于
The bcm2835-thermal driver was added with commit ac178e42 ("ARM64: bcm2835: add thermal driver to default config"). Unfortunately this was accidentally dropped by commit eb1e6716 ("arm64: defconfig: sync with savedefconfig"). So enable the driver again. Fixes: eb1e6716 ("arm64: defconfig: sync with savedefconfig") Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Manivannan Sadhasivam 提交于
Add interrupt support for UART in RDA Micro RDA8810PL SoC. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Manivannan Sadhasivam 提交于
Add timer support for RDA Micro RDA8810PL SoC. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Manivannan Sadhasivam 提交于
Add initial devicetree for Orange Pi i96 board from Xunlong. It is one of the 96Boards IoT Edition board. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Manivannan Sadhasivam 提交于
Add initial devicetree support for OrangePi 2G IoT board from Xunlong. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Manivannan Sadhasivam 提交于
Add initial device tree for RDA8810PL SoC from RDA Microelectronics. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Andreas Färber 提交于
Introduce ARCH_RDA and mach-rda for RDA Micro SoCs. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 31 12月, 2018 8 次提交
-
-
由 Guo Ren 提交于
C-SKY historically used 39, the same value as MCORE, from which the architecture was derived. C-SKY binutils support both EM_CSKY and EM_CSKY_OLD, confirmed by binutils:include/elf/common.h Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
With csky-gcc -pg -mbacktrace, ftrace call graph supported. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
When gcc with -pg, it'll add _mcount stub in every function. We need implement the _mcount in kernel and ftrace depends on stackstrace. To do: call-graph, dynamic ftrace Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
Cleanup struct cpuinfo_csky and struct thread_struct, remove all esp0 related code. We could get pt_regs from sp and backtrace could use fp in switch_stack. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
Use STACKTRACE to optimize panic print more pretty and align registers printing. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
The gcc option "-mbacktrace" will push fp(r8),lr into stack and we could unwind the stack with: fp = *fp lr = (unsigned int *)fp[1] Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
This is a simple implement of CPU-hotplug for power saving. CPU use wait instruction to enter power saving mode and waiting for IPI wakeup signal. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-
由 Guo Ren 提交于
HI, LO, DSPCR registers are 807/810 related regs and no need for 610/860. All of the regs must be saved in pt_regs and switch_stack. This patch fixup saving dspcr reg in switch_stack and pt_regs. Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
-