linux-stable.git/arch/arm64/kernel/setup.c, branch v4.1

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2015-04-24T15:23:45+00:00

Pull initial ACPI support for arm64 from Will Deacon:
 "This series introduces preliminary ACPI 5.1 support to the arm64
  kernel using the "hardware reduced" profile.  We don't support any
  peripherals yet, so it's fairly limited in scope:

   - MEMORY init (UEFI)

   - ACPI discovery (RSDP via UEFI)

   - CPU init (FADT)

   - GIC init (MADT)

   - SMP boot (MADT + PSCI)

   - ACPI Kconfig options (dependent on EXPERT)

  ACPI for arm64 has been in development for a while now and hardware
  has been available that can boot with either FDT or ACPI tables.  This
  has been made possible by both changes to the ACPI spec to cater for
  ARM-based machines (known as "hardware-reduced" in ACPI parlance) but
  also a Linaro-driven effort to get this supported on top of the Linux
  kernel.  This pull request is the result of that work.

  These changes allow us to initialise the CPUs, interrupt controller,
  and timers via ACPI tables, with memory information and cmdline coming
  from EFI.  We don't support a hybrid ACPI/FDT scheme.  Of course,
  there is still plenty of work to do (a serial console would be nice!)
  but I expect that to happen on a per-driver basis after this core
  series has been merged.

  Anyway, the diff stat here is fairly horrible, but splitting this up
  and merging it via all the different subsystems would have been
  extremely painful.  Instead, we've got all the relevant Acks in place
  and I've not seen anything other than trivial (Kconfig) conflicts in
  -next (for completeness, I've included my resolution below).  Nearly
  half of the insertions fall under Documentation/.

  So, we'll see how this goes.  Right now, it all depends on EXPERT and
  I fully expect people to use FDT by default for the immediate future"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (31 commits)
  ARM64 / ACPI: make acpi_map_gic_cpu_interface() as void function
  ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface()
  ARM64 / ACPI: fix usage of acpi_map_gic_cpu_interface
  ARM64: kernel: acpi: honour acpi=force command line parameter
  ARM64: kernel: acpi: refactor ACPI tables init and checks
  ARM64: kernel: psci: let ACPI probe PSCI version
  ARM64: kernel: psci: factor out probe function
  ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer
  ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed
  ARM64 / ACPI: additions of ACPI documentation for arm64
  Documentation: ACPI for ARM64
  ARM64 / ACPI: Enable ARM64 in Kconfig
  XEN / ACPI: Make XEN ACPI depend on X86
  ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64
  clocksource / arch_timer: Parse GTDT to initialize arch timer
  irqchip: Add GICv2 specific ACPI boot support
  ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
  ACPI / processor: Make it possible to get CPU hardware ID via GICC
  ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
  ARM64 / ACPI: Parse MADT for SMP initialization
  ...

ARM64: kernel: acpi: honour acpi=force command line parameter

2015-03-26T15:13:11+00:00

If acpi=force is passed on the command line, it forces ACPI to be
the only available boot method, hence it must be left enabled even
if the initialization and sanity checks on ACPI tables fails.

This patch refactors ACPI initialization to prevent disabling ACPI
if acpi=force is passed on the command line.

Signed-off-by: Lorenzo Pieralisi 
Acked-by: Ard Biesheuvel 
Acked-by: Hanjun Guo 
Cc: Ard Biesheuvel 
Cc: Hanjun Guo 
Cc: Catalin Marinas 
Signed-off-by: Will Deacon

ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed

2015-03-26T15:13:09+00:00

Since the policy is that once we pass acpi=force in the early
param, we will not unflatten device tree even if ACPI is disabled
in ACPI table init fails, so fix the code by comparinging both
acpi_disabled and param_acpi_force before the device tree is
unflattened.

CC: Ard Biesheuvel 
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

ARM64 / ACPI: Parse MADT for SMP initialization

2015-03-25T11:52:42+00:00

MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map.

ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and
Parking protocol, but the Parking protocol is only specified for
ARMv7 now, so make PSCI as the only way for the SMP boot protocol
before some updates for the ACPI spec or the Parking protocol spec.

Parking protocol patches for SMP boot will be sent to upstream when
the new version of Parking protocol is ready.

CC: Lorenzo Pieralisi 
CC: Catalin Marinas 
CC: Will Deacon 
CC: Mark Rutland 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Acked-by: Olof Johansson 
Reviewed-by: Grant Likely 
Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Will Deacon

ARM64 / ACPI: Get PSCI flags in FADT for PSCI init

2015-03-25T11:49:31+00:00

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the firmware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information in ACPI 5.1, FADT table was
parsed in ACPI table init and copy to struct acpi_gbl_FADT, so
use the flags in struct acpi_gbl_FADT for PSCI init.

Since ACPI 5.1 doesn't support self defined PSCI function IDs,
which means that only PSCI 0.2+ is supported in ACPI.

CC: Lorenzo Pieralisi 
CC: Catalin Marinas 
CC: Will Deacon 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Acked-by: Olof Johansson 
Acked-by: Grant Likely 
Signed-off-by: Graeme Gregory 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

ARM64 / ACPI: If we chose to boot from acpi then disable FDT

2015-03-25T11:49:31+00:00

If the early boot methods of acpi are happy that we have valid ACPI
tables and acpi=force has been passed, then do not unflat devicetree
effectively disabling further hardware probing from DT.

CC: Catalin Marinas 
CC: Will Deacon 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Acked-by: Olof Johansson 
Acked-by: Grant Likely 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

ARM64 / ACPI: Get RSDP and ACPI boot-time tables

2015-03-25T11:49:30+00:00

As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.

Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
  - asm/acenv.h for arch specific ACPICA environments and
    implementation, It is needed unconditionally by ACPI core;
  - asm/acpi.h for arch specific variables and functions needed by
    ACPI driver core;
  - acpi.c for ARM64 related ACPI implementation for ACPI driver
    core;

acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.

FADT Major.Minor version was introduced in ACPI 5.1, it is the same
as ACPI version.

In ACPI 5.1, some major gaps are fixed for ARM, such as updates in
MADT table for GIC and SMP init, without those updates, we can not
get the MPIDR for SMP init, and GICv2/3 related init information, so
we can't boot arm64 ACPI properly with table versions predating 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS has no way to retrieve the configuration data that is necessary
to init SMP boot protocol and the GIC properly, so disable ACPI if
we get an FADT table with version less that 5.1 when acpi_boot_table_init()
called.

CC: Catalin Marinas 
CC: Will Deacon 
CC: Lorenzo Pieralisi 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Acked-by: Olof Johansson 
Acked-by: Grant Likely 
Signed-off-by: Al Stone 
Signed-off-by: Graeme Gregory 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

arm64: enforce x1|x2|x3 == 0 upon kernel entry as per boot protocol

2015-03-19T19:46:02+00:00

According to the arm64 boot protocol, registers x1 to x3 should be
zero upon kernel entry, and non-zero values are reserved for future
use. This future use is going to be problematic if we never enforce
the current rules, so start enforcing them now, by emitting a warning
if non-zero values are detected.

Acked-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon

arm64: remove processor_id

2015-03-19T19:46:01+00:00

The global processor_id is assigned the MIDR_EL1 value of the boot
CPU in the early init code, but is never referenced afterwards.

As the relevance of the MIDR_EL1 value of the boot CPU is debatable
anyway, especially under big.LITTLE, let's remove it before anyone
starts using it.

Tested-by: Mark Rutland 
Reviewed-by: Mark Rutland 
Reviewed-by: Catalin Marinas 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon

arm64: Get rid of struct cpu_table

2015-03-19T19:46:00+00:00

struct cpu_table is an artifact left from the (very) early days of
the arm64 port, and its only real use is to allow the most beautiful
"AArch64 Processor" string to be displayed at boot time.

Really? Yes, really.

Let's get rid of it. In order to avoid another BogoMips-gate, the
aforementioned string is preserved.

Acked-by: Mark Rutland 
Acked-by: Catalin Marinas 
Acked-by: Ard Biesheuvel 
Signed-off-by: Marc Zyngier 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon