1. 25 11月, 2021 1 次提交
  2. 16 8月, 2021 1 次提交
  3. 12 8月, 2021 1 次提交
  4. 30 7月, 2021 2 次提交
  5. 26 5月, 2021 2 次提交
  6. 01 5月, 2021 1 次提交
  7. 05 4月, 2021 3 次提交
  8. 29 1月, 2021 1 次提交
  9. 07 11月, 2020 1 次提交
  10. 31 10月, 2020 1 次提交
    • A
      timekeeping: default GENERIC_CLOCKEVENTS to enabled · 0774a6ed
      Arnd Bergmann 提交于
      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: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      0774a6ed
  11. 09 10月, 2020 1 次提交
  12. 09 9月, 2020 1 次提交
  13. 01 9月, 2020 1 次提交
  14. 28 7月, 2020 2 次提交
  15. 05 7月, 2020 1 次提交
  16. 31 3月, 2020 1 次提交
  17. 16 3月, 2020 1 次提交
  18. 05 2月, 2020 1 次提交
    • M
      xtensa: reorganize vectors placement · 5e4417f9
      Max Filippov 提交于
      Allow vectors to be either merged into the kernel .text or put at a
      fixed virtual address independently of XIP option. Drop option that
      puts vectors at a fixed offset from the kernel text. Add choice to
      Kconfig.
      Vectors at fixed virtual address may be useful for XIP-aware MTD support
      and for noMMU configurations with available IRAM. Configurations without
      VECBASE register must put their vectors at specific locations regardless
      of the selected option. All other configurations should happily use
      merged vectors.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      5e4417f9
  19. 01 2月, 2020 1 次提交
  20. 07 1月, 2020 1 次提交
  21. 13 12月, 2019 1 次提交
  22. 27 11月, 2019 1 次提交
    • M
      xtensa: add XIP kernel support · 7af710d9
      Max Filippov 提交于
      XIP (eXecute In Place) kernel image is the image that can be run
      directly from ROM, using RAM only for writable data.
      
      XIP xtensa kernel differs from regular xtensa kernel in the following
      ways:
      - it has exception/IRQ vectors merged into text section. No vectors
        relocation takes place at kernel startup.
      - .data/.bss location must be specified in the kernel configuration,
        its content is copied there in the _startup function.
      - .init.text is merged with the rest of text and is executed from ROM.
      - when MMU is used the virtual address where the kernel will be mapped
        must be specified in the kernel configuration. It may be in the KSEG
        or in the KIO, __pa macro is adjusted to be able to handle both.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      7af710d9
  23. 11 11月, 2019 1 次提交
  24. 21 10月, 2019 1 次提交
  25. 04 9月, 2019 1 次提交
    • C
      dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP · 62fcee9a
      Christoph Hellwig 提交于
      CONFIG_ARCH_NO_COHERENT_DMA_MMAP is now functionally identical to
      !CONFIG_MMU, so remove the separate symbol.  The only difference is that
      arm did not set it for !CONFIG_MMU, but arm uses a separate dma mapping
      implementation including its own mmap method, which is handled by moving
      the CONFIG_MMU check in dma_can_mmap so that is only applies to the
      dma-direct case, just as the other ifdefs for it.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>	# m68k
      62fcee9a
  26. 02 9月, 2019 1 次提交
    • M
      xtensa: add support for call0 ABI in userspace · 09f8a6db
      Max Filippov 提交于
      Provide a Kconfig choice to select whether only the default ABI, only
      call0 ABI or both are supported. The default for XEA2 is windowed, but
      it may change for XEA3. Call0 only runs userspace with PS.WOE disabled.
      Supporting both windowed and call0 ABIs is tricky, as there's no
      indication in the ELF binaries which ABI they use. So it is done by
      probing: each process is started with PS.WOE disabled, but the handler
      of an illegal instruction exception taken with PS.WOE retries faulting
      instruction after enabling PS.WOE. It must happen before any signal is
      delivered to the process, otherwise it may be delivered incorrectly.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      09f8a6db
  27. 24 6月, 2019 1 次提交
  28. 08 5月, 2019 1 次提交
  29. 03 4月, 2019 1 次提交
    • W
      locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs · 390a0c62
      Waiman Long 提交于
      Currently, we have two different implementation of rwsem:
      
       1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
       2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
      
      As we are going to use a single generic implementation for rwsem-xadd.c
      and no architecture-specific code will be needed, there is no point
      in keeping two different implementations of rwsem. In most cases, the
      performance of rwsem-spinlock.c will be worse. It also doesn't get all
      the performance tuning and optimizations that had been implemented in
      rwsem-xadd.c over the years.
      
      For simplication, we are going to remove rwsem-spinlock.c and make all
      architectures use a single implementation of rwsem - rwsem-xadd.c.
      
      All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHM
      in the code are removed.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-riscv@lists.infradead.org
      Cc: linux-um@lists.infradead.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: openrisc@lists.librecores.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Link: https://lkml.kernel.org/r/20190322143008.21313-3-longman@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      390a0c62
  30. 19 2月, 2019 1 次提交
    • Y
      32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option · 942fa985
      Yury Norov 提交于
      All new 32-bit architectures should have 64-bit userspace off_t type, but
      existing architectures has 32-bit ones.
      
      To enforce the rule, new config option is added to arch/Kconfig that defaults
      ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
      32-bit architectures enable it explicitly.
      
      New option affects force_o_largefile() behaviour. Namely, if userspace
      off_t is 64-bits long, we have no reason to reject user to open big files.
      
      Note that even if architectures has only 64-bit off_t in the kernel
      (arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
      a libc may use 32-bit off_t, and therefore want to limit the file size
      to 4GB unless specified differently in the open flags.
      Signed-off-by: NYury Norov <ynorov@caviumnetworks.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NYury Norov <ynorov@marvell.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      942fa985
  31. 14 2月, 2019 1 次提交
  32. 08 2月, 2019 1 次提交
  33. 26 1月, 2019 2 次提交
  34. 21 12月, 2018 1 次提交
    • M
      xtensa: implement jump_label support · 64711f9a
      Max Filippov 提交于
      Use 3-byte 'nop' and 'j' instructions that are always present. Don't let
      assembler mark a spot right after patchable 'j' instruction as
      unreachable and later put literals or padding bytes there. Add separate
      implementations of patch_text for SMP and UP cases, avoiding use of
      atomics on UP.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      64711f9a