1. 08 Sep, 2015 1 commit
  2. 03 Aug, 2015 1 commit
  3. 29 Jul, 2015 1 commit
  4. 27 Jul, 2015 8 commits
  5. 20 Jul, 2015 1 commit
  6. 02 Jun, 2015 1 commit
  7. 28 May, 2015 1 commit
  8. 19 May, 2015 1 commit
  9. 26 Mar, 2015 2 commits
  10. 25 Mar, 2015 4 commits
  11. 19 Mar, 2015 3 commits
  12. 17 Mar, 2015 2 commits
  13. 23 Jan, 2015 1 commit
  14. 22 Jan, 2015 1 commit
  15. 16 Jan, 2015 1 commit
    • Mark Rutland's avatar
      arm64: respect mem= for EFI · 6083fe74
      Mark Rutland authored
      
      
      When booting with EFI, we acquire the EFI memory map after parsing the
      early params. This unfortuantely renders the option useless as we call
      memblock_enforce_memory_limit (which uses memblock_remove_range behind
      the scenes) before we've added any memblocks. We end up removing
      nothing, then adding all of memory later when efi_init calls
      reserve_regions.
      
      Instead, we can log the limit and apply this later when we do the rest
      of the memblock work in memblock_init, which should work regardless of
      the presence of EFI. At the same time we may as well move the early
      parameter into arm64's mm/init.c, close to arm64_memblock_init.
      
      Any memory which must be mapped (e.g. for use by EFI runtime services)
      must be mapped explicitly reather than relying on the linear mapping,
      which may be truncated as a result of a mem= option passed on the kernel
      command line.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6083fe74
  16. 12 Jan, 2015 2 commits
  17. 08 Jan, 2015 1 commit
    • Ard Biesheuvel's avatar
      arm64/efi: add missing call to early_ioremap_reset() · 0e63ea48
      Ard Biesheuvel authored
      The early ioremap support introduced by patch bf4b558e
      ("arm64: add early_ioremap support") failed to add a call to
      early_ioremap_reset() at an appropriate time. Without this call,
      invocations of early_ioremap etc. that are done too late will go
      unnoticed and may cause corruption.
      
      This is exactly what happened when the first user of this feature
      was added in patch f84d0275 ("arm64: add EFI runtime services").
      The early mapping of the EFI memory map is unmapped during an early
      initcall, at which time the early ioremap support is long gone.
      
      Fix by adding the missing call to early_ioremap_reset() to
      setup_arch(), and move the offending early_memunmap() to right after
      the point where the early mapping of the EFI memory map is last used.
      
      Fixes: f84d0275
      
       ("arm64: add EFI runtime services")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarLeif Lindholm <leif.lindholm@linaro.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      0e63ea48
  18. 04 Dec, 2014 1 commit
    • Fabio Estevam's avatar
      arm64: Provide a namespace to NCAPS · 06f9eb88
      Fabio Estevam authored
      
      
      Building arm64.allmodconfig leads to the following warning:
      
      usb/gadget/function/f_ncm.c:203:0: warning: "NCAPS" redefined
       #define NCAPS (USB_CDC_NCM_NCAP_ETH_FILTER | USB_CDC_NCM_NCAP_CRC_MODE)
       ^
      In file included from /home/build/work/batch/arch/arm64/include/asm/io.h:32:0,
                       from /home/build/work/batch/include/linux/clocksource.h:19,
                       from /home/build/work/batch/include/clocksource/arm_arch_timer.h:19,
                       from /home/build/work/batch/arch/arm64/include/asm/arch_timer.h:27,
                       from /home/build/work/batch/arch/arm64/include/asm/timex.h:19,
                       from /home/build/work/batch/include/linux/timex.h:65,
                       from /home/build/work/batch/include/linux/sched.h:19,
                       from /home/build/work/batch/arch/arm64/include/asm/compat.h:25,
                       from /home/build/work/batch/arch/arm64/include/asm/stat.h:23,
                       from /home/build/work/batch/include/linux/stat.h:5,
                       from /home/build/work/batch/include/linux/module.h:10,
                       from /home/build/work/batch/drivers/usb/gadget/function/f_ncm.c:19:
      arch/arm64/include/asm/cpufeature.h:27:0: note: this is the location of the previous definition
       #define NCAPS     2
      
      So add a ARM64 prefix to avoid such problem.
      Reported-by: default avatarOlof's autobuilder <build@lixom.net>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      06f9eb88
  19. 25 Nov, 2014 2 commits
  20. 17 Nov, 2014 1 commit
  21. 14 Nov, 2014 1 commit
    • Mark Rutland's avatar
      arm64: Fix up /proc/cpuinfo · 44b82b77
      Mark Rutland authored
      Commit d7a49086 (arm64: cpuinfo: print info for all CPUs)
      attempted to clean up /proc/cpuinfo, but due to concerns regarding
      further changes was reverted in commit 5e39977e
      
       (Revert "arm64:
      cpuinfo: print info for all CPUs").
      
      There are two major issues with the arm64 /proc/cpuinfo format
      currently:
      
      * The "Features" line describes (only) the 64-bit hwcaps, which is
        problematic for some 32-bit applications which attempt to parse it. As
        the same names are used for analogous ISA features (e.g. aes) despite
        these generally being architecturally unrelated, it is not possible to
        simply append the 64-bit and 32-bit hwcaps in a manner that might not
        be misleading to some applications.
      
        Various potential solutions have appeared in vendor kernels. Typically
        the format of the Features line varies depending on whether the task
        is 32-bit.
      
      * Information is only printed regarding a single CPU. This does not
        match the ARM format, and does not provide sufficient information in
        big.LITTLE systems where CPUs are heterogeneous. The CPU information
        printed is queried from the current CPU's registers, which is racy
        w.r.t. cross-cpu migration.
      
      This patch attempts to solve these issues. The following changes are
      made:
      
      * When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
        the "Features" line contains the decoded 32-bit hwcaps, as with the
        arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
        with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
        the absense of compat support, the Features line is empty.
      
        The set of hwcaps injected into a task's auxval are unaffected.
      
      * Properties are printed per-cpu, as with the ARM port. The per-cpu
        information is queried from pre-recorded cpu information (as used by
        the sanity checks).
      
      * As with the previous attempt at fixing up /proc/cpuinfo, the hardware
        field is removed. The only users so far are 32-bit applications tied
        to particular boards, so no portable applications should be affected,
        and this should prevent future tying to particular boards.
      
      The following differences remain:
      
      * No model_name is printed, as this cannot be queried from the hardware
        and cannot be provided in a stable fashion. Use of the CPU
        {implementor,variant,part,revision} fields is sufficient to identify a
        CPU and is portable across arm and arm64.
      
      * The following system-wide properties are not provided, as they are not
        possible to provide generally. Programs relying on these are already
        tied to particular (32-bit only) boards:
        - Hardware
        - Revision
        - Serial
      
      No software has yet been identified for which these remaining
      differences are problematic.
      
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Serban Constantinescu <serban.constantinescu@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cross-distro@lists.linaro.org
      Cc: linux-api@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      44b82b77
  22. 06 Nov, 2014 2 commits
  23. 15 Sep, 2014 1 commit
    • Jon Masters's avatar
      setup: Move unmask of async interrupts after possible earlycon setup · 7a9c43be
      Jon Masters authored
      
      
      The kernel wants to enable reporting of asynchronous interrupts (i.e.
      System Errors) as early as possible. But if this happens too early then
      any pending System Error on initial entry into the kernel may never be
      reported where a user can see it. This situation will occur if the kernel
      is configured with CONFIG_PANIC_ON_OOPS set and (default or command line)
      enabled, in which case the kernel will panic as intended, however the
      associated logging messages indicating this failure condition will remain
      only in the kernel ring buffer and never be flushed out to the (not yet
      configured) console. Therefore, this patch moves the enabling of
      asynchronous interrupts during early setup to as early as reasonable,
      but after parsing any possible earlycon parameters setting up earlycon.
      Signed-off-by: default avatarJon Masters <jcm@redhat.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      7a9c43be