2019-05-27 08:55:21 +02:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
2015-12-23 23:25:33 +01:00
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
2025-08-23 15:03:11 -07:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-21 11:12:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2016-03-21 11:12:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2017-02-02 18:23:57 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-04 16:47:12 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
2015-03-04 16:47:12 +08:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
|
|
2015-02-18 08:05:43 +01:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:52 +08:00
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:56 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:52 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:54 +08:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:48 +08:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
2015-10-14 14:29:36 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:56 +08:00
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
2016-03-21 11:12:55 +00:00
|
|
|
|
2015-02-02 10:42:56 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
2015-10-14 14:29:36 +08:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
2015-10-14 14:29:36 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:49 +08:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
2015-02-02 10:42:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:59 +08:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:59 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:52 +08:00
|
|
|
|
2024-12-02 12:06:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
|
|
|
|
|
2015-10-14 14:29:36 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:52 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:53 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
2014-10-27 13:21:35 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
2015-02-02 10:42:51 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-23 23:25:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:09:37 -05:00
|
|
|
|
2015-12-23 23:25:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: resource: Consolidate IRQ trigger-type override DMI tables
Before this patch there were 6 dmi_system_id tables. While looking at
the override_table[] there are only 2 cases:
1. irq 1, level, active-low, not-shared, skip-override
2. irq 1, edge, activ-low, shared, force-override
Merge the dmi_system_id tables for identical cases together,
going from 6 dmi_system_id tables and 6 override_table[] entries
to just 2, one for each case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-13 13:19:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-25 14:16:01 +08:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2021-10-25 14:16:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-19 03:12:05 +01:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2023-03-19 03:12:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-28 23:04:19 -04:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2022-08-28 23:04:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2022-08-28 23:04:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-21 10:24:22 -07:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2022-09-21 10:24:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-14 01:19:31 -04:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2022-10-14 01:19:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-18 17:09:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-20 19:13:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-27 16:16:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-12 12:08:27 +02:00
|
|
|
|
2024-10-05 23:28:18 +02:00
|
|
|
|
2023-09-12 12:08:27 +02:00
|
|
|
|
|
|
|
|
|
2024-10-05 23:28:18 +02:00
|
|
|
|
2023-09-12 12:08:27 +02:00
|
|
|
|
|
|
|
|
|
2023-11-15 19:02:22 +01:00
|
|
|
|
2024-10-05 23:28:18 +02:00
|
|
|
|
2023-11-15 19:02:22 +01:00
|
|
|
|
|
|
|
|
|
2024-10-05 23:28:18 +02:00
|
|
|
|
2023-11-15 19:02:22 +01:00
|
|
|
|
|
|
|
|
|
2022-12-30 00:58:39 -05:00
|
|
|
|
2024-10-05 23:28:16 +02:00
|
|
|
|
2022-12-30 00:58:39 -05:00
|
|
|
|
|
|
|
|
|
2024-10-05 23:28:16 +02:00
|
|
|
|
2023-02-16 09:01:15 +01:00
|
|
|
|
|
|
|
|
|
2022-12-15 10:44:43 +01:00
|
|
|
|
2024-10-05 23:28:17 +02:00
|
|
|
|
2022-12-15 10:44:43 +01:00
|
|
|
|
|
|
|
|
|
2024-10-05 23:28:17 +02:00
|
|
|
|
2024-09-27 16:16:06 +02:00
|
|
|
|
|
|
|
|
|
2024-09-02 21:43:05 -04:00
|
|
|
|
2024-09-27 16:16:04 +02:00
|
|
|
|
2024-09-02 21:43:05 -04:00
|
|
|
|
|
|
|
|
|
2024-09-27 16:16:04 +02:00
|
|
|
|
2024-09-02 21:43:05 -04:00
|
|
|
|
|
|
|
|
|
2024-01-06 21:13:23 -05:00
|
|
|
|
2024-09-27 16:16:03 +02:00
|
|
|
|
2024-01-06 21:13:23 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-28 13:08:12 -04:00
|
|
|
|
2024-10-05 23:28:19 +02:00
|
|
|
|
2024-04-28 13:08:12 -04:00
|
|
|
|
|
|
|
|
|
2024-10-05 23:28:19 +02:00
|
|
|
|
2024-07-07 20:05:50 -04:00
|
|
|
|
|
|
|
|
|
2025-08-29 14:52:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
ACPI: resource: Consolidate IRQ trigger-type override DMI tables
Before this patch there were 6 dmi_system_id tables. While looking at
the override_table[] there are only 2 cases:
1. irq 1, level, active-low, not-shared, skip-override
2. irq 1, edge, activ-low, shared, force-override
Merge the dmi_system_id tables for identical cases together,
going from 6 dmi_system_id tables and 6 override_table[] entries
to just 2, one for each case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-13 13:19:50 +02:00
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
2024-10-17 13:16:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-13 15:27:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: resource: Consolidate IRQ trigger-type override DMI tables
Before this patch there were 6 dmi_system_id tables. While looking at
the override_table[] there are only 2 cases:
1. irq 1, level, active-low, not-shared, skip-override
2. irq 1, edge, activ-low, shared, force-override
Merge the dmi_system_id tables for identical cases together,
going from 6 dmi_system_id tables and 6 override_table[] entries
to just 2, one for each case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-13 13:19:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-03 16:13:18 +08:00
|
|
|
|
2025-04-17 15:39:46 +08:00
|
|
|
|
2024-08-03 16:13:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-15 20:51:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-16 18:08:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-10 11:40:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-23 15:57:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-27 02:39:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-16 18:08:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-13 13:19:51 +02:00
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:00:11 +02:00
|
|
|
|
2023-10-09 14:11:01 +02:00
|
|
|
|
2023-08-10 11:00:11 +02:00
|
|
|
|
2023-08-21 11:09:27 +02:00
|
|
|
|
2023-10-09 14:11:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:00:11 +02:00
|
|
|
|
|
|
|
|
|
2024-01-03 12:55:18 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-16 12:30:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-23 19:24:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-04 12:26:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-22 10:04:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-03 20:20:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-28 17:48:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-10 11:00:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-04 12:33:40 +02:00
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
2022-10-04 12:33:40 +02:00
|
|
|
|
ACPI: resource: Consolidate IRQ trigger-type override DMI tables
Before this patch there were 6 dmi_system_id tables. While looking at
the override_table[] there are only 2 cases:
1. irq 1, level, active-low, not-shared, skip-override
2. irq 1, edge, activ-low, shared, force-override
Merge the dmi_system_id tables for identical cases together,
going from 6 dmi_system_id tables and 6 override_table[] entries
to just 2, one for each case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-13 13:19:50 +02:00
|
|
|
|
2026-01-13 15:27:19 +08:00
|
|
|
|
|
|
|
|
|
ACPI: resource: Consolidate IRQ trigger-type override DMI tables
Before this patch there were 6 dmi_system_id tables. While looking at
the override_table[] there are only 2 cases:
1. irq 1, level, active-low, not-shared, skip-override
2. irq 1, edge, activ-low, shared, force-override
Merge the dmi_system_id tables for identical cases together,
going from 6 dmi_system_id tables and 6 override_table[] entries
to just 2, one for each case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-09-13 13:19:50 +02:00
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-04 12:33:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-28 17:52:53 +01:00
|
|
|
|
2022-10-04 12:33:40 +02:00
|
|
|
|
|
|
|
|
|
2024-12-28 17:52:53 +01:00
|
|
|
|
|
|
|
|
|
2022-10-04 12:33:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
2023-08-09 10:55:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-09 10:55:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01: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 15:41:45 +00:00
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-27 14:29:28 -08:00
|
|
|
|
2012-11-15 00:30:01 +01: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 15:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2021-09-15 21:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-04 12:33:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-23 15:03:11 -07:00
|
|
|
|
2022-10-04 12:33:41 +02:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2017-02-02 18:23:57 -05:00
|
|
|
|
|
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
2022-09-29 10:19:10 -06:00
|
|
|
|
|
|
|
|
|
2017-02-02 18:23:57 -05:00
|
|
|
|
2020-12-02 18:36:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:55 +08:00
|
|
|
|
2012-11-15 00:30:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
2026-06-17 11:05:55 +02:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
2015-02-02 10:43:00 +08:00
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-05 17:04:03 +00:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:42:58 +08:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-03 13:32:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-12 18:55:35 -07:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 13:44:43 +08:00
|
|
|
|
2026-06-17 11:05:55 +02:00
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-03 13:32:36 +01:00
|
|
|
|
|
|
|
|
|
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 00:30:21 +01:00
|
|
|
|
|
|
|
|
|
2015-02-02 10:43:01 +08:00
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-16 13:16:25 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-17 11:05:55 +02:00
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-16 13:16:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 10:43:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-30 12:41:28 +08:00
|
|
|
|
2015-02-02 10:43:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-30 14:47:13 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 17:37:10 +01:00
|
|
|
|
2016-11-30 14:47:13 -06:00
|
|
|
|
2021-12-03 17:37:10 +01:00
|
|
|
|
2016-11-30 14:47:13 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
