mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-30 21:46:31 +00:00
0294112ee3
This effectively reverts the following three commits:7bc10388ccACPI / resources: free memory on error in add_region_before()0f1b414d19ACPI / PNP: Avoid conflicting resource reservationsb9a5e5e18fACPI / init: Fix the ordering of acpi_reserve_resources() (commitb9a5e5e18fintroduced regressions some of which, but not all, were addressed by commit0f1b414d19and commit7bc10388ccwas a fixup on top of the latter) and causes ACPI fixed hardware resources to be reserved at the fs_initcall_sync stage of system initialization. The story is as follows. First, a boot regression was reported due to an apparent resource reservation ordering change after a commit that shouldn't lead to such changes. Investigation led to the conclusion that the problem happened because acpi_reserve_resources() was executed at the device_initcall() stage of system initialization which wasn't strictly ordered with respect to driver initialization (and with respect to the initialization of the pcieport driver in particular), so a random change causing the device initcalls to be run in a different order might break things. The response to that was to attempt to run acpi_reserve_resources() as soon as we knew that ACPI would be in use (commitb9a5e5e18f). However, that turned out to be too early, because it caused resource reservations made by the PNP system driver to fail on at least one system and that failure was addressed by commit0f1b414d19. That fix still turned out to be insufficient, though, because calling acpi_reserve_resources() before the fs_initcall stage of system initialization caused a boot regression to happen on the eCAFE EC-800-H20G/S netbook. That meant that we only could call acpi_reserve_resources() at the fs_initcall initialization stage or later, but then we might just as well call it after the PNP initalization in which case commit0f1b414d19wouldn't be necessary any more. For this reason, the changes made by commit0f1b414d19are reverted (along with a memory leak fixup on top of that commit), the changes made by commitb9a5e5e18fthat went too far are reverted too and acpi_reserve_resources() is changed into fs_initcall_sync, which will cause it to be executed after the PNP subsystem initialization (which is an fs_initcall) and before device initcalls (including the pcieport driver initialization) which should avoid the initial issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581 Link: http://marc.info/?t=143092384600002&r=1&w=2 Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Link: http://marc.info/?t=143389402600001&r=1&w=2 Fixes:b9a5e5e18f"ACPI / init: Fix the ordering of acpi_reserve_resources()" Reported-by: Roland Dreier <roland@purestorage.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
113 lines
2.7 KiB
C
113 lines
2.7 KiB
C
/*
|
|
* system.c - a driver for reserving pnp system resources
|
|
*
|
|
* Some code is based on pnpbios_core.c
|
|
* Copyright 2002 Adam Belay <ambx1@neo.rr.com>
|
|
* (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
|
|
* Bjorn Helgaas <bjorn.helgaas@hp.com>
|
|
*/
|
|
|
|
#include <linux/pnp.h>
|
|
#include <linux/device.h>
|
|
#include <linux/init.h>
|
|
#include <linux/slab.h>
|
|
#include <linux/kernel.h>
|
|
#include <linux/ioport.h>
|
|
|
|
static const struct pnp_device_id pnp_dev_table[] = {
|
|
/* General ID for reserving resources */
|
|
{"PNP0c02", 0},
|
|
/* memory controller */
|
|
{"PNP0c01", 0},
|
|
{"", 0}
|
|
};
|
|
|
|
static void reserve_range(struct pnp_dev *dev, struct resource *r, int port)
|
|
{
|
|
char *regionid;
|
|
const char *pnpid = dev_name(&dev->dev);
|
|
resource_size_t start = r->start, end = r->end;
|
|
struct resource *res;
|
|
|
|
regionid = kmalloc(16, GFP_KERNEL);
|
|
if (!regionid)
|
|
return;
|
|
|
|
snprintf(regionid, 16, "pnp %s", pnpid);
|
|
if (port)
|
|
res = request_region(start, end - start + 1, regionid);
|
|
else
|
|
res = request_mem_region(start, end - start + 1, regionid);
|
|
if (res)
|
|
res->flags &= ~IORESOURCE_BUSY;
|
|
else
|
|
kfree(regionid);
|
|
|
|
/*
|
|
* Failures at this point are usually harmless. pci quirks for
|
|
* example do reserve stuff they know about too, so we may well
|
|
* have double reservations.
|
|
*/
|
|
dev_info(&dev->dev, "%pR %s reserved\n", r,
|
|
res ? "has been" : "could not be");
|
|
}
|
|
|
|
static void reserve_resources_of_dev(struct pnp_dev *dev)
|
|
{
|
|
struct resource *res;
|
|
int i;
|
|
|
|
for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_IO, i)); i++) {
|
|
if (res->flags & IORESOURCE_DISABLED)
|
|
continue;
|
|
if (res->start == 0)
|
|
continue; /* disabled */
|
|
if (res->start < 0x100)
|
|
/*
|
|
* Below 0x100 is only standard PC hardware
|
|
* (pics, kbd, timer, dma, ...)
|
|
* We should not get resource conflicts there,
|
|
* and the kernel reserves these anyway
|
|
* (see arch/i386/kernel/setup.c).
|
|
* So, do nothing
|
|
*/
|
|
continue;
|
|
if (res->end < res->start)
|
|
continue; /* invalid */
|
|
|
|
reserve_range(dev, res, 1);
|
|
}
|
|
|
|
for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
|
|
if (res->flags & IORESOURCE_DISABLED)
|
|
continue;
|
|
|
|
reserve_range(dev, res, 0);
|
|
}
|
|
}
|
|
|
|
static int system_pnp_probe(struct pnp_dev *dev,
|
|
const struct pnp_device_id *dev_id)
|
|
{
|
|
reserve_resources_of_dev(dev);
|
|
return 0;
|
|
}
|
|
|
|
static struct pnp_driver system_pnp_driver = {
|
|
.name = "system",
|
|
.id_table = pnp_dev_table,
|
|
.flags = PNP_DRIVER_RES_DO_NOT_CHANGE,
|
|
.probe = system_pnp_probe,
|
|
};
|
|
|
|
static int __init pnp_system_init(void)
|
|
{
|
|
return pnp_register_driver(&system_pnp_driver);
|
|
}
|
|
|
|
/**
|
|
* Reserve motherboard resources after PCI claim BARs,
|
|
* but before PCI assign resources for uninitialized PCI devices
|
|
*/
|
|
fs_initcall(pnp_system_init);
|