2019-06-04 08:11:33 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-10-31 21:45:02 +00:00
|
|
|
/*
|
|
|
|
* ACPI support for platform bus type.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012, Intel Corporation
|
|
|
|
* Authors: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
|
|
* Mathias Nyman <mathias.nyman@linux.intel.com>
|
|
|
|
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/device.h>
|
2013-01-18 13:46:01 +00:00
|
|
|
#include <linux/err.h>
|
2012-10-31 21:45:02 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
2014-09-24 08:00:37 +00:00
|
|
|
#include <linux/dma-mapping.h>
|
ACPI / platform: Pay attention to parent device's resources
Given following simplified device hierarchy:
// PCI device having BAR0 (RMEM) split between 4 GPIO devices.
Device (P2S)
{
Name (_ADR, 0x000d0000)
Device (GPO0)
{
Name (_HID, "INT3452")
Name (_UID, 1)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000)
})
}
Device (GPO1)
{
Name (_HID, "INT3452")
Name (_UID, 2)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000)
})
}
Device (GPO2)
{
Name (_HID, "INT3452")
Name (_UID, 3)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000)
})
}
Device (GPO3)
{
Name (_HID, "INT3452")
Name (_UID, 4)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000)
})
}
}
The current ACPI platform enumeration code allocates resources from the
global MMIO resource pool (/proc/iomem) for all the four GPIO devices.
After this PCI core calls pcibios_resource_survey() to allocate resources
for all PCI devices including the parent device for these GPIO devices
(P2S). Since that resource range has already been reserved the allocation
fails.
The reason for this is that we never bother with parent device's resources
when ACPI platform devices are created.
Fix this by checking whether there is a parent device and in that case make
sure we assign correct parent resource to the resources for the child ACPI
platform device. Currently we only deal with parent devices if they are PCI
devices but we may expand this later to cover other bus types as well.
Reported-by: Aaron Durbin <adurbin@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-15 08:07:04 +00:00
|
|
|
#include <linux/pci.h>
|
2012-10-31 21:45:02 +00:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
|
2012-11-26 09:35:07 +00:00
|
|
|
#include "internal.h"
|
|
|
|
|
2014-05-30 12:35:34 +00:00
|
|
|
static const struct acpi_device_id forbidden_id_list[] = {
|
2022-08-31 14:03:27 +00:00
|
|
|
{"ACPI0009", 0}, /* IOxAPIC */
|
|
|
|
{"ACPI000A", 0}, /* IOAPIC */
|
2017-03-22 17:33:25 +00:00
|
|
|
{"PNP0000", 0}, /* PIC */
|
|
|
|
{"PNP0100", 0}, /* Timer */
|
|
|
|
{"PNP0200", 0}, /* AT DMA Controller */
|
ACPI / platform: Add SMB0001 HID to forbidden_id_list
Many HP AMD based laptops contain an SMB0001 device like this:
Device (SMBD)
{
Name (_HID, "SMB0001") // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0B20, // Range Minimum
0x0B20, // Range Maximum
0x20, // Alignment
0x20, // Length
)
IRQ (Level, ActiveLow, Shared, )
{7}
})
}
The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
be called with legacy=true and this message to show in dmesg:
ACPI: IRQ 7 override to edge, high
This causes issues when later on the AMD0030 GPIO device gets enumerated:
Device (GPIO)
{
Name (_HID, "AMDI0030") // _HID: Hardware ID
Name (_CID, "AMDI0030") // _CID: Compatible ID
Name (_UID, Zero) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000007,
}
Memory32Fixed (ReadWrite,
0xFED81500, // Address Base
0x00000400, // Address Length
)
})
Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
}
}
Now acpi_dev_get_irqresource() gets called with legacy=false, but because
of the earlier override of the trigger-type acpi_register_gsi() returns
-EBUSY (because we try to register the same interrupt with a different
trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
resulting in the following in dmesg:
amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
amd_gpio: probe of AMDI0030:00 failed with error -22
The SMB0001 is a "virtual" device in the sense that the only way the OS
interacts with it is through calling a couple of methods to do SMBus
transfers. As such it is weird that it has IO and IRQ resources at all,
because the driver for it is not expected to ever access the hardware
directly.
The Linux driver for the SMB0001 device directly binds to the acpi_device
through the acpi_bus, so we do not need to instantiate a platform_device
for this ACPI device. This commit adds the SMB0001 HID to the
forbidden_id_list, avoiding the instantiating of a platform_device for it.
Not instantiating a platform_device means we will no longer call
acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
the AMDI0030 device failing.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523
Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
Tested-by: Marc <suaefar@googlemail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-11-19 18:06:01 +00:00
|
|
|
{"SMB0001", 0}, /* ACPI SMBUS virtual device */
|
2022-08-31 14:03:27 +00:00
|
|
|
{ }
|
2013-01-30 13:27:40 +00:00
|
|
|
};
|
|
|
|
|
2019-08-30 14:34:32 +00:00
|
|
|
static struct platform_device *acpi_platform_device_find_by_companion(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
dev = bus_find_device_by_acpi_dev(&platform_bus_type, adev);
|
|
|
|
return dev ? to_platform_device(dev) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_platform_device_remove_notify(struct notifier_block *nb,
|
|
|
|
unsigned long value, void *arg)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = arg;
|
|
|
|
struct platform_device *pdev;
|
|
|
|
|
|
|
|
switch (value) {
|
|
|
|
case ACPI_RECONFIG_DEVICE_ADD:
|
|
|
|
/* Nothing to do here */
|
|
|
|
break;
|
|
|
|
case ACPI_RECONFIG_DEVICE_REMOVE:
|
|
|
|
if (!acpi_device_enumerated(adev))
|
|
|
|
break;
|
|
|
|
|
|
|
|
pdev = acpi_platform_device_find_by_companion(adev);
|
|
|
|
if (!pdev)
|
|
|
|
break;
|
|
|
|
|
|
|
|
platform_device_unregister(pdev);
|
|
|
|
put_device(&pdev->dev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block acpi_platform_notifier = {
|
|
|
|
.notifier_call = acpi_platform_device_remove_notify,
|
|
|
|
};
|
|
|
|
|
ACPI / platform: Pay attention to parent device's resources
Given following simplified device hierarchy:
// PCI device having BAR0 (RMEM) split between 4 GPIO devices.
Device (P2S)
{
Name (_ADR, 0x000d0000)
Device (GPO0)
{
Name (_HID, "INT3452")
Name (_UID, 1)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000)
})
}
Device (GPO1)
{
Name (_HID, "INT3452")
Name (_UID, 2)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000)
})
}
Device (GPO2)
{
Name (_HID, "INT3452")
Name (_UID, 3)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000)
})
}
Device (GPO3)
{
Name (_HID, "INT3452")
Name (_UID, 4)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000)
})
}
}
The current ACPI platform enumeration code allocates resources from the
global MMIO resource pool (/proc/iomem) for all the four GPIO devices.
After this PCI core calls pcibios_resource_survey() to allocate resources
for all PCI devices including the parent device for these GPIO devices
(P2S). Since that resource range has already been reserved the allocation
fails.
The reason for this is that we never bother with parent device's resources
when ACPI platform devices are created.
Fix this by checking whether there is a parent device and in that case make
sure we assign correct parent resource to the resources for the child ACPI
platform device. Currently we only deal with parent devices if they are PCI
devices but we may expand this later to cover other bus types as well.
Reported-by: Aaron Durbin <adurbin@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-15 08:07:04 +00:00
|
|
|
static void acpi_platform_fill_resource(struct acpi_device *adev,
|
|
|
|
const struct resource *src, struct resource *dest)
|
|
|
|
{
|
|
|
|
struct device *parent;
|
|
|
|
|
|
|
|
*dest = *src;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the device has parent we need to take its resources into
|
|
|
|
* account as well because this device might consume part of those.
|
|
|
|
*/
|
2022-08-24 16:59:48 +00:00
|
|
|
parent = acpi_get_first_physical_node(acpi_dev_parent(adev));
|
ACPI / platform: Pay attention to parent device's resources
Given following simplified device hierarchy:
// PCI device having BAR0 (RMEM) split between 4 GPIO devices.
Device (P2S)
{
Name (_ADR, 0x000d0000)
Device (GPO0)
{
Name (_HID, "INT3452")
Name (_UID, 1)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000)
})
}
Device (GPO1)
{
Name (_HID, "INT3452")
Name (_UID, 2)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000)
})
}
Device (GPO2)
{
Name (_HID, "INT3452")
Name (_UID, 3)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000)
})
}
Device (GPO3)
{
Name (_HID, "INT3452")
Name (_UID, 4)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000)
})
}
}
The current ACPI platform enumeration code allocates resources from the
global MMIO resource pool (/proc/iomem) for all the four GPIO devices.
After this PCI core calls pcibios_resource_survey() to allocate resources
for all PCI devices including the parent device for these GPIO devices
(P2S). Since that resource range has already been reserved the allocation
fails.
The reason for this is that we never bother with parent device's resources
when ACPI platform devices are created.
Fix this by checking whether there is a parent device and in that case make
sure we assign correct parent resource to the resources for the child ACPI
platform device. Currently we only deal with parent devices if they are PCI
devices but we may expand this later to cover other bus types as well.
Reported-by: Aaron Durbin <adurbin@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-15 08:07:04 +00:00
|
|
|
if (parent && dev_is_pci(parent))
|
|
|
|
dest->parent = pci_find_resource(to_pci_dev(parent), dest);
|
|
|
|
}
|
|
|
|
|
2012-10-31 21:45:02 +00:00
|
|
|
/**
|
|
|
|
* acpi_create_platform_device - Create platform device for ACPI device node
|
|
|
|
* @adev: ACPI device node to create a platform device for.
|
2016-11-03 14:21:26 +00:00
|
|
|
* @properties: Optional collection of build-in properties.
|
2012-10-31 21:45:02 +00:00
|
|
|
*
|
|
|
|
* Check if the given @adev can be represented as a platform device and, if
|
|
|
|
* that's the case, create and register a platform device, populate its common
|
|
|
|
* resources and returns a pointer to it. Otherwise, return %NULL.
|
|
|
|
*
|
2013-01-18 14:09:35 +00:00
|
|
|
* Name of the platform device will be the same as @adev's.
|
2012-10-31 21:45:02 +00:00
|
|
|
*/
|
2016-11-03 14:21:26 +00:00
|
|
|
struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
|
2022-02-23 23:56:20 +00:00
|
|
|
const struct property_entry *properties)
|
2012-10-31 21:45:02 +00:00
|
|
|
{
|
2022-08-24 16:59:48 +00:00
|
|
|
struct acpi_device *parent = acpi_dev_parent(adev);
|
2012-10-31 21:45:02 +00:00
|
|
|
struct platform_device *pdev = NULL;
|
ACPI / platform: Initialize ACPI handles of platform devices in advance
The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted. This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code. However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it. This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.
Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward. Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type. In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-20 23:21:59 +00:00
|
|
|
struct platform_device_info pdevinfo;
|
2015-02-05 05:44:43 +00: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-14 23:30:21 +00:00
|
|
|
struct list_head resource_list;
|
2013-07-22 23:51:20 +00:00
|
|
|
struct resource *resources = NULL;
|
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-14 23:30:21 +00:00
|
|
|
int count;
|
2012-10-31 21:45:02 +00:00
|
|
|
|
|
|
|
/* If the ACPI node already has a physical device attached, skip it. */
|
|
|
|
if (adev->physical_node_count)
|
2014-05-25 12:38:52 +00:00
|
|
|
return NULL;
|
2012-10-31 21:45:02 +00:00
|
|
|
|
2014-05-30 12:35:34 +00:00
|
|
|
if (!acpi_match_device_ids(adev, forbidden_id_list))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
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-14 23:30:21 +00:00
|
|
|
INIT_LIST_HEAD(&resource_list);
|
|
|
|
count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
|
2022-08-31 14:03:24 +00:00
|
|
|
if (count < 0)
|
2014-05-25 12:38:52 +00:00
|
|
|
return NULL;
|
2022-08-31 14:03:24 +00:00
|
|
|
if (count > 0) {
|
2022-08-31 14:03:26 +00:00
|
|
|
resources = kcalloc(count, sizeof(*resources), GFP_KERNEL);
|
2013-08-06 23:11:33 +00:00
|
|
|
if (!resources) {
|
|
|
|
acpi_dev_free_resource_list(&resource_list);
|
2014-05-25 12:38:52 +00:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2013-08-06 23:11:33 +00:00
|
|
|
}
|
|
|
|
count = 0;
|
|
|
|
list_for_each_entry(rentry, &resource_list, node)
|
ACPI / platform: Pay attention to parent device's resources
Given following simplified device hierarchy:
// PCI device having BAR0 (RMEM) split between 4 GPIO devices.
Device (P2S)
{
Name (_ADR, 0x000d0000)
Device (GPO0)
{
Name (_HID, "INT3452")
Name (_UID, 1)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000)
})
}
Device (GPO1)
{
Name (_HID, "INT3452")
Name (_UID, 2)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000)
})
}
Device (GPO2)
{
Name (_HID, "INT3452")
Name (_UID, 3)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000)
})
}
Device (GPO3)
{
Name (_HID, "INT3452")
Name (_UID, 4)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000)
})
}
}
The current ACPI platform enumeration code allocates resources from the
global MMIO resource pool (/proc/iomem) for all the four GPIO devices.
After this PCI core calls pcibios_resource_survey() to allocate resources
for all PCI devices including the parent device for these GPIO devices
(P2S). Since that resource range has already been reserved the allocation
fails.
The reason for this is that we never bother with parent device's resources
when ACPI platform devices are created.
Fix this by checking whether there is a parent device and in that case make
sure we assign correct parent resource to the resources for the child ACPI
platform device. Currently we only deal with parent devices if they are PCI
devices but we may expand this later to cover other bus types as well.
Reported-by: Aaron Durbin <adurbin@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-15 08:07:04 +00:00
|
|
|
acpi_platform_fill_resource(adev, rentry->res,
|
|
|
|
&resources[count++]);
|
2012-10-31 21:45:02 +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-14 23:30:21 +00:00
|
|
|
acpi_dev_free_resource_list(&resource_list);
|
2012-10-31 21:45:02 +00:00
|
|
|
}
|
|
|
|
|
ACPI / platform: Initialize ACPI handles of platform devices in advance
The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted. This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code. However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it. This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.
Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward. Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type. In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-20 23:21:59 +00:00
|
|
|
memset(&pdevinfo, 0, sizeof(pdevinfo));
|
2012-10-31 21:45:02 +00:00
|
|
|
/*
|
|
|
|
* If the ACPI node has a parent and that parent has a physical device
|
|
|
|
* attached to it, that physical device should be the parent of the
|
|
|
|
* platform device we are about to create.
|
|
|
|
*/
|
2022-08-24 16:59:48 +00:00
|
|
|
pdevinfo.parent = parent ? acpi_get_first_physical_node(parent) : NULL;
|
ACPI / platform: Initialize ACPI handles of platform devices in advance
The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted. This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code. However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it. This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.
Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward. Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type. In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-20 23:21:59 +00:00
|
|
|
pdevinfo.name = dev_name(&adev->dev);
|
2022-09-01 10:04:11 +00:00
|
|
|
pdevinfo.id = PLATFORM_DEVID_NONE;
|
ACPI / platform: Initialize ACPI handles of platform devices in advance
The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted. This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code. However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it. This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.
Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward. Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type. In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-20 23:21:59 +00:00
|
|
|
pdevinfo.res = resources;
|
|
|
|
pdevinfo.num_res = count;
|
2015-03-16 22:49:03 +00:00
|
|
|
pdevinfo.fwnode = acpi_fwnode_handle(adev);
|
2016-11-03 14:21:26 +00:00
|
|
|
pdevinfo.properties = properties;
|
2015-10-28 22:50:50 +00:00
|
|
|
|
|
|
|
if (acpi_dma_supported(adev))
|
|
|
|
pdevinfo.dma_mask = DMA_BIT_MASK(32);
|
|
|
|
else
|
|
|
|
pdevinfo.dma_mask = 0;
|
|
|
|
|
ACPI / platform: Initialize ACPI handles of platform devices in advance
The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted. This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code. However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it. This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.
Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward. Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type. In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-20 23:21:59 +00:00
|
|
|
pdev = platform_device_register_full(&pdevinfo);
|
2014-05-25 12:38:52 +00:00
|
|
|
if (IS_ERR(pdev))
|
2012-10-31 21:45:02 +00:00
|
|
|
dev_err(&adev->dev, "platform device creation failed: %ld\n",
|
|
|
|
PTR_ERR(pdev));
|
2017-03-29 11:39:19 +00:00
|
|
|
else {
|
|
|
|
set_dev_node(&pdev->dev, acpi_get_node(adev->handle));
|
2012-10-31 21:45:02 +00:00
|
|
|
dev_dbg(&adev->dev, "created platform device %s\n",
|
|
|
|
dev_name(&pdev->dev));
|
2017-03-29 11:39:19 +00:00
|
|
|
}
|
2012-10-31 21:45:02 +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-14 23:30:21 +00:00
|
|
|
kfree(resources);
|
2017-03-29 11:39:19 +00:00
|
|
|
|
2014-05-25 12:38:52 +00:00
|
|
|
return pdev;
|
|
|
|
}
|
2014-03-14 06:06:25 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_create_platform_device);
|
2019-08-30 14:34:32 +00:00
|
|
|
|
|
|
|
void __init acpi_platform_init(void)
|
|
|
|
{
|
|
|
|
acpi_reconfig_notifier_register(&acpi_platform_notifier);
|
|
|
|
}
|