2012-11-15 07:30:01 +08:00
|
|
|
/*
|
|
|
|
* drivers/acpi/resource.c - ACPI device resources interpretation.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012, Intel Corp.
|
|
|
|
* Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as published
|
|
|
|
* by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/ioport.h>
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
#include <linux/slab.h>
|
2015-12-24 06:25:33 +08:00
|
|
|
#include <linux/irq.h>
|
2012-11-15 07:30:01 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_X86
|
|
|
|
#define valid_IRQ(i) (((i) != 0) && ((i) != 2))
|
2016-03-21 19:12:55 +08:00
|
|
|
static inline bool acpi_iospace_resource_valid(struct resource *res)
|
|
|
|
{
|
|
|
|
/* On X86 IO space is limited to the [0 - 64K] IO port range */
|
|
|
|
return res->end < 0x10003;
|
|
|
|
}
|
2012-11-15 07:30:01 +08:00
|
|
|
#else
|
|
|
|
#define valid_IRQ(i) (true)
|
2016-03-21 19:12:55 +08:00
|
|
|
/*
|
|
|
|
* ACPI IO descriptors on arches other than X86 contain MMIO CPU physical
|
|
|
|
* addresses mapping IO space in CPU physical address space, IO space
|
|
|
|
* resources can be placed anywhere in the 64-bit physical address space.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
acpi_iospace_resource_valid(struct resource *res) { return true; }
|
2012-11-15 07:30:01 +08:00
|
|
|
#endif
|
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len, bool io)
|
2012-11-15 07:30:01 +08:00
|
|
|
{
|
2015-02-02 10:42:48 +08:00
|
|
|
u64 reslen = end - start + 1;
|
2012-11-15 07:30:01 +08:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
/*
|
|
|
|
* CHECKME: len might be required to check versus a minimum
|
|
|
|
* length as well. 1 for io is fine, but for memory it does
|
|
|
|
* not make any sense at all.
|
2015-03-04 16:47:12 +08:00
|
|
|
* Note: some BIOSes report incorrect length for ACPI address space
|
|
|
|
* descriptor, so remove check of 'reslen == len' to avoid regression.
|
2015-02-02 10:42:48 +08:00
|
|
|
*/
|
2015-03-04 16:47:12 +08:00
|
|
|
if (len && reslen && start <= end)
|
2015-02-02 10:42:48 +08:00
|
|
|
return true;
|
|
|
|
|
2015-02-18 15:05:43 +08:00
|
|
|
pr_debug("ACPI: invalid or unassigned resource %s [%016llx - %016llx] length [%016llx]\n",
|
2015-02-02 10:42:48 +08:00
|
|
|
io ? "io" : "mem", start, end, len);
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_dev_memresource_flags(struct resource *res, u64 len,
|
2015-02-02 10:42:52 +08:00
|
|
|
u8 write_protect)
|
2015-02-02 10:42:48 +08:00
|
|
|
{
|
|
|
|
res->flags = IORESOURCE_MEM;
|
|
|
|
|
|
|
|
if (!acpi_dev_resource_len_valid(res->start, res->end, len, false))
|
2015-02-02 10:42:56 +08:00
|
|
|
res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
|
2012-11-15 07:30:01 +08:00
|
|
|
|
|
|
|
if (write_protect == ACPI_READ_WRITE_MEMORY)
|
2015-02-02 10:42:48 +08:00
|
|
|
res->flags |= IORESOURCE_MEM_WRITEABLE;
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_dev_get_memresource(struct resource *res, u64 start, u64 len,
|
|
|
|
u8 write_protect)
|
|
|
|
{
|
|
|
|
res->start = start;
|
|
|
|
res->end = start + len - 1;
|
2015-02-02 10:42:52 +08:00
|
|
|
acpi_dev_memresource_flags(res, len, write_protect);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_resource_memory - Extract ACPI memory resource information.
|
|
|
|
* @ares: Input ACPI resource object.
|
|
|
|
* @res: Output generic resource object.
|
|
|
|
*
|
|
|
|
* Check if the given ACPI resource object represents a memory resource and
|
|
|
|
* if that's the case, use the information in it to populate the generic
|
|
|
|
* resource object pointed to by @res.
|
2015-02-02 10:42:55 +08:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* 1) false with res->flags setting to zero: not the expected resource type
|
|
|
|
* 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
|
|
|
|
* 3) true: valid assigned resource
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
|
|
|
bool acpi_dev_resource_memory(struct acpi_resource *ares, struct resource *res)
|
|
|
|
{
|
|
|
|
struct acpi_resource_memory24 *memory24;
|
|
|
|
struct acpi_resource_memory32 *memory32;
|
|
|
|
struct acpi_resource_fixed_memory32 *fixed_memory32;
|
|
|
|
|
|
|
|
switch (ares->type) {
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
|
|
|
memory24 = &ares->data.memory24;
|
2015-02-02 10:42:54 +08:00
|
|
|
acpi_dev_get_memresource(res, memory24->minimum << 8,
|
|
|
|
memory24->address_length << 8,
|
2012-11-15 07:30:01 +08:00
|
|
|
memory24->write_protect);
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
|
|
|
memory32 = &ares->data.memory32;
|
|
|
|
acpi_dev_get_memresource(res, memory32->minimum,
|
|
|
|
memory32->address_length,
|
|
|
|
memory32->write_protect);
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
|
|
|
fixed_memory32 = &ares->data.fixed_memory32;
|
|
|
|
acpi_dev_get_memresource(res, fixed_memory32->address,
|
|
|
|
fixed_memory32->address_length,
|
|
|
|
fixed_memory32->write_protect);
|
|
|
|
break;
|
|
|
|
default:
|
2015-02-02 10:42:55 +08:00
|
|
|
res->flags = 0;
|
2012-11-15 07:30:01 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
return !(res->flags & IORESOURCE_DISABLED);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resource_memory);
|
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
|
2015-10-14 14:29:36 +08:00
|
|
|
u8 io_decode, u8 translation_type)
|
2012-11-15 07:30:01 +08:00
|
|
|
{
|
2015-02-02 10:42:49 +08:00
|
|
|
res->flags = IORESOURCE_IO;
|
2012-11-15 07:30:01 +08:00
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
if (!acpi_dev_resource_len_valid(res->start, res->end, len, true))
|
2015-02-02 10:42:56 +08:00
|
|
|
res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
|
2015-02-02 10:42:49 +08:00
|
|
|
|
2016-03-21 19:12:55 +08:00
|
|
|
if (!acpi_iospace_resource_valid(res))
|
2015-02-02 10:42:56 +08:00
|
|
|
res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
|
2012-11-15 07:30:01 +08:00
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
if (io_decode == ACPI_DECODE_16)
|
|
|
|
res->flags |= IORESOURCE_IO_16BIT_ADDR;
|
2015-10-14 14:29:36 +08:00
|
|
|
if (translation_type == ACPI_SPARSE_TRANSLATION)
|
|
|
|
res->flags |= IORESOURCE_IO_SPARSE;
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
|
|
|
|
u8 io_decode)
|
|
|
|
{
|
|
|
|
res->start = start;
|
2015-02-02 10:42:49 +08:00
|
|
|
res->end = start + len - 1;
|
2015-10-14 14:29:36 +08:00
|
|
|
acpi_dev_ioresource_flags(res, len, io_decode, 0);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_resource_io - Extract ACPI I/O resource information.
|
|
|
|
* @ares: Input ACPI resource object.
|
|
|
|
* @res: Output generic resource object.
|
|
|
|
*
|
|
|
|
* Check if the given ACPI resource object represents an I/O resource and
|
|
|
|
* if that's the case, use the information in it to populate the generic
|
|
|
|
* resource object pointed to by @res.
|
2015-02-02 10:42:55 +08:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* 1) false with res->flags setting to zero: not the expected resource type
|
|
|
|
* 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
|
|
|
|
* 3) true: valid assigned resource
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
|
|
|
bool acpi_dev_resource_io(struct acpi_resource *ares, struct resource *res)
|
|
|
|
{
|
|
|
|
struct acpi_resource_io *io;
|
|
|
|
struct acpi_resource_fixed_io *fixed_io;
|
|
|
|
|
|
|
|
switch (ares->type) {
|
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
|
|
|
io = &ares->data.io;
|
|
|
|
acpi_dev_get_ioresource(res, io->minimum,
|
|
|
|
io->address_length,
|
|
|
|
io->io_decode);
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
|
|
|
fixed_io = &ares->data.fixed_io;
|
|
|
|
acpi_dev_get_ioresource(res, fixed_io->address,
|
|
|
|
fixed_io->address_length,
|
|
|
|
ACPI_DECODE_10);
|
|
|
|
break;
|
|
|
|
default:
|
2015-02-02 10:42:55 +08:00
|
|
|
res->flags = 0;
|
2012-11-15 07:30:01 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-02-02 10:42:49 +08:00
|
|
|
|
|
|
|
return !(res->flags & IORESOURCE_DISABLED);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
static bool acpi_decode_space(struct resource_win *win,
|
2015-02-02 10:42:51 +08:00
|
|
|
struct acpi_resource_address *addr,
|
|
|
|
struct acpi_address64_attribute *attr)
|
|
|
|
{
|
|
|
|
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
|
|
|
|
bool wp = addr->info.mem.write_protect;
|
|
|
|
u64 len = attr->address_length;
|
ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because of this,
either ACPI or the Realtek chip kept the bad state and after rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
good."
The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-tested-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08 15:26:39 +08:00
|
|
|
u64 start, end, offset = 0;
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource *res = &win->res;
|
2015-02-02 10:42:51 +08:00
|
|
|
|
2015-02-02 10:42:57 +08:00
|
|
|
/*
|
|
|
|
* Filter out invalid descriptor according to ACPI Spec 5.0, section
|
|
|
|
* 6.4.3.5 Address Space Resource Descriptors.
|
|
|
|
*/
|
|
|
|
if ((addr->min_address_fixed != addr->max_address_fixed && len) ||
|
|
|
|
(addr->min_address_fixed && addr->max_address_fixed && !len))
|
|
|
|
pr_debug("ACPI: Invalid address space min_addr_fix %d, max_addr_fix %d, len %llx\n",
|
|
|
|
addr->min_address_fixed, addr->max_address_fixed, len);
|
|
|
|
|
2015-02-02 10:42:59 +08:00
|
|
|
/*
|
|
|
|
* For bridges that translate addresses across the bridge,
|
|
|
|
* translation_offset is the offset that must be added to the
|
|
|
|
* address on the secondary side to obtain the address on the
|
|
|
|
* primary side. Non-bridge devices must list 0 for all Address
|
|
|
|
* Translation offset bits.
|
|
|
|
*/
|
ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because of this,
either ACPI or the Realtek chip kept the bad state and after rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
good."
The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-tested-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08 15:26:39 +08:00
|
|
|
if (addr->producer_consumer == ACPI_PRODUCER)
|
|
|
|
offset = attr->translation_offset;
|
|
|
|
else if (attr->translation_offset)
|
2015-02-02 10:42:59 +08:00
|
|
|
pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
|
|
|
|
attr->translation_offset);
|
ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because of this,
either ACPI or the Realtek chip kept the bad state and after rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
good."
The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-tested-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08 15:26:39 +08:00
|
|
|
start = attr->minimum + offset;
|
|
|
|
end = attr->maximum + offset;
|
|
|
|
|
|
|
|
win->offset = offset;
|
|
|
|
res->start = start;
|
|
|
|
res->end = end;
|
|
|
|
if (sizeof(resource_size_t) < sizeof(u64) &&
|
|
|
|
(offset != win->offset || start != res->start || end != res->end)) {
|
|
|
|
pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
|
|
|
|
attr->minimum, attr->maximum);
|
|
|
|
return false;
|
2015-02-02 10:42:59 +08:00
|
|
|
}
|
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
switch (addr->resource_type) {
|
|
|
|
case ACPI_MEMORY_RANGE:
|
2015-02-02 10:42:52 +08:00
|
|
|
acpi_dev_memresource_flags(res, len, wp);
|
2015-02-02 10:42:51 +08:00
|
|
|
break;
|
|
|
|
case ACPI_IO_RANGE:
|
2015-10-14 14:29:36 +08:00
|
|
|
acpi_dev_ioresource_flags(res, len, iodec,
|
|
|
|
addr->info.io.translation_type);
|
2015-02-02 10:42:51 +08:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_NUMBER_RANGE:
|
|
|
|
res->flags = IORESOURCE_BUS;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-02-02 10:42:52 +08:00
|
|
|
if (addr->producer_consumer == ACPI_PRODUCER)
|
|
|
|
res->flags |= IORESOURCE_WINDOW;
|
2015-02-02 10:42:53 +08:00
|
|
|
|
|
|
|
if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
|
|
|
|
res->flags |= IORESOURCE_PREFETCH;
|
2015-02-02 10:42:52 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
return !(res->flags & IORESOURCE_DISABLED);
|
|
|
|
}
|
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
/**
|
|
|
|
* acpi_dev_resource_address_space - Extract ACPI address space information.
|
|
|
|
* @ares: Input ACPI resource object.
|
2015-02-02 10:42:58 +08:00
|
|
|
* @win: Output generic resource object.
|
2012-11-15 07:30:01 +08:00
|
|
|
*
|
|
|
|
* Check if the given ACPI resource object represents an address space resource
|
|
|
|
* and if that's the case, use the information in it to populate the generic
|
2015-02-02 10:42:58 +08:00
|
|
|
* resource object pointed to by @win.
|
2015-02-02 10:42:55 +08:00
|
|
|
*
|
|
|
|
* Return:
|
2015-02-02 10:42:58 +08:00
|
|
|
* 1) false with win->res.flags setting to zero: not the expected resource type
|
|
|
|
* 2) false with IORESOURCE_DISABLED in win->res.flags: valid unassigned
|
|
|
|
* resource
|
2015-02-02 10:42:55 +08:00
|
|
|
* 3) true: valid assigned resource
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
|
|
|
bool acpi_dev_resource_address_space(struct acpi_resource *ares,
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource_win *win)
|
2012-11-15 07:30:01 +08:00
|
|
|
{
|
|
|
|
struct acpi_resource_address64 addr;
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
win->res.flags = 0;
|
2015-02-02 10:42:51 +08:00
|
|
|
if (ACPI_FAILURE(acpi_resource_to_address64(ares, &addr)))
|
2014-10-27 13:21:35 +08:00
|
|
|
return false;
|
2012-11-15 07:30:01 +08:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
return acpi_decode_space(win, (struct acpi_resource_address *)&addr,
|
2015-02-02 10:42:51 +08:00
|
|
|
&addr.address);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_resource_ext_address_space - Extract ACPI address space information.
|
|
|
|
* @ares: Input ACPI resource object.
|
2015-02-02 10:42:58 +08:00
|
|
|
* @win: Output generic resource object.
|
2012-11-15 07:30:01 +08:00
|
|
|
*
|
|
|
|
* Check if the given ACPI resource object represents an extended address space
|
|
|
|
* resource and if that's the case, use the information in it to populate the
|
2015-02-02 10:42:58 +08:00
|
|
|
* generic resource object pointed to by @win.
|
2015-02-02 10:42:55 +08:00
|
|
|
*
|
|
|
|
* Return:
|
2015-02-02 10:42:58 +08:00
|
|
|
* 1) false with win->res.flags setting to zero: not the expected resource type
|
|
|
|
* 2) false with IORESOURCE_DISABLED in win->res.flags: valid unassigned
|
|
|
|
* resource
|
2015-02-02 10:42:55 +08:00
|
|
|
* 3) true: valid assigned resource
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
|
|
|
bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource_win *win)
|
2012-11-15 07:30:01 +08:00
|
|
|
{
|
|
|
|
struct acpi_resource_extended_address64 *ext_addr;
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
win->res.flags = 0;
|
2012-11-15 07:30:01 +08:00
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
ext_addr = &ares->data.ext_address64;
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
return acpi_decode_space(win, (struct acpi_resource_address *)ext_addr,
|
2015-02-02 10:42:51 +08:00
|
|
|
&ext_addr->address);
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resource_ext_address_space);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_irq_flags - Determine IRQ resource flags.
|
|
|
|
* @triggering: Triggering type as provided by ACPI.
|
|
|
|
* @polarity: Interrupt polarity as provided by ACPI.
|
|
|
|
* @shareable: Whether or not the interrupt is shareable.
|
|
|
|
*/
|
|
|
|
unsigned long acpi_dev_irq_flags(u8 triggering, u8 polarity, u8 shareable)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
if (triggering == ACPI_LEVEL_SENSITIVE)
|
|
|
|
flags = polarity == ACPI_ACTIVE_LOW ?
|
|
|
|
IORESOURCE_IRQ_LOWLEVEL : IORESOURCE_IRQ_HIGHLEVEL;
|
|
|
|
else
|
|
|
|
flags = polarity == ACPI_ACTIVE_LOW ?
|
|
|
|
IORESOURCE_IRQ_LOWEDGE : IORESOURCE_IRQ_HIGHEDGE;
|
|
|
|
|
|
|
|
if (shareable == ACPI_SHARED)
|
|
|
|
flags |= IORESOURCE_IRQ_SHAREABLE;
|
|
|
|
|
|
|
|
return flags | IORESOURCE_IRQ;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_irq_flags);
|
|
|
|
|
2015-12-24 06:25:33 +08:00
|
|
|
/**
|
|
|
|
* acpi_dev_get_irq_type - Determine irq type.
|
|
|
|
* @triggering: Triggering type as provided by ACPI.
|
|
|
|
* @polarity: Interrupt polarity as provided by ACPI.
|
|
|
|
*/
|
|
|
|
unsigned int acpi_dev_get_irq_type(int triggering, int polarity)
|
|
|
|
{
|
|
|
|
switch (polarity) {
|
|
|
|
case ACPI_ACTIVE_LOW:
|
|
|
|
return triggering == ACPI_EDGE_SENSITIVE ?
|
|
|
|
IRQ_TYPE_EDGE_FALLING :
|
|
|
|
IRQ_TYPE_LEVEL_LOW;
|
|
|
|
case ACPI_ACTIVE_HIGH:
|
|
|
|
return triggering == ACPI_EDGE_SENSITIVE ?
|
|
|
|
IRQ_TYPE_EDGE_RISING :
|
|
|
|
IRQ_TYPE_LEVEL_HIGH;
|
|
|
|
case ACPI_ACTIVE_BOTH:
|
|
|
|
if (triggering == ACPI_EDGE_SENSITIVE)
|
|
|
|
return IRQ_TYPE_EDGE_BOTH;
|
|
|
|
default:
|
|
|
|
return IRQ_TYPE_NONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_get_irq_type);
|
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
|
|
|
|
{
|
|
|
|
res->start = gsi;
|
|
|
|
res->end = gsi;
|
2015-02-02 10:42:56 +08:00
|
|
|
res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
|
2012-11-15 07:30:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
u8 triggering, u8 polarity, u8 shareable,
|
|
|
|
bool legacy)
|
2012-11-15 07:30:01 +08:00
|
|
|
{
|
|
|
|
int irq, p, t;
|
|
|
|
|
|
|
|
if (!valid_IRQ(gsi)) {
|
|
|
|
acpi_dev_irqresource_disabled(res, gsi);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In IO-APIC mode, use overrided attribute. Two reasons:
|
|
|
|
* 1. BIOS bug in DSDT
|
|
|
|
* 2. BIOS uses IO-APIC mode Interrupt Source Override
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
*
|
|
|
|
* We do this only if we are dealing with IRQ() or IRQNoFlags()
|
|
|
|
* resource (the legacy ISA resources). With modern ACPI 5 devices
|
|
|
|
* using extended IRQ descriptors we take the IRQ configuration
|
|
|
|
* from _CRS directly.
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
|
2012-11-15 07:30:01 +08:00
|
|
|
u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
|
|
|
|
u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
|
|
|
|
|
|
|
|
if (triggering != trig || polarity != pol) {
|
|
|
|
pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
t ? "level" : "edge", p ? "low" : "high");
|
2012-11-15 07:30:01 +08:00
|
|
|
triggering = trig;
|
|
|
|
polarity = pol;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
|
|
|
|
irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
|
|
|
|
if (irq >= 0) {
|
|
|
|
res->start = irq;
|
|
|
|
res->end = irq;
|
|
|
|
} else {
|
|
|
|
acpi_dev_irqresource_disabled(res, gsi);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_resource_interrupt - Extract ACPI interrupt resource information.
|
|
|
|
* @ares: Input ACPI resource object.
|
|
|
|
* @index: Index into the array of GSIs represented by the resource.
|
|
|
|
* @res: Output generic resource object.
|
|
|
|
*
|
|
|
|
* Check if the given ACPI resource object represents an interrupt resource
|
|
|
|
* and @index does not exceed the resource's interrupt count (true is returned
|
|
|
|
* in that case regardless of the results of the other checks)). If that's the
|
|
|
|
* case, register the GSI corresponding to @index from the array of interrupts
|
|
|
|
* represented by the resource and populate the generic resource object pointed
|
|
|
|
* to by @res accordingly. If the registration of the GSI is not successful,
|
|
|
|
* IORESOURCE_DISABLED will be set it that object's flags.
|
2015-02-02 10:42:55 +08:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* 1) false with res->flags setting to zero: not the expected resource type
|
|
|
|
* 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned resource
|
|
|
|
* 3) true: valid assigned resource
|
2012-11-15 07:30:01 +08:00
|
|
|
*/
|
|
|
|
bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
|
|
|
|
struct resource *res)
|
|
|
|
{
|
|
|
|
struct acpi_resource_irq *irq;
|
|
|
|
struct acpi_resource_extended_irq *ext_irq;
|
|
|
|
|
|
|
|
switch (ares->type) {
|
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
|
|
|
/*
|
|
|
|
* Per spec, only one interrupt per descriptor is allowed in
|
|
|
|
* _CRS, but some firmware violates this, so parse them all.
|
|
|
|
*/
|
|
|
|
irq = &ares->data.irq;
|
|
|
|
if (index >= irq->interrupt_count) {
|
|
|
|
acpi_dev_irqresource_disabled(res, 0);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
acpi_dev_get_irqresource(res, irq->interrupts[index],
|
|
|
|
irq->triggering, irq->polarity,
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
irq->sharable, true);
|
2012-11-15 07:30:01 +08:00
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
|
|
|
ext_irq = &ares->data.extended_irq;
|
|
|
|
if (index >= ext_irq->interrupt_count) {
|
|
|
|
acpi_dev_irqresource_disabled(res, 0);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
|
|
|
|
ext_irq->triggering, ext_irq->polarity,
|
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-20 23:41:45 +08:00
|
|
|
ext_irq->sharable, false);
|
2012-11-15 07:30:01 +08:00
|
|
|
break;
|
|
|
|
default:
|
2015-02-02 10:42:55 +08:00
|
|
|
res->flags = 0;
|
2012-11-15 07:30:01 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_free_resource_list - Free resource from %acpi_dev_get_resources().
|
|
|
|
* @list: The head of the resource list to free.
|
|
|
|
*/
|
|
|
|
void acpi_dev_free_resource_list(struct list_head *list)
|
|
|
|
{
|
2015-02-05 13:44:43 +08:00
|
|
|
resource_list_free(list);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
|
|
|
|
|
|
|
|
struct res_proc_context {
|
|
|
|
struct list_head *list;
|
|
|
|
int (*preproc)(struct acpi_resource *, void *);
|
|
|
|
void *preproc_data;
|
|
|
|
int count;
|
|
|
|
int error;
|
|
|
|
};
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
static acpi_status acpi_dev_new_resource_entry(struct resource_win *win,
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
struct res_proc_context *c)
|
|
|
|
{
|
2015-02-05 13:44:43 +08:00
|
|
|
struct resource_entry *rentry;
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
rentry = resource_list_create_entry(NULL, 0);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
if (!rentry) {
|
|
|
|
c->error = -ENOMEM;
|
|
|
|
return AE_NO_MEMORY;
|
|
|
|
}
|
2015-02-05 13:44:43 +08:00
|
|
|
*rentry->res = win->res;
|
2015-02-02 10:43:00 +08:00
|
|
|
rentry->offset = win->offset;
|
2015-02-05 13:44:43 +08:00
|
|
|
resource_list_add_tail(rentry, c->list);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
c->count++;
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
|
|
|
|
void *context)
|
|
|
|
{
|
|
|
|
struct res_proc_context *c = context;
|
2015-02-02 10:42:58 +08:00
|
|
|
struct resource_win win;
|
|
|
|
struct resource *res = &win.res;
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (c->preproc) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = c->preproc(ares, c->preproc_data);
|
|
|
|
if (ret < 0) {
|
|
|
|
c->error = ret;
|
2012-11-17 04:55:48 +08:00
|
|
|
return AE_CTRL_TERMINATE;
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
} else if (ret > 0) {
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
memset(&win, 0, sizeof(win));
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
if (acpi_dev_resource_memory(ares, res)
|
|
|
|
|| acpi_dev_resource_io(ares, res)
|
|
|
|
|| acpi_dev_resource_address_space(ares, &win)
|
|
|
|
|| acpi_dev_resource_ext_address_space(ares, &win))
|
|
|
|
return acpi_dev_new_resource_entry(&win, c);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
for (i = 0; acpi_dev_resource_interrupt(ares, i, res); i++) {
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
status = acpi_dev_new_resource_entry(&win, c);
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_get_resources - Get current resources of a device.
|
|
|
|
* @adev: ACPI device node to get the resources for.
|
|
|
|
* @list: Head of the resultant list of resources (must be empty).
|
|
|
|
* @preproc: The caller's preprocessing routine.
|
|
|
|
* @preproc_data: Pointer passed to the caller's preprocessing routine.
|
|
|
|
*
|
|
|
|
* Evaluate the _CRS method for the given device node and process its output by
|
|
|
|
* (1) executing the @preproc() rountine provided by the caller, passing the
|
|
|
|
* resource pointer and @preproc_data to it as arguments, for each ACPI resource
|
|
|
|
* returned and (2) converting all of the returned ACPI resources into struct
|
|
|
|
* resource objects if possible. If the return value of @preproc() in step (1)
|
|
|
|
* is different from 0, step (2) is not applied to the given ACPI resource and
|
|
|
|
* if that value is negative, the whole processing is aborted and that value is
|
|
|
|
* returned as the final error code.
|
|
|
|
*
|
|
|
|
* The resultant struct resource objects are put on the list pointed to by
|
2015-02-05 13:44:43 +08:00
|
|
|
* @list, that must be empty initially, as members of struct resource_entry
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
* objects. Callers of this routine should use %acpi_dev_free_resource_list() to
|
|
|
|
* free that list.
|
|
|
|
*
|
|
|
|
* The number of resources in the output list is returned on success, an error
|
|
|
|
* code reflecting the error condition is returned otherwise.
|
|
|
|
*/
|
|
|
|
int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
|
|
|
|
int (*preproc)(struct acpi_resource *, void *),
|
|
|
|
void *preproc_data)
|
|
|
|
{
|
|
|
|
struct res_proc_context c;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
if (!adev || !adev->handle || !list_empty(list))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
|
ACPI: Centralized processing of ACPI device resources
Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items. This generally
is cumbersome, time-consuming and inefficient. Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way. However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.
For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.
Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.
In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-15 07:30:21 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
c.list = list;
|
|
|
|
c.preproc = preproc;
|
|
|
|
c.preproc_data = preproc_data;
|
|
|
|
c.count = 0;
|
|
|
|
c.error = 0;
|
|
|
|
status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
|
|
|
|
acpi_dev_process_resource, &c);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
acpi_dev_free_resource_list(list);
|
|
|
|
return c.error ? c.error : -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return c.count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_get_resources);
|
2015-02-02 10:43:01 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_dev_filter_resource_type - Filter ACPI resource according to resource
|
|
|
|
* types
|
|
|
|
* @ares: Input ACPI resource object.
|
|
|
|
* @types: Valid resource types of IORESOURCE_XXX
|
|
|
|
*
|
2015-04-30 12:41:28 +08:00
|
|
|
* This is a helper function to support acpi_dev_get_resources(), which filters
|
2015-02-02 10:43:01 +08:00
|
|
|
* ACPI resource objects according to resource types.
|
|
|
|
*/
|
|
|
|
int acpi_dev_filter_resource_type(struct acpi_resource *ares,
|
|
|
|
unsigned long types)
|
|
|
|
{
|
|
|
|
unsigned long type = 0;
|
|
|
|
|
|
|
|
switch (ares->type) {
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
|
|
|
type = IORESOURCE_MEM;
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
|
|
|
type = IORESOURCE_IO;
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
|
|
|
type = IORESOURCE_IRQ;
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_DMA:
|
|
|
|
type = IORESOURCE_DMA;
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
|
|
|
type = IORESOURCE_REG;
|
|
|
|
break;
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS16:
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS32:
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS64:
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
|
|
|
if (ares->data.address.resource_type == ACPI_MEMORY_RANGE)
|
|
|
|
type = IORESOURCE_MEM;
|
|
|
|
else if (ares->data.address.resource_type == ACPI_IO_RANGE)
|
|
|
|
type = IORESOURCE_IO;
|
|
|
|
else if (ares->data.address.resource_type ==
|
|
|
|
ACPI_BUS_NUMBER_RANGE)
|
|
|
|
type = IORESOURCE_BUS;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (type & types) ? 0 : 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
|