1. 23 May, 2021 1 commit
  2. 05 May, 2021 1 commit
    • Anshuman Khandual's avatar
      mm: generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS) · 855f9a8e
      Anshuman Khandual authored
      SYS_SUPPORTS_HUGETLBFS config has duplicate definitions on platforms
      that subscribe it.  Instead, just make it a generic option which can be
      selected on applicable platforms.
      Also rename it as ARCH_SUPPORTS_HUGETLBFS instead.  This reduces code
      duplication and makes it cleaner.
      Link: https://lkml.kernel.org/r/1617259448-22529-3-git-send-email-anshuman.khandual@arm.com
      Signed-off-by: Anshuman Khandual's avatarAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: Catalin Marinas <catalin.marinas@arm.com>	[arm64]
      Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>	[riscv]
      Acked-by: Michael Ellerman <mpe@ellerman.id.au>		[powerpc]
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 26 Apr, 2021 6 commits
    • Vitaly Wool's avatar
      RISC-V: enable XIP · 44c92257
      Vitaly Wool authored
      Introduce XIP (eXecute In Place) support for RISC-V platforms.
      It allows code to be executed directly from non-volatile storage
      directly addressable by the CPU, such as QSPI NOR flash which can
      be found on many RISC-V platforms. This makes way for significant
      optimization of RAM footprint. The XIP kernel is not compressed
      since it has to run directly from flash, so it will occupy more
      space on the non-volatile storage. The physical flash address used
      to link the kernel object files and for storing it has to be known
      at compile time and is represented by a Kconfig option.
      XIP on RISC-V will for the time being only work on MMU-enabled
      Signed-off-by: default avatarVitaly Wool <vitaly.wool@konsulko.com>
      [Alex: Rebase on top of "Move kernel mapping outside the linear mapping" ]
      Signed-off-by: default avatarAlexandre Ghiti <alex@ghiti.fr>
      [Palmer: disable XIP for allyesconfig]
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Nick Kossifidis's avatar
      RISC-V: Add crash kernel support · 56409750
      Nick Kossifidis authored
      This patch allows Linux to act as a crash kernel for use with
      kdump. Userspace will let the crash kernel know about the
      memory region it can use through linux,usable-memory property
      on the /memory node (overriding its reg property), and about the
      memory region where the elf core header of the previous kernel
      is saved, through a reserved-memory node with a compatible string
      of "linux,elfcorehdr". This approach is the least invasive and
      re-uses functionality already present.
      I tested this on riscv64 qemu and it works as expected, you
      may test it by retrieving the dmesg of the previous kernel
      through /proc/vmcore, using the vmcore-dmesg utility from
      Signed-off-by: default avatarNick Kossifidis <mick@ics.forth.gr>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Nick Kossifidis's avatar
      RISC-V: Add kexec support · fba8a867
      Nick Kossifidis authored
      This patch adds support for kexec on RISC-V. On SMP systems it depends
      on HOTPLUG_CPU in order to be able to bring up all harts after kexec.
      It also needs a recent OpenSBI version that supports the HSM extension.
      I tested it on riscv64 QEMU on both an smp and a non-smp system.
      Signed-off-by: default avatarNick Kossifidis <mick@ics.forth.gr>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Jisheng Zhang's avatar
      riscv: Set ARCH_HAS_STRICT_MODULE_RWX if MMU · a9451b8e
      Jisheng Zhang authored
      Now we can set ARCH_HAS_STRICT_MODULE_RWX for MMU riscv platforms, this
      is good from security perspective.
      Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Nathan Chancellor's avatar
      riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is available · adebc881
      Nathan Chancellor authored
      clang prior to 13.0.0 does not support -fpatchable-function-entry for
      clang: error: unsupported option '-fpatchable-function-entry=8' for target 'riscv64-unknown-linux-gnu'
      To avoid this error, only select HAVE_DYNAMIC_FTRACE when this option is
      not available.
      Fixes: afc76b8b ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT")
      Link: https://github.com/ClangBuiltLinux/linux/issues/1268
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarFangrui Song <maskray@google.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Vincent Chen's avatar
      riscv: Introduce alternative mechanism to apply errata solution · 6f4eea90
      Vincent Chen authored
      Introduce the "alternative" mechanism from ARM64 and x86 to apply the CPU
      vendors' errata solution at runtime. The main purpose of this patch is
      to provide a framework. Therefore, the implementation is quite basic for
      now so that some scenarios could not use this schemei, such as patching
      code to a module, relocating the patching code and heterogeneous CPU
      Users could use the macro ALTERNATIVE to apply an errata to the existing
      code flow. In the macro ALTERNATIVE, users need to specify the manufacturer
      information(vendorid, archid, and impid) for this errata. Therefore, kernel
      will know this errata is suitable for which CPU core. During the booting
      procedure, kernel will select the errata required by the CPU core and then
      patch it. It means that the kernel only applies the errata to the specified
      CPU core. In this case, the vendor's errata does not affect each other at
      runtime. The above patching procedure only occurs during the booting phase,
      so we only take the overhead of the "alternative" mechanism once.
      This "alternative" mechanism is enabled by default to ensure that all
      required errata will be applied. However, users can disable this feature by
      Signed-off-by: default avatarVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: default avatarAnup Patel <anup@brainfault.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
  4. 23 Apr, 2021 1 commit
    • Damien Le Moal's avatar
      riscv: Disable data start offset in flat binaries · 09accc3a
      Damien Le Moal authored
      uclibc/gcc combined with elf2flt riscv linker file fully resolve the
      PC relative __global_pointer$ value at compile time and do not generate
      a relocation entry to set a correct value of the gp register at runtime.
      As a result, if the flatbin loader offsets the start of the data
      section, the relative position change between the text and data sections
      compared to the compile time positions results in an incorrect gp value
      being used. This causes flatbin executables to crash.
      Avoid this problem by enabling CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET
      automatically when CONFIG_RISCV is enabled and CONFIG_MMU is disabled.
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Acked-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
  5. 16 Apr, 2021 1 commit
  6. 02 Apr, 2021 1 commit
  7. 17 Mar, 2021 2 commits
  8. 10 Mar, 2021 1 commit
  9. 27 Feb, 2021 1 commit
  10. 19 Feb, 2021 2 commits
  11. 03 Feb, 2021 1 commit
  12. 16 Jan, 2021 1 commit
  13. 14 Jan, 2021 7 commits
    • Guo Ren's avatar
      riscv: Enable per-task stack canaries · fea2fed2
      Guo Ren authored
      This enables the use of per-task stack canary values if GCC has
      support for emitting the stack canary reference relative to the
      value of tp, which holds the task struct pointer in the riscv
      After compare arm64 and x86 implementations, seems arm64's is more
      flexible and readable. The key point is how gcc get the offset of
      stack_canary from gs/el0_sp.
      x86: Use a fix offset from gs, not flexible.
      struct fixed_percpu_data {
      	 * GCC hardcodes the stack canary as %gs:40.  Since the
      	 * irq_stack is the object at %gs:0, we reserve the bottom
      	 * 48 bytes of the irq stack for the canary.
      	char            gs_base[40]; // :(
      	unsigned long   stack_canary;
      arm64: Use -mstack-protector-guard-offset & guard-reg
      	gcc options:
      riscv: Use -mstack-protector-guard-offset & guard-reg
      	gcc options:
       GCC's implementation has been merged:
       commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
       Author: Cooper Qu <cooper.qu@linux.alibaba.com>
       Date:   Mon Jul 13 16:15:08 2020 +0800
           RISC-V: Add support for TLS stack protector canary access
      In the end, these codes are inserted by gcc before return:
      *  0xffffffe00020b396 <+120>:   ld      a5,1008(tp) # 0x3f0
      *  0xffffffe00020b39a <+124>:   xor     a5,a5,a4
      *  0xffffffe00020b39c <+126>:   mv      a0,s5
      *  0xffffffe00020b39e <+128>:   bnez    a5,0xffffffe00020b61c <_do_fork+766>
         0xffffffe00020b3a2 <+132>:   ld      ra,136(sp)
         0xffffffe00020b3a4 <+134>:   ld      s0,128(sp)
         0xffffffe00020b3a6 <+136>:   ld      s1,120(sp)
         0xffffffe00020b3a8 <+138>:   ld      s2,112(sp)
         0xffffffe00020b3aa <+140>:   ld      s3,104(sp)
         0xffffffe00020b3ac <+142>:   ld      s4,96(sp)
         0xffffffe00020b3ae <+144>:   ld      s5,88(sp)
         0xffffffe00020b3b0 <+146>:   ld      s6,80(sp)
         0xffffffe00020b3b2 <+148>:   ld      s7,72(sp)
         0xffffffe00020b3b4 <+150>:   addi    sp,sp,144
         0xffffffe00020b3b6 <+152>:   ret
      *  0xffffffe00020b61c <+766>:   auipc   ra,0x7f8
      *  0xffffffe00020b620 <+770>:   jalr    -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Signed-off-by: default avatarCooper Qu <cooper.qu@linux.alibaba.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Guo Ren's avatar
      riscv: Add support for function error injection · ee55ff80
      Guo Ren authored
      Inspired by the commit 42d038c4
       ("arm64: Add support for function
      error injection"), this patch supports function error injection for
      This patch mainly support two functions: one is regs_set_return_value()
      which is used to overwrite the return value; the another function is
      override_function_with_return() which is to override the probed
      function returning and jump to its caller.
      Test log:
       cd /sys/kernel/debug/fail_function
       echo sys_clone > inject
       echo 100 > probability
       echo 1 > interval
       ls /
      [  313.176875] FAULT_INJECTION: forcing a failure.
      [  313.176875] name fail_function, interval 1, probability 100, space 0, times 1
      [  313.184357] CPU: 0 PID: 87 Comm: sh Not tainted 5.8.0-rc5-00007-g6a758cc #117
      [  313.187616] Call Trace:
      [  313.189100] [<ffffffe0002036b6>] walk_stackframe+0x0/0xc2
      [  313.191626] [<ffffffe00020395c>] show_stack+0x40/0x4c
      [  313.193927] [<ffffffe000556c60>] dump_stack+0x7c/0x96
      [  313.194795] [<ffffffe0005522e8>] should_fail+0x140/0x142
      [  313.195923] [<ffffffe000299ffc>] fei_kprobe_handler+0x2c/0x5a
      [  313.197687] [<ffffffe0009e2ec4>] kprobe_breakpoint_handler+0xb4/0x18a
      [  313.200054] [<ffffffe00020357e>] do_trap_break+0x36/0xca
      [  313.202147] [<ffffffe000201bca>] ret_from_exception+0x0/0xc
      [  313.204556] [<ffffffe000201bbc>] ret_from_syscall+0x0/0x2
      -sh: can't fork: Invalid argument
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Guo Ren's avatar
      riscv: Add uprobes supported · 74784081
      Guo Ren authored
      This patch adds support for uprobes on riscv architecture.
      Just like kprobe, it support single-step and simulate instructions.
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: default avatarPekka Enberg <penberg@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Guo Ren's avatar
      riscv: Add KPROBES_ON_FTRACE supported · 829adda5
      Guo Ren authored
      This patch adds support for kprobes on ftrace call sites to avoids
      much of the overhead with regular kprobes. Try it with simple
       echo 'p:myprobe sys_clone a0=%a0 a1=%a1 stack_val=+4($stack)' > /sys/kernel/de
       echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
       cat /sys/kernel/debug/tracing/trace
       tracer: nop
       entries-in-buffer/entries-written: 1/1   #P:1
                                      _-----=> irqs-off
                                     / _----=> need-resched
                                    | / _---=> hardirq/softirq
                                    || / _--=> preempt-depth
                                    ||| /     delay
                 TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
                    | |         |   ||||      |         |
                    sh-92      [000] ....   369.899962: myprobe: (sys_clone+0x0/0x28) a0=0x1200011 a1=0x0 stack_val=0x201c20ffffffe0
       cat /sys/kernel/debug/kprobes/list
      ffffffe00020b584  k  sys_clone+0x0    [FTRACE]
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Guo Ren's avatar
      riscv: Add kprobes supported · c22b0bcb
      Guo Ren authored
      This patch enables "kprobe & kretprobe" to work with ftrace
      interface. It utilized software breakpoint as single-step
      Some instructions which can't be single-step executed must be
      simulated in kernel execution slot, such as: branch, jal, auipc,
      la ...
      Some instructions should be rejected for probing and we use a
      blacklist to filter, such as: ecall, ebreak, ...
      We use ebreak & c.ebreak to replace origin instruction and the
      kprobe handler prepares an executable memory slot for out-of-line
      execution with a copy of the original instruction being probed.
      In execution slot we add ebreak behind original instruction to
      simulate a single-setp mechanism.
      The patch is based on packi's work [1] and csky's work [2].
       - The kprobes_trampoline.S is all from packi's patch
       - The single-step mechanism is new designed for riscv without hw
         single-step trap
       - The simulation codes are from csky
       - Frankly, all codes refer to other archs' implementation
       [1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1-me@packi.ch/
       [2] https://lore.kernel.org/linux-csky/20200403044150.20562-9-guoren@kernel.org/
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Co-developed-by: default avatarPatrick Stählin <me@packi.ch>
      Signed-off-by: default avatarPatrick Stählin <me@packi.ch>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: default avatarZong Li <zong.li@sifive.com>
      Reviewed-by: default avatarPekka Enberg <penberg@kernel.org>
      Cc: Patrick Stählin <me@packi.ch>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Björn Töpel <bjorn.topel@gmail.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Patrick Stählin's avatar
      RISC-V: Implement ptrace regs and stack API · dcdc7a53
      Patrick Stählin authored
      Needed for kprobes support. Copied and adapted from arm64 code.
      Guo Ren fixup pt_regs type for linux-5.8-rc1.
      Signed-off-by: default avatarPatrick Stählin <me@packi.ch>
      Signed-off-by: default avatarGuo Ren <guoren@linux.alibaba.com>
      Reviewed-by: default avatarPekka Enberg <penberg@kernel.org>
      Reviewed-by: default avatarZong Li <zong.li@sifive.com>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
    • Atish Patra's avatar
      riscv: Add numa support for riscv64 platform · 4f0e8eef
      Atish Patra authored
      Use the generic numa implementation to add NUMA support for RISC-V.
      This is based on Greentime's patch[1] but modified to use generic NUMA
      implementation and few more fixes.
      [1] https://lkml.org/lkml/2020/1/10/233
      Co-developed-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: default avatarAtish Patra <atish.patra@wdc.com>
      Reviewed-by: default avatarAnup Patel <anup@brainfault.org>
      Reviewed-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
  14. 15 Dec, 2020 1 commit
    • Mike Rapoport's avatar
      arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC · 5d6ad668
      Mike Rapoport authored
      The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must
      never fail.  With this assumption is wouldn't be safe to allow general
      usage of this function.
      Moreover, some architectures that implement __kernel_map_pages() have this
      function guarded by #ifdef DEBUG_PAGEALLOC and some refuse to map/unmap
      pages when page allocation debugging is disabled at runtime.
      As all the users of __kernel_map_pages() were converted to use
      debug_pagealloc_map_pages() it is safe to make it available only when
      DEBUG_PAGEALLOC is set.
      Link: https://lkml.kernel.org/r/20201109192128.960-4-rppt@kernel.org
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 11 Dec, 2020 1 commit
  16. 26 Nov, 2020 1 commit
  17. 21 Nov, 2020 1 commit
  18. 30 Oct, 2020 1 commit
    • Arnd Bergmann's avatar
      timekeeping: default GENERIC_CLOCKEVENTS to enabled · 0774a6ed
      Arnd Bergmann authored
      Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
      require each one to select that symbol manually.
      Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
      a simplification. It should be possible to select both
      GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now
      and decide at runtime between the two.
      For the clockevents arch-support.txt file, this means that additional
      architectures are marked as TODO when they have at least one machine
      that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when
      at least one machine has been converted. This means that both m68k and
      arm (for riscpc) revert to TODO.
      At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS
      rather than leaving it off when not needed. I built an m68k
      defconfig kernel (using gcc-10.1.0) and found that this would add
      around 5.5KB in kernel image size:
         text	   data	    bss	    dec	    hex	filename
      3861936	1092236	 196656	5150828	 4e986c	obj-m68k/vmlinux-no-clockevent
      3866201	1093832	 196184	5156217	 4ead79	obj-m68k/vmlinux-clockevent
      On Arm (MACH_RPC), that difference appears to be twice as large,
      around 11KB on top of an 6MB vmlinux.
      Reviewed-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  19. 08 Oct, 2020 1 commit
  20. 04 Oct, 2020 2 commits
  21. 02 Oct, 2020 3 commits
  22. 19 Sep, 2020 1 commit
  23. 09 Sep, 2020 1 commit
  24. 20 Aug, 2020 1 commit