From 204ebc0aa30a7115f300cac39fbb7eeb66524881 Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Mon, 20 May 2013 15:41:45 +0000 Subject: 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 Cc: 3.9+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/resource.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index a3868f6c222..3322b47ab7c 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -304,7 +304,8 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi) } static void acpi_dev_get_irqresource(struct resource *res, u32 gsi, - u8 triggering, u8 polarity, u8 shareable) + u8 triggering, u8 polarity, u8 shareable, + bool legacy) { int irq, p, t; @@ -317,14 +318,19 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi, * In IO-APIC mode, use overrided attribute. Two reasons: * 1. BIOS bug in DSDT * 2. BIOS uses IO-APIC mode Interrupt Source Override + * + * We do this only if we are dealing with IRQ() or IRQNoFlags() + * resource (the legacy ISA resources). With modern ACPI 5 devices + * using extended IRQ descriptors we take the IRQ configuration + * from _CRS directly. */ - if (!acpi_get_override_irq(gsi, &t, &p)) { + if (legacy && !acpi_get_override_irq(gsi, &t, &p)) { u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE; u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH; if (triggering != trig || polarity != pol) { pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi, - t ? "edge" : "level", p ? "low" : "high"); + t ? "level" : "edge", p ? "low" : "high"); triggering = trig; polarity = pol; } @@ -373,7 +379,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index, } acpi_dev_get_irqresource(res, irq->interrupts[index], irq->triggering, irq->polarity, - irq->sharable); + irq->sharable, true); break; case ACPI_RESOURCE_TYPE_EXTENDED_IRQ: ext_irq = &ares->data.extended_irq; @@ -383,7 +389,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index, } acpi_dev_get_irqresource(res, ext_irq->interrupts[index], ext_irq->triggering, ext_irq->polarity, - ext_irq->sharable); + ext_irq->sharable, false); break; default: return false; -- cgit v1.2.3 From 8112006f41fd76ddf4988f8ddd904563db85613c Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sun, 16 Jun 2013 00:38:30 +0200 Subject: ACPI / dock: Take ACPI scan lock in write_undock() Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be called under acpi_scan_lock, but currently the following scenario violating that requirement is possible: write_undock() handle_eject_request() hotplug_dock_devices() dock_remove_acpi_device() acpi_bus_trim() Fix that by making write_undock() acquire acpi_scan_lock before calling handle_eject_request() as appropriate (begin_undock() is under the lock too in analogy with acpi_dock_deferred_cb()). Signed-off-by: Rafael J. Wysocki Cc: 3.9+ Acked-by: Toshi Kani --- drivers/acpi/dock.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers') diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c index 4fdea381ef2..ec117c6c996 100644 --- a/drivers/acpi/dock.c +++ b/drivers/acpi/dock.c @@ -868,8 +868,10 @@ static ssize_t write_undock(struct device *dev, struct device_attribute *attr, if (!count) return -EINVAL; + acpi_scan_lock_acquire(); begin_undock(dock_station); ret = handle_eject_request(dock_station, ACPI_NOTIFY_EJECT_REQUEST); + acpi_scan_lock_release(); return ret ? ret: count; } static DEVICE_ATTR(undock, S_IWUSR, NULL, write_undock); -- cgit v1.2.3 From 6ee22e9d59151550a55d370b14109bdae8b58bda Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 19 Jun 2013 00:44:45 +0200 Subject: ACPI / PM: Fix error code path for power resources initialization Commit 781d737 (ACPI: Drop power resources driver) introduced a bug in the power resources initialization error code path causing a NULL pointer to be referenced in acpi_release_power_resource() if there's an error triggering a jump to the 'err' label in acpi_add_power_resource(). This happens because the list_node field of struct acpi_power_resource has not been initialized yet at this point and doing a list_del() on it is a bad idea. To prevent this problem from occuring, initialize the list_node field of struct acpi_power_resource upfront. Reported-by: Mika Westerberg Tested-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Cc: 3.9+ Acked-by: Yasuaki Ishimatsu Reviewed-by: Mika Westerberg --- drivers/acpi/power.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers') diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index f962047c6c8..288bb270f8e 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -885,6 +885,7 @@ int acpi_add_power_resource(acpi_handle handle) ACPI_STA_DEFAULT); mutex_init(&resource->resource_lock); INIT_LIST_HEAD(&resource->dependent); + INIT_LIST_HEAD(&resource->list_node); resource->name = device->pnp.bus_id; strcpy(acpi_device_name(device), ACPI_POWER_DEVICE_NAME); strcpy(acpi_device_class(device), ACPI_POWER_CLASS); -- cgit v1.2.3 From b9e95fc65ededbec083aa91b4faa58ad992c0891 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 19 Jun 2013 00:45:34 +0200 Subject: ACPI / LPSS: Power up LPSS devices during enumeration Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_lpss.c | 21 +++++++++++++++------ drivers/acpi/device_pm.c | 20 ++++++++++++++++++++ 2 files changed, 35 insertions(+), 6 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index 652fd5ce303..cab13f2fc28 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -164,15 +164,24 @@ static int acpi_lpss_create_device(struct acpi_device *adev, if (dev_desc->clk_required) { ret = register_device_clock(adev, pdata); if (ret) { - /* - * Skip the device, but don't terminate the namespace - * scan. - */ - kfree(pdata); - return 0; + /* Skip the device, but continue the namespace scan. */ + ret = 0; + goto err_out; } } + /* + * This works around a known issue in ACPI tables where LPSS devices + * have _PS0 and _PS3 without _PSC (and no power resources), so + * acpi_bus_init_power() will assume that the BIOS has put them into D0. + */ + ret = acpi_device_fix_up_power(adev); + if (ret) { + /* Skip the device, but continue the namespace scan. */ + ret = 0; + goto err_out; + } + adev->driver_data = pdata; ret = acpi_create_platform_device(adev, id); if (ret > 0) diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 318fa32a141..31c217a4283 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -290,6 +290,26 @@ int acpi_bus_init_power(struct acpi_device *device) return 0; } +/** + * acpi_device_fix_up_power - Force device with missing _PSC into D0. + * @device: Device object whose power state is to be fixed up. + * + * Devices without power resources and _PSC, but having _PS0 and _PS3 defined, + * are assumed to be put into D0 by the BIOS. However, in some cases that may + * not be the case and this function should be used then. + */ +int acpi_device_fix_up_power(struct acpi_device *device) +{ + int ret = 0; + + if (!device->power.flags.power_resources + && !device->power.flags.explicit_get + && device->power.state == ACPI_STATE_D0) + ret = acpi_dev_pm_explicit_set(device, ACPI_STATE_D0); + + return ret; +} + int acpi_bus_update_power(acpi_handle handle, int *state_p) { struct acpi_device *device; -- cgit v1.2.3