linux-stable.git/include/linux/acpi.h, branch v4.1.2

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
  ...

device property: Make it possible to use secondary firmware nodes

2015-04-03T21:23:37+00:00

Add a secondary pointer to struct fwnode_handle so as to make it
possible for a device to have two firmware nodes associated with
it at the same time, for example, an ACPI node and a node with
a set of properties provided by platform initialization code.

In the future that will allow device property lookup to fall back
from the primary firmware node to the secondary one if the given
property is not present there to make it easier to provide defaults
for device properties used by device drivers.

Introduce two helper routines, set_primary_fwnode() and
set_secondary_fwnode() allowing callers to add a primary/secondary
firmware node to the given device in such a way that

 (1) If there's only one firmware node for that device, it will be
     pointed to by the device's firmware node pointer.
 (2) If both the primary and secondary firmware nodes are present,
     the primary one will be pointed to by the device's firmware
     node pointer, while the secondary one will be pointed to by the
     primary node's secondary pointer.
 (3) If one of these nodes is removed (by calling one of the new
     nelpers with NULL as the second argument), the other one will
     be preserved.

Make ACPI use set_primary_fwnode() for attaching its firmware nodes
to devices.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Heikki Krogerus 
Acked-by: Greg Kroah-Hartman

ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi

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

Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.

acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.

We are going to implement stacked domains when GICv2m, GICv3, ITS
support are added.

CC: Marc Zyngier 
Originally-by: Amit Daniel Kachhap 
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: Rafael J. Wysocki 
Reviewed-by: Grant Likely 
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID

2015-03-26T15:12:51+00:00

CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
but phys_id is used as int in acpi processor driver, so it will lead to
some inconsistence for the drivers.

Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
ids a generic CPU physical id type is required.

So introduce typedef u32 phys_cpuid_t in a common file, and introduce
a macro PHYS_CPUID_INVALID as (phys_cpuid_t)(-1) if it's not defined
by other archs, this will solve the inconsistence in acpi processor driver,
and will prepare for the ACPI on ARM64 for the 64 bit CPU hardware ID
in the following patch.

CC: Rafael J Wysocki 
Suggested-by: Lorenzo Pieralisi 
Reviewed-by: Grant Likely 
Acked-by: Sudeep Holla 
Acked-by: Lorenzo Pieralisi 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Catalin Marinas 
[hj: reworked cpu physid map return codes]
Signed-off-by: Hanjun Guo 
Signed-off-by: Will Deacon

ACPI: Introduce has_acpi_companion()

2015-03-16T22:49:08+00:00

Now that the ACPI companions of devices are represented by pointers
to struct fwnode_handle, it is not quite efficient to check whether
or not an ACPI companion of a device is present by evaluating the
ACPI_COMPANION() macro.

For this reason, introduce a special static inline routine for that,
has_acpi_companion(), and update the code to use it where applicable.

Signed-off-by: Rafael J. Wysocki

driver core / ACPI: Represent ACPI companions using fwnode_handle

2015-03-16T22:49:03+00:00

Now that we have struct fwnode_handle, we can use that to point to
ACPI companions from struct device objects instead of pointing to
struct acpi_device directly.

There are two benefits from that.  First, the somewhat ugly and
hackish struct acpi_dev_node can be dropped and, second, the same
struct fwnode_handle pointer can be used in the future to point
to other (non-ACPI) firmware device node types.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Acked-by: Grant Likely

ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug

2015-02-05T14:09:26+00:00

We need to parse APIC ID for IOAPIC registration for IOAPIC hotplug.
ACPI _MAT method and MADT table are used to figure out IOAPIC ID, just
like parsing CPU APIC ID for CPU hotplug.

[ tglx: Fixed docbook comment ]

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
Cc: Konrad Rzeszutek Wilk 
Cc: Tony Luck 
Cc: Joerg Roedel 
Cc: Greg Kroah-Hartman 
Cc: Benjamin Herrenschmidt 
Cc: Rafael J. Wysocki 
Cc: Bjorn Helgaas 
Cc: Randy Dunlap 
Cc: Borislav Petkov 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/1414387308-27148-8-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Rafael J. Wysocki

resources: Move struct resource_list_entry from ACPI into resource core

2015-02-05T14:09:25+00:00

Currently ACPI, PCI and pnp all implement the same resource list
management with different data structure. We need to transfer from
one data structure into another when passing resources from one
subsystem into another subsystem. So move struct resource_list_entry
from ACPI into resource core and rename it as resource_entry,
then it could be reused by different subystems and avoid the data
structure conversion.

Introduce dedicated header file resource_ext.h instead of embedding
it into ioport.h to avoid header file inclusion order issues.

Signed-off-by: Jiang Liu 
Acked-by: Vinod Koul 
Signed-off-by: Rafael J. Wysocki

ACPI: Introduce helper function acpi_dev_filter_resource_type()

2015-02-03T21:27:23+00:00

Introduce helper function acpi_dev_filter_resource_type(), which may
be used by acpi_dev_get_resources() to filer out resource based on
resource type.

Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki

ACPI: Add field offset to struct resource_list_entry

2015-02-03T21:27:23+00:00

Add field offset to struct resource_list_entry to host address space
translation offset so it could be used to represent bridge resources.

Signed-off-by: Jiang Liu 
Signed-off-by: Rafael J. Wysocki