1. 30 1月, 2013 6 次提交
  2. 23 1月, 2013 2 次提交
    • C
      arm64: Add simple earlyprintk support · 2475ff9d
      Catalin Marinas 提交于
      This patch adds support for "earlyprintk=" parameter on the kernel
      command line. The format is:
      
        earlyprintk=<name>[,<addr>][,<options>]
      
      where <name> is the name of the (UART) device, e.g. "pl011", <addr> is
      the I/O address. The <options> aren't currently used.
      
      The mapping of the earlyprintk device is done very early during kernel
      boot and there are restrictions on which functions it can call. A
      special early_io_map() function is added which creates the mapping from
      the pre-defined EARLY_IOBASE to the device I/O address passed via the
      kernel parameter. The pgd entry corresponding to EARLY_IOBASE is
      pre-populated in head.S during kernel boot.
      
      Only PL011 is currently supported and it is assumed that the interface
      is already initialised by the boot loader before the kernel is started.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      2475ff9d
    • W
      arm64: elf: fix core dumping to match what glibc expects · 9cf2b72b
      Will Deacon 提交于
      The kernel's internal definition of ELF_NGREG uses struct pt_regs, which
      means that we disagree with userspace on the size of coredumps since
      glibc correctly uses the user-visible struct user_pt_regs.
      
      This patch fixes our ELF_NGREG definition to use struct user_pt_regs
      and introduces our own ELF_CORE_COPY_REGS to convert between the user
      and kernel structure definitions.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      9cf2b72b
  3. 16 1月, 2013 1 次提交
  4. 10 1月, 2013 2 次提交
  5. 02 1月, 2013 1 次提交
  6. 20 12月, 2012 2 次提交
    • A
      new helper: compat_user_stack_pointer() · 9b064fc3
      Al Viro 提交于
      Compat counterpart of current_user_stack_pointer(); for most of the biarch
      architectures those two are identical, but e.g. arm64 and arm use different
      registers for stack pointer...
      
      Note that amd64 variants of current_user_stack_pointer/compat_user_stack_pointer
      do *not* rely on pt_regs having been through FIXUP_TOP_OF_STACK.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9b064fc3
    • A
      Bury the conditionals from kernel_thread/kernel_execve series · ae903caa
      Al Viro 提交于
      All architectures have
      	CONFIG_GENERIC_KERNEL_THREAD
      	CONFIG_GENERIC_KERNEL_EXECVE
      	__ARCH_WANT_SYS_EXECVE
      None of them have __ARCH_WANT_KERNEL_EXECVE and there are only two callers
      of kernel_execve() (which is a trivial wrapper for do_execve() now) left.
      Kill the conditionals and make both callers use do_execve().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ae903caa
  7. 18 12月, 2012 1 次提交
  8. 05 12月, 2012 8 次提交
  9. 03 12月, 2012 1 次提交
    • A
      open*(2) compat fixes (s390, arm64) · 9d73fc2d
      Al Viro 提交于
      The usual rules for open()/openat()/open_by_handle_at() are
       1) native 32bit - don't force O_LARGEFILE in flags
       2) native 64bit - force O_LARGEFILE in flags
       3) compat on 64bit host - as for native 32bit
       4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for
          native 64bit
      
      There are only two exceptions - s390 compat has open() forcing
      O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same
      thing.  The same binaries on native host (s390/31 and arm resp.) will
      *not* force O_LARGEFILE, so IMO both are emulation bugs.
      
      Objections? The fix is obvious...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d73fc2d
  10. 29 11月, 2012 3 次提交
  11. 28 11月, 2012 1 次提交
  12. 24 11月, 2012 2 次提交
  13. 16 11月, 2012 1 次提交
  14. 14 11月, 2012 1 次提交
  15. 09 11月, 2012 3 次提交
  16. 23 10月, 2012 3 次提交
  17. 20 10月, 2012 1 次提交
    • M
      arm64: fix alignment padding in assembly code · aeed41a9
      Marc Zyngier 提交于
      An interesting effect of using the generic version of linkage.h
      is that the padding is defined in terms of x86 NOPs, which can have
      even more interesting effects when the assembly code looks like this:
      
      ENTRY(func1)
      	mov	x0, xzr
      ENDPROC(func1)
      	// fall through
      ENTRY(func2)
      	mov	x0, #1
      	ret
      ENDPROC(func2)
      
      Admittedly, the code is not very nice. But having code from another
      architecture doesn't look completely sane either.
      
      The fix is to add arm64's version of linkage.h, which causes the insertion
      of proper AArch64 NOPs.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      aeed41a9
  18. 19 10月, 2012 1 次提交