1. 26 Feb, 2016 4 commits
  2. 25 Feb, 2016 9 commits
    • Catalin Marinas's avatar
      arm64: Fix building error with 16KB pages and 36-bit VA · cac4b8cd
      Catalin Marinas authored
      In such configuration, Linux uses only two pages of page tables and
      __pud_populate() should not be used. However, the BUILD_BUG() triggers
      since pud_sect() is still defined and the compiler cannot eliminate such
      code, even though at run-time it should not be triggered. This patch
      extends the #ifdef ARM64_64K_PAGES condition for pud_sect to include
      PGTABLE_LEVELS < 3.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      cac4b8cd
    • Suzuki K Poulose's avatar
      arm64: Rename cpuid_feature field extract routines · 28c5dcb2
      Suzuki K Poulose authored
      Now that we have a clear understanding of the sign of a feature,
      rename the routines to reflect the sign, so that it is not misused.
      The cpuid_feature_extract_field() now accepts a 'sign' parameter.
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      28c5dcb2
    • Suzuki K Poulose's avatar
      arm64: capabilities: Handle sign of the feature bit · ff96f7bc
      Suzuki K Poulose authored
      Use the appropriate accessor for the feature bit by keeping
      track of the sign of the feature
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ff96f7bc
    • Suzuki K Poulose's avatar
      arm64: cpufeature: Fix the sign of feature bits · 0710cfdb
      Suzuki K Poulose authored
      There is a confusion on whether the values of a feature are signed
      or not in ARM. This is not clearly mentioned in the ARM ARM either.
      We have dealt most of the bits as signed so far, and marked the
      rest as unsigned explicitly. This fixed in ARM ARM and will be rolled
      out soon.
      
      Here is the criteria in a nutshell:
      
      1) The fields, which are either signed or unsigned, use increasing
         numerical values to indicate an increase in functionality. Thus, if a value
         of 0x1 indicates the presence of some instructions, then the 0x2 value will
         indicate the presence of those instructions plus some additional instructions
         or functionality.
      
      2) For ID field values where the value 0x0 defines that a feature is not present,
         the number is an unsigned value.
      
      3) For some features where the feature was made optional or removed after the
         start of the definition of the architecture, the value 0x0 is used to
         indicate the presence of a feature, and 0xF indicates the absence of the
         feature. In these cases, the fields are, in effect, holding signed values.
      
      So with these rules applied, we have only the following fields which are signed and
      the rest are unsigned.
      
       a) ID_AA64PFR0_EL1: {FP, ASIMD}
       b) ID_AA64MMFR0_EL1: {TGran4K, TGran64K}
       c) ID_AA64DFR0_EL1: PMUVer (0xf - PMUv3 not implemented)
       d) ID_DFR0_EL1: PerfMon
       e) ID_MMFR0_EL1: {InnerShr, OuterShr}
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      0710cfdb
    • Suzuki K Poulose's avatar
      arm64: cpufeature: Correct feature register tables · e5343503
      Suzuki K Poulose authored
      Correct the feature bit entries for :
        ID_DFR0
        ID_MMFR0
      
      to fix the default safe value for some of the bits.
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      e5343503
    • Suzuki K Poulose's avatar
      arm64: Ensure the secondary CPUs have safe ASIDBits size · 13f417f3
      Suzuki K Poulose authored
      Adds a hook for checking whether a secondary CPU has the
      features used already by the kernel during early boot, based
      on the boot CPU and plugs in the check for ASID size.
      
      The ID_AA64MMFR0_EL1:ASIDBits determines the size of the mm context
      id and is used in the early boot to make decisions. The value is
      picked up from the Boot CPU and cannot be delayed until other CPUs
      are up. If a secondary CPU has a smaller size than that of the Boot
      CPU, things will break horribly and the usual SANITY check is not good
      enough to prevent the system from crashing. So, crash the system with
      enough information.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      13f417f3
    • Suzuki K Poulose's avatar
      arm64: Add helper for extracting ASIDBits · 038dc9c6
      Suzuki K Poulose authored
      Add a helper to extract ASIDBits on the current cpu
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      038dc9c6
    • Suzuki K Poulose's avatar
      arm64: Enable CPU capability verification unconditionally · fd9c2790
      Suzuki K Poulose authored
      We verify the capabilities of the secondary CPUs only when
      hotplug is enabled. The boot time activated CPUs do not
      go through the verification by checking whether the system
      wide capabilities were initialised or not.
      
      This patch removes the capability check dependency on CONFIG_HOTPLUG_CPU,
      to make sure that all the secondary CPUs go through the check.
      The boot time activated CPUs will still skip the system wide
      capability check. The plan is to hook in a check for CPU features
      used by the kernel at early boot up, based on the Boot CPU values.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      fd9c2790
    • Suzuki K Poulose's avatar
      arm64: Handle early CPU boot failures · bb905274
      Suzuki K Poulose authored
      A secondary CPU could fail to come online due to insufficient
      capabilities and could simply die or loop in the kernel.
      e.g, a CPU with no support for the selected kernel PAGE_SIZE
      loops in kernel with MMU turned off.
      or a hotplugged CPU which doesn't have one of the advertised
      system capability will die during the activation.
      
      There is no way to synchronise the status of the failing CPU
      back to the master. This patch solves the issue by adding a
      field to the secondary_data which can be updated by the failing
      CPU. If the secondary CPU fails even before turning the MMU on,
      it updates the status in a special variable reserved in the head.txt
      section to make sure that the update can be cache invalidated safely
      without possible sharing of cache write back granule.
      
      Here are the possible states :
      
       -1. CPU_MMU_OFF - Initial value set by the master CPU, this value
      indicates that the CPU could not turn the MMU on, hence the status
      could not be reliably updated in the secondary_data. Instead, the
      CPU has updated the status @ __early_cpu_boot_status.
      
       0. CPU_BOOT_SUCCESS - CPU has booted successfully.
      
       1. CPU_KILL_ME - CPU has invoked cpu_ops->die, indicating the
      master CPU to synchronise by issuing a cpu_ops->cpu_kill.
      
       2. CPU_STUCK_IN_KERNEL - CPU couldn't invoke die(), instead is
      looping in the kernel. This information could be used by say,
      kexec to check if it is really safe to do a kexec reboot.
      
       3. CPU_PANIC_KERNEL - CPU detected some serious issues which
      requires kernel to crash immediately. The secondary CPU cannot
      call panic() until it has initialised the GIC. This flag can
      be used to instruct the master to do so.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      [catalin.marinas@arm.com: conflict resolution]
      [catalin.marinas@arm.com: converted "status" from int to long]
      [catalin.marinas@arm.com: updated update_early_cpu_boot_status to use str_l]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      bb905274
  3. 24 Feb, 2016 17 commits
  4. 23 Feb, 2016 3 commits
  5. 19 Feb, 2016 1 commit
  6. 18 Feb, 2016 6 commits