Skip to content
  1. Apr 30, 2021
  2. Apr 09, 2021
  3. Mar 27, 2021
  4. Mar 23, 2021
  5. Feb 25, 2021
  6. Feb 22, 2021
  7. Dec 29, 2020
  8. Dec 15, 2020
  9. Dec 12, 2020
  10. Nov 13, 2020
  11. Nov 06, 2020
  12. Oct 30, 2020
    • 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>
      0774a6ed
  13. Oct 27, 2020
  14. Oct 26, 2020
  15. Oct 17, 2020
  16. Oct 14, 2020
    • Mike Rapoport's avatar
      h8300, nds32, openrisc: simplify detection of memory extents · 80c45744
      Mike Rapoport authored
      
      
      Instead of traversing memblock.memory regions to find memory_start and
      memory_end, simply query memblock_{start,end}_of_DRAM().
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarStafford Horne <shorne@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Daniel Axtens <dja@axtens.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Emil Renner Berthing <kernel@esmil.dk>
      Cc: Hari Bathini <hbathini@linux.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Link: https://lkml.kernel.org/r/20200818151634.14343-6-rppt@kernel.org
      
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      80c45744
  17. Oct 06, 2020
  18. Sep 09, 2020
  19. Sep 07, 2020
  20. Sep 01, 2020
  21. Aug 26, 2020
  22. Aug 23, 2020
  23. Aug 12, 2020
  24. Aug 07, 2020
  25. Jul 27, 2020
  26. Jul 04, 2020
  27. Jun 17, 2020
  28. Jun 09, 2020
Loading