Hi,
The following (updated) series of patches provides basic run-time power
management support for PCI devices through ACPI and/or the native PCIe
PME.
[1/9] - Add function for checking PME status of devices
[2/9] - PCIe PME root port service driver
[3/9] - "Don't use MSIs for PME signaling" switch for PCIe
[4/9] - ACPI GPE refcounting, from Matthew Garrett
[5/9] - ACPI drivers support for GPE refcounting, from Matthew Garrett
[6/9] - ACPI removal of the old GPE API, from Matthew Garrett
[7/9] - ACPI add fields for handling run-wake devices
[8/9] - PCI / ACPI platform support for run-time power management
[9/9] - Runtime PM callbacks for the PCI bus type
Bob, patches [4/9] - [6/9] from Matthew introduce GPE refconting which is
necessary for the PCI run-time power management. If I remeber correctly, you
saw these patches some time ago, but we need your ack before they can go
upstream. Please let us know if there's anything to fix in these patches.
Thanks,
Rafael
From: Matthew Garrett <[email protected]>
ACPI GPEs may map to multiple devices. The current GPE interface only
provides a mechanism for enabling and disabling GPEs, making it difficult
to change the state of GPEs at runtime without extensive cooperation
between devices. Add an API to allow devices to indicate whether or not
they want their device's GPE to be enabled for both runtime and wakeup
events.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/acpica/aclocal.h | 2 +
drivers/acpi/acpica/aclocal.h | 2
drivers/acpi/acpica/evxfevnt.c | 161 +++++++++++++++++++++++++++++++++++++++++
include/acpi/acpixf.h | 8 ++
3 files changed, 171 insertions(+)
Index: linux-2.6/drivers/acpi/acpica/aclocal.h
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/aclocal.h
+++ linux-2.6/drivers/acpi/acpica/aclocal.h
@@ -426,6 +426,8 @@ struct acpi_gpe_event_info {
struct acpi_gpe_register_info *register_info; /* Backpointer to register info */
u8 flags; /* Misc info about this GPE */
u8 gpe_number; /* This GPE */
+ u8 runtime_count;
+ u8 wakeup_count;
};
/* Information about a GPE register pair, one per each status/enable pair in an array */
Index: linux-2.6/drivers/acpi/acpica/evxfevnt.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxfevnt.c
+++ linux-2.6/drivers/acpi/acpica/evxfevnt.c
@@ -201,6 +201,167 @@ ACPI_EXPORT_SYMBOL(acpi_enable_event)
/*******************************************************************************
*
+ * FUNCTION: acpi_ref_runtime_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Take a reference to a runtime GPE
+ *
+ ******************************************************************************/
+acpi_status acpi_ref_runtime_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ acpi_status status = AE_OK;
+ acpi_cpu_flags flags;
+ struct acpi_gpe_event_info *gpe_event_info;
+
+ ACPI_FUNCTION_TRACE(acpi_ref_runtime_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ if (++gpe_event_info->runtime_count == 1)
+ status = acpi_ev_enable_gpe(gpe_event_info, TRUE);
+
+ if (ACPI_FAILURE(status))
+ gpe_event_info->runtime_count--;
+
+unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ return_ACPI_STATUS(status);
+}
+ACPI_EXPORT_SYMBOL(acpi_ref_runtime_gpe)
+
+/*******************************************************************************
+ *
+ * FUNCTION: acpi_unref_runtime_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Release a reference to a runtime GPE
+ *
+ ******************************************************************************/
+acpi_status acpi_unref_runtime_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ acpi_status status = AE_OK;
+ acpi_cpu_flags flags;
+ struct acpi_gpe_event_info *gpe_event_info;
+
+ ACPI_FUNCTION_TRACE(acpi_unref_runtime_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ if (--gpe_event_info->runtime_count == 0)
+ acpi_ev_disable_gpe(gpe_event_info);
+
+unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ return_ACPI_STATUS(status);
+}
+ACPI_EXPORT_SYMBOL(acpi_unref_runtime_gpe)
+
+/*******************************************************************************
+ *
+ * FUNCTION: acpi_ref_wakeup_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Take a reference to a wakeup GPE
+ *
+ ******************************************************************************/
+acpi_status acpi_ref_wakeup_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ acpi_status status = AE_OK;
+ acpi_cpu_flags flags;
+ struct acpi_gpe_event_info *gpe_event_info;
+
+ ACPI_FUNCTION_TRACE(acpi_ref_wakeup_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ if (++gpe_event_info->wakeup_count == 1)
+ acpi_ev_update_gpe_enable_masks(gpe_event_info,
+ ACPI_GPE_ENABLE);
+
+unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ return_ACPI_STATUS(status);
+}
+ACPI_EXPORT_SYMBOL(acpi_ref_wakeup_gpe)
+
+/*******************************************************************************
+ *
+ * FUNCTION: acpi_unref_wakeup_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Release a reference to a wakeup GPE
+ *
+ ******************************************************************************/
+acpi_status acpi_unref_wakeup_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ acpi_status status = AE_OK;
+ acpi_cpu_flags flags;
+ struct acpi_gpe_event_info *gpe_event_info;
+
+ ACPI_FUNCTION_TRACE(acpi_unref_wakeup_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+ /* Ensure that we have a valid GPE number */
+
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ if (--gpe_event_info->wakeup_count == 0)
+ acpi_ev_update_gpe_enable_masks(gpe_event_info,
+ ACPI_GPE_DISABLE);
+
+unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+ return_ACPI_STATUS(status);
+}
+ACPI_EXPORT_SYMBOL(acpi_unref_wakeup_gpe)
+
+/*******************************************************************************
+ *
* FUNCTION: acpi_set_gpe_type
*
* PARAMETERS: gpe_device - Parent GPE Device
Index: linux-2.6/include/acpi/acpixf.h
===================================================================
--- linux-2.6.orig/include/acpi/acpixf.h
+++ linux-2.6/include/acpi/acpixf.h
@@ -283,6 +283,14 @@ acpi_status acpi_get_event_status(u32 ev
*/
acpi_status acpi_set_gpe_type(acpi_handle gpe_device, u32 gpe_number, u8 type);
+acpi_status acpi_ref_runtime_gpe(acpi_handle gpe_device, u32 gpe_number);
+
+acpi_status acpi_unref_runtime_gpe(acpi_handle gpe_device, u32 gpe_number);
+
+acpi_status acpi_ref_wakeup_gpe(acpi_handle gpe_device, u32 gpe_number);
+
+acpi_status acpi_unref_wakeup_gpe(acpi_handle gpe_device, u32 gpe_number);
+
acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number);
acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number);
From: Rafael J. Wysocki <[email protected]>
PCIe native PME detection mechanism is based on interrupts generated
by root ports or event collectors every time a PCIe device sends a
PME message upstream.
Once a PME message has been sent by an endpoint device and received
by its root port (or event collector in the case of root complex
integrated endpoints), the Requester ID from the message header is
registered in the root port's Root Status register. At the same
time, the PME Status bit of the Root Status register is set to
indicate that there's a PME to handle. If PCIe PME interrupt is
enabled for the root port, it generates an interrupt once the PME
Status has been set. After receiving the interrupt, the kernel can
identify the PCIe device that generated the PME using the Requester
ID from the root port's Root Status register. [For details, see PCI
Express Base Specification, Rev. 2.0.]
Implement a driver for the PCIe PME root port service working in
accordance with the above description.
Based on a patch from Shaohua Li <[email protected]>.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
Documentation/kernel-parameters.txt | 6
drivers/pci/pcie/Kconfig | 4
drivers/pci/pcie/Makefile | 2
drivers/pci/pcie/pme/Makefile | 8
drivers/pci/pcie/pme/pcie_pme.c | 493 +++++++++++++++++++++++++++++++++++
drivers/pci/pcie/pme/pcie_pme.h | 28 +
drivers/pci/pcie/pme/pcie_pme_acpi.c | 54 +++
include/linux/pci.h | 1
8 files changed, 596 insertions(+)
Index: linux-2.6/drivers/pci/pcie/Kconfig
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/Kconfig
+++ linux-2.6/drivers/pci/pcie/Kconfig
@@ -46,3 +46,7 @@ config PCIEASPM_DEBUG
help
This enables PCI Express ASPM debug support. It will add per-device
interface to control ASPM.
+
+config PCIE_PME
+ def_bool y
+ depends on PCIEPORTBUS && PM_RUNTIME && EXPERIMENTAL
Index: linux-2.6/drivers/pci/pcie/Makefile
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/Makefile
+++ linux-2.6/drivers/pci/pcie/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_PCIEPORTBUS) += pcieportdrv
# Build PCI Express AER if needed
obj-$(CONFIG_PCIEAER) += aer/
+
+obj-$(CONFIG_PCIE_PME) += pme/
Index: linux-2.6/drivers/pci/pcie/pme/pcie_pme.c
===================================================================
--- /dev/null
+++ linux-2.6/drivers/pci/pcie/pme/pcie_pme.c
@@ -0,0 +1,493 @@
+/*
+ * PCIe Native PME support
+ *
+ * Copyright (C) 2007 - 2009 Intel Corp
+ * Copyright (C) 2007 - 2009 Shaohua Li <[email protected]>
+ * Copyright (C) 2009 Rafael J. Wysocki <[email protected]>, Novell Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License V2. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/pcieport_if.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <linux/pm_runtime.h>
+
+#include "../../pci.h"
+#include "pcie_pme.h"
+
+#define PCI_EXP_RTSTA_PME 0x10000 /* PME status */
+#define PCI_EXP_RTSTA_PENDING 0x20000 /* PME pending */
+
+/*
+ * If set, this switch will prevent the PCIe root port PME service driver from
+ * being registered. Consequently, the interrupt-based PCIe PME signaling will
+ * not be used by any PCIe root ports in that case.
+ */
+static bool pcie_pme_disabled;
+
+/*
+ * The PCI Express Base Specification 2.0, Section 6.1.8, states the following:
+ * "In order to maintain compatibility with non-PCI Express-aware system
+ * software, system power management logic must be configured by firmware to use
+ * the legacy mechanism of signaling PME by default. PCI Express-aware system
+ * software must notify the firmware prior to enabling native, interrupt-based
+ * PME signaling." However, if the platform doesn't provide us with a suitable
+ * notification mechanism or the notification fails, it is not clear whether or
+ * not we are supposed to use the interrupt-based PCIe PME signaling. The
+ * switch below can be used to indicate the desired behaviour. When set, it
+ * will make the kernel use the interrupt-based PCIe PME signaling regardless of
+ * the platform notification status, although the kernel will attempt to notify
+ * the platform anyway. When unset, it will prevent the kernel from using the
+ * the interrupt-based PCIe PME signaling if the platform notification fails,
+ * which is the default.
+ */
+static bool pcie_pme_force_enable;
+
+static int __init pcie_pme_setup(char *str)
+{
+ if (!strcmp(str, "off"))
+ pcie_pme_disabled = true;
+ else if (!strcmp(str, "force"))
+ pcie_pme_force_enable = true;
+ return 1;
+}
+__setup("pcie_pme=", pcie_pme_setup);
+
+/**
+ * pcie_pme_platform_setup - Ensure that the kernel controls the PCIe PME.
+ * @srv: PCIe PME root port service to use for carrying out the check.
+ *
+ * Notify the platform that the native PCIe PME is going to be used and return
+ * 'true' if the control of the PCIe PME registers has been acquired from the
+ * platform.
+ */
+static bool pcie_pme_platform_setup(struct pcie_device *srv)
+{
+ return !pcie_pme_platform_notify(srv) || pcie_pme_force_enable;
+}
+
+struct pcie_pme_service_data {
+ spinlock_t lock;
+ struct pcie_device *srv;
+ struct work_struct work;
+ bool noirq; /* Don't enable the PME interrupt used by this service. */
+};
+
+/**
+ * pcie_pme_interrupt_enable - Enable/disable PCIe PME interrupt generation.
+ * @dev: PCIe root port or event collector.
+ * @enable: Enable or disable the interrupt.
+ */
+static void pcie_pme_interrupt_enable(struct pci_dev *dev, bool enable)
+{
+ int rtctl_pos;
+ u16 rtctl;
+
+ rtctl_pos = pci_find_capability(dev, PCI_CAP_ID_EXP) + PCI_EXP_RTCTL;
+
+ pci_read_config_word(dev, rtctl_pos, &rtctl);
+ if (enable)
+ rtctl |= PCI_EXP_RTCTL_PMEIE;
+ else
+ rtctl &= ~PCI_EXP_RTCTL_PMEIE;
+ pci_write_config_word(dev, rtctl_pos, rtctl);
+}
+
+/**
+ * pcie_pme_clear_status - Clear root port PME interrupt status.
+ * @dev: PCIe root port or event collector.
+ */
+static void pcie_pme_clear_status(struct pci_dev *dev)
+{
+ int rtsta_pos;
+ u32 rtsta;
+
+ rtsta_pos = pci_find_capability(dev, PCI_CAP_ID_EXP) + PCI_EXP_RTSTA;
+
+ pci_read_config_dword(dev, rtsta_pos, &rtsta);
+ rtsta |= PCI_EXP_RTSTA_PME;
+ pci_write_config_dword(dev, rtsta_pos, rtsta);
+}
+
+/**
+ * pcie_pme_walk_bus - Scan a PCI bus for devices asserting PME#.
+ * @bus: PCI bus to scan.
+ *
+ * Scan given PCI bus and all buses under it for devices asserting PME#.
+ */
+static bool pcie_pme_walk_bus(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ bool ret = false;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ /* Skip PCIe devices in case we started from a root port. */
+ if (!dev->is_pcie && pci_check_pme_status(dev)) {
+ pm_request_resume(&dev->dev);
+ ret = true;
+ }
+
+ if (dev->subordinate && pcie_pme_walk_bus(dev->subordinate))
+ ret = true;
+ }
+
+ return ret;
+}
+
+/**
+ * pcie_pme_from_pci_bridge - Check if PCIe-PCI bridge generated a PME.
+ * @bus: Secondary bus of the bridge.
+ * @devfn: Device/function number to check.
+ *
+ * PME from PCI devices under a PCIe-PCI bridge may be converted to an in-band
+ * PCIe PME message. In such that case the bridge should use the Requester ID
+ * of device/function number 0 on its secondary bus.
+ */
+static bool pcie_pme_from_pci_bridge(struct pci_bus *bus, u8 devfn)
+{
+ struct pci_dev *dev;
+ bool found = false;
+
+ if (devfn)
+ return false;
+
+ dev = pci_dev_get(bus->self);
+ if (!dev)
+ return false;
+
+ if (dev->is_pcie && dev->pcie_type == PCI_EXP_TYPE_PCI_BRIDGE) {
+ down_read(&pci_bus_sem);
+ if (pcie_pme_walk_bus(bus))
+ found = true;
+ up_read(&pci_bus_sem);
+ }
+
+ pci_dev_put(dev);
+ return found;
+}
+
+/**
+ * pcie_pme_handle_request - Find device that generated PME and handle it.
+ * @port: Root port or event collector that generated the PME interrupt.
+ * @req_id: PCIe Requester ID of the device that generated the PME.
+ */
+static void pcie_pme_handle_request(struct pci_dev *port, u16 req_id)
+{
+ u8 busnr = req_id >> 8, devfn = req_id & 0xff;
+ struct pci_bus *bus;
+ struct pci_dev *dev;
+ bool found = false;
+
+ /* First, check if the PME is from the root port itself. */
+ if (port->devfn == devfn && port->bus->number == busnr) {
+ if (pci_check_pme_status(port)) {
+ pm_request_resume(&port->dev);
+ found = true;
+ } else {
+ /*
+ * Apparently, the root port generated the PME on behalf
+ * of a non-PCIe device downstream. If this is done by
+ * a root port, the Requester ID field in its status
+ * register may contain either the root port's, or the
+ * source device's information (PCI Express Base
+ * Specification, Rev. 2.0, Section 6.1.9).
+ */
+ down_read(&pci_bus_sem);
+ found = pcie_pme_walk_bus(port->subordinate);
+ up_read(&pci_bus_sem);
+ }
+ goto out;
+ }
+
+ /* Second, find the bus the source device is on. */
+ bus = pci_find_bus(pci_domain_nr(port->bus), busnr);
+ if (!bus)
+ goto out;
+
+ /* Next, check if the PME is from a PCIe-PCI bridge. */
+ found = pcie_pme_from_pci_bridge(bus, devfn);
+ if (found)
+ goto out;
+
+ /* Finally, try to find the PME source on the bus. */
+ down_read(&pci_bus_sem);
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ pci_dev_get(dev);
+ if (dev->devfn == devfn) {
+ found = true;
+ break;
+ }
+ pci_dev_put(dev);
+ }
+ up_read(&pci_bus_sem);
+
+ if (found) {
+ /* The device is there, but we have to check its PME status. */
+ found = pci_check_pme_status(dev);
+ if (found)
+ pm_request_resume(&dev->dev);
+ pci_dev_put(dev);
+ } else if (devfn) {
+ /*
+ * The device is not there, but we can still try to recover by
+ * assuming that the PME was reported by a PCIe-PCI bridge that
+ * used devfn different from zero.
+ */
+ dev_dbg(&port->dev, "PME interrupt generated for "
+ "non-existent device %02x:%02x.%d\n",
+ busnr, PCI_SLOT(devfn), PCI_FUNC(devfn));
+ found = pcie_pme_from_pci_bridge(bus, 0);
+ }
+
+ out:
+ if (!found)
+ dev_dbg(&port->dev, "Spurious native PME interrupt!\n");
+}
+
+/**
+ * pcie_pme_work_fn - Work handler for PCIe PME interrupt.
+ * @work: Work structure giving access to service data.
+ */
+static void pcie_pme_work_fn(struct work_struct *work)
+{
+ struct pcie_pme_service_data *data =
+ container_of(work, struct pcie_pme_service_data, work);
+ struct pci_dev *port = data->srv->port;
+ int rtsta_pos;
+ u32 rtsta;
+
+ rtsta_pos = pci_find_capability(port, PCI_CAP_ID_EXP) + PCI_EXP_RTSTA;
+
+ spin_lock_irq(&data->lock);
+
+ for (;;) {
+ if (data->noirq)
+ break;
+
+ pci_read_config_dword(port, rtsta_pos, &rtsta);
+ if (rtsta & PCI_EXP_RTSTA_PME) {
+ /*
+ * Clear PME status of the port. If there are other
+ * pending PMEs, the status will be set again.
+ */
+ pcie_pme_clear_status(port);
+
+ spin_unlock_irq(&data->lock);
+ pcie_pme_handle_request(port, rtsta & 0xffff);
+ spin_lock_irq(&data->lock);
+
+ continue;
+ }
+
+ /* No need to loop if there are no more PMEs pending. */
+ if (!(rtsta & PCI_EXP_RTSTA_PENDING))
+ break;
+
+ spin_unlock_irq(&data->lock);
+ cpu_relax();
+ spin_lock_irq(&data->lock);
+ }
+
+ if (!data->noirq)
+ pcie_pme_interrupt_enable(port, true);
+
+ spin_unlock_irq(&data->lock);
+}
+
+/**
+ * pcie_pme_irq - Interrupt handler for PCIe root port PME interrupt.
+ * @irq: Interrupt vector.
+ * @context: Interrupt context pointer.
+ */
+static irqreturn_t pcie_pme_irq(int irq, void *context)
+{
+ struct pci_dev *port;
+ struct pcie_pme_service_data *data;
+ int rtsta_pos;
+ u32 rtsta;
+ unsigned long flags;
+
+ port = ((struct pcie_device *)context)->port;
+ data = get_service_data((struct pcie_device *)context);
+
+ rtsta_pos = pci_find_capability(port, PCI_CAP_ID_EXP) + PCI_EXP_RTSTA;
+
+ spin_lock_irqsave(&data->lock, flags);
+ pci_read_config_dword(port, rtsta_pos, &rtsta);
+
+ if (!(rtsta & PCI_EXP_RTSTA_PME)) {
+ spin_unlock_irqrestore(&data->lock, flags);
+ return IRQ_NONE;
+ }
+
+ pcie_pme_interrupt_enable(port, false);
+ spin_unlock_irqrestore(&data->lock, flags);
+
+ /* We don't use pm_wq, because it's freezable. */
+ schedule_work(&data->work);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * pcie_pme_set_native - Set the PME interrupt flag for given device.
+ * @dev: PCI device to handle.
+ * @ign: Ignored.
+ */
+static int pcie_pme_set_native(struct pci_dev *dev, void *ign)
+{
+ dev_info(&dev->dev, "Signaling PME through PCIe PME interrupt\n");
+
+ device_set_run_wake(&dev->dev, true);
+ dev->pme_interrupt = true;
+ return 0;
+}
+
+/**
+ * pcie_pme_mark_devices - Set the PME interrupt flag for devices below a port.
+ * @port: PCIe root port or event collector to handle.
+ *
+ * For each device below given root port, including the port itself (or for each
+ * root complex integrated endpoint if @port is a root complex event collector)
+ * set the flag indicating that it can signal run-time wake-up events via PCIe
+ * PME interrupts.
+ */
+static void pcie_pme_mark_devices(struct pci_dev *port)
+{
+ pcie_pme_set_native(port, NULL);
+ if (port->subordinate) {
+ pci_walk_bus(port->subordinate, pcie_pme_set_native, NULL);
+ } else {
+ struct pci_bus *bus = port->bus;
+ struct pci_dev *dev;
+
+ /* Check if this is a root port event collector. */
+ if (port->pcie_type != PCI_EXP_TYPE_RC_EC || !bus)
+ return;
+
+ down_read(&pci_bus_sem);
+ list_for_each_entry(dev, &bus->devices, bus_list)
+ if (dev->is_pcie
+ && dev->pcie_type == PCI_EXP_TYPE_RC_END)
+ pcie_pme_set_native(dev, NULL);
+ up_read(&pci_bus_sem);
+ }
+}
+
+/**
+ * pcie_pme_probe - Initialize PCIe PME service for given root port.
+ * @srv: PCIe service to initialize.
+ */
+static int pcie_pme_probe(struct pcie_device *srv)
+{
+ struct pci_dev *port;
+ struct pcie_pme_service_data *data;
+ int ret;
+
+ if (!pcie_pme_platform_setup(srv))
+ return -EACCES;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock_init(&data->lock);
+ INIT_WORK(&data->work, pcie_pme_work_fn);
+ data->srv = srv;
+ set_service_data(srv, data);
+
+ port = srv->port;
+ pcie_pme_interrupt_enable(port, false);
+ pcie_pme_clear_status(port);
+
+ ret = request_irq(srv->irq, pcie_pme_irq, IRQF_SHARED, "PCIe PME", srv);
+ if (ret) {
+ kfree(data);
+ } else {
+ pcie_pme_mark_devices(port);
+ pcie_pme_interrupt_enable(port, true);
+ }
+
+ return ret;
+}
+
+/**
+ * pcie_pme_suspend - Suspend PCIe PME service device.
+ * @srv: PCIe service device to suspend.
+ */
+static int pcie_pme_suspend(struct pcie_device *srv)
+{
+ struct pcie_pme_service_data *data = get_service_data(srv);
+ struct pci_dev *port = srv->port;
+
+ spin_lock_irq(&data->lock);
+ pcie_pme_interrupt_enable(port, false);
+ pcie_pme_clear_status(port);
+ data->noirq = true;
+ spin_unlock_irq(&data->lock);
+
+ synchronize_irq(srv->irq);
+
+ return 0;
+}
+
+/**
+ * pcie_pme_resume - Resume PCIe PME service device.
+ * @srv - PCIe service device to resume.
+ */
+static int pcie_pme_resume(struct pcie_device *srv)
+{
+ struct pcie_pme_service_data *data = get_service_data(srv);
+ struct pci_dev *port = srv->port;
+
+ spin_lock_irq(&data->lock);
+ data->noirq = false;
+ pcie_pme_clear_status(port);
+ pcie_pme_interrupt_enable(port, true);
+ spin_unlock_irq(&data->lock);
+
+ return 0;
+}
+
+/**
+ * pcie_pme_remove - Prepare PCIe PME service device for removal.
+ * @srv - PCIe service device to resume.
+ */
+static void pcie_pme_remove(struct pcie_device *srv)
+{
+ pcie_pme_suspend(srv);
+ free_irq(srv->irq, srv);
+ kfree(get_service_data(srv));
+}
+
+static struct pcie_port_service_driver pcie_pme_driver = {
+ .name = "pcie_pme",
+ .port_type = PCI_EXP_TYPE_ROOT_PORT,
+ .service = PCIE_PORT_SERVICE_PME,
+
+ .probe = pcie_pme_probe,
+ .suspend = pcie_pme_suspend,
+ .resume = pcie_pme_resume,
+ .remove = pcie_pme_remove,
+};
+
+/**
+ * pcie_pme_service_init - Register the PCIe PME service driver.
+ */
+static int __init pcie_pme_service_init(void)
+{
+ return pcie_pme_disabled ?
+ -ENODEV : pcie_port_service_register(&pcie_pme_driver);
+}
+
+module_init(pcie_pme_service_init);
Index: linux-2.6/drivers/pci/pcie/pme/pcie_pme_acpi.c
===================================================================
--- /dev/null
+++ linux-2.6/drivers/pci/pcie/pme/pcie_pme_acpi.c
@@ -0,0 +1,54 @@
+/*
+ * PCIe Native PME support, ACPI-related part
+ *
+ * Copyright (C) 2009 Rafael J. Wysocki <[email protected]>, Novell Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License V2. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/pci.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <linux/pcieport_if.h>
+
+/**
+ * pcie_pme_acpi_setup - Request the ACPI BIOS to release control over PCIe PME.
+ * @srv - PCIe PME service for a root port or event collector.
+ *
+ * Invoked when the PCIe bus type loads PCIe PME service driver. To avoid
+ * conflict with the BIOS PCIe support requires the BIOS to yield PCIe PME
+ * control to the kernel.
+ */
+int pcie_pme_acpi_setup(struct pcie_device *srv)
+{
+ acpi_status status = AE_NOT_FOUND;
+ struct pci_dev *port = srv->port;
+ acpi_handle handle;
+ int error = 0;
+
+ if (acpi_pci_disabled)
+ return -ENOSYS;
+
+ dev_info(&port->dev, "Requesting control of PCIe PME from ACPI BIOS\n");
+
+ handle = acpi_find_root_bridge_handle(port);
+ if (!handle)
+ return -EINVAL;
+
+ status = acpi_pci_osc_control_set(handle,
+ OSC_PCI_EXPRESS_PME_CONTROL |
+ OSC_PCI_EXPRESS_CAP_STRUCTURE_CONTROL);
+ if (ACPI_FAILURE(status)) {
+ dev_info(&port->dev,
+ "Failed to receive control of PCIe PME service: %s\n",
+ (status == AE_SUPPORT || status == AE_NOT_FOUND) ?
+ "no _OSC support" : "ACPI _OSC failed");
+ error = -ENODEV;
+ }
+
+ return error;
+}
Index: linux-2.6/drivers/pci/pcie/pme/Makefile
===================================================================
--- /dev/null
+++ linux-2.6/drivers/pci/pcie/pme/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for PCI-Express Root Port PME signaling driver
+#
+
+obj-$(CONFIG_PCIE_PME) += pmedriver.o
+
+pmedriver-objs := pcie_pme.o
+pmedriver-$(CONFIG_ACPI) += pcie_pme_acpi.o
Index: linux-2.6/drivers/pci/pcie/pme/pcie_pme.h
===================================================================
--- /dev/null
+++ linux-2.6/drivers/pci/pcie/pme/pcie_pme.h
@@ -0,0 +1,28 @@
+/*
+ * drivers/pci/pcie/pme/pcie_pme.h
+ *
+ * PCI Express Root Port PME signaling support
+ *
+ * Copyright (C) 2009 Rafael J. Wysocki <[email protected]>, Novell Inc.
+ */
+
+#ifndef _PCIE_PME_H_
+#define _PCIE_PME_H_
+
+struct pcie_device;
+
+#ifdef CONFIG_ACPI
+extern int pcie_pme_acpi_setup(struct pcie_device *srv);
+
+static inline int pcie_pme_platform_notify(struct pcie_device *srv)
+{
+ return pcie_pme_acpi_setup(srv);
+}
+#else /* !CONFIG_ACPI */
+static inline int pcie_pme_platform_notify(struct pcie_device *srv)
+{
+ return 0;
+}
+#endif /* !CONFIG_ACPI */
+
+#endif
Index: linux-2.6/include/linux/pci.h
===================================================================
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -239,6 +239,7 @@ struct pci_dev {
configuration space */
unsigned int pme_support:5; /* Bitmask of states from which PME#
can be generated */
+ unsigned int pme_interrupt:1;
unsigned int d1_support:1; /* Low power state D1 is supported */
unsigned int d2_support:1; /* Low power state D2 is supported */
unsigned int no_d1d2:1; /* Only allow D0 and D3 */
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1989,6 +1989,12 @@ and is between 256 and 4096 characters.
force Enable ASPM even on devices that claim not to support it.
WARNING: Forcing ASPM on may cause system lockups.
+ pcie_pme= [PCIE,PM] Native PCIe PME signaling options:
+ off Do not use native PCIe PME signaling.
+ force Use native PCIe PME signaling even if the BIOS refuses
+ to allow the kernel to control the relevant PCIe config
+ registers.
+
pcmv= [HW,PCMCIA] BadgePAD 4
pd. [PARIDE]
From: Rafael J. Wysocki <[email protected]>
Introduce run-time PM callbacks for the PCI bus type. Make the new
callbacks work in analogy with the existing system sleep PM
callbacks, so that the drivers already converted to struct dev_pm_ops
can use their suspend and resume routines for run-time PM without
modifications.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/pci/pci-driver.c | 105 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/pci/pci.c | 43 ++++++++++++++++---
drivers/pci/pci.h | 1
include/linux/pci.h | 9 +++-
kernel/power/Kconfig | 5 ++
5 files changed, 151 insertions(+), 12 deletions(-)
Index: linux-2.6/kernel/power/Kconfig
===================================================================
--- linux-2.6.orig/kernel/power/Kconfig
+++ linux-2.6/kernel/power/Kconfig
@@ -222,3 +222,8 @@ config PM_RUNTIME
and the bus type drivers of the buses the devices are on are
responsible for the actual handling of the autosuspend requests and
wake-up events.
+
+config PM_OPS
+ bool
+ depends on PM_SLEEP || PM_RUNTIME
+ default y
Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/cpu.h>
+#include <linux/pm_runtime.h>
#include "pci.h"
struct pci_dynid {
@@ -537,7 +538,7 @@ static int pci_restore_standard_config(s
return pci_restore_state(pci_dev);
}
-static void pci_pm_default_resume_noirq(struct pci_dev *pci_dev)
+static void pci_pm_default_resume_early(struct pci_dev *pci_dev)
{
pci_restore_standard_config(pci_dev);
pci_fixup_device(pci_fixup_resume_early, pci_dev);
@@ -581,6 +582,17 @@ static int pci_pm_prepare(struct device
struct device_driver *drv = dev->driver;
int error = 0;
+ /*
+ * PCI devices suspended at run time need to be resumed at this
+ * point, because in general it is necessary to reconfigure them for
+ * system suspend. Namely, if the device is supposed to wake up the
+ * system from the sleep state, we may need to reconfigure it for this
+ * purpose. In turn, if the device is not supposed to wake up the
+ * system from the sleep state, we'll have to prevent it from signaling
+ * wake-up.
+ */
+ pm_runtime_resume(dev);
+
if (drv && drv->pm && drv->pm->prepare)
error = drv->pm->prepare(dev);
@@ -681,7 +693,7 @@ static int pci_pm_resume_noirq(struct de
struct device_driver *drv = dev->driver;
int error = 0;
- pci_pm_default_resume_noirq(pci_dev);
+ pci_pm_default_resume_early(pci_dev);
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
@@ -879,7 +891,7 @@ static int pci_pm_restore_noirq(struct d
struct device_driver *drv = dev->driver;
int error = 0;
- pci_pm_default_resume_noirq(pci_dev);
+ pci_pm_default_resume_early(pci_dev);
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
@@ -931,6 +943,86 @@ static int pci_pm_restore(struct device
#endif /* !CONFIG_HIBERNATION */
+#endif /* !CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int pci_pm_runtime_suspend(struct device *dev)
+{
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ pci_power_t prev = pci_dev->current_state;
+ int error;
+
+ if (!pm || !pm->runtime_suspend)
+ return -ENOSYS;
+
+ error = pm->runtime_suspend(dev);
+ suspend_report_result(pm->runtime_suspend, error);
+ if (error)
+ return error;
+
+ pci_fixup_device(pci_fixup_suspend, pci_dev);
+
+ if (!pci_dev->state_saved && pci_dev->current_state != PCI_D0
+ && pci_dev->current_state != PCI_UNKNOWN) {
+ WARN_ONCE(pci_dev->current_state != prev,
+ "PCI PM: State of device not saved by %pF\n",
+ pm->runtime_suspend);
+ return 0;
+ }
+
+ if (!pci_dev->state_saved)
+ pci_save_state(pci_dev);
+
+ pci_finish_runtime_suspend(pci_dev);
+
+ return 0;
+}
+
+static int pci_pm_runtime_resume(struct device *dev)
+{
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+ if (!pm || !pm->runtime_resume)
+ return -ENOSYS;
+
+ pci_pm_default_resume_early(pci_dev);
+ __pci_enable_wake(pci_dev, PCI_D0, true, false);
+ pci_fixup_device(pci_fixup_resume, pci_dev);
+
+ return pm->runtime_resume(dev);
+}
+
+static int pci_pm_runtime_idle(struct device *dev)
+{
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+ if (!pm)
+ return -ENOSYS;
+
+ if (pm->runtime_idle) {
+ int ret = pm->runtime_idle(dev);
+ if (ret)
+ return ret;
+ }
+
+ pm_runtime_suspend(dev);
+
+ return 0;
+}
+
+#else /* !CONFIG_PM_RUNTIME */
+
+#define pci_pm_runtime_suspend NULL
+#define pci_pm_runtime_resume NULL
+#define pci_pm_runtime_idle NULL
+
+#endif /* !CONFIG_PM_RUNTIME */
+
+#ifdef CONFIG_PM_OPS
+
const struct dev_pm_ops pci_dev_pm_ops = {
.prepare = pci_pm_prepare,
.complete = pci_pm_complete,
@@ -946,15 +1038,18 @@ const struct dev_pm_ops pci_dev_pm_ops =
.thaw_noirq = pci_pm_thaw_noirq,
.poweroff_noirq = pci_pm_poweroff_noirq,
.restore_noirq = pci_pm_restore_noirq,
+ .runtime_suspend = pci_pm_runtime_suspend,
+ .runtime_resume = pci_pm_runtime_resume,
+ .runtime_idle = pci_pm_runtime_idle,
};
#define PCI_PM_OPS_PTR (&pci_dev_pm_ops)
-#else /* !CONFIG_PM_SLEEP */
+#else /* !COMFIG_PM_OPS */
#define PCI_PM_OPS_PTR NULL
-#endif /* !CONFIG_PM_SLEEP */
+#endif /* !COMFIG_PM_OPS */
/**
* __pci_register_driver - register a new pci driver
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -1302,9 +1302,10 @@ void pci_pme_active(struct pci_dev *dev,
}
/**
- * pci_enable_wake - enable PCI device as wakeup event source
+ * __pci_enable_wake - enable PCI device as wakeup event source
* @dev: PCI device affected
* @state: PCI state from which device will issue wakeup events
+ * @runtime: True if the events are to be generated at run time
* @enable: True to enable event generation; false to disable
*
* This enables the device as a wakeup event source, or disables it.
@@ -1320,11 +1321,12 @@ void pci_pme_active(struct pci_dev *dev,
* Error code depending on the platform is returned if both the platform and
* the native mechanism fail to enable the generation of wake-up events
*/
-int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
+int __pci_enable_wake(struct pci_dev *dev, pci_power_t state,
+ bool runtime, bool enable)
{
int ret = 0;
- if (enable && !device_may_wakeup(&dev->dev))
+ if (enable && !runtime && !device_may_wakeup(&dev->dev))
return -EINVAL;
/* Don't do the same thing twice in a row for one device. */
@@ -1344,19 +1346,24 @@ int pci_enable_wake(struct pci_dev *dev,
pci_pme_active(dev, true);
else
ret = 1;
- error = platform_pci_sleep_wake(dev, true);
+ error = runtime ? platform_pci_run_wake(dev, true) :
+ platform_pci_sleep_wake(dev, true);
if (ret)
ret = error;
if (!ret)
dev->wakeup_prepared = true;
} else {
- platform_pci_sleep_wake(dev, false);
+ if (runtime)
+ platform_pci_run_wake(dev, false);
+ else
+ platform_pci_sleep_wake(dev, false);
pci_pme_active(dev, false);
dev->wakeup_prepared = false;
}
return ret;
}
+EXPORT_SYMBOL(__pci_enable_wake);
/**
* pci_wake_from_d3 - enable/disable device to wake up from D3_hot or D3_cold
@@ -1466,6 +1473,31 @@ int pci_back_from_sleep(struct pci_dev *
}
/**
+ * pci_finish_runtime_suspend - Carry out PCI-specific part of runtime suspend.
+ * @dev: PCI device being suspended.
+ *
+ * Prepare @dev to generate wake-up events at run time and put it into a low
+ * power state.
+ */
+int pci_finish_runtime_suspend(struct pci_dev *dev)
+{
+ pci_power_t target_state = pci_target_state(dev);
+ int error;
+
+ if (target_state == PCI_POWER_ERROR)
+ return -EIO;
+
+ __pci_enable_wake(dev, target_state, true, pci_dev_run_wake(dev));
+
+ error = pci_set_power_state(dev, target_state);
+
+ if (error)
+ __pci_enable_wake(dev, target_state, true, false);
+
+ return error;
+}
+
+/**
* pci_dev_run_wake - Check if device can generate run-time wake-up events.
* @dev: Device to check.
*
@@ -2978,7 +3010,6 @@ EXPORT_SYMBOL(pci_save_state);
EXPORT_SYMBOL(pci_restore_state);
EXPORT_SYMBOL(pci_pme_capable);
EXPORT_SYMBOL(pci_pme_active);
-EXPORT_SYMBOL(pci_enable_wake);
EXPORT_SYMBOL(pci_wake_from_d3);
EXPORT_SYMBOL(pci_target_state);
EXPORT_SYMBOL(pci_prepare_to_sleep);
Index: linux-2.6/include/linux/pci.h
===================================================================
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -751,13 +751,20 @@ int pci_set_power_state(struct pci_dev *
pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state);
bool pci_pme_capable(struct pci_dev *dev, pci_power_t state);
void pci_pme_active(struct pci_dev *dev, bool enable);
-int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable);
+int __pci_enable_wake(struct pci_dev *dev, pci_power_t state,
+ bool runtime, bool enable);
int pci_wake_from_d3(struct pci_dev *dev, bool enable);
pci_power_t pci_target_state(struct pci_dev *dev);
int pci_prepare_to_sleep(struct pci_dev *dev);
int pci_back_from_sleep(struct pci_dev *dev);
bool pci_dev_run_wake(struct pci_dev *dev);
+static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
+ bool enable)
+{
+ return __pci_enable_wake(dev, state, false, enable);
+}
+
/* Functions for PCI Hotplug drivers to use */
int pci_bus_find_capability(struct pci_bus *bus, unsigned int devfn, int cap);
#ifdef CONFIG_HOTPLUG
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -55,6 +55,7 @@ extern int pci_set_platform_pm(struct pc
extern void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
extern void pci_disable_enabled_device(struct pci_dev *dev);
extern bool pci_check_pme_status(struct pci_dev *dev);
+extern int pci_finish_runtime_suspend(struct pci_dev *dev);
extern int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
extern void pci_pme_wakeup_bus(struct pci_bus *bus);
extern void pci_pm_init(struct pci_dev *dev);
From: Rafael J. Wysocki <[email protected]>
Apparently, some machines may have problems with PCI run-time power
management if MSIs are used for the native PCIe PME signaling. In
particular, on the MSI Wind U-100 PCIe PME interrupts are not
generated by a PCIe root port after a resume from suspend to RAM, if
the system wake-up was triggered by a PME from the device attached to
this port. [It doesn't help to free the interrupt on suspend and
request it back on resume, even if that is done along with disabling
the MSI and re-enabling it, respectively.] However, if INTx
interrupts are used for this purpose on the same machine, everything
works just fine.
For this reason, add a kernel command line switch allowing one to
request that MSIs be not used for the native PCIe PME signaling,
introduce a DMI table allowing us to blacklist machines that need
this switch to be set by default and put the MSI Wind U-100 into this
table.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
Documentation/kernel-parameters.txt | 2 ++
drivers/pci/pcie/pme/pcie_pme.c | 14 +++++++++++++-
drivers/pci/pcie/portdrv.h | 17 +++++++++++++++++
drivers/pci/pcie/portdrv_core.c | 12 ++++++++++--
drivers/pci/pcie/portdrv_pci.c | 27 +++++++++++++++++++++++++++
5 files changed, 69 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/pci/pcie/pme/pcie_pme.c
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/pme/pcie_pme.c
+++ linux-2.6/drivers/pci/pcie/pme/pcie_pme.c
@@ -53,12 +53,22 @@ static bool pcie_pme_disabled;
*/
static bool pcie_pme_force_enable;
+/*
+ * If this switch is set, MSI will not be used for PCIe PME signaling. This
+ * causes the PCIe port driver to use INTx interrupts only, but it turns out
+ * that using MSI for PCIe PME signaling doesn't play well with PCIe PME-based
+ * wake-up from system sleep states.
+ */
+bool pcie_pme_msi_disabled;
+
static int __init pcie_pme_setup(char *str)
{
if (!strcmp(str, "off"))
pcie_pme_disabled = true;
else if (!strcmp(str, "force"))
pcie_pme_force_enable = true;
+ else if (!strcmp(str, "nomsi"))
+ pcie_pme_msi_disabled = true;
return 1;
}
__setup("pcie_pme=", pcie_pme_setup);
@@ -73,7 +83,9 @@ __setup("pcie_pme=", pcie_pme_setup);
*/
static bool pcie_pme_platform_setup(struct pcie_device *srv)
{
- return !pcie_pme_platform_notify(srv) || pcie_pme_force_enable;
+ if (!pcie_pme_platform_notify(srv))
+ return true;
+ return pcie_pme_force_enable;
}
struct pcie_pme_service_data {
Index: linux-2.6/drivers/pci/pcie/portdrv_core.c
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/portdrv_core.c
+++ linux-2.6/drivers/pci/pcie/portdrv_core.c
@@ -186,16 +186,24 @@ static int pcie_port_enable_msix(struct
*/
static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
{
- int i, irq;
+ int i, irq = -1;
+
+ /* We have to use INTx if MSI cannot be used for PCIe PME. */
+ if ((mask & PCIE_PORT_SERVICE_PME) && pcie_pme_no_msi()) {
+ if (dev->pin)
+ irq = dev->irq;
+ goto no_msi;
+ }
/* Try to use MSI-X if supported */
if (!pcie_port_enable_msix(dev, irqs, mask))
return 0;
+
/* We're not going to use MSI-X, so try MSI and fall back to INTx */
- irq = -1;
if (!pci_enable_msi(dev) || dev->pin)
irq = dev->irq;
+ no_msi:
for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
irqs[i] = irq;
irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
Index: linux-2.6/drivers/pci/pcie/portdrv_pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/portdrv_pci.c
+++ linux-2.6/drivers/pci/pcie/portdrv_pci.c
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <linux/pcieport_if.h>
#include <linux/aer.h>
+#include <linux/dmi.h>
#include "portdrv.h"
#include "aer/aerdrv.h"
@@ -273,10 +274,36 @@ static struct pci_driver pcie_portdriver
.driver.pm = PCIE_PORTDRV_PM_OPS,
};
+static int __init dmi_pcie_pme_disable_msi(const struct dmi_system_id *d)
+{
+ pr_notice("%s detected: will not use MSI for PCIe PME signaling\n",
+ d->ident);
+ pcie_pme_disable_msi();
+ return 0;
+}
+
+static struct dmi_system_id __initdata pcie_portdrv_dmi_table[] = {
+ /*
+ * Boxes that should not use MSI for PCIe PME signaling.
+ */
+ {
+ .callback = dmi_pcie_pme_disable_msi,
+ .ident = "MSI Wind U-100",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR,
+ "MICRO-STAR INTERNATIONAL CO., LTD"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "U-100"),
+ },
+ },
+ {}
+};
+
static int __init pcie_portdrv_init(void)
{
int retval;
+ dmi_check_system(pcie_portdrv_dmi_table);
+
retval = pcie_port_bus_register();
if (retval) {
printk(KERN_WARNING "PCIE: bus_register error: %d\n", retval);
Index: linux-2.6/drivers/pci/pcie/portdrv.h
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/portdrv.h
+++ linux-2.6/drivers/pci/pcie/portdrv.h
@@ -30,4 +30,21 @@ extern void pcie_port_device_remove(stru
extern int __must_check pcie_port_bus_register(void);
extern void pcie_port_bus_unregister(void);
+#ifdef CONFIG_PCIE_PME
+extern bool pcie_pme_msi_disabled;
+
+static inline void pcie_pme_disable_msi(void)
+{
+ pcie_pme_msi_disabled = true;
+}
+
+static inline bool pcie_pme_no_msi(void)
+{
+ return pcie_pme_msi_disabled;
+}
+#else /* !CONFIG_PCIE_PME */
+static inline void pcie_pme_disable_msi(void) {}
+static inline bool pcie_pme_no_msi(void) { return false; }
+#endif /* !CONFIG_PCIE_PME */
+
#endif /* _PORTDRV_H_ */
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1994,6 +1994,8 @@ and is between 256 and 4096 characters.
force Use native PCIe PME signaling even if the BIOS refuses
to allow the kernel to control the relevant PCIe config
registers.
+ nomsi Do not use MSI for native PCIe PME signaling (this makes
+ all PCIe root ports use INTx for everything).
pcmv= [HW,PCMCIA] BadgePAD 4
From: Rafael J. Wysocki <[email protected]>
Although the majority of PCI devices can generate PMEs that in
principle may be used to wake up devices suspended at run time,
platform support is generally necessary to convert PMEs into wake-up
events that can be delivered to the kernel. If ACPI is used for this
purpose, a PME generated by a PCI device will trigger the ACPI GPE
associated with the device to generate an ACPI wake-up event that we
can set up a handler for, provided that everything is configured
correctly.
Unfortunately, the subset of PCI devices that have GPEs associated
with them is quite limited and the other devices have to rely on
the GPEs associated with their upstream bridges and, possibly, the
root bridge to generate ACPI wake-up events in response to PMEs from
them. Moreover, ACPI-based PCI hotplug also uses ACPI notify
handlers that in general may conflict with the PM notify handlers,
unless this issue is specifically taken care of.
Add ACPI platform support for PCI PME wake-up:
o Add a framework making is possible to use ACPI system notify
handlers for both PM and hotplug at the same time and to take the
wake-up GPE sharing into account.
o Add new PCI platform callback ->run_wake() to struct
pci_platform_pm_ops allowing us to enable/disable the platform to
generate wake-up events for given device. Implemet this callback
for the ACPI platform.
o Define ACPI wake-up handlers for PCI devices and PCI buses and make
the PCI-ACPI binding code register wake-up notifiers for devices
associated with wake-up GPEs.
o Add function pci_dev_run_wake() which can be used by PCI drivers to
check if given device is capable of generating wake-up events at
run time.
Developed in cooperation with Matthew Garrett <[email protected]>.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/internal.h | 2
drivers/acpi/pci_bind.c | 14 +
drivers/acpi/pci_root.c | 8
drivers/pci/hotplug/acpiphp_glue.c | 23 --
drivers/pci/pci-acpi.c | 341 +++++++++++++++++++++++++++++++++++++
drivers/pci/pci.c | 67 +++++++
drivers/pci/pci.h | 7
include/acpi/acpi_bus.h | 4
include/linux/pci-acpi.h | 10 +
include/linux/pci.h | 1
10 files changed, 460 insertions(+), 17 deletions(-)
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -35,6 +35,10 @@ int pci_probe_reset_function(struct pci_
*
* @sleep_wake: enables/disables the system wake up capability of given device
*
+ * @run_wake: enables/disables the platform to generate run-time wake-up events
+ * for given device (the device's wake-up capability has to be
+ * enabled by @sleep_wake for this feature to work)
+ *
* If given platform is generally capable of power managing PCI devices, all of
* these callbacks are mandatory.
*/
@@ -44,12 +48,15 @@ struct pci_platform_pm_ops {
pci_power_t (*choose_state)(struct pci_dev *dev);
bool (*can_wakeup)(struct pci_dev *dev);
int (*sleep_wake)(struct pci_dev *dev, bool enable);
+ int (*run_wake)(struct pci_dev *dev, bool enable);
};
extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
extern void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
extern void pci_disable_enabled_device(struct pci_dev *dev);
extern bool pci_check_pme_status(struct pci_dev *dev);
+extern int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
+extern void pci_pme_wakeup_bus(struct pci_bus *bus);
extern void pci_pm_init(struct pci_dev *dev);
extern void platform_pci_wakeup_init(struct pci_dev *dev);
extern void pci_allocate_cap_save_buffers(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -16,8 +16,276 @@
#include <acpi/acpi_bus.h>
#include <linux/pci-acpi.h>
+#include <linux/pm_runtime.h>
#include "pci.h"
+static DEFINE_MUTEX(pci_acpi_notifier_mtx);
+
+struct pci_acpi_notify_data
+{
+ acpi_notify_handler hp_cb;
+ void *hp_data;
+ struct pci_bus *pci_bus;
+ struct pci_dev *pci_dev;
+};
+
+/**
+ * pci_acpi_event_fn - Universal system notification handler.
+ * @handle: ACPI handle of a device the notification is for.
+ * @event: Type of the signaled event.
+ * @ign: The value of this argument is ignored.
+ *
+ * Use @handle to obtain the address of the ACPI device object the event is
+ * signaled for. If this is a wake-up event, execute the appropriate PME
+ * handler for the bus or device represented by it (or both, if @dev is a
+ * bridge). If this is not a wake-up event, execute the hotplug notify handler
+ * for @handle.
+ */
+static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *ign)
+{
+ struct acpi_device *dev;
+ struct pci_acpi_notify_data *nd;
+
+ if (ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
+ pr_warning("ACPI handle has no context in %s!\n", __func__);
+ return;
+ }
+
+ mutex_lock(&pci_acpi_notifier_mtx);
+
+ nd = dev->bus_data;
+ if (!nd)
+ goto out;
+
+ if (event == ACPI_NOTIFY_DEVICE_WAKE) {
+ if (nd->pci_bus) {
+ pci_pme_wakeup_bus(nd->pci_bus);
+ }
+ if (nd->pci_dev) {
+ pci_check_pme_status(nd->pci_dev);
+ pm_request_resume(&nd->pci_dev->dev);
+ }
+ } else if (nd->hp_cb) {
+ nd->hp_cb(handle, event, nd->hp_data);
+ }
+
+ out:
+ mutex_unlock(&pci_acpi_notifier_mtx);
+}
+
+/**
+ * add_notify_data - Create a new notify data object for given ACPI device.
+ * @dev: Device to create the notify data object for.
+ */
+static struct pci_acpi_notify_data *add_notify_data(struct acpi_device *dev)
+{
+ struct pci_acpi_notify_data *nd;
+
+ nd = kzalloc(sizeof(*nd), GFP_KERNEL);
+ if (!nd)
+ return NULL;
+
+ dev->bus_data = nd;
+ return nd;
+}
+
+/**
+ * remove_notify_data - Remove the notify data object from given ACPI device.
+ * @dev: Device to remove the notify data object from.
+ */
+static void remove_notify_data(struct acpi_device *dev)
+{
+ kfree(dev->bus_data);
+ dev->bus_data = NULL;
+}
+
+/**
+ * pci_acpi_add_hp_notifier - Register a hotplug notifier for given device.
+ * @handle: ACPI handle of the device to register the notifier for.
+ * @handler: Callback to execute for hotplug events related to @handle.
+ * @context: Pointer to the context data to pass to @handler.
+ *
+ * Use @handle to get an ACPI device object and check if there is a notify data
+ * object for it. If this is the case, add @handler and @context to the
+ * existing notify data object, unless there already is a hotplug handler in
+ * there. Otherwise, create a new notify data object for the ACPI device
+ * associated with @handle and add @handler and @context to it.
+ */
+acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler, void *context)
+{
+ struct pci_acpi_notify_data *nd;
+ struct acpi_device *dev;
+ acpi_status status = AE_OK;
+
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
+ return AE_NOT_FOUND;
+
+ mutex_lock(&pci_acpi_notifier_mtx);
+
+ nd = dev->bus_data;
+ if (nd) {
+ if (!nd->hp_cb)
+ goto add;
+
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ }
+
+ nd = add_notify_data(dev);
+ if (!nd) {
+ status = AE_NO_MEMORY;
+ goto out;
+ }
+
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, NULL);
+ if (ACPI_FAILURE(status)) {
+ remove_notify_data(dev);
+ goto out;
+ }
+
+ add:
+ nd->hp_cb = handler;
+ nd->hp_data = context;
+
+ out:
+ mutex_unlock(&pci_acpi_notifier_mtx);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(pci_acpi_add_hp_notifier);
+
+/**
+ * pci_acpi_remove_hp_notifier - Unregister a hotplug notifier for given device.
+ * @handle: ACPI handle of the device to unregister the notifier for.
+ * @handler: Callback executed for hotplug events related to @handle.
+ *
+ * Remove the hotplug callback and the pointer to the hotplug context data from
+ * the notify data object belonging to the device represented by @handle. If
+ * the notify data object is not necessary any more, remove it altogether.
+ */
+acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler)
+{
+ struct pci_acpi_notify_data *nd;
+ struct acpi_device *dev;
+ acpi_status status = AE_NOT_FOUND;
+
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
+ return AE_NOT_FOUND;
+
+ mutex_lock(&pci_acpi_notifier_mtx);
+
+ nd = dev->bus_data;
+ if (!nd)
+ goto out;
+
+ nd->hp_data = NULL;
+ nd->hp_cb = NULL;
+
+ if (nd->pci_bus || nd->pci_dev)
+ goto out;
+
+ status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn);
+ remove_notify_data(dev);
+
+ out:
+ mutex_unlock(&pci_acpi_notifier_mtx);
+ return status;
+}
+EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_notifier);
+
+/**
+ * pci_acpi_add_pm_notifier - Register PM notifier for given device.
+ * @dev: ACPI device to add the notifier for.
+ * @pci_dev: PCI device to check for the PME status if an event is signaled.
+ * @pci_bus: PCI bus to walk (checking PME status) if an event is signaled.
+ *
+ * Check if there is a notify data object for @dev and if that is the case, add
+ * @pci_dev to it as the device whose PME status should be checked whenever a PM
+ * event is signaled for @dev. Also, add @pci_bus to it as the bus to walk
+ * checking the PME status of all devices on it whenever a PM event is signaled
+ * for @dev.
+ *
+ * Otherwise, create a new notify data object for @dev and add both @pci_dev and
+ * @pci_bus to it.
+ *
+ * NOTE: @dev need not be a run-wake or wake-up device to be a valid source of
+ * PM wake-up events. For example, wake-up events may be generated for bridges
+ * if one of the devices below the bridge is signaling PME, even if the bridge
+ * itself doesn't have a wake-up GPE associated with it.
+ */
+acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev,
+ struct pci_dev *pci_dev,
+ struct pci_bus *pci_bus)
+{
+ struct pci_acpi_notify_data *nd;
+ acpi_status status = AE_OK;
+
+ mutex_lock(&pci_acpi_notifier_mtx);
+
+ nd = dev->bus_data;
+ if (nd)
+ goto add;
+
+ nd = add_notify_data(dev);
+ if (!nd) {
+ status = AE_NO_MEMORY;
+ goto out;
+ }
+
+ status = acpi_install_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, NULL);
+ if (ACPI_FAILURE(status)) {
+ remove_notify_data(dev);
+ goto out;
+ }
+
+ add:
+ nd->pci_dev = pci_dev;
+ nd->pci_bus = pci_bus;
+
+ out:
+ mutex_unlock(&pci_acpi_notifier_mtx);
+ return status;
+}
+
+/**
+ * pci_acpi_remove_pm_notifier - Unregister PM notifier for given device.
+ * @dev: ACPI device to remove the notifier from.
+ *
+ * Find the notify data object for @dev and clear its @pci_dev and @pci_bus
+ * fields. If the notify data object is not necessary any more after that,
+ * remove it too.
+ */
+acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
+{
+ struct pci_acpi_notify_data *nd;
+ acpi_status status = AE_NOT_FOUND;
+
+ mutex_lock(&pci_acpi_notifier_mtx);
+
+ nd = dev->bus_data;
+ if (!nd)
+ goto out;
+
+ nd->pci_dev = NULL;
+ nd->pci_bus = NULL;
+
+ if (nd->hp_cb)
+ goto out;
+
+ status = acpi_remove_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn);
+ remove_notify_data(dev);
+
+ out:
+ mutex_unlock(&pci_acpi_notifier_mtx);
+ return status;
+}
+
/*
* _SxD returns the D-state with the highest power
* (lowest D-state number) supported in the S-state "x".
@@ -131,12 +399,85 @@ static int acpi_pci_sleep_wake(struct pc
return 0;
}
+/**
+ * acpi_dev_run_wake - Enable/disable wake-up for given device.
+ * @phys_dev: Device to enable/disable the platform to wake-up the system for.
+ * @enable: Whether enable or disable the wake-up functionality.
+ *
+ * Find the ACPI device object corresponding to @pci_dev and try to
+ * enable/disable the GPE associated with it.
+ */
+static int acpi_dev_run_wake(struct device *phys_dev, bool enable)
+{
+ struct acpi_device *dev;
+ acpi_handle handle;
+ int error = -ENODEV;
+
+ if (!device_run_wake(phys_dev))
+ return -EINVAL;
+
+ handle = DEVICE_ACPI_HANDLE(phys_dev);
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
+ dev_dbg(phys_dev, "ACPI handle has no context in %s!\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ if (enable) {
+ if (!dev->wakeup.run_wake_count++) {
+ acpi_enable_wakeup_device_power(dev, ACPI_STATE_S0);
+ acpi_ref_runtime_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
+ }
+ } else if (dev->wakeup.run_wake_count > 0) {
+ if (!--dev->wakeup.run_wake_count) {
+ acpi_unref_runtime_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
+ acpi_disable_wakeup_device_power(dev);
+ }
+ } else {
+ error = -EALREADY;
+ }
+
+ return error;
+}
+
+static void acpi_pci_propagate_run_wake(struct pci_bus *bus, bool enable)
+{
+ while (bus->parent) {
+ struct pci_dev *bridge = bus->self;
+
+ if (bridge->pme_interrupt)
+ return;
+ if (!acpi_dev_run_wake(&bridge->dev, enable))
+ return;
+ bus = bus->parent;
+ }
+
+ /* We have reached the root bus. */
+ if (bus->bridge)
+ acpi_dev_run_wake(bus->bridge, enable);
+}
+
+static int acpi_pci_run_wake(struct pci_dev *dev, bool enable)
+{
+ if (dev->pme_interrupt)
+ return 0;
+
+ if (!acpi_dev_run_wake(&dev->dev, enable))
+ return 0;
+
+ acpi_pci_propagate_run_wake(dev->bus, enable);
+ return 0;
+}
+
static struct pci_platform_pm_ops acpi_pci_platform_pm = {
.is_manageable = acpi_pci_power_manageable,
.set_state = acpi_pci_set_power_state,
.choose_state = acpi_pci_choose_state,
.can_wakeup = acpi_pci_can_wakeup,
.sleep_wake = acpi_pci_sleep_wake,
+ .run_wake = acpi_pci_run_wake,
};
/* ACPI bus type */
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -20,6 +20,7 @@
#include <linux/pm_wakeup.h>
#include <linux/interrupt.h>
#include <linux/device.h>
+#include <linux/pm_runtime.h>
#include <asm/setup.h>
#include "pci.h"
@@ -462,6 +463,12 @@ static inline int platform_pci_sleep_wak
pci_platform_pm->sleep_wake(dev, enable) : -ENODEV;
}
+static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable)
+{
+ return pci_platform_pm ?
+ pci_platform_pm->run_wake(dev, enable) : -ENODEV;
+}
+
/**
* pci_raw_set_power_state - Use PCI PM registers to set the power state of
* given PCI device
@@ -1230,6 +1237,31 @@ bool pci_check_pme_status(struct pci_dev
}
/**
+ * pci_pme_wakeup - Wake up a PCI device if its PME Status bit is set.
+ * @dev: Device to handle.
+ * @ign: Ignored.
+ *
+ * Check if @dev has generated PME and queue a resume request for it in that
+ * case.
+ */
+static int pci_pme_wakeup(struct pci_dev *dev, void *ign)
+{
+ if (pci_check_pme_status(dev))
+ pm_request_resume(&dev->dev);
+ return 0;
+}
+
+/**
+ * pci_pme_wakeup_bus - Walk given bus and wake up devices on it, if necessary.
+ * @bus: Top bus of the subtree to walk.
+ */
+void pci_pme_wakeup_bus(struct pci_bus *bus)
+{
+ if (bus)
+ pci_walk_bus(bus, pci_pme_wakeup, NULL);
+}
+
+/**
* pci_pme_capable - check the capability of PCI device to generate PME#
* @dev: PCI device to handle.
* @state: PCI state from which device will issue PME#.
@@ -1434,6 +1466,41 @@ int pci_back_from_sleep(struct pci_dev *
}
/**
+ * pci_dev_run_wake - Check if device can generate run-time wake-up events.
+ * @dev: Device to check.
+ *
+ * Return true if the device itself is cabable of generating wake-up events
+ * (through the platform or using the native PCIe PME) or if the device supports
+ * PME and one of its upstream bridges can generate wake-up events.
+ */
+bool pci_dev_run_wake(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+
+ if (device_run_wake(&dev->dev))
+ return true;
+
+ if (!dev->pme_support)
+ return false;
+
+ while (bus->parent) {
+ struct pci_dev *bridge = bus->self;
+
+ if (device_run_wake(&bridge->dev))
+ return true;
+
+ bus = bus->parent;
+ }
+
+ /* We have reached the root bus. */
+ if (bus->bridge)
+ return device_run_wake(bus->bridge);
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(pci_dev_run_wake);
+
+/**
* pci_pm_init - Initialize PM functions of given PCI device
* @dev: PCI device to handle.
*/
Index: linux-2.6/include/linux/pci-acpi.h
===================================================================
--- linux-2.6.orig/include/linux/pci-acpi.h
+++ linux-2.6/include/linux/pci-acpi.h
@@ -11,6 +11,16 @@
#include <linux/acpi.h>
#ifdef CONFIG_ACPI
+extern acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler,
+ void *context);
+extern acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler);
+extern acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev,
+ struct pci_dev *pci_dev,
+ struct pci_bus *pci_bus);
+extern acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev);
+
static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
{
struct pci_bus *pbus = pdev->bus;
Index: linux-2.6/drivers/acpi/pci_bind.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_bind.c
+++ linux-2.6/drivers/acpi/pci_bind.c
@@ -26,7 +26,9 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/pci.h>
+#include <linux/pci-acpi.h>
#include <linux/acpi.h>
+#include <linux/pm_runtime.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
@@ -38,7 +40,13 @@ static int acpi_pci_unbind(struct acpi_d
struct pci_dev *dev;
dev = acpi_get_pci_dev(device->handle);
- if (!dev || !dev->subordinate)
+ if (!dev)
+ goto out;
+
+ device_set_run_wake(&dev->dev, false);
+ pci_acpi_remove_pm_notifier(device);
+
+ if (!dev->subordinate)
goto out;
acpi_pci_irq_del_prt(dev->subordinate);
@@ -62,6 +70,10 @@ static int acpi_pci_bind(struct acpi_dev
if (!dev)
return 0;
+ pci_acpi_add_pm_notifier(device, dev, dev->subordinate);
+ if (device->wakeup.flags.run_wake)
+ device_set_run_wake(&dev->dev, true);
+
/*
* Install the 'bind' function to facilitate callbacks for
* children of the P2P bridge.
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===================================================================
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -236,8 +236,7 @@ register_slot(acpi_handle handle, u32 lv
/* install notify handler */
if (!(newfunc->flags & FUNC_HAS_DCK)) {
- status = acpi_install_notify_handler(handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(handle,
handle_hotplug_event_func,
newfunc);
@@ -288,14 +287,12 @@ static void init_bridge_misc(struct acpi
/* install notify handler */
if (bridge->type != BRIDGE_TYPE_HOST) {
if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
- status = acpi_remove_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(bridge->func->handle,
handle_hotplug_event_func);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
}
- status = acpi_install_notify_handler(bridge->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(bridge->handle,
handle_hotplug_event_bridge,
bridge);
@@ -505,15 +502,14 @@ static void cleanup_bridge(struct acpiph
acpi_status status;
acpi_handle handle = bridge->handle;
- status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(handle,
handle_hotplug_event_bridge);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
if ((bridge->type != BRIDGE_TYPE_HOST) &&
((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func)) {
- status = acpi_install_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(bridge->func->handle,
handle_hotplug_event_func,
bridge->func);
if (ACPI_FAILURE(status))
@@ -529,8 +525,7 @@ static void cleanup_bridge(struct acpiph
unregister_dock_notifier(&func->nb);
}
if (!(func->flags & FUNC_HAS_DCK)) {
- status = acpi_remove_notify_handler(func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(func->handle,
handle_hotplug_event_func);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
@@ -592,7 +587,7 @@ static void remove_bridge(acpi_handle ha
if (bridge)
cleanup_bridge(bridge);
else
- acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_remove_hp_notifier(handle,
handle_hotplug_event_bridge);
}
@@ -1278,8 +1273,8 @@ find_root_bridges(acpi_handle handle, u3
int *count = (int *)context;
if (acpi_is_root_bridge(handle)) {
- acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_bridge, NULL);
+ pci_acpi_add_hp_notifier(handle,
+ handle_hotplug_event_bridge, NULL);
(*count)++;
}
return AE_OK ;
Index: linux-2.6/include/linux/pci.h
===================================================================
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -756,6 +756,7 @@ int pci_wake_from_d3(struct pci_dev *dev
pci_power_t pci_target_state(struct pci_dev *dev);
int pci_prepare_to_sleep(struct pci_dev *dev);
int pci_back_from_sleep(struct pci_dev *dev);
+bool pci_dev_run_wake(struct pci_dev *dev);
/* Functions for PCI Hotplug drivers to use */
int pci_bus_find_capability(struct pci_bus *bus, unsigned int devfn, int cap);
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -282,6 +282,7 @@ struct acpi_device {
struct device dev;
struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
+ void *bus_data;
};
static inline void *acpi_driver_data(struct acpi_device *d)
@@ -388,6 +389,9 @@ acpi_handle acpi_get_pci_rootbridge_hand
struct acpi_pci_root *acpi_pci_find_root(acpi_handle handle);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->archdata.acpi_handle))
+int acpi_enable_wakeup_device_power(struct acpi_device *dev, int state);
+int acpi_disable_wakeup_device_power(struct acpi_device *dev);
+
#ifdef CONFIG_PM_SLEEP
int acpi_pm_device_sleep_state(struct device *, int *);
int acpi_pm_device_sleep_wake(struct device *, bool);
Index: linux-2.6/drivers/acpi/pci_root.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_root.c
+++ linux-2.6/drivers/acpi/pci_root.c
@@ -30,6 +30,7 @@
#include <linux/proc_fs.h>
#include <linux/spinlock.h>
#include <linux/pm.h>
+#include <linux/pm_runtime.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
#include <linux/acpi.h>
@@ -528,6 +529,10 @@ static int __devinit acpi_pci_root_add(s
if (flags != base_flags)
acpi_pci_osc_support(root, flags);
+ pci_acpi_add_pm_notifier(device, NULL, root->bus);
+ if (device->wakeup.flags.run_wake)
+ device_set_run_wake(root->bus->bridge, true);
+
return 0;
end:
@@ -549,6 +554,9 @@ static int acpi_pci_root_remove(struct a
{
struct acpi_pci_root *root = acpi_driver_data(device);
+ device_set_run_wake(root->bus->bridge, false);
+ pci_acpi_remove_pm_notifier(device);
+
kfree(root);
return 0;
}
Index: linux-2.6/drivers/acpi/internal.h
===================================================================
--- linux-2.6.orig/drivers/acpi/internal.h
+++ linux-2.6/drivers/acpi/internal.h
@@ -36,8 +36,6 @@ static inline int acpi_debug_init(void)
int acpi_power_init(void);
int acpi_device_sleep_wake(struct acpi_device *dev,
int enable, int sleep_state, int dev_state);
-int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state);
-int acpi_disable_wakeup_device_power(struct acpi_device *dev);
int acpi_power_get_inferred_state(struct acpi_device *device);
int acpi_power_transition(struct acpi_device *device, int state);
extern int acpi_power_nocheck;
From: Rafael J. Wysocki <[email protected]>
Add function pci_check_pme_status() that will check the PME status
bit of given device and clear it along with the PME enable bit. It
will be necessary for PCI run-time power management.
Based on a patch from Shaohua Li <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/pci/pci.c | 35 +++++++++++++++++++++++++++++++++++
drivers/pci/pci.h | 1 +
2 files changed, 36 insertions(+)
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -49,6 +49,7 @@ struct pci_platform_pm_ops {
extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
extern void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
extern void pci_disable_enabled_device(struct pci_dev *dev);
+extern bool pci_check_pme_status(struct pci_dev *dev);
extern void pci_pm_init(struct pci_dev *dev);
extern void platform_pci_wakeup_init(struct pci_dev *dev);
extern void pci_allocate_cap_save_buffers(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -1195,6 +1195,41 @@ int pci_set_pcie_reset_state(struct pci_
}
/**
+ * pci_check_pme_status - Check if given device has generated PME.
+ * @dev: Device to check.
+ *
+ * Check the PME status of the device and if set, clear it and clear PME enable
+ * (if set). Return 'true' if PME status and PME enable were both set or
+ * 'false' otherwise.
+ */
+bool pci_check_pme_status(struct pci_dev *dev)
+{
+ int pmcsr_pos;
+ u16 pmcsr;
+ bool ret = false;
+
+ if (!dev->pm_cap)
+ return false;
+
+ pmcsr_pos = dev->pm_cap + PCI_PM_CTRL;
+ pci_read_config_word(dev, pmcsr_pos, &pmcsr);
+ if (!(pmcsr & PCI_PM_CTRL_PME_STATUS))
+ return false;
+
+ /* Clear PME status. */
+ pmcsr |= PCI_PM_CTRL_PME_STATUS;
+ if (pmcsr & PCI_PM_CTRL_PME_ENABLE) {
+ /* Disable PME to avoid interrupt flood. */
+ pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
+ ret = true;
+ }
+
+ pci_write_config_word(dev, pmcsr_pos, pmcsr);
+
+ return ret;
+}
+
+/**
* pci_pme_capable - check the capability of PCI device to generate PME#
* @dev: PCI device to handle.
* @state: PCI state from which device will issue PME#.
From: Matthew Garrett <[email protected]>
Remove the old GPE type handling entirely, which gets rid of various quirks
like the implicit disabling with GPE type setting. This requires a small
amount of rework in order to ensure that non-wake GPEs are enabled by
default to preserve existing behaviour.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/acpica/acevents.h | 6 +--
drivers/acpi/acpica/acevents.h | 6 -
drivers/acpi/acpica/evgpe.c | 147 +++--------------------------------------
drivers/acpi/acpica/evgpeblk.c | 69 ++++++-------------
drivers/acpi/acpica/evxface.c | 14 ---
drivers/acpi/acpica/evxfevnt.c | 48 -------------
drivers/acpi/button.c | 5 -
drivers/acpi/ec.c | 2
drivers/acpi/wakeup.c | 55 ++-------------
include/acpi/actypes.h | 32 ++------
9 files changed, 59 insertions(+), 319 deletions(-)
Index: linux-2.6/drivers/acpi/acpica/acevents.h
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/acevents.h
+++ linux-2.6/drivers/acpi/acpica/acevents.h
@@ -76,8 +76,7 @@ acpi_ev_queue_notify_request(struct acpi
* evgpe - GPE handling and dispatch
*/
acpi_status
-acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info,
- u8 type);
+acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info);
acpi_status
acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info,
@@ -122,9 +121,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_eve
u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *gpe_xrupt_list);
acpi_status
-acpi_ev_set_gpe_type(struct acpi_gpe_event_info *gpe_event_info, u8 type);
-
-acpi_status
acpi_ev_check_for_wake_only_gpe(struct acpi_gpe_event_info *gpe_event_info);
acpi_status acpi_ev_gpe_initialize(void);
Index: linux-2.6/drivers/acpi/acpica/evgpe.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpe.c
+++ linux-2.6/drivers/acpi/acpica/evgpe.c
@@ -54,54 +54,9 @@ static void ACPI_SYSTEM_XFACE acpi_ev_as
/*******************************************************************************
*
- * FUNCTION: acpi_ev_set_gpe_type
- *
- * PARAMETERS: gpe_event_info - GPE to set
- * Type - New type
- *
- * RETURN: Status
- *
- * DESCRIPTION: Sets the new type for the GPE (wake, run, or wake/run)
- *
- ******************************************************************************/
-
-acpi_status
-acpi_ev_set_gpe_type(struct acpi_gpe_event_info *gpe_event_info, u8 type)
-{
- acpi_status status;
-
- ACPI_FUNCTION_TRACE(ev_set_gpe_type);
-
- /* Validate type and update register enable masks */
-
- switch (type) {
- case ACPI_GPE_TYPE_WAKE:
- case ACPI_GPE_TYPE_RUNTIME:
- case ACPI_GPE_TYPE_WAKE_RUN:
- break;
-
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
- }
-
- /* Disable the GPE if currently enabled */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
-
- /* Clear the type bits and insert the new Type */
-
- gpe_event_info->flags &= ~ACPI_GPE_TYPE_MASK;
- gpe_event_info->flags |= type;
- return_ACPI_STATUS(status);
-}
-
-/*******************************************************************************
- *
* FUNCTION: acpi_ev_update_gpe_enable_masks
*
* PARAMETERS: gpe_event_info - GPE to update
- * Type - What to do: ACPI_GPE_DISABLE or
- * ACPI_GPE_ENABLE
*
* RETURN: Status
*
@@ -110,8 +65,7 @@ acpi_ev_set_gpe_type(struct acpi_gpe_eve
******************************************************************************/
acpi_status
-acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info,
- u8 type)
+acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info)
{
struct acpi_gpe_register_info *gpe_register_info;
u8 register_bit;
@@ -127,37 +81,13 @@ acpi_ev_update_gpe_enable_masks(struct a
(1 <<
(gpe_event_info->gpe_number - gpe_register_info->base_gpe_number));
- /* 1) Disable case. Simply clear all enable bits */
-
- if (type == ACPI_GPE_DISABLE) {
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake,
- register_bit);
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- return_ACPI_STATUS(AE_OK);
- }
-
- /* 2) Enable case. Set/Clear the appropriate enable bits */
-
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
- ACPI_SET_BIT(gpe_register_info->enable_for_wake, register_bit);
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
+ ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake, register_bit);
+ ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- case ACPI_GPE_TYPE_RUNTIME:
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake,
- register_bit);
+ if (gpe_event_info->runtime_count)
ACPI_SET_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
-
- case ACPI_GPE_TYPE_WAKE_RUN:
+ if (gpe_event_info->wakeup_count)
ACPI_SET_BIT(gpe_register_info->enable_for_wake, register_bit);
- ACPI_SET_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
-
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
- }
return_ACPI_STATUS(AE_OK);
}
@@ -186,47 +116,21 @@ acpi_ev_enable_gpe(struct acpi_gpe_event
/* Make sure HW enable masks are updated */
- status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info, ACPI_GPE_ENABLE);
+ status = acpi_ev_update_gpe_enable_masks(gpe_event_info);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
/* Mark wake-enabled or HW enable, or both */
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
- break;
-
- case ACPI_GPE_TYPE_WAKE_RUN:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
-
- /*lint -fallthrough */
-
- case ACPI_GPE_TYPE_RUNTIME:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_RUN_ENABLED);
-
- if (write_to_hardware) {
-
- /* Clear the GPE (of stale events), then enable it */
-
- status = acpi_hw_clear_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
- }
-
- /* Enable the requested runtime GPE */
-
- status = acpi_hw_write_gpe_enable_reg(gpe_event_info);
- }
- break;
+ if (gpe_event_info->runtime_count && write_to_hardware) {
+ /* Clear the GPE (of stale events), then enable it */
+ status = acpi_hw_clear_gpe(gpe_event_info);
+ if (ACPI_FAILURE(status))
+ return_ACPI_STATUS(status);
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
+ /* Enable the requested runtime GPE */
+ status = acpi_hw_write_gpe_enable_reg(gpe_event_info);
}
return_ACPI_STATUS(AE_OK);
@@ -253,34 +157,11 @@ acpi_status acpi_ev_disable_gpe(struct a
/* Make sure HW enable masks are updated */
status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info, ACPI_GPE_DISABLE);
+ acpi_ev_update_gpe_enable_masks(gpe_event_info);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
- /* Clear the appropriate enabled flags for this GPE */
-
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
- break;
-
- case ACPI_GPE_TYPE_WAKE_RUN:
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
-
- /* fallthrough */
-
- case ACPI_GPE_TYPE_RUNTIME:
-
- /* Disable the requested runtime GPE */
-
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_RUN_ENABLED);
- break;
-
- default:
- break;
- }
-
/*
* Even if we don't know the GPE type, make sure that we always
* disable it. low_disable_gpe will just clear the enable bit for this
Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c
+++ linux-2.6/drivers/acpi/acpica/evgpeblk.c
@@ -325,22 +325,16 @@ acpi_ev_save_method_info(acpi_handle obj
/*
* Now we can add this information to the gpe_event_info block for use
- * during dispatch of this GPE. Default type is RUNTIME, although this may
- * change when the _PRW methods are executed later.
+ * during dispatch of this GPE.
*/
gpe_event_info =
&gpe_block->event_info[gpe_number - gpe_block->block_base_number];
- gpe_event_info->flags = (u8)
- (type | ACPI_GPE_DISPATCH_METHOD | ACPI_GPE_TYPE_RUNTIME);
+ gpe_event_info->flags = (u8) (type | ACPI_GPE_DISPATCH_METHOD);
gpe_event_info->dispatch.method_node =
(struct acpi_namespace_node *)obj_handle;
- /* Update enable mask, but don't enable the HW GPE as of yet */
-
- status = acpi_ev_enable_gpe(gpe_event_info, FALSE);
-
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Registered GPE method %s as GPE number 0x%.2X\n",
name, gpe_number));
@@ -454,20 +448,7 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob
gpe_block->
block_base_number];
- /* Mark GPE for WAKE-ONLY but WAKE_DISABLED */
-
- gpe_event_info->flags &=
- ~(ACPI_GPE_WAKE_ENABLED | ACPI_GPE_RUN_ENABLED);
-
- status =
- acpi_ev_set_gpe_type(gpe_event_info, ACPI_GPE_TYPE_WAKE);
- if (ACPI_FAILURE(status)) {
- goto cleanup;
- }
-
- status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info,
- ACPI_GPE_DISABLE);
+ gpe_event_info->flags |= ACPI_GPE_CAN_WAKE;
}
cleanup:
@@ -1027,33 +1008,35 @@ acpi_ev_initialize_gpe_block(struct acpi
}
/*
- * Enable all GPEs in this block that have these attributes:
- * 1) are "runtime" or "run/wake" GPEs, and
- * 2) have a corresponding _Lxx or _Exx method
- *
- * Any other GPEs within this block must be enabled via the
- * acpi_enable_gpe() external interface.
+ * Enable all GPEs that have a corresponding method and aren't
+ * capable of generating wakeups. Any other GPEs within this block
+ * must be enabled via the acpi_ref_runtime_gpe interface.
*/
wake_gpe_count = 0;
gpe_enabled_count = 0;
for (i = 0; i < gpe_block->register_count; i++) {
for (j = 0; j < 8; j++) {
+ int gpe_number = i * ACPI_GPE_REGISTER_WIDTH + j;
/* Get the info block for this particular GPE */
- gpe_event_info = &gpe_block->event_info[((acpi_size) i *
- ACPI_GPE_REGISTER_WIDTH)
- + j];
-
- if (((gpe_event_info->flags & ACPI_GPE_DISPATCH_MASK) ==
- ACPI_GPE_DISPATCH_METHOD) &&
- (gpe_event_info->flags & ACPI_GPE_TYPE_RUNTIME)) {
- gpe_enabled_count++;
- }
+ gpe_event_info = &gpe_block->event_info[(acpi_size)
+ gpe_number];
- if (gpe_event_info->flags & ACPI_GPE_TYPE_WAKE) {
+ if (gpe_event_info->flags & ACPI_GPE_CAN_WAKE) {
wake_gpe_count++;
+ continue;
+ }
+
+ if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD) {
+ gpe_enabled_count++;
+ if (gpe_device == acpi_gbl_fadt_gpe_device)
+ status = acpi_ref_runtime_gpe(NULL,
+ gpe_number);
+ else
+ status = acpi_ref_runtime_gpe(gpe_device,
+ gpe_number);
}
}
}
@@ -1062,15 +1045,7 @@ acpi_ev_initialize_gpe_block(struct acpi
"Found %u Wake, Enabled %u Runtime GPEs in this block\n",
wake_gpe_count, gpe_enabled_count));
- /* Enable all valid runtime GPEs found above */
-
- status = acpi_hw_enable_runtime_gpe_block(NULL, gpe_block, NULL);
- if (ACPI_FAILURE(status)) {
- ACPI_ERROR((AE_INFO, "Could not enable GPEs in GpeBlock %p",
- gpe_block));
- }
-
- return_ACPI_STATUS(status);
+ return_ACPI_STATUS(AE_OK);
}
/*******************************************************************************
Index: linux-2.6/drivers/acpi/acpica/evxface.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxface.c
+++ linux-2.6/drivers/acpi/acpica/evxface.c
@@ -617,13 +617,6 @@ acpi_install_gpe_handler(acpi_handle gpe
handler->context = context;
handler->method_node = gpe_event_info->dispatch.method_node;
- /* Disable the GPE before installing the handler */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- goto unlock_and_exit;
- }
-
/* Install the handler */
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
@@ -707,13 +700,6 @@ acpi_remove_gpe_handler(acpi_handle gpe_
goto unlock_and_exit;
}
- /* Disable the GPE before removing the handler */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- goto unlock_and_exit;
- }
-
/* Make sure all deferred tasks are completed */
(void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
Index: linux-2.6/drivers/acpi/acpica/evxfevnt.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxfevnt.c
+++ linux-2.6/drivers/acpi/acpica/evxfevnt.c
@@ -311,8 +311,7 @@ acpi_status acpi_ref_wakeup_gpe(acpi_han
}
if (++gpe_event_info->wakeup_count == 1)
- acpi_ev_update_gpe_enable_masks(gpe_event_info,
- ACPI_GPE_ENABLE);
+ acpi_ev_update_gpe_enable_masks(gpe_event_info);
unlock_and_exit:
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
@@ -351,8 +350,7 @@ acpi_status acpi_unref_wakeup_gpe(acpi_h
}
if (--gpe_event_info->wakeup_count == 0)
- acpi_ev_update_gpe_enable_masks(gpe_event_info,
- ACPI_GPE_DISABLE);
+ acpi_ev_update_gpe_enable_masks(gpe_event_info);
unlock_and_exit:
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
@@ -362,48 +360,6 @@ ACPI_EXPORT_SYMBOL(acpi_unref_wakeup_gpe
/*******************************************************************************
*
- * FUNCTION: acpi_set_gpe_type
- *
- * PARAMETERS: gpe_device - Parent GPE Device
- * gpe_number - GPE level within the GPE block
- * Type - New GPE type
- *
- * RETURN: Status
- *
- * DESCRIPTION: Set the type of an individual GPE
- *
- ******************************************************************************/
-acpi_status acpi_set_gpe_type(acpi_handle gpe_device, u32 gpe_number, u8 type)
-{
- acpi_status status = AE_OK;
- struct acpi_gpe_event_info *gpe_event_info;
-
- ACPI_FUNCTION_TRACE(acpi_set_gpe_type);
-
- /* Ensure that we have a valid GPE number */
-
- gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
- if (!gpe_event_info) {
- status = AE_BAD_PARAMETER;
- goto unlock_and_exit;
- }
-
- if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == type) {
- return_ACPI_STATUS(AE_OK);
- }
-
- /* Set the new type (will disable GPE if currently enabled) */
-
- status = acpi_ev_set_gpe_type(gpe_event_info, type);
-
- unlock_and_exit:
- return_ACPI_STATUS(status);
-}
-
-ACPI_EXPORT_SYMBOL(acpi_set_gpe_type)
-
-/*******************************************************************************
- *
* FUNCTION: acpi_enable_gpe
*
* PARAMETERS: gpe_device - Parent GPE Device
Index: linux-2.6/drivers/acpi/button.c
===================================================================
--- linux-2.6.orig/drivers/acpi/button.c
+++ linux-2.6/drivers/acpi/button.c
@@ -422,11 +422,6 @@ static int acpi_button_add(struct acpi_d
if (device->wakeup.flags.valid) {
/* Button's GPE is run-wake GPE */
- acpi_set_gpe_type(device->wakeup.gpe_device,
- device->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
- acpi_enable_gpe(device->wakeup.gpe_device,
- device->wakeup.gpe_number);
acpi_ref_runtime_gpe(device->wakeup.gpe_device,
device->wakeup.gpe_number);
acpi_ref_wakeup_gpe(device->wakeup.gpe_device,
Index: linux-2.6/drivers/acpi/ec.c
===================================================================
--- linux-2.6.orig/drivers/acpi/ec.c
+++ linux-2.6/drivers/acpi/ec.c
@@ -754,7 +754,7 @@ static int ec_install_handlers(struct ac
&acpi_ec_gpe_handler, ec);
if (ACPI_FAILURE(status))
return -ENODEV;
- acpi_set_gpe_type(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
+
acpi_ref_runtime_gpe(NULL, ec->gpe);
status = acpi_install_address_space_handler(ec->handle,
ACPI_ADR_SPACE_EC,
Index: linux-2.6/drivers/acpi/wakeup.c
===================================================================
--- linux-2.6.orig/drivers/acpi/wakeup.c
+++ linux-2.6/drivers/acpi/wakeup.c
@@ -62,25 +62,12 @@ void acpi_enable_wakeup_device(u8 sleep_
struct acpi_device *dev =
container_of(node, struct acpi_device, wakeup_list);
- if (!dev->wakeup.flags.valid)
+ if (!dev->wakeup.flags.valid ||
+ !dev->wakeup.prepare_count ||
+ !dev->wakeup.state.enabled ||
+ (sleep_state > (u32) dev->wakeup.sleep_state))
continue;
- /* If users want to disable run-wake GPE,
- * we only disable it for wake and leave it for runtime
- */
- if ((!dev->wakeup.state.enabled && !dev->wakeup.prepare_count)
- || sleep_state > (u32) dev->wakeup.sleep_state) {
- if (dev->wakeup.flags.run_wake) {
- /* set_gpe_type will disable GPE, leave it like that */
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_RUNTIME);
- }
- continue;
- }
- if (!dev->wakeup.flags.run_wake)
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
acpi_ref_wakeup_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number);
}
@@ -99,32 +86,13 @@ void acpi_disable_wakeup_device(u8 sleep
struct acpi_device *dev =
container_of(node, struct acpi_device, wakeup_list);
- if (!dev->wakeup.flags.valid)
- continue;
-
- if ((!dev->wakeup.state.enabled && !dev->wakeup.prepare_count)
- || sleep_state > (u32) dev->wakeup.sleep_state) {
- if (dev->wakeup.flags.run_wake) {
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
- /* Re-enable it, since set_gpe_type will disable it */
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
- }
- continue;
- }
+ if (dev->wakeup.state.enabled &&
+ dev->wakeup.prepare_count &&
+ sleep_state <= (u32) dev->wakeup.sleep_state)
+ acpi_unref_wakeup_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
acpi_disable_wakeup_device_power(dev);
- /* Never disable run-wake GPE */
- if (!dev->wakeup.flags.run_wake) {
- acpi_disable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
- acpi_clear_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number, ACPI_NOT_ISR);
- }
- acpi_unref_wakeup_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
}
}
@@ -140,11 +108,6 @@ int __init acpi_wakeup_device_init(void)
/* In case user doesn't load button driver */
if (!dev->wakeup.flags.run_wake || dev->wakeup.state.enabled)
continue;
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
acpi_ref_wakeup_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number);
dev->wakeup.state.enabled = 1;
Index: linux-2.6/include/acpi/actypes.h
===================================================================
--- linux-2.6.orig/include/acpi/actypes.h
+++ linux-2.6/include/acpi/actypes.h
@@ -668,41 +668,29 @@ typedef u32 acpi_event_status;
/*
* GPE info flags - Per GPE
- * +-+-+-+---+---+-+
- * |7|6|5|4:3|2:1|0|
- * +-+-+-+---+---+-+
- * | | | | | |
- * | | | | | +--- Interrupt type: Edge or Level Triggered
- * | | | | +--- Type: Wake-only, Runtime-only, or wake/runtime
+ * +-+-+-+---+-+-+-+
+ * |7|6|5|4:3|2|1|0|
+ * +-+-+-+---+-+-+-+
+ * | | | | | | |
+ * | | | | | | +--- Interrupt type: Edge or Level Triggered
+ * | | | | | +--- GPE can wake the system
+ * | | | | +--- Unused
* | | | +--- Type of dispatch -- to method, handler, or none
- * | | +--- Enabled for runtime?
- * | +--- Enabled for wake?
+ * | | +--- Unused
+ * | +--- Unused
* +--- Unused
*/
#define ACPI_GPE_XRUPT_TYPE_MASK (u8) 0x01
#define ACPI_GPE_LEVEL_TRIGGERED (u8) 0x01
#define ACPI_GPE_EDGE_TRIGGERED (u8) 0x00
-#define ACPI_GPE_TYPE_MASK (u8) 0x06
-#define ACPI_GPE_TYPE_WAKE_RUN (u8) 0x06
-#define ACPI_GPE_TYPE_WAKE (u8) 0x02
-#define ACPI_GPE_TYPE_RUNTIME (u8) 0x04 /* Default */
+#define ACPI_GPE_CAN_WAKE (u8) 0x02
#define ACPI_GPE_DISPATCH_MASK (u8) 0x18
#define ACPI_GPE_DISPATCH_HANDLER (u8) 0x08
#define ACPI_GPE_DISPATCH_METHOD (u8) 0x10
#define ACPI_GPE_DISPATCH_NOT_USED (u8) 0x00 /* Default */
-#define ACPI_GPE_RUN_ENABLE_MASK (u8) 0x20
-#define ACPI_GPE_RUN_ENABLED (u8) 0x20
-#define ACPI_GPE_RUN_DISABLED (u8) 0x00 /* Default */
-
-#define ACPI_GPE_WAKE_ENABLE_MASK (u8) 0x40
-#define ACPI_GPE_WAKE_ENABLED (u8) 0x40
-#define ACPI_GPE_WAKE_DISABLED (u8) 0x00 /* Default */
-
-#define ACPI_GPE_ENABLE_MASK (u8) 0x60 /* Both run/wake */
-
/*
* Flags for GPE and Lock interfaces
*/
From: Rafael J. Wysocki <[email protected]>
Use the run_wake flag to mark all devices for which run-time wake-up
events may be generated by the platform. Introduce a new wake-up
flag, always_enabled, for marking devices that should be permanently
enabled to generate run-time events. Also, introduce a reference
counter for run-wake devices and a function that will initialize all
of the run-time wake-up fields for given device.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Len Brown <[email protected]>
---
drivers/acpi/button.c | 2 ++
drivers/acpi/scan.c | 37 +++++++++++++++++++++++++++----------
drivers/acpi/wakeup.c | 3 ++-
include/acpi/acpi_bus.h | 2 ++
4 files changed, 33 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/acpi/wakeup.c
===================================================================
--- linux-2.6.orig/drivers/acpi/wakeup.c
+++ linux-2.6/drivers/acpi/wakeup.c
@@ -106,7 +106,8 @@ int __init acpi_wakeup_device_init(void)
struct acpi_device,
wakeup_list);
/* In case user doesn't load button driver */
- if (!dev->wakeup.flags.run_wake || dev->wakeup.state.enabled)
+ if (!dev->wakeup.flags.always_enabled ||
+ dev->wakeup.state.enabled)
continue;
acpi_ref_wakeup_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number);
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -242,6 +242,7 @@ struct acpi_device_perf {
struct acpi_device_wakeup_flags {
u8 valid:1; /* Can successfully enable wakeup? */
u8 run_wake:1; /* Run-Wake GPE devices */
+ u8 always_enabled:1; /* Run-wake devices that are always enabled */
};
struct acpi_device_wakeup_state {
@@ -256,6 +257,7 @@ struct acpi_device_wakeup {
struct acpi_device_wakeup_state state;
struct acpi_device_wakeup_flags flags;
int prepare_count;
+ int run_wake_count;
};
/* Device */
Index: linux-2.6/drivers/acpi/button.c
===================================================================
--- linux-2.6.orig/drivers/acpi/button.c
+++ linux-2.6/drivers/acpi/button.c
@@ -426,6 +426,7 @@ static int acpi_button_add(struct acpi_d
device->wakeup.gpe_number);
acpi_ref_wakeup_gpe(device->wakeup.gpe_device,
device->wakeup.gpe_number);
+ device->wakeup.run_wake_count++;
device->wakeup.state.enabled = 1;
}
@@ -450,6 +451,7 @@ static int acpi_button_remove(struct acp
device->wakeup.gpe_number);
acpi_unref_wakeup_gpe(device->wakeup.gpe_device,
device->wakeup.gpe_number);
+ device->wakeup.run_wake_count--;
device->wakeup.state.enabled = 0;
}
Index: linux-2.6/drivers/acpi/scan.c
===================================================================
--- linux-2.6.orig/drivers/acpi/scan.c
+++ linux-2.6/drivers/acpi/scan.c
@@ -741,19 +741,39 @@ acpi_bus_extract_wakeup_device_power_pac
return AE_OK;
}
-static int acpi_bus_get_wakeup_device_flags(struct acpi_device *device)
+static void acpi_bus_set_run_wake_flags(struct acpi_device *device)
{
- acpi_status status = 0;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- union acpi_object *package = NULL;
- int psw_error;
-
struct acpi_device_id button_device_ids[] = {
{"PNP0C0D", 0},
{"PNP0C0C", 0},
{"PNP0C0E", 0},
{"", 0},
};
+ acpi_status status;
+ acpi_event_status event_status;
+
+ device->wakeup.run_wake_count = 0;
+
+ /* Power button, Lid switch always enable wakeup */
+ if (!acpi_match_device_ids(device, button_device_ids)) {
+ device->wakeup.flags.run_wake = 1;
+ device->wakeup.flags.always_enabled = 1;
+ return;
+ }
+
+ status = acpi_get_gpe_status(NULL, device->wakeup.gpe_number,
+ ACPI_NOT_ISR, &event_status);
+ if (status == AE_OK)
+ device->wakeup.flags.run_wake =
+ !!(event_status & ACPI_EVENT_FLAG_HANDLE);
+}
+
+static int acpi_bus_get_wakeup_device_flags(struct acpi_device *device)
+{
+ acpi_status status = 0;
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *package = NULL;
+ int psw_error;
/* _PRW */
status = acpi_evaluate_object(device->handle, "_PRW", NULL, &buffer);
@@ -773,6 +793,7 @@ static int acpi_bus_get_wakeup_device_fl
device->wakeup.flags.valid = 1;
device->wakeup.prepare_count = 0;
+ acpi_bus_set_run_wake_flags(device);
/* Call _PSW/_DSW object to disable its ability to wake the sleeping
* system for the ACPI device with the _PRW object.
* The _PSW object is depreciated in ACPI 3.0 and is replaced by _DSW.
@@ -784,10 +805,6 @@ static int acpi_bus_get_wakeup_device_fl
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"error in _DSW or _PSW evaluation\n"));
- /* Power button, Lid switch always enable wakeup */
- if (!acpi_match_device_ids(device, button_device_ids))
- device->wakeup.flags.run_wake = 1;
-
end:
if (ACPI_FAILURE(status))
device->flags.wake_capable = 0;
From: Matthew Garrett <[email protected]>
Add GPE refcounting support to ACPI drivers that need it. This will
currently do little until the core is changed over to use the new
behaviour.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by; Rafael J. Wysocki <[email protected]>
---
drivers/acpi/button.c | 12 ++++++++++++
drivers/acpi/button.c | 12 ++++++++++++
drivers/acpi/ec.c | 4 +++-
drivers/acpi/wakeup.c | 6 ++++++
3 files changed, 21 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/acpi/button.c
===================================================================
--- linux-2.6.orig/drivers/acpi/button.c
+++ linux-2.6/drivers/acpi/button.c
@@ -427,6 +427,10 @@ static int acpi_button_add(struct acpi_d
ACPI_GPE_TYPE_WAKE_RUN);
acpi_enable_gpe(device->wakeup.gpe_device,
device->wakeup.gpe_number);
+ acpi_ref_runtime_gpe(device->wakeup.gpe_device,
+ device->wakeup.gpe_number);
+ acpi_ref_wakeup_gpe(device->wakeup.gpe_device,
+ device->wakeup.gpe_number);
device->wakeup.state.enabled = 1;
}
@@ -446,6 +450,14 @@ static int acpi_button_remove(struct acp
{
struct acpi_button *button = acpi_driver_data(device);
+ if (device->wakeup.flags.valid) {
+ acpi_unref_runtime_gpe(device->wakeup.gpe_device,
+ device->wakeup.gpe_number);
+ acpi_unref_wakeup_gpe(device->wakeup.gpe_device,
+ device->wakeup.gpe_number);
+ device->wakeup.state.enabled = 0;
+ }
+
acpi_button_remove_fs(device);
input_unregister_device(button->input);
kfree(button);
Index: linux-2.6/drivers/acpi/ec.c
===================================================================
--- linux-2.6.orig/drivers/acpi/ec.c
+++ linux-2.6/drivers/acpi/ec.c
@@ -755,7 +755,7 @@ static int ec_install_handlers(struct ac
if (ACPI_FAILURE(status))
return -ENODEV;
acpi_set_gpe_type(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
- acpi_enable_gpe(NULL, ec->gpe);
+ acpi_ref_runtime_gpe(NULL, ec->gpe);
status = acpi_install_address_space_handler(ec->handle,
ACPI_ADR_SPACE_EC,
&acpi_ec_space_handler,
@@ -772,6 +772,7 @@ static int ec_install_handlers(struct ac
} else {
acpi_remove_gpe_handler(NULL, ec->gpe,
&acpi_ec_gpe_handler);
+ acpi_unref_runtime_gpe(NULL, ec->gpe);
return -ENODEV;
}
}
@@ -782,6 +783,7 @@ static int ec_install_handlers(struct ac
static void ec_remove_handlers(struct acpi_ec *ec)
{
+ acpi_unref_runtime_gpe(NULL, ec->gpe);
if (ACPI_FAILURE(acpi_remove_address_space_handler(ec->handle,
ACPI_ADR_SPACE_EC, &acpi_ec_space_handler)))
pr_err(PREFIX "failed to remove space handler\n");
Index: linux-2.6/drivers/acpi/wakeup.c
===================================================================
--- linux-2.6.orig/drivers/acpi/wakeup.c
+++ linux-2.6/drivers/acpi/wakeup.c
@@ -81,6 +81,8 @@ void acpi_enable_wakeup_device(u8 sleep_
if (!dev->wakeup.flags.run_wake)
acpi_enable_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number);
+ acpi_ref_wakeup_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
}
}
@@ -121,6 +123,8 @@ void acpi_disable_wakeup_device(u8 sleep
acpi_clear_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number, ACPI_NOT_ISR);
}
+ acpi_unref_wakeup_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
}
}
@@ -141,6 +145,8 @@ int __init acpi_wakeup_device_init(void)
ACPI_GPE_TYPE_WAKE_RUN);
acpi_enable_gpe(dev->wakeup.gpe_device,
dev->wakeup.gpe_number);
+ acpi_ref_wakeup_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
dev->wakeup.state.enabled = 1;
}
mutex_unlock(&acpi_device_lock);
On Sun, 10 Jan 2010 14:35:18 +0100
"Rafael J. Wysocki" <[email protected]> wrote:
> From: Rafael J. Wysocki <[email protected]>
>
> Add function pci_check_pme_status() that will check the PME status
> bit of given device and clear it along with the PME enable bit. It
> will be necessary for PCI run-time power management.
>
> Based on a patch from Shaohua Li <[email protected]>
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
Applied this series to my linux-next branch, thanks Rafael.
--
Jesse Barnes, Intel Open Source Technology Center
On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[email protected]>
>
> Although the majority of PCI devices can generate PMEs that in
> principle may be used to wake up devices suspended at run time,
> platform support is generally necessary to convert PMEs into wake-up
> events that can be delivered to the kernel. If ACPI is used for this
> purpose, a PME generated by a PCI device will trigger the ACPI GPE
> associated with the device to generate an ACPI wake-up event that we
> can set up a handler for, provided that everything is configured
> correctly.
I think acpiphp needs a little attention after this patch. Gary
Hade noticed while testing Jesse's linux-next branch that acpiphp
complains like this:
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp: Slot [9] registered
acpiphp: Slot [10] registered
acpiphp_glue: failed to register interrupt notify handler
acpiphp: Slot [6] registered
acpiphp_glue: failed to register interrupt notify handler
I reproduced this on an HP rx3600 (ia64), and found that acpiphp
doesn't complain on commit 82533a617f453, but it *does* complain
on commit fb3383bb4ac6e, which seems to be this patch.
I haven't tried to debug it any farther than just noticing that
acpiphp starts complaining here, so I don't know what the right
fix is, or even if acpiphp is really broken.
I did use acpiphp to power-cycle a slot ("echo 0 > power"), and
it seemed to work despite the warnings. But I guess the notification
is probably not involved in that path; I suppose the notification
is like a latch or attention button interrupt or something.
Bjorn
On Saturday 06 February 2010, Bjorn Helgaas wrote:
> On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[email protected]>
> >
> > Although the majority of PCI devices can generate PMEs that in
> > principle may be used to wake up devices suspended at run time,
> > platform support is generally necessary to convert PMEs into wake-up
> > events that can be delivered to the kernel. If ACPI is used for this
> > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > associated with the device to generate an ACPI wake-up event that we
> > can set up a handler for, provided that everything is configured
> > correctly.
>
> I think acpiphp needs a little attention after this patch. Gary
> Hade noticed while testing Jesse's linux-next branch that acpiphp
> complains like this:
>
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> acpiphp: Slot [9] registered
> acpiphp: Slot [10] registered
> acpiphp_glue: failed to register interrupt notify handler
> acpiphp: Slot [6] registered
> acpiphp_glue: failed to register interrupt notify handler
>
> I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> doesn't complain on commit 82533a617f453, but it *does* complain
> on commit fb3383bb4ac6e, which seems to be this patch.
>
> I haven't tried to debug it any farther than just noticing that
> acpiphp starts complaining here, so I don't know what the right
> fix is, or even if acpiphp is really broken.
>
> I did use acpiphp to power-cycle a slot ("echo 0 > power"), and
> it seemed to work despite the warnings. But I guess the notification
> is probably not involved in that path; I suppose the notification
> is like a latch or attention button interrupt or something.
Thanks for the report, I'll look at this tomorrow.
Rafael
On Saturday 06 February 2010, Bjorn Helgaas wrote:
> On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[email protected]>
> >
> > Although the majority of PCI devices can generate PMEs that in
> > principle may be used to wake up devices suspended at run time,
> > platform support is generally necessary to convert PMEs into wake-up
> > events that can be delivered to the kernel. If ACPI is used for this
> > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > associated with the device to generate an ACPI wake-up event that we
> > can set up a handler for, provided that everything is configured
> > correctly.
>
> I think acpiphp needs a little attention after this patch. Gary
> Hade noticed while testing Jesse's linux-next branch that acpiphp
> complains like this:
>
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> acpiphp: Slot [9] registered
> acpiphp: Slot [10] registered
> acpiphp_glue: failed to register interrupt notify handler
> acpiphp: Slot [6] registered
> acpiphp_glue: failed to register interrupt notify handler
>
> I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> doesn't complain on commit 82533a617f453, but it *does* complain
> on commit fb3383bb4ac6e, which seems to be this patch.
I can't see the possible reason looking at the code alone.
Could you add a debug printk() printing the error code returned by
pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
Rafael
On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[email protected]>
> > >
> > > Although the majority of PCI devices can generate PMEs that in
> > > principle may be used to wake up devices suspended at run time,
> > > platform support is generally necessary to convert PMEs into wake-up
> > > events that can be delivered to the kernel. If ACPI is used for this
> > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > associated with the device to generate an ACPI wake-up event that we
> > > can set up a handler for, provided that everything is configured
> > > correctly.
> >
> > I think acpiphp needs a little attention after this patch. Gary
> > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > complains like this:
> >
> > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > acpiphp: Slot [9] registered
> > acpiphp: Slot [10] registered
> > acpiphp_glue: failed to register interrupt notify handler
> > acpiphp: Slot [6] registered
> > acpiphp_glue: failed to register interrupt notify handler
> >
> > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > doesn't complain on commit 82533a617f453, but it *does* complain
> > on commit fb3383bb4ac6e, which seems to be this patch.
>
> I can't see the possible reason looking at the code alone.
>
> Could you add a debug printk() printing the error code returned by
> pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
Rafael, On the system where I ran into the problem it returns
AE_NOT_FOUND. See below.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
[ 188.347195] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 188.374707] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 188.375125] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
[ 188.375156] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
[ 188.375187] acpiphp: Slot [1] registered
[ 188.375192] register_slot: status=0x5
[ 188.375194] acpiphp_glue: failed to register interrupt notify handler
[ 188.375262] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
[ 188.375289] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
[ 188.375315] acpiphp: Slot [2] registered
[ 188.375319] register_slot: status=0x5
[ 188.375321] acpiphp_glue: failed to register interrupt notify handler
[ 188.375430] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
[ 188.375464] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
[ 188.375486] acpiphp: Slot [3] registered
[ 188.375490] register_slot: status=0x5
[ 188.375492] acpiphp_glue: failed to register interrupt notify handler
[ 188.375673] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
[ 188.375705] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
[ 188.375727] acpiphp: Slot [4] registered
[ 188.375731] register_slot: status=0x5
[ 188.375733] acpiphp_glue: failed to register interrupt notify handler
[ 188.375917] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
[ 188.375949] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
[ 188.375970] acpiphp: Slot [5] registered
[ 188.375974] register_slot: status=0x5
[ 188.375976] acpiphp_glue: failed to register interrupt notify handler
[ 188.376160] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
[ 188.376194] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
[ 188.376217] acpiphp: Slot [6] registered
[ 188.376221] register_slot: status=0x5
[ 188.376223] acpiphp_glue: failed to register interrupt notify handler
[ 188.376344] acpiphp_glue: Total 0 slots
On Monday 08 February 2010, Gary Hade wrote:
> On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <[email protected]>
> > > >
> > > > Although the majority of PCI devices can generate PMEs that in
> > > > principle may be used to wake up devices suspended at run time,
> > > > platform support is generally necessary to convert PMEs into wake-up
> > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > associated with the device to generate an ACPI wake-up event that we
> > > > can set up a handler for, provided that everything is configured
> > > > correctly.
> > >
> > > I think acpiphp needs a little attention after this patch. Gary
> > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > complains like this:
> > >
> > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > acpiphp: Slot [9] registered
> > > acpiphp: Slot [10] registered
> > > acpiphp_glue: failed to register interrupt notify handler
> > > acpiphp: Slot [6] registered
> > > acpiphp_glue: failed to register interrupt notify handler
> > >
> > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > on commit fb3383bb4ac6e, which seems to be this patch.
> >
> > I can't see the possible reason looking at the code alone.
> >
> > Could you add a debug printk() printing the error code returned by
> > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
>
> Rafael, On the system where I ran into the problem it returns
> AE_NOT_FOUND. See below.
Thanks!
Well, that means there's no struct acpi_device object associated with handle.
I must admit I didn't take that into consideration, but it should be easily
fixable. I'll send a patch for that later today.
Rafael
On Mon, Feb 08, 2010 at 08:17:14PM +0100, Rafael J. Wysocki wrote:
> On Monday 08 February 2010, Gary Hade wrote:
> > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <[email protected]>
> > > > >
> > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > principle may be used to wake up devices suspended at run time,
> > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > can set up a handler for, provided that everything is configured
> > > > > correctly.
> > > >
> > > > I think acpiphp needs a little attention after this patch. Gary
> > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > complains like this:
> > > >
> > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > acpiphp: Slot [9] registered
> > > > acpiphp: Slot [10] registered
> > > > acpiphp_glue: failed to register interrupt notify handler
> > > > acpiphp: Slot [6] registered
> > > > acpiphp_glue: failed to register interrupt notify handler
> > > >
> > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > >
> > > I can't see the possible reason looking at the code alone.
> > >
> > > Could you add a debug printk() printing the error code returned by
> > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> >
> > Rafael, On the system where I ran into the problem it returns
> > AE_NOT_FOUND. See below.
>
> Thanks!
>
> Well, that means there's no struct acpi_device object associated with handle.
Yes, I also added code to pci_acpi_add_hp_notifier() that
confirms the -ENODEV return from acpi_bus_get_device() for
non-populated slots.
I thought it was kind of curious that Bjorn's message seemed
to indicate that acpiphp actually loaded on his system when
it did not load on mine. It turns out that the load failure
on my system was apparently due to all of the hotpluggable
slots being non-populated. After booting with a card
present in slot 3, register_slot() got some AE_OK returns
from pci_acpi_add_hp_notifier() _and_ the acpiphp load
succeeded. See below.
>
> I must admit I didn't take that into consideration, but it should be easily
> fixable. I'll send a patch for that later today.
Thanks. I'll give it a test drive when I see it.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
[ 120.320794] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 120.341939] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 120.341960] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342027] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342043] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342073] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342105] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342151] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342191] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342232] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342440] acpiphp: Slot [1] registered
[ 120.342445] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=-19
[ 120.342448] register_slot: status=0x5
[ 120.342450] acpiphp_glue: failed to register interrupt notify handler
[ 120.342576] acpiphp: Slot [2] registered
[ 120.342580] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=-19
[ 120.342582] register_slot: status=0x5
[ 120.342584] acpiphp_glue: failed to register interrupt notify handler
[ 120.342744] acpiphp: Slot [3] registered
[ 120.342748] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342751] register_slot: status=0x0
[ 120.342886] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342889] register_slot: status=0x0
[ 120.342966] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.342973] register_slot: status=0x0
[ 120.343049] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343054] register_slot: status=0x0
[ 120.343128] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343133] register_slot: status=0x0
[ 120.343209] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343215] register_slot: status=0x0
[ 120.343290] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343295] register_slot: status=0x0
[ 120.343368] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343374] register_slot: status=0x0
[ 120.343378] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=0
[ 120.343381] init_bridge_misc: status=0x0
[ 120.343640] acpiphp: Slot [4] registered
[ 120.343645] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=-19
[ 120.343647] register_slot: status=0x5
[ 120.343649] acpiphp_glue: failed to register interrupt notify handler
[ 120.343881] acpiphp: Slot [5] registered
[ 120.343885] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=-19
[ 120.343887] register_slot: status=0x5
[ 120.343889] acpiphp_glue: failed to register interrupt notify handler
[ 120.344225] acpiphp: Slot [6] registered
[ 120.344234] pci_acpi_add_hp_notifier: acpi_bus_get_device_ret=-19
[ 120.344242] register_slot: status=0x5
[ 120.344249] acpiphp_glue: failed to register interrupt notify handler
On Monday 08 February 2010, Rafael J. Wysocki wrote:
> On Monday 08 February 2010, Gary Hade wrote:
> > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <[email protected]>
> > > > >
> > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > principle may be used to wake up devices suspended at run time,
> > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > can set up a handler for, provided that everything is configured
> > > > > correctly.
> > > >
> > > > I think acpiphp needs a little attention after this patch. Gary
> > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > complains like this:
> > > >
> > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > acpiphp: Slot [9] registered
> > > > acpiphp: Slot [10] registered
> > > > acpiphp_glue: failed to register interrupt notify handler
> > > > acpiphp: Slot [6] registered
> > > > acpiphp_glue: failed to register interrupt notify handler
> > > >
> > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > >
> > > I can't see the possible reason looking at the code alone.
> > >
> > > Could you add a debug printk() printing the error code returned by
> > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> >
> > Rafael, On the system where I ran into the problem it returns
> > AE_NOT_FOUND. See below.
>
> Thanks!
>
> Well, that means there's no struct acpi_device object associated with handle.
>
> I must admit I didn't take that into consideration, but it should be easily
> fixable. I'll send a patch for that later today.
Patch appended.
If the theory is correct, it should fix the issue. Please test.
Rafael
---
drivers/pci/pci-acpi.c | 30 ++++++++++++++++++++++++------
1 file changed, 24 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -116,10 +116,19 @@ acpi_status pci_acpi_add_hp_notifier(acp
{
struct pci_acpi_notify_data *nd;
struct acpi_device *dev;
- acpi_status status = AE_OK;
+ acpi_status status;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ status = acpi_bus_get_device(handle, &dev);
+ /*
+ * If there's no struct acpi_device for given handle, try to install the
+ * handler directly.
+ */
+ if (ACPI_FAILURE(status))
+ return acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ handler, context);
mutex_lock(&pci_acpi_notifier_mtx);
@@ -170,10 +179,19 @@ acpi_status pci_acpi_remove_hp_notifier(
{
struct pci_acpi_notify_data *nd;
struct acpi_device *dev;
- acpi_status status = AE_NOT_FOUND;
+ acpi_status status;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ status = acpi_bus_get_device(handle, &dev);
+ /*
+ * If there's no struct acpi_device for given handle, try to remove the
+ * handler directly.
+ */
+ if (ACPI_FAILURE(status))
+ return acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ handler);
mutex_lock(&pci_acpi_notifier_mtx);
On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > On Monday 08 February 2010, Gary Hade wrote:
> > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > >
> > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > can set up a handler for, provided that everything is configured
> > > > > > correctly.
> > > > >
> > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > complains like this:
> > > > >
> > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > acpiphp: Slot [9] registered
> > > > > acpiphp: Slot [10] registered
> > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > acpiphp: Slot [6] registered
> > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > >
> > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > >
> > > > I can't see the possible reason looking at the code alone.
> > > >
> > > > Could you add a debug printk() printing the error code returned by
> > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > >
> > > Rafael, On the system where I ran into the problem it returns
> > > AE_NOT_FOUND. See below.
> >
> > Thanks!
> >
> > Well, that means there's no struct acpi_device object associated with handle.
> >
> > I must admit I didn't take that into consideration, but it should be easily
> > fixable. I'll send a patch for that later today.
>
> Patch appended.
>
> If the theory is correct, it should fix the issue. Please test.
Well, acpiphp now loads OK with no disturbing messages:
[ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
[ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
[ 247.385519] acpiphp: Slot [1] registered
[ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
[ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
[ 247.386225] acpiphp: Slot [2] registered
[ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
[ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
[ 247.386902] acpiphp: Slot [3] registered
[ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
[ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
[ 247.387620] acpiphp: Slot [4] registered
[ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
[ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
[ 247.388347] acpiphp: Slot [5] registered
[ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
[ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
[ 247.389114] acpiphp: Slot [6] registered
[ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
[ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
[ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
[ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
[ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
[ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
[ 247.389753] acpiphp_glue: Total 6 slots
However, I didn't have a chance to confirm that hot-add of a
PCI card works correctly before someone else swiped the system
from me for a while. I will verify this when I get it back,
hopefully later today.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > On Monday 08 February 2010, Gary Hade wrote:
> > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > >
> > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > correctly.
> > > > > >
> > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > complains like this:
> > > > > >
> > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > acpiphp: Slot [9] registered
> > > > > > acpiphp: Slot [10] registered
> > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > acpiphp: Slot [6] registered
> > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > >
> > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > >
> > > > > I can't see the possible reason looking at the code alone.
> > > > >
> > > > > Could you add a debug printk() printing the error code returned by
> > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > >
> > > > Rafael, On the system where I ran into the problem it returns
> > > > AE_NOT_FOUND. See below.
> > >
> > > Thanks!
> > >
> > > Well, that means there's no struct acpi_device object associated with handle.
> > >
> > > I must admit I didn't take that into consideration, but it should be easily
> > > fixable. I'll send a patch for that later today.
> >
> > Patch appended.
> >
> > If the theory is correct, it should fix the issue. Please test.
>
> Well, acpiphp now loads OK with no disturbing messages:
> [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> [ 247.385519] acpiphp: Slot [1] registered
> [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> [ 247.386225] acpiphp: Slot [2] registered
> [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> [ 247.386902] acpiphp: Slot [3] registered
> [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> [ 247.387620] acpiphp: Slot [4] registered
> [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> [ 247.388347] acpiphp: Slot [5] registered
> [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> [ 247.389114] acpiphp: Slot [6] registered
> [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> [ 247.389753] acpiphp_glue: Total 6 slots
>
> However, I didn't have a chance to confirm that hot-add of a
> PCI card works correctly before someone else swiped the system
> from me for a while. I will verify this when I get it back,
> hopefully later today.
I got the system back but unfortunately have some bad news.
The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
card but acpiphp did not seem to see the hot-add event for
either card. acpiphp was loaded with debug=1 and issued no
messages when I added the cards.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Tuesday 09 February 2010, Gary Hade wrote:
> On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > >
> > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > correctly.
> > > > > > >
> > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > complains like this:
> > > > > > >
> > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > acpiphp: Slot [9] registered
> > > > > > > acpiphp: Slot [10] registered
> > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > acpiphp: Slot [6] registered
> > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > >
> > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > >
> > > > > > I can't see the possible reason looking at the code alone.
> > > > > >
> > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > >
> > > > > Rafael, On the system where I ran into the problem it returns
> > > > > AE_NOT_FOUND. See below.
> > > >
> > > > Thanks!
> > > >
> > > > Well, that means there's no struct acpi_device object associated with handle.
> > > >
> > > > I must admit I didn't take that into consideration, but it should be easily
> > > > fixable. I'll send a patch for that later today.
> > >
> > > Patch appended.
> > >
> > > If the theory is correct, it should fix the issue. Please test.
> >
> > Well, acpiphp now loads OK with no disturbing messages:
> > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > [ 247.385519] acpiphp: Slot [1] registered
> > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > [ 247.386225] acpiphp: Slot [2] registered
> > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > [ 247.386902] acpiphp: Slot [3] registered
> > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > [ 247.387620] acpiphp: Slot [4] registered
> > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > [ 247.388347] acpiphp: Slot [5] registered
> > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > [ 247.389114] acpiphp: Slot [6] registered
> > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > [ 247.389753] acpiphp_glue: Total 6 slots
> >
> > However, I didn't have a chance to confirm that hot-add of a
> > PCI card works correctly before someone else swiped the system
> > from me for a while. I will verify this when I get it back,
> > hopefully later today.
>
> I got the system back but unfortunately have some bad news.
> The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> card but acpiphp did not seem to see the hot-add event for
> either card. acpiphp was loaded with debug=1 and issued no
> messages when I added the cards.
I gather it works without the $subject patch?
Rafael
On Tuesday 09 February 2010, Rafael J. Wysocki wrote:
> On Tuesday 09 February 2010, Gary Hade wrote:
> > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > >
> > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > correctly.
> > > > > > > >
> > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > complains like this:
> > > > > > > >
> > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > >
> > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > >
> > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > >
> > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > >
> > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > AE_NOT_FOUND. See below.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > >
> > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > fixable. I'll send a patch for that later today.
> > > >
> > > > Patch appended.
> > > >
> > > > If the theory is correct, it should fix the issue. Please test.
> > >
> > > Well, acpiphp now loads OK with no disturbing messages:
> > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > [ 247.385519] acpiphp: Slot [1] registered
> > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > [ 247.386225] acpiphp: Slot [2] registered
> > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > [ 247.386902] acpiphp: Slot [3] registered
> > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > [ 247.387620] acpiphp: Slot [4] registered
> > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > [ 247.388347] acpiphp: Slot [5] registered
> > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > [ 247.389114] acpiphp: Slot [6] registered
> > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > [ 247.389753] acpiphp_glue: Total 6 slots
> > >
> > > However, I didn't have a chance to confirm that hot-add of a
> > > PCI card works correctly before someone else swiped the system
> > > from me for a while. I will verify this when I get it back,
> > > hopefully later today.
> >
> > I got the system back but unfortunately have some bad news.
> > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > card but acpiphp did not seem to see the hot-add event for
> > either card. acpiphp was loaded with debug=1 and issued no
> > messages when I added the cards.
>
> I gather it works without the $subject patch?
Anyway, can you please try with the appended patch applied and see if
"handle_bridge_insertion" appears in the log?
There's one case we don't handle correctly at the moment and it may be the
reason for the hotplug not working.
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===================================================================
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -1065,6 +1065,8 @@ static void handle_bridge_insertion(acpi
struct acpi_device *device, *pdevice;
acpi_handle phandle;
+ warn("%s\n", __func__);
+
if ((type != ACPI_NOTIFY_BUS_CHECK) &&
(type != ACPI_NOTIFY_DEVICE_CHECK)) {
err("unexpected notification type %d\n", type);
On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> On Tuesday 09 February 2010, Gary Hade wrote:
> > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > >
> > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > correctly.
> > > > > > > >
> > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > complains like this:
> > > > > > > >
> > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > >
> > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > >
> > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > >
> > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > >
> > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > AE_NOT_FOUND. See below.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > >
> > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > fixable. I'll send a patch for that later today.
> > > >
> > > > Patch appended.
> > > >
> > > > If the theory is correct, it should fix the issue. Please test.
> > >
> > > Well, acpiphp now loads OK with no disturbing messages:
> > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > [ 247.385519] acpiphp: Slot [1] registered
> > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > [ 247.386225] acpiphp: Slot [2] registered
> > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > [ 247.386902] acpiphp: Slot [3] registered
> > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > [ 247.387620] acpiphp: Slot [4] registered
> > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > [ 247.388347] acpiphp: Slot [5] registered
> > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > [ 247.389114] acpiphp: Slot [6] registered
> > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > [ 247.389753] acpiphp_glue: Total 6 slots
> > >
> > > However, I didn't have a chance to confirm that hot-add of a
> > > PCI card works correctly before someone else swiped the system
> > > from me for a while. I will verify this when I get it back,
> > > hopefully later today.
> >
> > I got the system back but unfortunately have some bad news.
> > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > card but acpiphp did not seem to see the hot-add event for
> > either card. acpiphp was loaded with debug=1 and issued no
> > messages when I added the cards.
>
> I gather it works without the $subject patch?
I don't know for sure. Late Friday after running into the handler
registration issue I reverted 8/9 which required hand fixup for
one hunk failure. I then got some compile errors which I assumed
may be related to my non-removal of some of the other patches in the
series. I started reverting the entire series but got a failure right
away with 9/9 but didn't take the time to try to resolve it.
Since it sounds like you are doubtful that your changes are
responsible for this new issue I will try to make time to fuss
with this more today.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday 09 February 2010, Gary Hade wrote:
> > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > > >
> > > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > > correctly.
> > > > > > > > >
> > > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > > complains like this:
> > > > > > > > >
> > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > >
> > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > > >
> > > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > > >
> > > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > > >
> > > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > > AE_NOT_FOUND. See below.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > > >
> > > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > > fixable. I'll send a patch for that later today.
> > > > >
> > > > > Patch appended.
> > > > >
> > > > > If the theory is correct, it should fix the issue. Please test.
> > > >
> > > > Well, acpiphp now loads OK with no disturbing messages:
> > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > > [ 247.385519] acpiphp: Slot [1] registered
> > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > > [ 247.386225] acpiphp: Slot [2] registered
> > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > > [ 247.386902] acpiphp: Slot [3] registered
> > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > > [ 247.387620] acpiphp: Slot [4] registered
> > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > > [ 247.388347] acpiphp: Slot [5] registered
> > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > > [ 247.389114] acpiphp: Slot [6] registered
> > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > > [ 247.389753] acpiphp_glue: Total 6 slots
> > > >
> > > > However, I didn't have a chance to confirm that hot-add of a
> > > > PCI card works correctly before someone else swiped the system
> > > > from me for a while. I will verify this when I get it back,
> > > > hopefully later today.
> > >
> > > I got the system back but unfortunately have some bad news.
> > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > > card but acpiphp did not seem to see the hot-add event for
> > > either card. acpiphp was loaded with debug=1 and issued no
> > > messages when I added the cards.
> >
> > I gather it works without the $subject patch?
>
> I don't know for sure. Late Friday after running into the handler
> registration issue I reverted 8/9 which required hand fixup for
> one hunk failure. I then got some compile errors which I assumed
> may be related to my non-removal of some of the other patches in the
> series. I started reverting the entire series but got a failure right
> away with 9/9 but didn't take the time to try to resolve it.
>
> Since it sounds like you are doubtful that your changes are
> responsible for this new issue I will try to make time to fuss
> with this more today.
Rafael, I think I can approach this from a different direction.
Except for a trivial failure with 9/9, the entire series applies
to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without
your patches and let you know what happens.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Tuesday 09 February 2010, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote:
> > On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> > > On Tuesday 09 February 2010, Gary Hade wrote:
> > > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > > > >
> > > > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > > > correctly.
> > > > > > > > > >
> > > > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > > > complains like this:
> > > > > > > > > >
> > > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > >
> > > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > > > >
> > > > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > > > >
> > > > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > > > >
> > > > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > > > AE_NOT_FOUND. See below.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > > > >
> > > > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > > > fixable. I'll send a patch for that later today.
> > > > > >
> > > > > > Patch appended.
> > > > > >
> > > > > > If the theory is correct, it should fix the issue. Please test.
> > > > >
> > > > > Well, acpiphp now loads OK with no disturbing messages:
> > > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > > > [ 247.385519] acpiphp: Slot [1] registered
> > > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > > > [ 247.386225] acpiphp: Slot [2] registered
> > > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > > > [ 247.386902] acpiphp: Slot [3] registered
> > > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > > > [ 247.387620] acpiphp: Slot [4] registered
> > > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > > > [ 247.388347] acpiphp: Slot [5] registered
> > > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > > > [ 247.389114] acpiphp: Slot [6] registered
> > > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > > > [ 247.389753] acpiphp_glue: Total 6 slots
> > > > >
> > > > > However, I didn't have a chance to confirm that hot-add of a
> > > > > PCI card works correctly before someone else swiped the system
> > > > > from me for a while. I will verify this when I get it back,
> > > > > hopefully later today.
> > > >
> > > > I got the system back but unfortunately have some bad news.
> > > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > > > card but acpiphp did not seem to see the hot-add event for
> > > > either card. acpiphp was loaded with debug=1 and issued no
> > > > messages when I added the cards.
> > >
> > > I gather it works without the $subject patch?
> >
> > I don't know for sure. Late Friday after running into the handler
> > registration issue I reverted 8/9 which required hand fixup for
> > one hunk failure. I then got some compile errors which I assumed
> > may be related to my non-removal of some of the other patches in the
> > series. I started reverting the entire series but got a failure right
> > away with 9/9 but didn't take the time to try to resolve it.
> >
> > Since it sounds like you are doubtful that your changes are
> > responsible for this new issue I will try to make time to fuss
> > with this more today.
>
> Rafael, I think I can approach this from a different direction.
> Except for a trivial failure with 9/9, the entire series applies
> to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without
> your patches and let you know what happens.
Yes, please, but you may want to test the appended patch first.
If I think correctly what the problem is, it should work.
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c | 4 ++++
drivers/pci/pci-acpi.c | 30 ++++++++++++++++++++++++------
2 files changed, 28 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -116,10 +116,19 @@ acpi_status pci_acpi_add_hp_notifier(acp
{
struct pci_acpi_notify_data *nd;
struct acpi_device *dev;
- acpi_status status = AE_OK;
+ acpi_status status;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ status = acpi_bus_get_device(handle, &dev);
+ /*
+ * If there's no struct acpi_device for given handle, try to install the
+ * handler directly.
+ */
+ if (ACPI_FAILURE(status))
+ return acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ handler, context);
mutex_lock(&pci_acpi_notifier_mtx);
@@ -170,10 +179,19 @@ acpi_status pci_acpi_remove_hp_notifier(
{
struct pci_acpi_notify_data *nd;
struct acpi_device *dev;
- acpi_status status = AE_NOT_FOUND;
+ acpi_status status;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ status = acpi_bus_get_device(handle, &dev);
+ /*
+ * If there's no struct acpi_device for given handle, try to remove the
+ * handler directly.
+ */
+ if (ACPI_FAILURE(status))
+ return acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ handler);
mutex_lock(&pci_acpi_notifier_mtx);
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===================================================================
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -1140,8 +1140,12 @@ static void handle_hotplug_event_bridge(
int num_sub_bridges = 0;
if (acpi_bus_get_device(handle, &device)) {
+ pci_acpi_remove_hp_notifier(handle,
+ handle_hotplug_event_bridge);
/* This bridge must have just been physically inserted */
handle_bridge_insertion(handle, type);
+ pci_acpi_add_hp_notifier(handle, handle_hotplug_event_bridge,
+ context);
return;
}
On Tue, Feb 09, 2010 at 09:19:51PM +0100, Rafael J. Wysocki wrote:
> On Tuesday 09 February 2010, Gary Hade wrote:
> > On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote:
> > > On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> > > > On Tuesday 09 February 2010, Gary Hade wrote:
> > > > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > > > > >
> > > > > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > > > > correctly.
> > > > > > > > > > >
> > > > > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > > > > complains like this:
> > > > > > > > > > >
> > > > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > >
> > > > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > > > > >
> > > > > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > > > > >
> > > > > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > > > > >
> > > > > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > > > > AE_NOT_FOUND. See below.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > > > > >
> > > > > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > > > > fixable. I'll send a patch for that later today.
> > > > > > >
> > > > > > > Patch appended.
> > > > > > >
> > > > > > > If the theory is correct, it should fix the issue. Please test.
> > > > > >
> > > > > > Well, acpiphp now loads OK with no disturbing messages:
> > > > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > > > > [ 247.385519] acpiphp: Slot [1] registered
> > > > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > > > > [ 247.386225] acpiphp: Slot [2] registered
> > > > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > > > > [ 247.386902] acpiphp: Slot [3] registered
> > > > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > > > > [ 247.387620] acpiphp: Slot [4] registered
> > > > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > > > > [ 247.388347] acpiphp: Slot [5] registered
> > > > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > > > > [ 247.389114] acpiphp: Slot [6] registered
> > > > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > > > > [ 247.389753] acpiphp_glue: Total 6 slots
> > > > > >
> > > > > > However, I didn't have a chance to confirm that hot-add of a
> > > > > > PCI card works correctly before someone else swiped the system
> > > > > > from me for a while. I will verify this when I get it back,
> > > > > > hopefully later today.
> > > > >
> > > > > I got the system back but unfortunately have some bad news.
> > > > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > > > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > > > > card but acpiphp did not seem to see the hot-add event for
> > > > > either card. acpiphp was loaded with debug=1 and issued no
> > > > > messages when I added the cards.
> > > >
> > > > I gather it works without the $subject patch?
> > >
> > > I don't know for sure. Late Friday after running into the handler
> > > registration issue I reverted 8/9 which required hand fixup for
> > > one hunk failure. I then got some compile errors which I assumed
> > > may be related to my non-removal of some of the other patches in the
> > > series. I started reverting the entire series but got a failure right
> > > away with 9/9 but didn't take the time to try to resolve it.
> > >
> > > Since it sounds like you are doubtful that your changes are
> > > responsible for this new issue I will try to make time to fuss
> > > with this more today.
> >
> > Rafael, I think I can approach this from a different direction.
> > Except for a trivial failure with 9/9, the entire series applies
> > to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without
> > your patches and let you know what happens.
>
> Yes, please, but you may want to test the appended patch first.
>
> If I think correctly what the problem is, it should work.
OK. I already confirmed that the problem reproduces with your
patches applied. I am now in the process of trying vanilla
2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
your patch a try.
Thanks!
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 09:19:51PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday 09 February 2010, Gary Hade wrote:
> > > On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote:
> > > > On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> > > > > On Tuesday 09 February 2010, Gary Hade wrote:
> > > > > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > > > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > > > > > correctly.
> > > > > > > > > > > >
> > > > > > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > > > > > complains like this:
> > > > > > > > > > > >
> > > > > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > > >
> > > > > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > > > > > >
> > > > > > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > > > > > >
> > > > > > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > > > > > >
> > > > > > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > > > > > AE_NOT_FOUND. See below.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > > > > > >
> > > > > > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > > > > > fixable. I'll send a patch for that later today.
> > > > > > > >
> > > > > > > > Patch appended.
> > > > > > > >
> > > > > > > > If the theory is correct, it should fix the issue. Please test.
> > > > > > >
> > > > > > > Well, acpiphp now loads OK with no disturbing messages:
> > > > > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > > > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > > > > > [ 247.385519] acpiphp: Slot [1] registered
> > > > > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > > > > > [ 247.386225] acpiphp: Slot [2] registered
> > > > > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > > > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > > > > > [ 247.386902] acpiphp: Slot [3] registered
> > > > > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > > > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > > > > > [ 247.387620] acpiphp: Slot [4] registered
> > > > > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > > > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > > > > > [ 247.388347] acpiphp: Slot [5] registered
> > > > > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > > > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > > > > > [ 247.389114] acpiphp: Slot [6] registered
> > > > > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > > > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > > > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > > > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > > > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > > > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > > > > > [ 247.389753] acpiphp_glue: Total 6 slots
> > > > > > >
> > > > > > > However, I didn't have a chance to confirm that hot-add of a
> > > > > > > PCI card works correctly before someone else swiped the system
> > > > > > > from me for a while. I will verify this when I get it back,
> > > > > > > hopefully later today.
> > > > > >
> > > > > > I got the system back but unfortunately have some bad news.
> > > > > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > > > > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > > > > > card but acpiphp did not seem to see the hot-add event for
> > > > > > either card. acpiphp was loaded with debug=1 and issued no
> > > > > > messages when I added the cards.
> > > > >
> > > > > I gather it works without the $subject patch?
> > > >
> > > > I don't know for sure. Late Friday after running into the handler
> > > > registration issue I reverted 8/9 which required hand fixup for
> > > > one hunk failure. I then got some compile errors which I assumed
> > > > may be related to my non-removal of some of the other patches in the
> > > > series. I started reverting the entire series but got a failure right
> > > > away with 9/9 but didn't take the time to try to resolve it.
> > > >
> > > > Since it sounds like you are doubtful that your changes are
> > > > responsible for this new issue I will try to make time to fuss
> > > > with this more today.
> > >
> > > Rafael, I think I can approach this from a different direction.
> > > Except for a trivial failure with 9/9, the entire series applies
> > > to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without
> > > your patches and let you know what happens.
> >
> > Yes, please, but you may want to test the appended patch first.
> >
> > If I think correctly what the problem is, it should work.
>
> OK. I already confirmed that the problem reproduces with your
> patches applied. I am now in the process of trying vanilla
> 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> your patch a try.
The hot-add worked fine with an unpatched 2.6.33-rc7.
The new patch when added to the 2.6.33-rc7 tree that
included the original patchset unfortunately did not
correct the problem.
Hot-remove also seems to be acting a little strange.
After I echoed 0 to the power file for a card that was
present during boot, a read of the power file correctly
showed 0, dmesg output showed the normal remove related
messages, the green LED next to the slot transitioned
from 'on' to 'off' as it normally does, and the amber LED
next to the slot transitioned from 'off' to
'blinking on and off' as it normally does. Everything up
to this point appeared normal but after I removed the card
and closed the latch the amber LED continued
'blinking on and off' which is _not_ normal. It normally
transitions to totally 'off' after latch is closed following
removal of the card.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wednesday 10 February 2010, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
> > OK. I already confirmed that the problem reproduces with your
> > patches applied. I am now in the process of trying vanilla
> > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > your patch a try.
>
> The hot-add worked fine with an unpatched 2.6.33-rc7.
Good.
> The new patch when added to the 2.6.33-rc7 tree that
> included the original patchset unfortunately did not
> correct the problem.
Bad.
Well, fortunately I have another one, but I haven't tested it myself yet except
for checking that it builds. Hopefully it won't break things more.
The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
applied. Please test it and let me know the results.
Rafael
---
drivers/pci/pci-acpi.c | 240 ++++++++++++++++++++++++------------------------
include/acpi/acpi_bus.h | 1
2 files changed, 124 insertions(+), 117 deletions(-)
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -19,10 +19,13 @@
#include <linux/pm_runtime.h>
#include "pci.h"
-static DEFINE_MUTEX(pci_acpi_notifier_mtx);
+static DEFINE_MUTEX(pci_acpi_notify_mtx);
+static LIST_HEAD(pci_acpi_notify_list);
-struct pci_acpi_notify_data
+struct pci_acpi_notify_object
{
+ struct list_head entry;
+ acpi_handle handle;
acpi_notify_handler hp_cb;
void *hp_data;
struct pci_bus *pci_bus;
@@ -33,7 +36,7 @@ struct pci_acpi_notify_data
* pci_acpi_event_fn - Universal system notification handler.
* @handle: ACPI handle of a device the notification is for.
* @event: Type of the signaled event.
- * @ign: The value of this argument is ignored.
+ * @context: Pointer to the notify object associated with the handle.
*
* Use @handle to obtain the address of the ACPI device object the event is
* signaled for. If this is a wake-up event, execute the appropriate PME
@@ -41,116 +44,98 @@ struct pci_acpi_notify_data
* bridge). If this is not a wake-up event, execute the hotplug notify handler
* for @handle.
*/
-static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *ign)
+static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *context)
{
- struct acpi_device *dev;
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj = context;
- if (ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
- pr_warning("ACPI handle has no context in %s!\n", __func__);
+ if (!notify_obj)
return;
- }
-
- mutex_lock(&pci_acpi_notifier_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ mutex_lock(&pci_acpi_notify_mtx);
if (event == ACPI_NOTIFY_DEVICE_WAKE) {
- if (nd->pci_bus) {
- pci_pme_wakeup_bus(nd->pci_bus);
+ if (notify_obj->pci_bus) {
+ pci_pme_wakeup_bus(notify_obj->pci_bus);
}
- if (nd->pci_dev) {
- pci_check_pme_status(nd->pci_dev);
- pm_request_resume(&nd->pci_dev->dev);
+ if (notify_obj->pci_dev) {
+ pci_check_pme_status(notify_obj->pci_dev);
+ pm_request_resume(¬ify_obj->pci_dev->dev);
}
- } else if (nd->hp_cb) {
- nd->hp_cb(handle, event, nd->hp_data);
+ } else if (notify_obj->hp_cb) {
+ notify_obj->hp_cb(handle, event, notify_obj->hp_data);
}
- out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
}
/**
- * add_notify_data - Create a new notify data object for given ACPI device.
- * @dev: Device to create the notify data object for.
+ * add_notify_obj - Create a new notify object for given ACPI handle.
+ * @handle: ACPI handle to create the notify object for.
*/
-static struct pci_acpi_notify_data *add_notify_data(struct acpi_device *dev)
+static struct pci_acpi_notify_object *add_notify_obj(acpi_handle handle)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
- nd = kzalloc(sizeof(*nd), GFP_KERNEL);
- if (!nd)
+ notify_obj = kzalloc(sizeof(*notify_obj), GFP_KERNEL);
+ if (!notify_obj)
return NULL;
- dev->bus_data = nd;
- return nd;
-}
-
-/**
- * remove_notify_data - Remove the notify data object from given ACPI device.
- * @dev: Device to remove the notify data object from.
- */
-static void remove_notify_data(struct acpi_device *dev)
-{
- kfree(dev->bus_data);
- dev->bus_data = NULL;
+ notify_obj->handle = handle;
+ return notify_obj;
}
/**
* pci_acpi_add_hp_notifier - Register a hotplug notifier for given device.
- * @handle: ACPI handle of the device to register the notifier for.
+ * @handle: ACPI handle to register the notifier for.
* @handler: Callback to execute for hotplug events related to @handle.
* @context: Pointer to the context data to pass to @handler.
*
- * Use @handle to get an ACPI device object and check if there is a notify data
- * object for it. If this is the case, add @handler and @context to the
- * existing notify data object, unless there already is a hotplug handler in
- * there. Otherwise, create a new notify data object for the ACPI device
- * associated with @handle and add @handler and @context to it.
+ * Find the notify object associated with @handle or create one if not found.
+ * Return error code if the notify object already contains a valid pointer to
+ * a hotplug handler or add @handler and @context to the notify object.
*/
acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
acpi_notify_handler handler, void *context)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_OK;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (nd) {
- if (!nd->hp_cb)
- goto add;
-
- status = AE_ALREADY_EXISTS;
- goto out;
- }
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->hp_cb) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }
- nd = add_notify_data(dev);
- if (!nd) {
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}
status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->hp_cb = handler;
- nd->hp_data = context;
+ notify_obj->hp_cb = handler;
+ notify_obj->hp_data = context;
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
@@ -161,38 +146,43 @@ EXPORT_SYMBOL_GPL(pci_acpi_add_hp_notifi
* @handle: ACPI handle of the device to unregister the notifier for.
* @handler: Callback executed for hotplug events related to @handle.
*
- * Remove the hotplug callback and the pointer to the hotplug context data from
- * the notify data object belonging to the device represented by @handle. If
- * the notify data object is not necessary any more, remove it altogether.
+ * Find the notify object corresponding to @handle and remove the pointers to
+ * the hotplug handler and data from it. Return error code if the notify object
+ * is not found.
*/
acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
acpi_notify_handler handler)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_NOT_FOUND;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
- nd->hp_data = NULL;
- nd->hp_cb = NULL;
+ goto out;
- if (nd->pci_bus || nd->pci_dev)
+ remove:
+ notify_obj->hp_data = NULL;
+ notify_obj->hp_cb = NULL;
+
+ if (notify_obj->pci_bus || notify_obj->pci_dev) {
+ status = AE_OK;
goto out;
+ }
status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_notifier);
@@ -203,14 +193,13 @@ EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_not
* @pci_dev: PCI device to check for the PME status if an event is signaled.
* @pci_bus: PCI bus to walk (checking PME status) if an event is signaled.
*
- * Check if there is a notify data object for @dev and if that is the case, add
- * @pci_dev to it as the device whose PME status should be checked whenever a PM
- * event is signaled for @dev. Also, add @pci_bus to it as the bus to walk
- * checking the PME status of all devices on it whenever a PM event is signaled
- * for @dev.
- *
- * Otherwise, create a new notify data object for @dev and add both @pci_dev and
- * @pci_bus to it.
+ * Use @dev to find the notify object corresponding to its handle or create a
+ * new one if not found. Return error code if the notify object already
+ * contains a valid pointer to a PCI device or bus object. Otherwise, add
+ * @pci_dev and @pci_bus to the notify object, as the device whose PME status
+ * should be checked whenever a PM event is signaled for @dev and the bus to
+ * walk checking the PME status of all devices on it whenever a PM event is
+ * signaled for @dev, respectively.
*
* NOTE: @dev need not be a run-wake or wake-up device to be a valid source of
* PM wake-up events. For example, wake-up events may be generated for bridges
@@ -221,34 +210,46 @@ acpi_status pci_acpi_add_pm_notifier(str
struct pci_dev *pci_dev,
struct pci_bus *pci_bus)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_OK;
- mutex_lock(&pci_acpi_notifier_mtx);
+ if (!handle)
+ return AE_BAD_PARAMETER;
- nd = dev->bus_data;
- if (nd)
- goto add;
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = add_notify_data(dev);
- if (!nd) {
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->pci_dev || notify_obj->pci_bus) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else
+ goto add;
+ }
+ }
+
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}
- status = acpi_install_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->pci_dev = pci_dev;
- nd->pci_bus = pci_bus;
+ notify_obj->pci_dev = pci_dev;
+ notify_obj->pci_bus = pci_bus;
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
@@ -256,33 +257,40 @@ acpi_status pci_acpi_add_pm_notifier(str
* pci_acpi_remove_pm_notifier - Unregister PM notifier for given device.
* @dev: ACPI device to remove the notifier from.
*
- * Find the notify data object for @dev and clear its @pci_dev and @pci_bus
+ * Find the notify object for @dev and clear its @pci_dev and @pci_bus
* fields. If the notify data object is not necessary any more after that,
- * remove it too.
+ * remove it altogether.
*/
acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_NOT_FOUND;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
+
+ goto out;
- nd->pci_dev = NULL;
- nd->pci_bus = NULL;
+ remove:
+ notify_obj->pci_dev = NULL;
+ notify_obj->pci_bus = NULL;
- if (nd->hp_cb)
+ if (notify_obj->hp_cb) {
+ status = AE_OK;
goto out;
+ }
status = acpi_remove_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -282,7 +282,6 @@ struct acpi_device {
struct device dev;
struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
- void *bus_data;
};
static inline void *acpi_driver_data(struct acpi_device *d)
On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> On Wednesday 10 February 2010, Gary Hade wrote:
> > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> ...
> > > OK. I already confirmed that the problem reproduces with your
> > > patches applied. I am now in the process of trying vanilla
> > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > your patch a try.
> >
> > The hot-add worked fine with an unpatched 2.6.33-rc7.
>
> Good.
>
> > The new patch when added to the 2.6.33-rc7 tree that
> > included the original patchset unfortunately did not
> > correct the problem.
>
> Bad.
>
> Well, fortunately I have another one, but I haven't tested it myself yet except
> for checking that it builds. Hopefully it won't break things more.
>
> The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> applied. Please test it and let me know the results.
Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
The correct one is appended.
Rafael
---
drivers/pci/pci-acpi.c | 240 ++++++++++++++++++++++++------------------------
include/acpi/acpi_bus.h | 1
2 files changed, 124 insertions(+), 117 deletions(-)
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -19,10 +19,13 @@
#include <linux/pm_runtime.h>
#include "pci.h"
-static DEFINE_MUTEX(pci_acpi_notifier_mtx);
+static DEFINE_MUTEX(pci_acpi_notify_mtx);
+static LIST_HEAD(pci_acpi_notify_list);
-struct pci_acpi_notify_data
+struct pci_acpi_notify_object
{
+ struct list_head entry;
+ acpi_handle handle;
acpi_notify_handler hp_cb;
void *hp_data;
struct pci_bus *pci_bus;
@@ -33,7 +36,7 @@ struct pci_acpi_notify_data
* pci_acpi_event_fn - Universal system notification handler.
* @handle: ACPI handle of a device the notification is for.
* @event: Type of the signaled event.
- * @ign: The value of this argument is ignored.
+ * @context: Pointer to the notify object associated with the handle.
*
* Use @handle to obtain the address of the ACPI device object the event is
* signaled for. If this is a wake-up event, execute the appropriate PME
@@ -41,116 +44,98 @@ struct pci_acpi_notify_data
* bridge). If this is not a wake-up event, execute the hotplug notify handler
* for @handle.
*/
-static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *ign)
+static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *context)
{
- struct acpi_device *dev;
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj = context;
- if (ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
- pr_warning("ACPI handle has no context in %s!\n", __func__);
+ if (!notify_obj)
return;
- }
-
- mutex_lock(&pci_acpi_notifier_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ mutex_lock(&pci_acpi_notify_mtx);
if (event == ACPI_NOTIFY_DEVICE_WAKE) {
- if (nd->pci_bus) {
- pci_pme_wakeup_bus(nd->pci_bus);
+ if (notify_obj->pci_bus) {
+ pci_pme_wakeup_bus(notify_obj->pci_bus);
}
- if (nd->pci_dev) {
- pci_check_pme_status(nd->pci_dev);
- pm_request_resume(&nd->pci_dev->dev);
+ if (notify_obj->pci_dev) {
+ pci_check_pme_status(notify_obj->pci_dev);
+ pm_request_resume(¬ify_obj->pci_dev->dev);
}
- } else if (nd->hp_cb) {
- nd->hp_cb(handle, event, nd->hp_data);
+ } else if (notify_obj->hp_cb) {
+ notify_obj->hp_cb(handle, event, notify_obj->hp_data);
}
- out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
}
/**
- * add_notify_data - Create a new notify data object for given ACPI device.
- * @dev: Device to create the notify data object for.
+ * add_notify_obj - Create a new notify object for given ACPI handle.
+ * @handle: ACPI handle to create the notify object for.
*/
-static struct pci_acpi_notify_data *add_notify_data(struct acpi_device *dev)
+static struct pci_acpi_notify_object *add_notify_obj(acpi_handle handle)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
- nd = kzalloc(sizeof(*nd), GFP_KERNEL);
- if (!nd)
+ notify_obj = kzalloc(sizeof(*notify_obj), GFP_KERNEL);
+ if (!notify_obj)
return NULL;
- dev->bus_data = nd;
- return nd;
-}
-
-/**
- * remove_notify_data - Remove the notify data object from given ACPI device.
- * @dev: Device to remove the notify data object from.
- */
-static void remove_notify_data(struct acpi_device *dev)
-{
- kfree(dev->bus_data);
- dev->bus_data = NULL;
+ notify_obj->handle = handle;
+ return notify_obj;
}
/**
* pci_acpi_add_hp_notifier - Register a hotplug notifier for given device.
- * @handle: ACPI handle of the device to register the notifier for.
+ * @handle: ACPI handle to register the notifier for.
* @handler: Callback to execute for hotplug events related to @handle.
* @context: Pointer to the context data to pass to @handler.
*
- * Use @handle to get an ACPI device object and check if there is a notify data
- * object for it. If this is the case, add @handler and @context to the
- * existing notify data object, unless there already is a hotplug handler in
- * there. Otherwise, create a new notify data object for the ACPI device
- * associated with @handle and add @handler and @context to it.
+ * Find the notify object associated with @handle or create one if not found.
+ * Return error code if the notify object already contains a valid pointer to
+ * a hotplug handler or add @handler and @context to the notify object.
*/
acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
acpi_notify_handler handler, void *context)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_OK;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (nd) {
- if (!nd->hp_cb)
- goto add;
-
- status = AE_ALREADY_EXISTS;
- goto out;
- }
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->hp_cb) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }
- nd = add_notify_data(dev);
- if (!nd) {
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}
status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->hp_cb = handler;
- nd->hp_data = context;
+ notify_obj->hp_cb = handler;
+ notify_obj->hp_data = context;
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
@@ -161,38 +146,43 @@ EXPORT_SYMBOL_GPL(pci_acpi_add_hp_notifi
* @handle: ACPI handle of the device to unregister the notifier for.
* @handler: Callback executed for hotplug events related to @handle.
*
- * Remove the hotplug callback and the pointer to the hotplug context data from
- * the notify data object belonging to the device represented by @handle. If
- * the notify data object is not necessary any more, remove it altogether.
+ * Find the notify object corresponding to @handle and remove the pointers to
+ * the hotplug handler and data from it. Return error code if the notify object
+ * is not found.
*/
acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
acpi_notify_handler handler)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_NOT_FOUND;
- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
- nd->hp_data = NULL;
- nd->hp_cb = NULL;
+ goto out;
- if (nd->pci_bus || nd->pci_dev)
+ remove:
+ notify_obj->hp_data = NULL;
+ notify_obj->hp_cb = NULL;
+
+ if (notify_obj->pci_bus || notify_obj->pci_dev) {
+ status = AE_OK;
goto out;
+ }
status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_notifier);
@@ -203,14 +193,13 @@ EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_not
* @pci_dev: PCI device to check for the PME status if an event is signaled.
* @pci_bus: PCI bus to walk (checking PME status) if an event is signaled.
*
- * Check if there is a notify data object for @dev and if that is the case, add
- * @pci_dev to it as the device whose PME status should be checked whenever a PM
- * event is signaled for @dev. Also, add @pci_bus to it as the bus to walk
- * checking the PME status of all devices on it whenever a PM event is signaled
- * for @dev.
- *
- * Otherwise, create a new notify data object for @dev and add both @pci_dev and
- * @pci_bus to it.
+ * Use @dev to find the notify object corresponding to its handle or create a
+ * new one if not found. Return error code if the notify object already
+ * contains a valid pointer to a PCI device or bus object. Otherwise, add
+ * @pci_dev and @pci_bus to the notify object, as the device whose PME status
+ * should be checked whenever a PM event is signaled for @dev and the bus to
+ * walk checking the PME status of all devices on it whenever a PM event is
+ * signaled for @dev, respectively.
*
* NOTE: @dev need not be a run-wake or wake-up device to be a valid source of
* PM wake-up events. For example, wake-up events may be generated for bridges
@@ -221,34 +210,46 @@ acpi_status pci_acpi_add_pm_notifier(str
struct pci_dev *pci_dev,
struct pci_bus *pci_bus)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_OK;
- mutex_lock(&pci_acpi_notifier_mtx);
+ if (!handle)
+ return AE_BAD_PARAMETER;
- nd = dev->bus_data;
- if (nd)
- goto add;
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = add_notify_data(dev);
- if (!nd) {
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->pci_dev || notify_obj->pci_bus) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }
+
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}
- status = acpi_install_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->pci_dev = pci_dev;
- nd->pci_bus = pci_bus;
+ notify_obj->pci_dev = pci_dev;
+ notify_obj->pci_bus = pci_bus;
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
@@ -256,33 +257,40 @@ acpi_status pci_acpi_add_pm_notifier(str
* pci_acpi_remove_pm_notifier - Unregister PM notifier for given device.
* @dev: ACPI device to remove the notifier from.
*
- * Find the notify data object for @dev and clear its @pci_dev and @pci_bus
+ * Find the notify object for @dev and clear its @pci_dev and @pci_bus
* fields. If the notify data object is not necessary any more after that,
- * remove it too.
+ * remove it altogether.
*/
acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_NOT_FOUND;
- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);
- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
+
+ goto out;
- nd->pci_dev = NULL;
- nd->pci_bus = NULL;
+ remove:
+ notify_obj->pci_dev = NULL;
+ notify_obj->pci_bus = NULL;
- if (nd->hp_cb)
+ if (notify_obj->hp_cb) {
+ status = AE_OK;
goto out;
+ }
status = acpi_remove_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -282,7 +282,6 @@ struct acpi_device {
struct device dev;
struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
- void *bus_data;
};
static inline void *acpi_driver_data(struct acpi_device *d)
On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > On Wednesday 10 February 2010, Gary Hade wrote:
> > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > ...
> > > > OK. I already confirmed that the problem reproduces with your
> > > > patches applied. I am now in the process of trying vanilla
> > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > your patch a try.
> > >
> > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> >
> > Good.
> >
> > > The new patch when added to the 2.6.33-rc7 tree that
> > > included the original patchset unfortunately did not
> > > correct the problem.
> >
> > Bad.
> >
> > Well, fortunately I have another one, but I haven't tested it myself yet except
> > for checking that it builds. Hopefully it won't break things more.
> >
> > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > applied. Please test it and let me know the results.
>
> Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> The correct one is appended.
No problem. I received this message before doing anything with
the previous one.
Sorry, both hot-add and hot-remove behaviors appear unchanged
with this patch.
I would like to dig into the code and help with the debugging
but I am swamped with other things right now. However, feel
free to continue using me for testing if you have other ideas
you want me to try.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wednesday 10 February 2010, Gary Hade wrote:
> On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > ...
> > > > > OK. I already confirmed that the problem reproduces with your
> > > > > patches applied. I am now in the process of trying vanilla
> > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > your patch a try.
> > > >
> > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > >
> > > Good.
> > >
> > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > included the original patchset unfortunately did not
> > > > correct the problem.
> > >
> > > Bad.
> > >
> > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > for checking that it builds. Hopefully it won't break things more.
> > >
> > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > applied. Please test it and let me know the results.
> >
> > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > The correct one is appended.
>
> No problem. I received this message before doing anything with
> the previous one.
>
> Sorry, both hot-add and hot-remove behaviors appear unchanged
> with this patch.
Hmm, that's kind of strange. I'm getting suspicious.
> I would like to dig into the code and help with the debugging
> but I am swamped with other things right now. However, feel
> free to continue using me for testing if you have other ideas
> you want me to try.
Thanks, of course I have some ideas. :-)
First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
(ie. without the $subject patch and [9/9]). Let's make sure we're debugging
the right patch.
Rafael
On Wed, Feb 10, 2010 at 07:00:54PM +0100, Rafael J. Wysocki wrote:
> On Wednesday 10 February 2010, Gary Hade wrote:
> > On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > > ...
> > > > > > OK. I already confirmed that the problem reproduces with your
> > > > > > patches applied. I am now in the process of trying vanilla
> > > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > > your patch a try.
> > > > >
> > > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > > >
> > > > Good.
> > > >
> > > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > > included the original patchset unfortunately did not
> > > > > correct the problem.
> > > >
> > > > Bad.
> > > >
> > > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > > for checking that it builds. Hopefully it won't break things more.
> > > >
> > > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > > applied. Please test it and let me know the results.
> > >
> > > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > > The correct one is appended.
> >
> > No problem. I received this message before doing anything with
> > the previous one.
> >
> > Sorry, both hot-add and hot-remove behaviors appear unchanged
> > with this patch.
>
> Hmm, that's kind of strange. I'm getting suspicious.
>
> > I would like to dig into the code and help with the debugging
> > but I am swamped with other things right now. However, feel
> > free to continue using me for testing if you have other ideas
> > you want me to try.
>
> Thanks, of course I have some ideas. :-)
>
> First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
> (ie. without the $subject patch and [9/9]). Let's make sure we're debugging
> the right patch.
It does look like both the hot-add and hot-remove issues were
introduced by something in 1/9 through 7/9. I started with a
clean 2.6.33-rc7 tree and applied only 1/9 through 7/9. I still
see that lingering blinking amber LED with hot-remove and no
response from the driver during hot-add.
Now I suppose you want me to start reverting 1/9 through 7/9
in reverse order to find the culprit. :)
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wednesday 10 February 2010, Gary Hade wrote:
> On Wed, Feb 10, 2010 at 07:00:54PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday 10 February 2010, Gary Hade wrote:
> > > On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > > > ...
> > > > > > > OK. I already confirmed that the problem reproduces with your
> > > > > > > patches applied. I am now in the process of trying vanilla
> > > > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > > > your patch a try.
> > > > > >
> > > > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > > > >
> > > > > Good.
> > > > >
> > > > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > > > included the original patchset unfortunately did not
> > > > > > correct the problem.
> > > > >
> > > > > Bad.
> > > > >
> > > > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > > > for checking that it builds. Hopefully it won't break things more.
> > > > >
> > > > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > > > applied. Please test it and let me know the results.
> > > >
> > > > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > > > The correct one is appended.
> > >
> > > No problem. I received this message before doing anything with
> > > the previous one.
> > >
> > > Sorry, both hot-add and hot-remove behaviors appear unchanged
> > > with this patch.
> >
> > Hmm, that's kind of strange. I'm getting suspicious.
> >
> > > I would like to dig into the code and help with the debugging
> > > but I am swamped with other things right now. However, feel
> > > free to continue using me for testing if you have other ideas
> > > you want me to try.
> >
> > Thanks, of course I have some ideas. :-)
> >
> > First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
> > (ie. without the $subject patch and [9/9]). Let's make sure we're debugging
> > the right patch.
>
> It does look like both the hot-add and hot-remove issues were
> introduced by something in 1/9 through 7/9. I started with a
> clean 2.6.33-rc7 tree and applied only 1/9 through 7/9. I still
> see that lingering blinking amber LED with hot-remove and no
> response from the driver during hot-add.
>
> Now I suppose you want me to start reverting 1/9 through 7/9
> in reverse order to find the culprit. :)
Actually, I think [6/9] is the offending one, so please try with [1/9] - [5/9]
applied and if that works, please apply [6/9] and retest to confirm it's the
culprit.
Rafael
On Wed, Feb 10, 2010 at 10:42:11PM +0100, Rafael J. Wysocki wrote:
> On Wednesday 10 February 2010, Gary Hade wrote:
> > On Wed, Feb 10, 2010 at 07:00:54PM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > > > > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > > > > ...
> > > > > > > > OK. I already confirmed that the problem reproduces with your
> > > > > > > > patches applied. I am now in the process of trying vanilla
> > > > > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > > > > your patch a try.
> > > > > > >
> > > > > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > > > > >
> > > > > > Good.
> > > > > >
> > > > > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > > > > included the original patchset unfortunately did not
> > > > > > > correct the problem.
> > > > > >
> > > > > > Bad.
> > > > > >
> > > > > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > > > > for checking that it builds. Hopefully it won't break things more.
> > > > > >
> > > > > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > > > > applied. Please test it and let me know the results.
> > > > >
> > > > > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > > > > The correct one is appended.
> > > >
> > > > No problem. I received this message before doing anything with
> > > > the previous one.
> > > >
> > > > Sorry, both hot-add and hot-remove behaviors appear unchanged
> > > > with this patch.
> > >
> > > Hmm, that's kind of strange. I'm getting suspicious.
> > >
> > > > I would like to dig into the code and help with the debugging
> > > > but I am swamped with other things right now. However, feel
> > > > free to continue using me for testing if you have other ideas
> > > > you want me to try.
> > >
> > > Thanks, of course I have some ideas. :-)
> > >
> > > First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
> > > (ie. without the $subject patch and [9/9]). Let's make sure we're debugging
> > > the right patch.
> >
> > It does look like both the hot-add and hot-remove issues were
> > introduced by something in 1/9 through 7/9. I started with a
> > clean 2.6.33-rc7 tree and applied only 1/9 through 7/9. I still
> > see that lingering blinking amber LED with hot-remove and no
> > response from the driver during hot-add.
> >
> > Now I suppose you want me to start reverting 1/9 through 7/9
> > in reverse order to find the culprit. :)
>
> Actually, I think [6/9] is the offending one, so please try with [1/9] - [5/9]
> applied and if that works, please apply [6/9] and retest to confirm it's the
> culprit.
Yes, 6/9 also appeared to be the most likely suspect to me and
I was already doing what you asked except in the opposite order.
With 1/9 through 6/9 both the hot-add and hot-remove issues still
reproduced. After removing 6/9 both issues disappeared.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Wednesday 10 February 2010, Gary Hade wrote:
> On Wed, Feb 10, 2010 at 10:42:11PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday 10 February 2010, Gary Hade wrote:
> > > On Wed, Feb 10, 2010 at 07:00:54PM +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > > > > > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > > > > > ...
> > > > > > > > > OK. I already confirmed that the problem reproduces with your
> > > > > > > > > patches applied. I am now in the process of trying vanilla
> > > > > > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > > > > > your patch a try.
> > > > > > > >
> > > > > > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > > > > > >
> > > > > > > Good.
> > > > > > >
> > > > > > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > > > > > included the original patchset unfortunately did not
> > > > > > > > correct the problem.
> > > > > > >
> > > > > > > Bad.
> > > > > > >
> > > > > > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > > > > > for checking that it builds. Hopefully it won't break things more.
> > > > > > >
> > > > > > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > > > > > applied. Please test it and let me know the results.
> > > > > >
> > > > > > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > > > > > The correct one is appended.
> > > > >
> > > > > No problem. I received this message before doing anything with
> > > > > the previous one.
> > > > >
> > > > > Sorry, both hot-add and hot-remove behaviors appear unchanged
> > > > > with this patch.
> > > >
> > > > Hmm, that's kind of strange. I'm getting suspicious.
> > > >
> > > > > I would like to dig into the code and help with the debugging
> > > > > but I am swamped with other things right now. However, feel
> > > > > free to continue using me for testing if you have other ideas
> > > > > you want me to try.
> > > >
> > > > Thanks, of course I have some ideas. :-)
> > > >
> > > > First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
> > > > (ie. without the $subject patch and [9/9]). Let's make sure we're debugging
> > > > the right patch.
> > >
> > > It does look like both the hot-add and hot-remove issues were
> > > introduced by something in 1/9 through 7/9. I started with a
> > > clean 2.6.33-rc7 tree and applied only 1/9 through 7/9. I still
> > > see that lingering blinking amber LED with hot-remove and no
> > > response from the driver during hot-add.
> > >
> > > Now I suppose you want me to start reverting 1/9 through 7/9
> > > in reverse order to find the culprit. :)
> >
> > Actually, I think [6/9] is the offending one, so please try with [1/9] - [5/9]
> > applied and if that works, please apply [6/9] and retest to confirm it's the
> > culprit.
>
> Yes, 6/9 also appeared to be the most likely suspect to me and
> I was already doing what you asked except in the opposite order.
> With 1/9 through 6/9 both the hot-add and hot-remove issues still
> reproduced. After removing 6/9 both issues disappeared.
Thanks for verifying, I've already started to look for bugs in it.
What's your kernel command line, BTW?
Rafael
On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> On Wednesday 10 February 2010, Gary Hade wrote:
> > On Wed, Feb 10, 2010 at 10:42:11PM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > On Wed, Feb 10, 2010 at 07:00:54PM +0100, Rafael J. Wysocki wrote:
> > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > On Wed, Feb 10, 2010 at 02:12:29AM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday 10 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > > > On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> > > > > > > > ...
> > > > > > > > > > OK. I already confirmed that the problem reproduces with your
> > > > > > > > > > patches applied. I am now in the process of trying vanilla
> > > > > > > > > > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > > > > > > > > > your patch a try.
> > > > > > > > >
> > > > > > > > > The hot-add worked fine with an unpatched 2.6.33-rc7.
> > > > > > > >
> > > > > > > > Good.
> > > > > > > >
> > > > > > > > > The new patch when added to the 2.6.33-rc7 tree that
> > > > > > > > > included the original patchset unfortunately did not
> > > > > > > > > correct the problem.
> > > > > > > >
> > > > > > > > Bad.
> > > > > > > >
> > > > > > > > Well, fortunately I have another one, but I haven't tested it myself yet except
> > > > > > > > for checking that it builds. Hopefully it won't break things more.
> > > > > > > >
> > > > > > > > The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
> > > > > > > > applied. Please test it and let me know the results.
> > > > > > >
> > > > > > > Sorry, I sent a wrong version of the patch by mistake, it doesn't even build.
> > > > > > > The correct one is appended.
> > > > > >
> > > > > > No problem. I received this message before doing anything with
> > > > > > the previous one.
> > > > > >
> > > > > > Sorry, both hot-add and hot-remove behaviors appear unchanged
> > > > > > with this patch.
> > > > >
> > > > > Hmm, that's kind of strange. I'm getting suspicious.
> > > > >
> > > > > > I would like to dig into the code and help with the debugging
> > > > > > but I am swamped with other things right now. However, feel
> > > > > > free to continue using me for testing if you have other ideas
> > > > > > you want me to try.
> > > > >
> > > > > Thanks, of course I have some ideas. :-)
> > > > >
> > > > > First, please try to test 2.6.33-rc7 with patches [1/9] - [7/9] applied
> > > > > (ie. without the $subject patch and [9/9]). Let's make sure we're debugging
> > > > > the right patch.
> > > >
> > > > It does look like both the hot-add and hot-remove issues were
> > > > introduced by something in 1/9 through 7/9. I started with a
> > > > clean 2.6.33-rc7 tree and applied only 1/9 through 7/9. I still
> > > > see that lingering blinking amber LED with hot-remove and no
> > > > response from the driver during hot-add.
> > > >
> > > > Now I suppose you want me to start reverting 1/9 through 7/9
> > > > in reverse order to find the culprit. :)
> > >
> > > Actually, I think [6/9] is the offending one, so please try with [1/9] - [5/9]
> > > applied and if that works, please apply [6/9] and retest to confirm it's the
> > > culprit.
> >
> > Yes, 6/9 also appeared to be the most likely suspect to me and
> > I was already doing what you asked except in the opposite order.
> > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > reproduced. After removing 6/9 both issues disappeared.
>
> Thanks for verifying, I've already started to look for bugs in it.
Thanks!
>
> What's your kernel command line, BTW?
root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Thursday 11 February 2010, Gary Hade wrote:
> On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > On Wednesday 10 February 2010, Gary Hade wrote:
...
> > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > I was already doing what you asked except in the opposite order.
> > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > reproduced. After removing 6/9 both issues disappeared.
> >
> > Thanks for verifying, I've already started to look for bugs in it.
>
> Thanks!
>
> >
> > What's your kernel command line, BTW?
>
> root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
Thanks. We found a bug in the patch, but it would require you to use a
specific command line switch to trigger, which you don't use.
I'll let you know if I have anything to test.
Rafael
On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> On Thursday 11 February 2010, Gary Hade wrote:
> > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday 10 February 2010, Gary Hade wrote:
> ...
> > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > I was already doing what you asked except in the opposite order.
> > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > reproduced. After removing 6/9 both issues disappeared.
> > >
> > > Thanks for verifying, I've already started to look for bugs in it.
> >
> > Thanks!
> >
> > >
> > > What's your kernel command line, BTW?
> >
> > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
>
> Thanks. We found a bug in the patch, but it would require you to use a
> specific command line switch to trigger, which you don't use.
>
> I'll let you know if I have anything to test.
OK, please try the patch below on top of [1-6/9].
Rafael
---
drivers/acpi/acpica/evgpeblk.c | 4 ++++
drivers/acpi/acpica/evxface.c | 14 ++++++++++++++
2 files changed, 18 insertions(+)
Index: linux-2.6/drivers/acpi/acpica/evxface.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxface.c
+++ linux-2.6/drivers/acpi/acpica/evxface.c
@@ -617,6 +617,13 @@ acpi_install_gpe_handler(acpi_handle gpe
handler->context = context;
handler->method_node = gpe_event_info->dispatch.method_node;
+ /* Disable the GPE before installing the handler */
+
+ status = acpi_ev_disable_gpe(gpe_event_info);
+ if (ACPI_FAILURE(status)) {
+ goto unlock_and_exit;
+ }
+
/* Install the handler */
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
@@ -709,6 +716,13 @@ acpi_remove_gpe_handler(acpi_handle gpe_
return_ACPI_STATUS(status);
}
+ /* Disable the GPE before removing the handler */
+
+ status = acpi_ev_disable_gpe(gpe_event_info);
+ if (ACPI_FAILURE(status)) {
+ goto unlock_and_exit;
+ }
+
/* Remove the handler */
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c
+++ linux-2.6/drivers/acpi/acpica/evgpeblk.c
@@ -335,6 +335,10 @@ acpi_ev_save_method_info(acpi_handle obj
gpe_event_info->dispatch.method_node =
(struct acpi_namespace_node *)obj_handle;
+ /* Update enable mask, but don't enable the HW GPE as of yet */
+
+ status = acpi_ev_enable_gpe(gpe_event_info, FALSE);
+
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Registered GPE method %s as GPE number 0x%.2X\n",
name, gpe_number));
On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Gary Hade wrote:
> > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > ...
> > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > I was already doing what you asked except in the opposite order.
> > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > reproduced. After removing 6/9 both issues disappeared.
> > > >
> > > > Thanks for verifying, I've already started to look for bugs in it.
> > >
> > > Thanks!
> > >
> > > >
> > > > What's your kernel command line, BTW?
> > >
> > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> >
> > Thanks. We found a bug in the patch, but it would require you to use a
> > specific command line switch to trigger, which you don't use.
> >
> > I'll let you know if I have anything to test.
>
> OK, please try the patch below on top of [1-6/9].
Sorry, it didn't help. The hot-add and hot-remove behaviors
still look the same.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Thursday 11 February 2010, Gary Hade wrote:
> On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > ...
> > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > I was already doing what you asked except in the opposite order.
> > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > >
> > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > >
> > > > Thanks!
> > > >
> > > > >
> > > > > What's your kernel command line, BTW?
> > > >
> > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > >
> > > Thanks. We found a bug in the patch, but it would require you to use a
> > > specific command line switch to trigger, which you don't use.
> > >
> > > I'll let you know if I have anything to test.
> >
> > OK, please try the patch below on top of [1-6/9].
>
> Sorry, it didn't help. The hot-add and hot-remove behaviors
> still look the same.
Thanks for testing.
Well, this time I found another real bug, which is that we should add
gpe_block->block_base_number to the GPE index within the block in order to
compute the GPE number. If there are GPE devices other than the FADT ones in
your system, that may explain the symptoms.
Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
look for "Failed to ebable GPE" messages in dmesg and let me know if there are
any.
Rafael
---
drivers/acpi/acpica/evgpeblk.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c
+++ linux-2.6/drivers/acpi/acpica/evgpeblk.c
@@ -258,7 +258,6 @@ acpi_ev_save_method_info(acpi_handle obj
u32 gpe_number;
char name[ACPI_NAME_SIZE + 1];
u8 type;
- acpi_status status;
ACPI_FUNCTION_TRACE(ev_save_method_info);
@@ -338,7 +337,7 @@ acpi_ev_save_method_info(acpi_handle obj
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Registered GPE method %s as GPE number 0x%.2X\n",
name, gpe_number));
- return_ACPI_STATUS(status);
+ return_ACPI_STATUS(AE_OK);
}
/*******************************************************************************
@@ -1005,6 +1004,9 @@ acpi_ev_initialize_gpe_block(struct acpi
ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK,
acpi_ev_match_prw_and_gpe, NULL,
&gpe_info, NULL);
+ if (ACPI_FAILURE(status))
+ ACPI_ERROR((AE_INFO,
+ "Detection of wake GPEs failed\n"));
}
/*
@@ -1014,30 +1016,36 @@ acpi_ev_initialize_gpe_block(struct acpi
*/
wake_gpe_count = 0;
gpe_enabled_count = 0;
+ if (gpe_device == acpi_gbl_fadt_gpe_device)
+ gpe_device = NULL;
for (i = 0; i < gpe_block->register_count; i++) {
for (j = 0; j < 8; j++) {
- int gpe_number = i * ACPI_GPE_REGISTER_WIDTH + j;
+ acpi_size gpe_index;
+ int gpe_number;
/* Get the info block for this particular GPE */
- gpe_event_info = &gpe_block->event_info[(acpi_size)
- gpe_number];
+ gpe_index = (acpi_size)i * ACPI_GPE_REGISTER_WIDTH + j;
+ gpe_event_info = &gpe_block->event_info[gpe_index];
if (gpe_event_info->flags & ACPI_GPE_CAN_WAKE) {
wake_gpe_count++;
- continue;
+ if (acpi_gbl_leave_wake_gpes_disabled)
+ continue;
}
- if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD) {
+ if (!(gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD))
+ continue;
+
+ gpe_number = gpe_index + gpe_block->block_base_number;
+ status = acpi_ref_runtime_gpe(gpe_device, gpe_number);
+ if (ACPI_FAILURE(status))
+ ACPI_ERROR((AE_INFO,
+ "Failed to enable GPE %02X\n",
+ gpe_number));
+ else
gpe_enabled_count++;
- if (gpe_device == acpi_gbl_fadt_gpe_device)
- status = acpi_ref_runtime_gpe(NULL,
- gpe_number);
- else
- status = acpi_ref_runtime_gpe(gpe_device,
- gpe_number);
- }
}
}
On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> On Thursday 11 February 2010, Gary Hade wrote:
> > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > ...
> > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > >
> > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > >
> > > > > > What's your kernel command line, BTW?
> > > > >
> > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > >
> > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > specific command line switch to trigger, which you don't use.
> > > >
> > > > I'll let you know if I have anything to test.
> > >
> > > OK, please try the patch below on top of [1-6/9].
> >
> > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > still look the same.
>
> Thanks for testing.
>
> Well, this time I found another real bug, which is that we should add
> gpe_block->block_base_number to the GPE index within the block in order to
> compute the GPE number. If there are GPE devices other than the FADT ones in
> your system, that may explain the symptoms.
>
> Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> any.
That one worked! It corrected both the blinking amber LED
after hot-remove and acpiphp's failure to see the hot-add event.
Now when you have patch(es) ready for Jesse's linux-next branch
I can get back to my original mission of checking out Bjorn's
_CRS enablement changes.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Thursday 11 February 2010 11:29:10 am Gary Hade wrote:
> On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Gary Hade wrote:
> > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > ...
> > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > >
> > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > >
> > > > > > > What's your kernel command line, BTW?
> > > > > >
> > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > >
> > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > specific command line switch to trigger, which you don't use.
> > > > >
> > > > > I'll let you know if I have anything to test.
> > > >
> > > > OK, please try the patch below on top of [1-6/9].
> > >
> > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > still look the same.
> >
> > Thanks for testing.
> >
> > Well, this time I found another real bug, which is that we should add
> > gpe_block->block_base_number to the GPE index within the block in order to
> > compute the GPE number. If there are GPE devices other than the FADT ones in
> > your system, that may explain the symptoms.
> >
> > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > any.
>
> That one worked! It corrected both the blinking amber LED
> after hot-remove and acpiphp's failure to see the hot-add event.
>
> Now when you have patch(es) ready for Jesse's linux-next branch
> I can get back to my original mission of checking out Bjorn's
> _CRS enablement changes.
I'm hoping to repost my series today with some fixes, so don't
bother trying anything before that.
Bjorn
On Thursday 11 February 2010, Gary Hade wrote:
> On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Gary Hade wrote:
> > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > ...
> > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > >
> > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > >
> > > > > > > What's your kernel command line, BTW?
> > > > > >
> > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > >
> > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > specific command line switch to trigger, which you don't use.
> > > > >
> > > > > I'll let you know if I have anything to test.
> > > >
> > > > OK, please try the patch below on top of [1-6/9].
> > >
> > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > still look the same.
> >
> > Thanks for testing.
> >
> > Well, this time I found another real bug, which is that we should add
> > gpe_block->block_base_number to the GPE index within the block in order to
> > compute the GPE number. If there are GPE devices other than the FADT ones in
> > your system, that may explain the symptoms.
> >
> > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > any.
>
> That one worked! It corrected both the blinking amber LED
> after hot-remove and acpiphp's failure to see the hot-add event.
Great!
> Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
> I can get back to my original mission of checking out Bjorn's
> _CRS enablement changes.
May I still ask you to test something?
In case I can, please try the appended patch on top of [1-3/6]. It is a
replacement for [4-6/9] with the last fix included.
Rafael
---
Subject: ACPI: Use GPE reference counting to support shared GPEs
From: Rafael J. Wysocki <[email protected]>
ACPI GPEs may map to multiple devices. The current GPE interface
only provides a mechanism for enabling and disabling GPEs, making
it difficult to change the state of GPEs at runtime without extensive
cooperation between devices.
Add an API to allow devices to indicate whether or not they want
their device's GPE to be enabled for both runtime and wakeup events.
Remove the old GPE type handling entirely, which gets rid of various
quirks, like the implicit disabling with GPE type setting. This
requires a small amount of rework in order to ensure that non-wake
GPEs are enabled by default to preserve existing behaviour.
Based on patches from Matthew Garrett <[email protected]>.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/acpica/acevents.h | 6 -
drivers/acpi/acpica/aclocal.h | 2
drivers/acpi/acpica/evgpe.c | 153 ++++-------------------------------------
drivers/acpi/acpica/evgpeblk.c | 87 ++++++++---------------
drivers/acpi/acpica/evxface.c | 14 ---
drivers/acpi/acpica/evxfevnt.c | 90 +++++++++++++++++-------
drivers/acpi/button.c | 13 ++-
drivers/acpi/ec.c | 14 ++-
drivers/acpi/sleep.c | 15 +++-
drivers/acpi/system.c | 4 -
drivers/acpi/wakeup.c | 81 +++++++--------------
include/acpi/acpixf.h | 6 -
include/acpi/actypes.h | 28 ++-----
13 files changed, 188 insertions(+), 325 deletions(-)
Index: linux-2.6/drivers/acpi/acpica/aclocal.h
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/aclocal.h
+++ linux-2.6/drivers/acpi/acpica/aclocal.h
@@ -426,6 +426,8 @@ struct acpi_gpe_event_info {
struct acpi_gpe_register_info *register_info; /* Backpointer to register info */
u8 flags; /* Misc info about this GPE */
u8 gpe_number; /* This GPE */
+ u8 runtime_count;
+ u8 wakeup_count;
};
/* Information about a GPE register pair, one per each status/enable pair in an array */
Index: linux-2.6/drivers/acpi/acpica/evxfevnt.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxfevnt.c
+++ linux-2.6/drivers/acpi/acpica/evxfevnt.c
@@ -201,23 +201,27 @@ ACPI_EXPORT_SYMBOL(acpi_enable_event)
/*******************************************************************************
*
- * FUNCTION: acpi_set_gpe_type
+ * FUNCTION: acpi_set_gpe
*
* PARAMETERS: gpe_device - Parent GPE Device
* gpe_number - GPE level within the GPE block
- * Type - New GPE type
+ * action - Enable or disable
+ * Called from ISR or not
*
* RETURN: Status
*
- * DESCRIPTION: Set the type of an individual GPE
+ * DESCRIPTION: Enable or disable an ACPI event (general purpose)
*
******************************************************************************/
-acpi_status acpi_set_gpe_type(acpi_handle gpe_device, u32 gpe_number, u8 type)
+acpi_status acpi_set_gpe(acpi_handle gpe_device, u32 gpe_number, u8 action)
{
acpi_status status = AE_OK;
+ acpi_cpu_flags flags;
struct acpi_gpe_event_info *gpe_event_info;
- ACPI_FUNCTION_TRACE(acpi_set_gpe_type);
+ ACPI_FUNCTION_TRACE(acpi_set_gpe);
+
+ flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
/* Ensure that we have a valid GPE number */
@@ -227,19 +231,29 @@ acpi_status acpi_set_gpe_type(acpi_handl
goto unlock_and_exit;
}
- if ((gpe_event_info->flags & ACPI_GPE_TYPE_MASK) == type) {
- return_ACPI_STATUS(AE_OK);
- }
+ /* Perform the action */
- /* Set the new type (will disable GPE if currently enabled) */
+ switch (action) {
+ case ACPI_GPE_ENABLE:
+ status = acpi_ev_enable_gpe(gpe_event_info, TRUE);
+ break;
+
+ case ACPI_GPE_DISABLE:
+ status = acpi_ev_disable_gpe(gpe_event_info);
+ break;
- status = acpi_ev_set_gpe_type(gpe_event_info, type);
+ default:
+ ACPI_ERROR((AE_INFO, "Invalid action\n"));
+ status = AE_BAD_PARAMETER;
+ break;
+ }
unlock_and_exit:
+ acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
return_ACPI_STATUS(status);
}
-ACPI_EXPORT_SYMBOL(acpi_set_gpe_type)
+ACPI_EXPORT_SYMBOL(acpi_set_gpe)
/*******************************************************************************
*
@@ -247,15 +261,14 @@ ACPI_EXPORT_SYMBOL(acpi_set_gpe_type)
*
* PARAMETERS: gpe_device - Parent GPE Device
* gpe_number - GPE level within the GPE block
- * Flags - Just enable, or also wake enable?
- * Called from ISR or not
+ * type - Purpose the GPE will be used for
*
* RETURN: Status
*
- * DESCRIPTION: Enable an ACPI event (general purpose)
+ * DESCRIPTION: Take a reference to a GPE and enable it if necessary
*
******************************************************************************/
-acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number)
+acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number, u8 type)
{
acpi_status status = AE_OK;
acpi_cpu_flags flags;
@@ -273,15 +286,32 @@ acpi_status acpi_enable_gpe(acpi_handle
goto unlock_and_exit;
}
- /* Perform the enable */
+ if (type & ACPI_GPE_TYPE_RUNTIME) {
+ if (++gpe_event_info->runtime_count == 1)
+ status = acpi_ev_enable_gpe(gpe_event_info, TRUE);
- status = acpi_ev_enable_gpe(gpe_event_info, TRUE);
+ if (ACPI_FAILURE(status))
+ gpe_event_info->runtime_count--;
+ }
- unlock_and_exit:
+ if (type & ACPI_GPE_TYPE_WAKE) {
+ if (!(gpe_event_info->flags & ACPI_GPE_CAN_WAKE)) {
+ status = AE_BAD_PARAMETER;
+ goto unlock_and_exit;
+ }
+
+ /*
+ * Wake-up GPEs are only enabled right prior to putting the
+ * system into a sleep state.
+ */
+ if (++gpe_event_info->wakeup_count == 1)
+ acpi_ev_update_gpe_enable_masks(gpe_event_info);
+ }
+
+unlock_and_exit:
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
return_ACPI_STATUS(status);
}
-
ACPI_EXPORT_SYMBOL(acpi_enable_gpe)
/*******************************************************************************
@@ -290,15 +320,14 @@ ACPI_EXPORT_SYMBOL(acpi_enable_gpe)
*
* PARAMETERS: gpe_device - Parent GPE Device
* gpe_number - GPE level within the GPE block
- * Flags - Just disable, or also wake disable?
- * Called from ISR or not
+ * type - Purpose the GPE won't be used for any more
*
* RETURN: Status
*
- * DESCRIPTION: Disable an ACPI event (general purpose)
+ * DESCRIPTION: Release a reference to a GPE and disable it if necessary
*
******************************************************************************/
-acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number)
+acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number, u8 type)
{
acpi_status status = AE_OK;
acpi_cpu_flags flags;
@@ -315,13 +344,24 @@ acpi_status acpi_disable_gpe(acpi_handle
goto unlock_and_exit;
}
- status = acpi_ev_disable_gpe(gpe_event_info);
+ if ((type & ACPI_GPE_TYPE_WAKE) && gpe_event_info->runtime_count) {
+ if (--gpe_event_info->runtime_count == 0)
+ acpi_ev_disable_gpe(gpe_event_info);
+ }
+
+ if ((type & ACPI_GPE_TYPE_RUNTIME) && gpe_event_info->wakeup_count) {
+ /*
+ * Wake-up GPEs are not enabled after leaving system sleep
+ * states, so we don't need to disable them here.
+ */
+ if (--gpe_event_info->wakeup_count == 0)
+ acpi_ev_update_gpe_enable_masks(gpe_event_info);
+ }
unlock_and_exit:
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
return_ACPI_STATUS(status);
}
-
ACPI_EXPORT_SYMBOL(acpi_disable_gpe)
/*******************************************************************************
Index: linux-2.6/include/acpi/acpixf.h
===================================================================
--- linux-2.6.orig/include/acpi/acpixf.h
+++ linux-2.6/include/acpi/acpixf.h
@@ -281,11 +281,11 @@ acpi_status acpi_get_event_status(u32 ev
/*
* GPE Interfaces
*/
-acpi_status acpi_set_gpe_type(acpi_handle gpe_device, u32 gpe_number, u8 type);
+acpi_status acpi_set_gpe(acpi_handle gpe_device, u32 gpe_number, u8 action);
-acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number);
+acpi_status acpi_enable_gpe(acpi_handle gpe_device, u32 gpe_number, u8 type);
-acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number);
+acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 gpe_number, u8 type);
acpi_status acpi_clear_gpe(acpi_handle gpe_device, u32 gpe_number, u32 flags);
Index: linux-2.6/drivers/acpi/button.c
===================================================================
--- linux-2.6.orig/drivers/acpi/button.c
+++ linux-2.6/drivers/acpi/button.c
@@ -422,11 +422,9 @@ static int acpi_button_add(struct acpi_d
if (device->wakeup.flags.valid) {
/* Button's GPE is run-wake GPE */
- acpi_set_gpe_type(device->wakeup.gpe_device,
- device->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
acpi_enable_gpe(device->wakeup.gpe_device,
- device->wakeup.gpe_number);
+ device->wakeup.gpe_number,
+ ACPI_GPE_TYPE_WAKE_RUN);
device->wakeup.state.enabled = 1;
}
@@ -446,6 +444,13 @@ static int acpi_button_remove(struct acp
{
struct acpi_button *button = acpi_driver_data(device);
+ if (device->wakeup.flags.valid) {
+ acpi_disable_gpe(device->wakeup.gpe_device,
+ device->wakeup.gpe_number,
+ ACPI_GPE_TYPE_WAKE_RUN);
+ device->wakeup.state.enabled = 0;
+ }
+
acpi_button_remove_fs(device);
input_unregister_device(button->input);
kfree(button);
Index: linux-2.6/drivers/acpi/ec.c
===================================================================
--- linux-2.6.orig/drivers/acpi/ec.c
+++ linux-2.6/drivers/acpi/ec.c
@@ -307,7 +307,7 @@ static int acpi_ec_transaction(struct ac
pr_debug(PREFIX "transaction start\n");
/* disable GPE during transaction if storm is detected */
if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
- acpi_disable_gpe(NULL, ec->gpe);
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
}
status = acpi_ec_transaction_unlocked(ec, t);
@@ -317,7 +317,7 @@ static int acpi_ec_transaction(struct ac
if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
msleep(1);
/* it is safe to enable GPE outside of transaction */
- acpi_enable_gpe(NULL, ec->gpe);
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
pr_info(PREFIX "GPE storm detected, "
"transactions will use polling mode\n");
@@ -788,8 +788,8 @@ static int ec_install_handlers(struct ac
&acpi_ec_gpe_handler, ec);
if (ACPI_FAILURE(status))
return -ENODEV;
- acpi_set_gpe_type(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
- acpi_enable_gpe(NULL, ec->gpe);
+
+ acpi_enable_gpe(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
status = acpi_install_address_space_handler(ec->handle,
ACPI_ADR_SPACE_EC,
&acpi_ec_space_handler,
@@ -806,6 +806,7 @@ static int ec_install_handlers(struct ac
} else {
acpi_remove_gpe_handler(NULL, ec->gpe,
&acpi_ec_gpe_handler);
+ acpi_disable_gpe(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
return -ENODEV;
}
}
@@ -816,6 +817,7 @@ static int ec_install_handlers(struct ac
static void ec_remove_handlers(struct acpi_ec *ec)
{
+ acpi_disable_gpe(NULL, ec->gpe, ACPI_GPE_TYPE_RUNTIME);
if (ACPI_FAILURE(acpi_remove_address_space_handler(ec->handle,
ACPI_ADR_SPACE_EC, &acpi_ec_space_handler)))
pr_err(PREFIX "failed to remove space handler\n");
@@ -1058,7 +1060,7 @@ static int acpi_ec_suspend(struct acpi_d
{
struct acpi_ec *ec = acpi_driver_data(device);
/* Stop using GPE */
- acpi_disable_gpe(NULL, ec->gpe);
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
return 0;
}
@@ -1066,7 +1068,7 @@ static int acpi_ec_resume(struct acpi_de
{
struct acpi_ec *ec = acpi_driver_data(device);
/* Enable use of GPE back */
- acpi_enable_gpe(NULL, ec->gpe);
+ acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
return 0;
}
Index: linux-2.6/drivers/acpi/sleep.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep.c
+++ linux-2.6/drivers/acpi/sleep.c
@@ -745,9 +745,18 @@ int acpi_pm_device_sleep_wake(struct dev
return -ENODEV;
}
- error = enable ?
- acpi_enable_wakeup_device_power(adev, acpi_target_sleep_state) :
- acpi_disable_wakeup_device_power(adev);
+ if (enable) {
+ error = acpi_enable_wakeup_device_power(adev,
+ acpi_target_sleep_state);
+ if (!error)
+ acpi_enable_gpe(adev->wakeup.gpe_device,
+ adev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_WAKE);
+ } else {
+ acpi_disable_gpe(adev->wakeup.gpe_device, adev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_WAKE);
+ error = acpi_disable_wakeup_device_power(adev);
+ }
if (!error)
dev_info(dev, "wake-up capability %s by ACPI\n",
enable ? "enabled" : "disabled");
Index: linux-2.6/drivers/acpi/wakeup.c
===================================================================
--- linux-2.6.orig/drivers/acpi/wakeup.c
+++ linux-2.6/drivers/acpi/wakeup.c
@@ -21,12 +21,12 @@
ACPI_MODULE_NAME("wakeup_devices")
/**
- * acpi_enable_wakeup_device_prep - prepare wakeup devices
- * @sleep_state: ACPI state
- * Enable all wakup devices power if the devices' wakeup level
- * is higher than requested sleep level
+ * acpi_enable_wakeup_device_prep - Prepare wake-up devices.
+ * @sleep_state: ACPI system sleep state.
+ *
+ * Enable all wake-up devices' power, unless the requested system sleep state is
+ * too deep.
*/
-
void acpi_enable_wakeup_device_prep(u8 sleep_state)
{
struct list_head *node, *next;
@@ -36,9 +36,8 @@ void acpi_enable_wakeup_device_prep(u8 s
struct acpi_device,
wakeup_list);
- if (!dev->wakeup.flags.valid ||
- !dev->wakeup.state.enabled ||
- (sleep_state > (u32) dev->wakeup.sleep_state))
+ if (!dev->wakeup.flags.valid || !dev->wakeup.state.enabled
+ || (sleep_state > (u32) dev->wakeup.sleep_state))
continue;
acpi_enable_wakeup_device_power(dev, sleep_state);
@@ -46,9 +45,12 @@ void acpi_enable_wakeup_device_prep(u8 s
}
/**
- * acpi_enable_wakeup_device - enable wakeup devices
- * @sleep_state: ACPI state
- * Enable all wakup devices's GPE
+ * acpi_enable_wakeup_device - Enable wake-up device GPEs.
+ * @sleep_state: ACPI system sleep state.
+ *
+ * Enable all wake-up devices' GPEs, with the assumption that
+ * acpi_disable_all_gpes() was executed before, so we don't need to disable any
+ * GPEs here.
*/
void acpi_enable_wakeup_device(u8 sleep_state)
{
@@ -65,29 +67,22 @@ void acpi_enable_wakeup_device(u8 sleep_
if (!dev->wakeup.flags.valid)
continue;
- /* If users want to disable run-wake GPE,
- * we only disable it for wake and leave it for runtime
- */
if ((!dev->wakeup.state.enabled && !dev->wakeup.prepare_count)
- || sleep_state > (u32) dev->wakeup.sleep_state) {
- if (dev->wakeup.flags.run_wake) {
- /* set_gpe_type will disable GPE, leave it like that */
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_RUNTIME);
- }
+ || sleep_state > (u32) dev->wakeup.sleep_state)
continue;
- }
- if (!dev->wakeup.flags.run_wake)
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
+
+ /* The wake-up power should have been enabled already. */
+ acpi_set_gpe(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
+ ACPI_GPE_ENABLE);
}
}
/**
- * acpi_disable_wakeup_device - disable devices' wakeup capability
- * @sleep_state: ACPI state
- * Disable all wakup devices's GPE and wakeup capability
+ * acpi_disable_wakeup_device - Disable devices' wakeup capability.
+ * @sleep_state: ACPI system sleep state.
+ *
+ * This function only affects devices with wakeup.state.enabled set, which means
+ * that it reverses the changes made by acpi_enable_wakeup_device_prep().
*/
void acpi_disable_wakeup_device(u8 sleep_state)
{
@@ -97,30 +92,11 @@ void acpi_disable_wakeup_device(u8 sleep
struct acpi_device *dev =
container_of(node, struct acpi_device, wakeup_list);
- if (!dev->wakeup.flags.valid)
- continue;
-
- if ((!dev->wakeup.state.enabled && !dev->wakeup.prepare_count)
- || sleep_state > (u32) dev->wakeup.sleep_state) {
- if (dev->wakeup.flags.run_wake) {
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
- /* Re-enable it, since set_gpe_type will disable it */
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
- }
+ if (!dev->wakeup.flags.valid || !dev->wakeup.state.enabled
+ || (sleep_state > (u32) dev->wakeup.sleep_state))
continue;
- }
acpi_disable_wakeup_device_power(dev);
- /* Never disable run-wake GPE */
- if (!dev->wakeup.flags.run_wake) {
- acpi_disable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
- acpi_clear_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number, ACPI_NOT_ISR);
- }
}
}
@@ -136,11 +112,8 @@ int __init acpi_wakeup_device_init(void)
/* In case user doesn't load button driver */
if (!dev->wakeup.flags.run_wake || dev->wakeup.state.enabled)
continue;
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_WAKE_RUN);
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
+ acpi_enable_gpe(dev->wakeup.gpe_device, dev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_WAKE);
dev->wakeup.state.enabled = 1;
}
mutex_unlock(&acpi_device_lock);
Index: linux-2.6/drivers/acpi/acpica/acevents.h
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/acevents.h
+++ linux-2.6/drivers/acpi/acpica/acevents.h
@@ -76,8 +76,7 @@ acpi_ev_queue_notify_request(struct acpi
* evgpe - GPE handling and dispatch
*/
acpi_status
-acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info,
- u8 type);
+acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info);
acpi_status
acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info,
@@ -122,9 +121,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_eve
u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *gpe_xrupt_list);
acpi_status
-acpi_ev_set_gpe_type(struct acpi_gpe_event_info *gpe_event_info, u8 type);
-
-acpi_status
acpi_ev_check_for_wake_only_gpe(struct acpi_gpe_event_info *gpe_event_info);
acpi_status acpi_ev_gpe_initialize(void);
Index: linux-2.6/drivers/acpi/acpica/evgpe.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpe.c
+++ linux-2.6/drivers/acpi/acpica/evgpe.c
@@ -54,54 +54,9 @@ static void ACPI_SYSTEM_XFACE acpi_ev_as
/*******************************************************************************
*
- * FUNCTION: acpi_ev_set_gpe_type
- *
- * PARAMETERS: gpe_event_info - GPE to set
- * Type - New type
- *
- * RETURN: Status
- *
- * DESCRIPTION: Sets the new type for the GPE (wake, run, or wake/run)
- *
- ******************************************************************************/
-
-acpi_status
-acpi_ev_set_gpe_type(struct acpi_gpe_event_info *gpe_event_info, u8 type)
-{
- acpi_status status;
-
- ACPI_FUNCTION_TRACE(ev_set_gpe_type);
-
- /* Validate type and update register enable masks */
-
- switch (type) {
- case ACPI_GPE_TYPE_WAKE:
- case ACPI_GPE_TYPE_RUNTIME:
- case ACPI_GPE_TYPE_WAKE_RUN:
- break;
-
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
- }
-
- /* Disable the GPE if currently enabled */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
-
- /* Clear the type bits and insert the new Type */
-
- gpe_event_info->flags &= ~ACPI_GPE_TYPE_MASK;
- gpe_event_info->flags |= type;
- return_ACPI_STATUS(status);
-}
-
-/*******************************************************************************
- *
* FUNCTION: acpi_ev_update_gpe_enable_masks
*
* PARAMETERS: gpe_event_info - GPE to update
- * Type - What to do: ACPI_GPE_DISABLE or
- * ACPI_GPE_ENABLE
*
* RETURN: Status
*
@@ -110,8 +65,7 @@ acpi_ev_set_gpe_type(struct acpi_gpe_eve
******************************************************************************/
acpi_status
-acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info,
- u8 type)
+acpi_ev_update_gpe_enable_masks(struct acpi_gpe_event_info *gpe_event_info)
{
struct acpi_gpe_register_info *gpe_register_info;
u8 register_bit;
@@ -127,37 +81,14 @@ acpi_ev_update_gpe_enable_masks(struct a
(1 <<
(gpe_event_info->gpe_number - gpe_register_info->base_gpe_number));
- /* 1) Disable case. Simply clear all enable bits */
-
- if (type == ACPI_GPE_DISABLE) {
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake,
- register_bit);
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- return_ACPI_STATUS(AE_OK);
- }
-
- /* 2) Enable case. Set/Clear the appropriate enable bits */
+ ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake, register_bit);
+ ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
- ACPI_SET_BIT(gpe_register_info->enable_for_wake, register_bit);
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
-
- case ACPI_GPE_TYPE_RUNTIME:
- ACPI_CLEAR_BIT(gpe_register_info->enable_for_wake,
- register_bit);
+ if (gpe_event_info->runtime_count)
ACPI_SET_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
- case ACPI_GPE_TYPE_WAKE_RUN:
+ if (gpe_event_info->wakeup_count)
ACPI_SET_BIT(gpe_register_info->enable_for_wake, register_bit);
- ACPI_SET_BIT(gpe_register_info->enable_for_run, register_bit);
- break;
-
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
- }
return_ACPI_STATUS(AE_OK);
}
@@ -186,47 +117,20 @@ acpi_ev_enable_gpe(struct acpi_gpe_event
/* Make sure HW enable masks are updated */
- status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info, ACPI_GPE_ENABLE);
- if (ACPI_FAILURE(status)) {
+ status = acpi_ev_update_gpe_enable_masks(gpe_event_info);
+ if (ACPI_FAILURE(status))
return_ACPI_STATUS(status);
- }
/* Mark wake-enabled or HW enable, or both */
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
- break;
-
- case ACPI_GPE_TYPE_WAKE_RUN:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
-
- /*lint -fallthrough */
-
- case ACPI_GPE_TYPE_RUNTIME:
-
- ACPI_SET_BIT(gpe_event_info->flags, ACPI_GPE_RUN_ENABLED);
-
- if (write_to_hardware) {
-
- /* Clear the GPE (of stale events), then enable it */
-
- status = acpi_hw_clear_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
- }
-
- /* Enable the requested runtime GPE */
-
- status = acpi_hw_write_gpe_enable_reg(gpe_event_info);
- }
- break;
+ if (gpe_event_info->runtime_count && write_to_hardware) {
+ /* Clear the GPE (of stale events), then enable it */
+ status = acpi_hw_clear_gpe(gpe_event_info);
+ if (ACPI_FAILURE(status))
+ return_ACPI_STATUS(status);
- default:
- return_ACPI_STATUS(AE_BAD_PARAMETER);
+ /* Enable the requested runtime GPE */
+ status = acpi_hw_write_gpe_enable_reg(gpe_event_info);
}
return_ACPI_STATUS(AE_OK);
@@ -252,34 +156,9 @@ acpi_status acpi_ev_disable_gpe(struct a
/* Make sure HW enable masks are updated */
- status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info, ACPI_GPE_DISABLE);
- if (ACPI_FAILURE(status)) {
+ status = acpi_ev_update_gpe_enable_masks(gpe_event_info);
+ if (ACPI_FAILURE(status))
return_ACPI_STATUS(status);
- }
-
- /* Clear the appropriate enabled flags for this GPE */
-
- switch (gpe_event_info->flags & ACPI_GPE_TYPE_MASK) {
- case ACPI_GPE_TYPE_WAKE:
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
- break;
-
- case ACPI_GPE_TYPE_WAKE_RUN:
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_WAKE_ENABLED);
-
- /* fallthrough */
-
- case ACPI_GPE_TYPE_RUNTIME:
-
- /* Disable the requested runtime GPE */
-
- ACPI_CLEAR_BIT(gpe_event_info->flags, ACPI_GPE_RUN_ENABLED);
- break;
-
- default:
- break;
- }
/*
* Even if we don't know the GPE type, make sure that we always
Index: linux-2.6/drivers/acpi/acpica/evgpeblk.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evgpeblk.c
+++ linux-2.6/drivers/acpi/acpica/evgpeblk.c
@@ -258,7 +258,6 @@ acpi_ev_save_method_info(acpi_handle obj
u32 gpe_number;
char name[ACPI_NAME_SIZE + 1];
u8 type;
- acpi_status status;
ACPI_FUNCTION_TRACE(ev_save_method_info);
@@ -325,26 +324,20 @@ acpi_ev_save_method_info(acpi_handle obj
/*
* Now we can add this information to the gpe_event_info block for use
- * during dispatch of this GPE. Default type is RUNTIME, although this may
- * change when the _PRW methods are executed later.
+ * during dispatch of this GPE.
*/
gpe_event_info =
&gpe_block->event_info[gpe_number - gpe_block->block_base_number];
- gpe_event_info->flags = (u8)
- (type | ACPI_GPE_DISPATCH_METHOD | ACPI_GPE_TYPE_RUNTIME);
+ gpe_event_info->flags = (u8) (type | ACPI_GPE_DISPATCH_METHOD);
gpe_event_info->dispatch.method_node =
(struct acpi_namespace_node *)obj_handle;
- /* Update enable mask, but don't enable the HW GPE as of yet */
-
- status = acpi_ev_enable_gpe(gpe_event_info, FALSE);
-
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Registered GPE method %s as GPE number 0x%.2X\n",
name, gpe_number));
- return_ACPI_STATUS(status);
+ return_ACPI_STATUS(AE_OK);
}
/*******************************************************************************
@@ -454,20 +447,7 @@ acpi_ev_match_prw_and_gpe(acpi_handle ob
gpe_block->
block_base_number];
- /* Mark GPE for WAKE-ONLY but WAKE_DISABLED */
-
- gpe_event_info->flags &=
- ~(ACPI_GPE_WAKE_ENABLED | ACPI_GPE_RUN_ENABLED);
-
- status =
- acpi_ev_set_gpe_type(gpe_event_info, ACPI_GPE_TYPE_WAKE);
- if (ACPI_FAILURE(status)) {
- goto cleanup;
- }
-
- status =
- acpi_ev_update_gpe_enable_masks(gpe_event_info,
- ACPI_GPE_DISABLE);
+ gpe_event_info->flags |= ACPI_GPE_CAN_WAKE;
}
cleanup:
@@ -989,7 +969,6 @@ acpi_status
acpi_ev_initialize_gpe_block(struct acpi_namespace_node *gpe_device,
struct acpi_gpe_block_info *gpe_block)
{
- acpi_status status;
struct acpi_gpe_event_info *gpe_event_info;
struct acpi_gpe_walk_info gpe_info;
u32 wake_gpe_count;
@@ -1019,42 +998,50 @@ acpi_ev_initialize_gpe_block(struct acpi
gpe_info.gpe_block = gpe_block;
gpe_info.gpe_device = gpe_device;
- status =
- acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+ acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK,
acpi_ev_match_prw_and_gpe, NULL,
&gpe_info, NULL);
}
/*
- * Enable all GPEs in this block that have these attributes:
- * 1) are "runtime" or "run/wake" GPEs, and
- * 2) have a corresponding _Lxx or _Exx method
- *
- * Any other GPEs within this block must be enabled via the
- * acpi_enable_gpe() external interface.
+ * Enable all GPEs that have a corresponding method and aren't
+ * capable of generating wakeups. Any other GPEs within this block
+ * must be enabled via the acpi_enable_gpe() interface.
*/
wake_gpe_count = 0;
gpe_enabled_count = 0;
+ if (gpe_device == acpi_gbl_fadt_gpe_device)
+ gpe_device = NULL;
for (i = 0; i < gpe_block->register_count; i++) {
- for (j = 0; j < 8; j++) {
+ for (j = 0; j < ACPI_GPE_REGISTER_WIDTH; j++) {
+ acpi_status status;
+ acpi_size gpe_index;
+ int gpe_number;
/* Get the info block for this particular GPE */
+ gpe_index = (acpi_size)i * ACPI_GPE_REGISTER_WIDTH + j;
+ gpe_event_info = &gpe_block->event_info[gpe_index];
- gpe_event_info = &gpe_block->event_info[((acpi_size) i *
- ACPI_GPE_REGISTER_WIDTH)
- + j];
-
- if (((gpe_event_info->flags & ACPI_GPE_DISPATCH_MASK) ==
- ACPI_GPE_DISPATCH_METHOD) &&
- (gpe_event_info->flags & ACPI_GPE_TYPE_RUNTIME)) {
- gpe_enabled_count++;
- }
-
- if (gpe_event_info->flags & ACPI_GPE_TYPE_WAKE) {
+ if (gpe_event_info->flags & ACPI_GPE_CAN_WAKE) {
wake_gpe_count++;
+ if (acpi_gbl_leave_wake_gpes_disabled)
+ continue;
}
+
+ if (!(gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD))
+ continue;
+
+ gpe_number = gpe_index + gpe_block->block_base_number;
+ status = acpi_enable_gpe(gpe_device, gpe_number,
+ ACPI_GPE_TYPE_RUNTIME);
+ if (ACPI_FAILURE(status))
+ ACPI_ERROR((AE_INFO,
+ "Failed to enable GPE %02X\n",
+ gpe_number));
+ else
+ gpe_enabled_count++;
}
}
@@ -1062,15 +1049,7 @@ acpi_ev_initialize_gpe_block(struct acpi
"Found %u Wake, Enabled %u Runtime GPEs in this block\n",
wake_gpe_count, gpe_enabled_count));
- /* Enable all valid runtime GPEs found above */
-
- status = acpi_hw_enable_runtime_gpe_block(NULL, gpe_block, NULL);
- if (ACPI_FAILURE(status)) {
- ACPI_ERROR((AE_INFO, "Could not enable GPEs in GpeBlock %p",
- gpe_block));
- }
-
- return_ACPI_STATUS(status);
+ return_ACPI_STATUS(AE_OK);
}
/*******************************************************************************
Index: linux-2.6/drivers/acpi/acpica/evxface.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxface.c
+++ linux-2.6/drivers/acpi/acpica/evxface.c
@@ -617,13 +617,6 @@ acpi_install_gpe_handler(acpi_handle gpe
handler->context = context;
handler->method_node = gpe_event_info->dispatch.method_node;
- /* Disable the GPE before installing the handler */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- goto unlock_and_exit;
- }
-
/* Install the handler */
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
@@ -707,13 +700,6 @@ acpi_remove_gpe_handler(acpi_handle gpe_
goto unlock_and_exit;
}
- /* Disable the GPE before removing the handler */
-
- status = acpi_ev_disable_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- goto unlock_and_exit;
- }
-
/* Make sure all deferred tasks are completed */
(void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
Index: linux-2.6/include/acpi/actypes.h
===================================================================
--- linux-2.6.orig/include/acpi/actypes.h
+++ linux-2.6/include/acpi/actypes.h
@@ -668,15 +668,16 @@ typedef u32 acpi_event_status;
/*
* GPE info flags - Per GPE
- * +-+-+-+---+---+-+
- * |7|6|5|4:3|2:1|0|
- * +-+-+-+---+---+-+
- * | | | | | |
- * | | | | | +--- Interrupt type: Edge or Level Triggered
- * | | | | +--- Type: Wake-only, Runtime-only, or wake/runtime
+ * +-+-+-+---+-+-+-+
+ * |7|6|5|4:3|2|1|0|
+ * +-+-+-+---+-+-+-+
+ * | | | | | | |
+ * | | | | | | +--- Interrupt type: Edge or Level Triggered
+ * | | | | | +--- GPE can wake the system
+ * | | | | +--- Unused
* | | | +--- Type of dispatch -- to method, handler, or none
- * | | +--- Enabled for runtime?
- * | +--- Enabled for wake?
+ * | | +--- Unused
+ * | +--- Unused
* +--- Unused
*/
#define ACPI_GPE_XRUPT_TYPE_MASK (u8) 0x01
@@ -687,22 +688,13 @@ typedef u32 acpi_event_status;
#define ACPI_GPE_TYPE_WAKE_RUN (u8) 0x06
#define ACPI_GPE_TYPE_WAKE (u8) 0x02
#define ACPI_GPE_TYPE_RUNTIME (u8) 0x04 /* Default */
+#define ACPI_GPE_CAN_WAKE (u8) 0x02
#define ACPI_GPE_DISPATCH_MASK (u8) 0x18
#define ACPI_GPE_DISPATCH_HANDLER (u8) 0x08
#define ACPI_GPE_DISPATCH_METHOD (u8) 0x10
#define ACPI_GPE_DISPATCH_NOT_USED (u8) 0x00 /* Default */
-#define ACPI_GPE_RUN_ENABLE_MASK (u8) 0x20
-#define ACPI_GPE_RUN_ENABLED (u8) 0x20
-#define ACPI_GPE_RUN_DISABLED (u8) 0x00 /* Default */
-
-#define ACPI_GPE_WAKE_ENABLE_MASK (u8) 0x40
-#define ACPI_GPE_WAKE_ENABLED (u8) 0x40
-#define ACPI_GPE_WAKE_DISABLED (u8) 0x00 /* Default */
-
-#define ACPI_GPE_ENABLE_MASK (u8) 0x60 /* Both run/wake */
-
/*
* Flags for GPE and Lock interfaces
*/
Index: linux-2.6/drivers/acpi/system.c
===================================================================
--- linux-2.6.orig/drivers/acpi/system.c
+++ linux-2.6/drivers/acpi/system.c
@@ -387,10 +387,10 @@ static ssize_t counter_set(struct kobjec
if (index < num_gpes) {
if (!strcmp(buf, "disable\n") &&
(status & ACPI_EVENT_FLAG_ENABLED))
- result = acpi_disable_gpe(handle, index);
+ result = acpi_set_gpe(handle, index, ACPI_GPE_DISABLE);
else if (!strcmp(buf, "enable\n") &&
!(status & ACPI_EVENT_FLAG_ENABLED))
- result = acpi_enable_gpe(handle, index);
+ result = acpi_set_gpe(handle, index, ACPI_GPE_ENABLE);
else if (!strcmp(buf, "clear\n") &&
(status & ACPI_EVENT_FLAG_SET))
result = acpi_clear_gpe(handle, index, ACPI_NOT_ISR);
On Thursday 11 February 2010, Rafael J. Wysocki wrote:
...
> May I still ask you to test something?
>
> In case I can, please try the appended patch on top of [1-3/6].
That should be [1-3/9] in case it's not obvious.
> It is a replacement for [4-6/9] with the last fix included.
Rafael
On Thu, Feb 11, 2010 at 09:32:02PM +0100, Rafael J. Wysocki wrote:
> On Thursday 11 February 2010, Gary Hade wrote:
> > On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > ...
> > > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > > >
> > > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > >
> > > > > > > > What's your kernel command line, BTW?
> > > > > > >
> > > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > > >
> > > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > > specific command line switch to trigger, which you don't use.
> > > > > >
> > > > > > I'll let you know if I have anything to test.
> > > > >
> > > > > OK, please try the patch below on top of [1-6/9].
> > > >
> > > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > > still look the same.
> > >
> > > Thanks for testing.
> > >
> > > Well, this time I found another real bug, which is that we should add
> > > gpe_block->block_base_number to the GPE index within the block in order to
> > > compute the GPE number. If there are GPE devices other than the FADT ones in
> > > your system, that may explain the symptoms.
> > >
> > > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > > any.
> >
> > That one worked! It corrected both the blinking amber LED
> > after hot-remove and acpiphp's failure to see the hot-add event.
>
> Great!
>
> > Now when you have patch(es) ready for Jesse's linux-next branch
>
> Well, not quite. I had to rework them in the meantime. ;-)
>
> > I can get back to my original mission of checking out Bjorn's
> > _CRS enablement changes.
>
> May I still ask you to test something?
Oh, I guess so. :)
>
> In case I can, please try the appended patch on top of [1-3/6]. It is a
> replacement for [4-6/9] with the last fix included.
I just tried it and it seemed to work fine.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Thursday 11 February 2010, Gary Hade wrote:
> On Thu, Feb 11, 2010 at 09:32:02PM +0100, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Gary Hade wrote:
> > > On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > ...
> > > > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > > > >
> > > > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > >
> > > > > > > > > What's your kernel command line, BTW?
> > > > > > > >
> > > > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > > > >
> > > > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > > > specific command line switch to trigger, which you don't use.
> > > > > > >
> > > > > > > I'll let you know if I have anything to test.
> > > > > >
> > > > > > OK, please try the patch below on top of [1-6/9].
> > > > >
> > > > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > > > still look the same.
> > > >
> > > > Thanks for testing.
> > > >
> > > > Well, this time I found another real bug, which is that we should add
> > > > gpe_block->block_base_number to the GPE index within the block in order to
> > > > compute the GPE number. If there are GPE devices other than the FADT ones in
> > > > your system, that may explain the symptoms.
> > > >
> > > > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > > > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > > > any.
> > >
> > > That one worked! It corrected both the blinking amber LED
> > > after hot-remove and acpiphp's failure to see the hot-add event.
> >
> > Great!
> >
> > > Now when you have patch(es) ready for Jesse's linux-next branch
> >
> > Well, not quite. I had to rework them in the meantime. ;-)
> >
> > > I can get back to my original mission of checking out Bjorn's
> > > _CRS enablement changes.
> >
> > May I still ask you to test something?
>
> Oh, I guess so. :)
>
> >
> > In case I can, please try the appended patch on top of [1-3/6]. It is a
> > replacement for [4-6/9] with the last fix included.
>
> I just tried it and it seemed to work fine.
Great, thanks!
I have one more testing request if you don't mind, but I'd like to make sure
the PCI runtime PM patches won't break the PCI hotplug again.
Please apply [7/9] (ACPI / PM: Add more run-time wake-up field) on top of the
just tested patch and apply the appended patch on top of that. Then, please
check if the PCI hotplug still works.
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Subject: PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 8)
Although the majority of PCI devices can generate PMEs that in
principle may be used to wake up devices suspended at run time,
platform support is generally necessary to convert PMEs into wake-up
events that can be delivered to the kernel. If ACPI is used for this
purpose, a PME generated by a PCI device will trigger the ACPI GPE
associated with the device to generate an ACPI wake-up event that we
can set up a handler for, provided that everything is configured
correctly.
Unfortunately, the subset of PCI devices that have GPEs associated
with them is quite limited and the other devices have to rely on
the GPEs associated with their upstream bridges and, possibly, the
root bridge to generate ACPI wake-up events in response to PMEs from
them. Moreover, ACPI-based PCI hotplug also uses ACPI notify
handlers that in general may conflict with the PM notify handlers,
unless this issue is specifically taken care of.
Add ACPI platform support for PCI PME wake-up:
o Add a framework making is possible to use ACPI system notify
handlers for both PM and hotplug at the same time and to take the
wake-up GPE sharing into account.
o Add new PCI platform callback ->run_wake() to struct
pci_platform_pm_ops allowing us to enable/disable the platform to
generate wake-up events for given device. Implemet this callback
for the ACPI platform.
o Define ACPI wake-up handlers for PCI devices and PCI buses and make
the PCI-ACPI binding code register wake-up notifiers for devices
associated with wake-up GPEs.
o Add function pci_dev_run_wake() which can be used by PCI drivers to
check if given device is capable of generating wake-up events at
run time.
Developed in cooperation with Matthew Garrett <[email protected]>.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/internal.h | 2
drivers/acpi/pci_bind.c | 14 +
drivers/acpi/pci_root.c | 8
drivers/pci/hotplug/acpiphp_glue.c | 23 --
drivers/pci/pci-acpi.c | 351 +++++++++++++++++++++++++++++++++++++
drivers/pci/pci.c | 67 +++++++
drivers/pci/pci.h | 7
include/acpi/acpi_bus.h | 3
include/linux/pci-acpi.h | 10 +
include/linux/pci.h | 1
10 files changed, 469 insertions(+), 17 deletions(-)
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -35,6 +35,10 @@ int pci_probe_reset_function(struct pci_
*
* @sleep_wake: enables/disables the system wake up capability of given device
*
+ * @run_wake: enables/disables the platform to generate run-time wake-up events
+ * for given device (the device's wake-up capability has to be
+ * enabled by @sleep_wake for this feature to work)
+ *
* If given platform is generally capable of power managing PCI devices, all of
* these callbacks are mandatory.
*/
@@ -44,12 +48,15 @@ struct pci_platform_pm_ops {
pci_power_t (*choose_state)(struct pci_dev *dev);
bool (*can_wakeup)(struct pci_dev *dev);
int (*sleep_wake)(struct pci_dev *dev, bool enable);
+ int (*run_wake)(struct pci_dev *dev, bool enable);
};
extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
extern void pci_update_current_state(struct pci_dev *dev, pci_power_t state);
extern void pci_disable_enabled_device(struct pci_dev *dev);
extern bool pci_check_pme_status(struct pci_dev *dev);
+extern int __pci_pme_wakeup(struct pci_dev *dev, void *ign);
+extern void pci_pme_wakeup_bus(struct pci_bus *bus);
extern void pci_pm_init(struct pci_dev *dev);
extern void platform_pci_wakeup_init(struct pci_dev *dev);
extern void pci_allocate_cap_save_buffers(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -16,8 +16,284 @@
#include <acpi/acpi_bus.h>
#include <linux/pci-acpi.h>
+#include <linux/pm_runtime.h>
#include "pci.h"
+static DEFINE_MUTEX(pci_acpi_notify_mtx);
+static LIST_HEAD(pci_acpi_notify_list);
+
+struct pci_acpi_notify_object
+{
+ struct list_head entry;
+ acpi_handle handle;
+ acpi_notify_handler hp_cb;
+ void *hp_data;
+ struct pci_bus *pci_bus;
+ struct pci_dev *pci_dev;
+};
+
+/**
+ * pci_acpi_event_fn - Universal system notification handler.
+ * @handle: ACPI handle of a device the notification is for.
+ * @event: Type of the signaled event.
+ * @context: Pointer to the notify object associated with the handle.
+ *
+ * Use @handle to obtain the address of the ACPI device object the event is
+ * signaled for. If this is a wake-up event, execute the appropriate PME
+ * handler for the bus or device represented by it (or both, if @dev is a
+ * bridge). If this is not a wake-up event, execute the hotplug notify handler
+ * for @handle.
+ */
+static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *context)
+{
+ struct pci_acpi_notify_object *notify_obj = context;
+
+ if (!notify_obj)
+ return;
+
+ mutex_lock(&pci_acpi_notify_mtx);
+
+ if (event == ACPI_NOTIFY_DEVICE_WAKE) {
+ if (notify_obj->pci_bus) {
+ pci_pme_wakeup_bus(notify_obj->pci_bus);
+ }
+ if (notify_obj->pci_dev) {
+ pci_check_pme_status(notify_obj->pci_dev);
+ pm_request_resume(¬ify_obj->pci_dev->dev);
+ }
+ } else if (notify_obj->hp_cb) {
+ notify_obj->hp_cb(handle, event, notify_obj->hp_data);
+ }
+
+ mutex_unlock(&pci_acpi_notify_mtx);
+}
+
+/**
+ * add_notify_obj - Create a new notify object for given ACPI handle.
+ * @handle: ACPI handle to create the notify object for.
+ */
+static struct pci_acpi_notify_object *add_notify_obj(acpi_handle handle)
+{
+ struct pci_acpi_notify_object *notify_obj;
+
+ notify_obj = kzalloc(sizeof(*notify_obj), GFP_KERNEL);
+ if (!notify_obj)
+ return NULL;
+
+ notify_obj->handle = handle;
+ return notify_obj;
+}
+
+/**
+ * pci_acpi_add_hp_notifier - Register a hotplug notifier for given device.
+ * @handle: ACPI handle to register the notifier for.
+ * @handler: Callback to execute for hotplug events related to @handle.
+ * @context: Pointer to the context data to pass to @handler.
+ *
+ * Find the notify object associated with @handle or create one if not found.
+ * Return error code if the notify object already contains a valid pointer to
+ * a hotplug handler or add @handler and @context to the notify object.
+ */
+acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler, void *context)
+{
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_status status = AE_OK;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
+
+ mutex_lock(&pci_acpi_notify_mtx);
+
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->hp_cb) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }
+
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
+ status = AE_NO_MEMORY;
+ goto out;
+ }
+
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, notify_obj);
+ if (ACPI_FAILURE(status)) {
+ kfree(notify_obj);
+ goto out;
+ }
+
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
+ add:
+ notify_obj->hp_cb = handler;
+ notify_obj->hp_data = context;
+
+ out:
+ mutex_unlock(&pci_acpi_notify_mtx);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(pci_acpi_add_hp_notifier);
+
+/**
+ * pci_acpi_remove_hp_notifier - Unregister a hotplug notifier for given device.
+ * @handle: ACPI handle of the device to unregister the notifier for.
+ * @handler: Callback executed for hotplug events related to @handle.
+ *
+ * Find the notify object corresponding to @handle and remove the pointers to
+ * the hotplug handler and data from it. Return error code if the notify object
+ * is not found.
+ */
+acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler)
+{
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_status status = AE_NOT_FOUND;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
+
+ mutex_lock(&pci_acpi_notify_mtx);
+
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
+
+ goto out;
+
+ remove:
+ notify_obj->hp_data = NULL;
+ notify_obj->hp_cb = NULL;
+
+ if (notify_obj->pci_bus || notify_obj->pci_dev) {
+ status = AE_OK;
+ goto out;
+ }
+
+ status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
+
+ out:
+ mutex_unlock(&pci_acpi_notify_mtx);
+ return status;
+}
+EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_notifier);
+
+/**
+ * pci_acpi_add_pm_notifier - Register PM notifier for given device.
+ * @dev: ACPI device to add the notifier for.
+ * @pci_dev: PCI device to check for the PME status if an event is signaled.
+ * @pci_bus: PCI bus to walk (checking PME status) if an event is signaled.
+ *
+ * Use @dev to find the notify object corresponding to its handle or create a
+ * new one if not found. Return error code if the notify object already
+ * contains a valid pointer to a PCI device or bus object. Otherwise, add
+ * @pci_dev and @pci_bus to the notify object, as the device whose PME status
+ * should be checked whenever a PM event is signaled for @dev and the bus to
+ * walk checking the PME status of all devices on it whenever a PM event is
+ * signaled for @dev, respectively.
+ *
+ * NOTE: @dev need not be a run-wake or wake-up device to be a valid source of
+ * PM wake-up events. For example, wake-up events may be generated for bridges
+ * if one of the devices below the bridge is signaling PME, even if the bridge
+ * itself doesn't have a wake-up GPE associated with it.
+ */
+acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev,
+ struct pci_dev *pci_dev,
+ struct pci_bus *pci_bus)
+{
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
+ acpi_status status = AE_OK;
+
+ if (!handle)
+ return AE_BAD_PARAMETER;
+
+ mutex_lock(&pci_acpi_notify_mtx);
+
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->pci_dev || notify_obj->pci_bus) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }
+
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
+ status = AE_NO_MEMORY;
+ goto out;
+ }
+
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, notify_obj);
+ if (ACPI_FAILURE(status)) {
+ kfree(notify_obj);
+ goto out;
+ }
+
+ list_add_tail(¬ify_obj->entry, &pci_acpi_notify_list);
+
+ add:
+ notify_obj->pci_dev = pci_dev;
+ notify_obj->pci_bus = pci_bus;
+
+ out:
+ mutex_unlock(&pci_acpi_notify_mtx);
+ return status;
+}
+
+/**
+ * pci_acpi_remove_pm_notifier - Unregister PM notifier for given device.
+ * @dev: ACPI device to remove the notifier from.
+ *
+ * Find the notify object for @dev and clear its @pci_dev and @pci_bus
+ * fields. If the notify data object is not necessary any more after that,
+ * remove it altogether.
+ */
+acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
+{
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
+ acpi_status status = AE_NOT_FOUND;
+
+ mutex_lock(&pci_acpi_notify_mtx);
+
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
+
+ goto out;
+
+ remove:
+ notify_obj->pci_dev = NULL;
+ notify_obj->pci_bus = NULL;
+
+ if (notify_obj->hp_cb) {
+ status = AE_OK;
+ goto out;
+ }
+
+ status = acpi_remove_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn);
+ list_del(¬ify_obj->entry);
+ kfree(notify_obj);
+
+ out:
+ mutex_unlock(&pci_acpi_notify_mtx);
+ return status;
+}
+
/*
* _SxD returns the D-state with the highest power
* (lowest D-state number) supported in the S-state "x".
@@ -131,12 +407,87 @@ static int acpi_pci_sleep_wake(struct pc
return 0;
}
+/**
+ * acpi_dev_run_wake - Enable/disable wake-up for given device.
+ * @phys_dev: Device to enable/disable the platform to wake-up the system for.
+ * @enable: Whether enable or disable the wake-up functionality.
+ *
+ * Find the ACPI device object corresponding to @pci_dev and try to
+ * enable/disable the GPE associated with it.
+ */
+static int acpi_dev_run_wake(struct device *phys_dev, bool enable)
+{
+ struct acpi_device *dev;
+ acpi_handle handle;
+ int error = -ENODEV;
+
+ if (!device_run_wake(phys_dev))
+ return -EINVAL;
+
+ handle = DEVICE_ACPI_HANDLE(phys_dev);
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
+ dev_dbg(phys_dev, "ACPI handle has no context in %s!\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ if (enable) {
+ if (!dev->wakeup.run_wake_count++) {
+ acpi_enable_wakeup_device_power(dev, ACPI_STATE_S0);
+ acpi_enable_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_RUNTIME);
+ }
+ } else if (dev->wakeup.run_wake_count > 0) {
+ if (!--dev->wakeup.run_wake_count) {
+ acpi_disable_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_RUNTIME);
+ acpi_disable_wakeup_device_power(dev);
+ }
+ } else {
+ error = -EALREADY;
+ }
+
+ return error;
+}
+
+static void acpi_pci_propagate_run_wake(struct pci_bus *bus, bool enable)
+{
+ while (bus->parent) {
+ struct pci_dev *bridge = bus->self;
+
+ if (bridge->pme_interrupt)
+ return;
+ if (!acpi_dev_run_wake(&bridge->dev, enable))
+ return;
+ bus = bus->parent;
+ }
+
+ /* We have reached the root bus. */
+ if (bus->bridge)
+ acpi_dev_run_wake(bus->bridge, enable);
+}
+
+static int acpi_pci_run_wake(struct pci_dev *dev, bool enable)
+{
+ if (dev->pme_interrupt)
+ return 0;
+
+ if (!acpi_dev_run_wake(&dev->dev, enable))
+ return 0;
+
+ acpi_pci_propagate_run_wake(dev->bus, enable);
+ return 0;
+}
+
static struct pci_platform_pm_ops acpi_pci_platform_pm = {
.is_manageable = acpi_pci_power_manageable,
.set_state = acpi_pci_set_power_state,
.choose_state = acpi_pci_choose_state,
.can_wakeup = acpi_pci_can_wakeup,
.sleep_wake = acpi_pci_sleep_wake,
+ .run_wake = acpi_pci_run_wake,
};
/* ACPI bus type */
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -20,6 +20,7 @@
#include <linux/pm_wakeup.h>
#include <linux/interrupt.h>
#include <linux/device.h>
+#include <linux/pm_runtime.h>
#include <asm/setup.h>
#include "pci.h"
@@ -462,6 +463,12 @@ static inline int platform_pci_sleep_wak
pci_platform_pm->sleep_wake(dev, enable) : -ENODEV;
}
+static inline int platform_pci_run_wake(struct pci_dev *dev, bool enable)
+{
+ return pci_platform_pm ?
+ pci_platform_pm->run_wake(dev, enable) : -ENODEV;
+}
+
/**
* pci_raw_set_power_state - Use PCI PM registers to set the power state of
* given PCI device
@@ -1230,6 +1237,31 @@ bool pci_check_pme_status(struct pci_dev
}
/**
+ * pci_pme_wakeup - Wake up a PCI device if its PME Status bit is set.
+ * @dev: Device to handle.
+ * @ign: Ignored.
+ *
+ * Check if @dev has generated PME and queue a resume request for it in that
+ * case.
+ */
+static int pci_pme_wakeup(struct pci_dev *dev, void *ign)
+{
+ if (pci_check_pme_status(dev))
+ pm_request_resume(&dev->dev);
+ return 0;
+}
+
+/**
+ * pci_pme_wakeup_bus - Walk given bus and wake up devices on it, if necessary.
+ * @bus: Top bus of the subtree to walk.
+ */
+void pci_pme_wakeup_bus(struct pci_bus *bus)
+{
+ if (bus)
+ pci_walk_bus(bus, pci_pme_wakeup, NULL);
+}
+
+/**
* pci_pme_capable - check the capability of PCI device to generate PME#
* @dev: PCI device to handle.
* @state: PCI state from which device will issue PME#.
@@ -1434,6 +1466,41 @@ int pci_back_from_sleep(struct pci_dev *
}
/**
+ * pci_dev_run_wake - Check if device can generate run-time wake-up events.
+ * @dev: Device to check.
+ *
+ * Return true if the device itself is cabable of generating wake-up events
+ * (through the platform or using the native PCIe PME) or if the device supports
+ * PME and one of its upstream bridges can generate wake-up events.
+ */
+bool pci_dev_run_wake(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+
+ if (device_run_wake(&dev->dev))
+ return true;
+
+ if (!dev->pme_support)
+ return false;
+
+ while (bus->parent) {
+ struct pci_dev *bridge = bus->self;
+
+ if (device_run_wake(&bridge->dev))
+ return true;
+
+ bus = bus->parent;
+ }
+
+ /* We have reached the root bus. */
+ if (bus->bridge)
+ return device_run_wake(bus->bridge);
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(pci_dev_run_wake);
+
+/**
* pci_pm_init - Initialize PM functions of given PCI device
* @dev: PCI device to handle.
*/
Index: linux-2.6/include/linux/pci-acpi.h
===================================================================
--- linux-2.6.orig/include/linux/pci-acpi.h
+++ linux-2.6/include/linux/pci-acpi.h
@@ -11,6 +11,16 @@
#include <linux/acpi.h>
#ifdef CONFIG_ACPI
+extern acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler,
+ void *context);
+extern acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
+ acpi_notify_handler handler);
+extern acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev,
+ struct pci_dev *pci_dev,
+ struct pci_bus *pci_bus);
+extern acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev);
+
static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
{
struct pci_bus *pbus = pdev->bus;
Index: linux-2.6/drivers/acpi/pci_bind.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_bind.c
+++ linux-2.6/drivers/acpi/pci_bind.c
@@ -26,7 +26,9 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/pci.h>
+#include <linux/pci-acpi.h>
#include <linux/acpi.h>
+#include <linux/pm_runtime.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
@@ -38,7 +40,13 @@ static int acpi_pci_unbind(struct acpi_d
struct pci_dev *dev;
dev = acpi_get_pci_dev(device->handle);
- if (!dev || !dev->subordinate)
+ if (!dev)
+ goto out;
+
+ device_set_run_wake(&dev->dev, false);
+ pci_acpi_remove_pm_notifier(device);
+
+ if (!dev->subordinate)
goto out;
acpi_pci_irq_del_prt(dev->subordinate);
@@ -62,6 +70,10 @@ static int acpi_pci_bind(struct acpi_dev
if (!dev)
return 0;
+ pci_acpi_add_pm_notifier(device, dev, dev->subordinate);
+ if (device->wakeup.flags.run_wake)
+ device_set_run_wake(&dev->dev, true);
+
/*
* Install the 'bind' function to facilitate callbacks for
* children of the P2P bridge.
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===================================================================
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -236,8 +236,7 @@ register_slot(acpi_handle handle, u32 lv
/* install notify handler */
if (!(newfunc->flags & FUNC_HAS_DCK)) {
- status = acpi_install_notify_handler(handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(handle,
handle_hotplug_event_func,
newfunc);
@@ -288,14 +287,12 @@ static void init_bridge_misc(struct acpi
/* install notify handler */
if (bridge->type != BRIDGE_TYPE_HOST) {
if ((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func) {
- status = acpi_remove_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(bridge->func->handle,
handle_hotplug_event_func);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
}
- status = acpi_install_notify_handler(bridge->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(bridge->handle,
handle_hotplug_event_bridge,
bridge);
@@ -505,15 +502,14 @@ static void cleanup_bridge(struct acpiph
acpi_status status;
acpi_handle handle = bridge->handle;
- status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(handle,
handle_hotplug_event_bridge);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
if ((bridge->type != BRIDGE_TYPE_HOST) &&
((bridge->flags & BRIDGE_HAS_EJ0) && bridge->func)) {
- status = acpi_install_notify_handler(bridge->func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_add_hp_notifier(bridge->func->handle,
handle_hotplug_event_func,
bridge->func);
if (ACPI_FAILURE(status))
@@ -529,8 +525,7 @@ static void cleanup_bridge(struct acpiph
unregister_dock_notifier(&func->nb);
}
if (!(func->flags & FUNC_HAS_DCK)) {
- status = acpi_remove_notify_handler(func->handle,
- ACPI_SYSTEM_NOTIFY,
+ status = pci_acpi_remove_hp_notifier(func->handle,
handle_hotplug_event_func);
if (ACPI_FAILURE(status))
err("failed to remove notify handler\n");
@@ -592,7 +587,7 @@ static void remove_bridge(acpi_handle ha
if (bridge)
cleanup_bridge(bridge);
else
- acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_remove_hp_notifier(handle,
handle_hotplug_event_bridge);
}
@@ -1278,8 +1273,8 @@ find_root_bridges(acpi_handle handle, u3
int *count = (int *)context;
if (acpi_is_root_bridge(handle)) {
- acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- handle_hotplug_event_bridge, NULL);
+ pci_acpi_add_hp_notifier(handle,
+ handle_hotplug_event_bridge, NULL);
(*count)++;
}
return AE_OK ;
Index: linux-2.6/include/linux/pci.h
===================================================================
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -756,6 +756,7 @@ int pci_wake_from_d3(struct pci_dev *dev
pci_power_t pci_target_state(struct pci_dev *dev);
int pci_prepare_to_sleep(struct pci_dev *dev);
int pci_back_from_sleep(struct pci_dev *dev);
+bool pci_dev_run_wake(struct pci_dev *dev);
/* For use by arch with custom probe code */
void set_pcie_port_type(struct pci_dev *pdev);
Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -388,6 +388,9 @@ acpi_handle acpi_get_pci_rootbridge_hand
struct acpi_pci_root *acpi_pci_find_root(acpi_handle handle);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->archdata.acpi_handle))
+int acpi_enable_wakeup_device_power(struct acpi_device *dev, int state);
+int acpi_disable_wakeup_device_power(struct acpi_device *dev);
+
#ifdef CONFIG_PM_SLEEP
int acpi_pm_device_sleep_state(struct device *, int *);
int acpi_pm_device_sleep_wake(struct device *, bool);
Index: linux-2.6/drivers/acpi/pci_root.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_root.c
+++ linux-2.6/drivers/acpi/pci_root.c
@@ -30,6 +30,7 @@
#include <linux/proc_fs.h>
#include <linux/spinlock.h>
#include <linux/pm.h>
+#include <linux/pm_runtime.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
#include <linux/acpi.h>
@@ -528,6 +529,10 @@ static int __devinit acpi_pci_root_add(s
if (flags != base_flags)
acpi_pci_osc_support(root, flags);
+ pci_acpi_add_pm_notifier(device, NULL, root->bus);
+ if (device->wakeup.flags.run_wake)
+ device_set_run_wake(root->bus->bridge, true);
+
return 0;
end:
@@ -549,6 +554,9 @@ static int acpi_pci_root_remove(struct a
{
struct acpi_pci_root *root = acpi_driver_data(device);
+ device_set_run_wake(root->bus->bridge, false);
+ pci_acpi_remove_pm_notifier(device);
+
kfree(root);
return 0;
}
Index: linux-2.6/drivers/acpi/internal.h
===================================================================
--- linux-2.6.orig/drivers/acpi/internal.h
+++ linux-2.6/drivers/acpi/internal.h
@@ -36,8 +36,6 @@ static inline int acpi_debug_init(void)
int acpi_power_init(void);
int acpi_device_sleep_wake(struct acpi_device *dev,
int enable, int sleep_state, int dev_state);
-int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state);
-int acpi_disable_wakeup_device_power(struct acpi_device *dev);
int acpi_power_get_inferred_state(struct acpi_device *device);
int acpi_power_transition(struct acpi_device *device, int state);
extern int acpi_power_nocheck;
On Thu, Feb 11, 2010 at 11:21:13PM +0100, Rafael J. Wysocki wrote:
> On Thursday 11 February 2010, Gary Hade wrote:
> > On Thu, Feb 11, 2010 at 09:32:02PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > > ...
> > > > > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > > > > >
> > > > > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > What's your kernel command line, BTW?
> > > > > > > > >
> > > > > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > > > > >
> > > > > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > > > > specific command line switch to trigger, which you don't use.
> > > > > > > >
> > > > > > > > I'll let you know if I have anything to test.
> > > > > > >
> > > > > > > OK, please try the patch below on top of [1-6/9].
> > > > > >
> > > > > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > > > > still look the same.
> > > > >
> > > > > Thanks for testing.
> > > > >
> > > > > Well, this time I found another real bug, which is that we should add
> > > > > gpe_block->block_base_number to the GPE index within the block in order to
> > > > > compute the GPE number. If there are GPE devices other than the FADT ones in
> > > > > your system, that may explain the symptoms.
> > > > >
> > > > > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > > > > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > > > > any.
> > > >
> > > > That one worked! It corrected both the blinking amber LED
> > > > after hot-remove and acpiphp's failure to see the hot-add event.
> > >
> > > Great!
> > >
> > > > Now when you have patch(es) ready for Jesse's linux-next branch
> > >
> > > Well, not quite. I had to rework them in the meantime. ;-)
> > >
> > > > I can get back to my original mission of checking out Bjorn's
> > > > _CRS enablement changes.
> > >
> > > May I still ask you to test something?
> >
> > Oh, I guess so. :)
> >
> > >
> > > In case I can, please try the appended patch on top of [1-3/6]. It is a
> > > replacement for [4-6/9] with the last fix included.
> >
> > I just tried it and it seemed to work fine.
>
> Great, thanks!
>
> I have one more testing request if you don't mind, but I'd like to make sure
> the PCI runtime PM patches won't break the PCI hotplug again.
>
> Please apply [7/9] (ACPI / PM: Add more run-time wake-up field) on top of the
> just tested patch and apply the appended patch on top of that. Then, please
> check if the PCI hotplug still works.
There seems to be a problem.
The first time I booted I was able to successfully hot-remove
a PCIe card and then successfully hot-add it to a different slot.
When I tried to hot-remove a PCI-X card that was also present
during boot I saw that lingering blinking amber LED issue.
After rebooting I tried the same thing but this time I did
not see the lingering blinking amber LED after removing the
PCI-X card but I did see it when removing the PCIe card.
I then tried to hot-add the PCIe card to a different slot
and noticed the below messages.
I don't think I will be able to try to characterize this
better or test any more patches until Monday.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
[ 271.776748] acpiphp: disable_slot - physical_slot = 5
[ 271.856119] igb 0000:15:00.0: PCI INT A disabled
[ 271.952110] igb 0000:15:00.1: PCI INT B disabled
[ 281.294973] acpiphp: get_power_status - physical_slot = 5
[ 363.144064] INFO: task kacpi_notify:107 blocked for more than 120 seconds.
[ 363.144070] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 363.144074] kacpi_notify D 0000000000000000 0 107 2 0x00000000
[ 363.144081] ffff88017b38b910 0000000000000046 0000000000000000 ffff8801763a2680
[ 363.144087] 000000000000e720 ffff88017b38bfd8 ffff88017b3885c0 ffff88017b3889a0
[ 363.144093] ffff880176323980 ffff88000d40e720 ffffffff8160c020 00000000ffffbf2c
[ 363.144098] Call Trace:
[ 363.144118] [<ffffffff813a963f>] __mutex_lock_slowpath+0x12f/0x180
[ 363.144123] [<ffffffff813a8fbe>] mutex_lock+0x1e/0x40
[ 363.144135] [<ffffffff81224101>] pci_acpi_add_pm_notifier+0x41/0x130
[ 363.144146] [<ffffffff81245b5f>] acpi_pci_bind+0x32/0x103
[ 363.144157] [<ffffffff8118a63c>] ? sysfs_add_file+0xc/0x10
[ 363.144162] [<ffffffff8118a701>] ? sysfs_create_file+0x21/0x30
[ 363.144167] [<ffffffff81240f1a>] acpi_add_single_object+0xbb1/0xd60
[ 363.144172] [<ffffffff8123cc72>] ? acpi_os_signal_semaphore+0x66/0x6f
[ 363.144177] [<ffffffff8123fda6>] ? acpi_bus_data_handler+0x0/0x6
[ 363.144185] [<ffffffff81268fc5>] ? acpi_ut_release_mutex+0xad/0xb6
[ 363.144190] [<ffffffff812411a0>] acpi_bus_check_add+0xd7/0x12c
[ 363.144194] [<ffffffff8123cc72>] ? acpi_os_signal_semaphore+0x66/0x6f
[ 363.144198] [<ffffffff81241226>] acpi_bus_scan+0x31/0x6e
[ 363.144203] [<ffffffff812412ae>] acpi_bus_add+0x25/0x29
[ 363.144212] [<ffffffffa01b97a5>] enable_device+0x205/0x42b [acpiphp]
[ 363.144219] [<ffffffffa01b784d>] ? get_slot_status+0x4d/0xd0 [acpiphp]
[ 363.144224] [<ffffffff8123ced5>] ? acpi_os_execute_deferred+0x0/0x31
[ 363.144230] [<ffffffffa01b8630>] acpiphp_enable_slot+0xe0/0x160 [acpiphp]
[ 363.144235] [<ffffffffa01b8715>] acpiphp_check_bridge+0x65/0xf0 [acpiphp]
[ 363.144241] [<ffffffffa01b9383>] handle_hotplug_event_bridge+0x2d3/0x4d0 [acpiphp]
[ 363.144253] [<ffffffff81003330>] ? ptregscall_common+0x0/0x40
[ 363.144260] [<ffffffff8125b9ca>] ? acpi_get_data+0x5e/0x70
[ 363.144264] [<ffffffff8123f2fb>] ? acpi_bus_get_device+0x2a/0x71
[ 363.144269] [<ffffffff81223fb9>] pci_acpi_event_fn+0x49/0xa0
[ 363.144278] [<ffffffff8124fa3e>] acpi_ev_notify_dispatch+0x5f/0x6d
[ 363.144282] [<ffffffff8123cef9>] acpi_os_execute_deferred+0x24/0x31
[ 363.144292] [<ffffffff8106d709>] worker_thread+0x189/0x260
[ 363.144299] [<ffffffff81071d90>] ? autoremove_wake_function+0x0/0x40
[ 363.144303] [<ffffffff8106d580>] ? worker_thread+0x0/0x260
[ 363.144308] [<ffffffff810717c6>] kthread+0x96/0xa0
[ 363.144313] [<ffffffff81003dc4>] kernel_thread_helper+0x4/0x10
[ 363.144318] [<ffffffff81071730>] ? kthread+0x0/0xa0
[ 363.144322] [<ffffffff81003dc0>] ? kernel_thread_helper+0x0/0x10
On Friday 12 February 2010, Gary Hade wrote:
> On Thu, Feb 11, 2010 at 11:21:13PM +0100, Rafael J. Wysocki wrote:
> > On Thursday 11 February 2010, Gary Hade wrote:
> > > On Thu, Feb 11, 2010 at 09:32:02PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > On Thu, Feb 11, 2010 at 02:27:17PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > > On Thu, Feb 11, 2010 at 01:56:54AM +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Thursday 11 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > > On Thursday 11 February 2010, Gary Hade wrote:
> > > > > > > > > > On Wed, Feb 10, 2010 at 11:58:00PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > > > On Wednesday 10 February 2010, Gary Hade wrote:
> > > > > > > > > ...
> > > > > > > > > > > > Yes, 6/9 also appeared to be the most likely suspect to me and
> > > > > > > > > > > > I was already doing what you asked except in the opposite order.
> > > > > > > > > > > > With 1/9 through 6/9 both the hot-add and hot-remove issues still
> > > > > > > > > > > > reproduced. After removing 6/9 both issues disappeared.
> > > > > > > > > > >
> > > > > > > > > > > Thanks for verifying, I've already started to look for bugs in it.
> > > > > > > > > >
> > > > > > > > > > Thanks!
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > What's your kernel command line, BTW?
> > > > > > > > > >
> > > > > > > > > > root=/dev/disk/by-id/scsi-35000c5000036ffcb-part7 ip=9.47.66.9:9.47.67.50:9.47.66.1:255.255.254.0 resume=/dev/disk/by-id/scsi-35000c50000370247-part3 crashkernel=256M-:128M console=tty0 console=ttyS0,115200 pci=use_crs pci=norom
> > > > > > > > >
> > > > > > > > > Thanks. We found a bug in the patch, but it would require you to use a
> > > > > > > > > specific command line switch to trigger, which you don't use.
> > > > > > > > >
> > > > > > > > > I'll let you know if I have anything to test.
> > > > > > > >
> > > > > > > > OK, please try the patch below on top of [1-6/9].
> > > > > > >
> > > > > > > Sorry, it didn't help. The hot-add and hot-remove behaviors
> > > > > > > still look the same.
> > > > > >
> > > > > > Thanks for testing.
> > > > > >
> > > > > > Well, this time I found another real bug, which is that we should add
> > > > > > gpe_block->block_base_number to the GPE index within the block in order to
> > > > > > compute the GPE number. If there are GPE devices other than the FADT ones in
> > > > > > your system, that may explain the symptoms.
> > > > > >
> > > > > > Please try the patch below (on top of [1-6/9]). In case it doesn't help, please
> > > > > > look for "Failed to ebable GPE" messages in dmesg and let me know if there are
> > > > > > any.
> > > > >
> > > > > That one worked! It corrected both the blinking amber LED
> > > > > after hot-remove and acpiphp's failure to see the hot-add event.
> > > >
> > > > Great!
> > > >
> > > > > Now when you have patch(es) ready for Jesse's linux-next branch
> > > >
> > > > Well, not quite. I had to rework them in the meantime. ;-)
> > > >
> > > > > I can get back to my original mission of checking out Bjorn's
> > > > > _CRS enablement changes.
> > > >
> > > > May I still ask you to test something?
> > >
> > > Oh, I guess so. :)
> > >
> > > >
> > > > In case I can, please try the appended patch on top of [1-3/6]. It is a
> > > > replacement for [4-6/9] with the last fix included.
> > >
> > > I just tried it and it seemed to work fine.
> >
> > Great, thanks!
> >
> > I have one more testing request if you don't mind, but I'd like to make sure
> > the PCI runtime PM patches won't break the PCI hotplug again.
> >
> > Please apply [7/9] (ACPI / PM: Add more run-time wake-up field) on top of the
> > just tested patch and apply the appended patch on top of that. Then, please
> > check if the PCI hotplug still works.
>
> There seems to be a problem.
>
> The first time I booted I was able to successfully hot-remove
> a PCIe card and then successfully hot-add it to a different slot.
> When I tried to hot-remove a PCI-X card that was also present
> during boot I saw that lingering blinking amber LED issue.
>
> After rebooting I tried the same thing but this time I did
> not see the lingering blinking amber LED after removing the
> PCI-X card but I did see it when removing the PCIe card.
> I then tried to hot-add the PCIe card to a different slot
> and noticed the below messages.
>
> I don't think I will be able to try to characterize this
> better or test any more patches until Monday.
OK, thanks for testing.
It seems we have a deadlock on pci_acpi_notify_mtx, but I'm yet to understand
the exact mechanism of it.
Rafael
On Friday 12 February 2010, Rafael J. Wysocki wrote:
> On Friday 12 February 2010, Gary Hade wrote:
...
> > There seems to be a problem.
> >
> > The first time I booted I was able to successfully hot-remove
> > a PCIe card and then successfully hot-add it to a different slot.
> > When I tried to hot-remove a PCI-X card that was also present
> > during boot I saw that lingering blinking amber LED issue.
> >
> > After rebooting I tried the same thing but this time I did
> > not see the lingering blinking amber LED after removing the
> > PCI-X card but I did see it when removing the PCIe card.
> > I then tried to hot-add the PCIe card to a different slot
> > and noticed the below messages.
> >
> > I don't think I will be able to try to characterize this
> > better or test any more patches until Monday.
>
> OK, thanks for testing.
>
> It seems we have a deadlock on pci_acpi_notify_mtx, but I'm yet to understand
> the exact mechanism of it.
In fact there are two problems in there. First, the bridge event notification
calls handle_bridge_insertion() which attempts to install a PM notifier for
the bridge and that deadlocks, because it tries to acquire the mutex
recursively. Second, apparently, init_bridge_misc() may be called in the
notification code path and it attempts to unregister the notifier and register
it again, which can't be done with pci_acpi_notify_mtx held.
I guess there are similar problems on the hot remove notification path.
Anyway, I have a new version of the patch and I'm going to test it a bit
over the weekend. Unfortunately, I don't have hardware with PCI hotplug
capability, so I'll send you the new patch for testing on Monday, if you don't
mind.
Rafael
On Sat, Feb 13, 2010 at 01:20:29AM +0100, Rafael J. Wysocki wrote:
> On Friday 12 February 2010, Rafael J. Wysocki wrote:
> > On Friday 12 February 2010, Gary Hade wrote:
> ...
> > > There seems to be a problem.
> > >
> > > The first time I booted I was able to successfully hot-remove
> > > a PCIe card and then successfully hot-add it to a different slot.
> > > When I tried to hot-remove a PCI-X card that was also present
> > > during boot I saw that lingering blinking amber LED issue.
> > >
> > > After rebooting I tried the same thing but this time I did
> > > not see the lingering blinking amber LED after removing the
> > > PCI-X card but I did see it when removing the PCIe card.
> > > I then tried to hot-add the PCIe card to a different slot
> > > and noticed the below messages.
> > >
> > > I don't think I will be able to try to characterize this
> > > better or test any more patches until Monday.
> >
> > OK, thanks for testing.
> >
> > It seems we have a deadlock on pci_acpi_notify_mtx, but I'm yet to understand
> > the exact mechanism of it.
>
> In fact there are two problems in there. First, the bridge event notification
> calls handle_bridge_insertion() which attempts to install a PM notifier for
> the bridge and that deadlocks, because it tries to acquire the mutex
> recursively. Second, apparently, init_bridge_misc() may be called in the
> notification code path and it attempts to unregister the notifier and register
> it again, which can't be done with pci_acpi_notify_mtx held.
>
> I guess there are similar problems on the hot remove notification path.
>
> Anyway, I have a new version of the patch and I'm going to test it a bit
> over the weekend. Unfortunately, I don't have hardware with PCI hotplug
> capability, so I'll send you the new patch for testing on Monday, if you don't
> mind.
I don't mind. Although I am concerned that my acpiphp only
testing on our IBM System x boxes may not be sufficient to
assure that PCI hotplug will work well on other PCI hotplug
capable systems. I hope that others will also do some early
testing of this code.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Saturday 13 February 2010, Gary Hade wrote:
> On Sat, Feb 13, 2010 at 01:20:29AM +0100, Rafael J. Wysocki wrote:
> > On Friday 12 February 2010, Rafael J. Wysocki wrote:
> > > On Friday 12 February 2010, Gary Hade wrote:
...
> > In fact there are two problems in there. First, the bridge event notification
> > calls handle_bridge_insertion() which attempts to install a PM notifier for
> > the bridge and that deadlocks, because it tries to acquire the mutex
> > recursively. Second, apparently, init_bridge_misc() may be called in the
> > notification code path and it attempts to unregister the notifier and register
> > it again, which can't be done with pci_acpi_notify_mtx held.
> >
> > I guess there are similar problems on the hot remove notification path.
> >
> > Anyway, I have a new version of the patch and I'm going to test it a bit
> > over the weekend. Unfortunately, I don't have hardware with PCI hotplug
> > capability, so I'll send you the new patch for testing on Monday, if you don't
> > mind.
>
> I don't mind.
Thanks!
> Although I am concerned that my acpiphp only
> testing on our IBM System x boxes may not be sufficient to
> assure that PCI hotplug will work well on other PCI hotplug
> capable systems. I hope that others will also do some early
> testing of this code.
The code that you've been testing is not very hardware-dependent. It only
matters whether or not the hardware is capable of PCI hotplugging
(ACPI-based), so your testing should be sufficient.
In fact I have two patches to test. The first one is an ACPI CA patch that
allows us to use more than one system notify handler per device (below).
Please test it on top of [1-3/9] with the replacement for [4-6/9] I sent
you earlier (http://patchwork.kernel.org/patch/78814/) and (updated) [7/9].
If this works, please apply the patch from
http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=patch;h=d42c8b334bafe3a15f2dd43e395dafefe58dc588
on top of the appended one and see if things still work correctly.
For convenience the entire patch series to test is located in the
pci-runtime-pm of my suspend-2.6 tree:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git pci-runtime-pm
I think you can just try it as a whole and go back to individual patches if it
doesn't work.
Thanks,
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Subject: ACPI / ACPICA: Multiple system notify handlers per device
Currently it only is possible to install one system notify handler
per namespace node, but this is not enough for PCI run-time power
management, because we need to install power management notifiers for
devices that already have hotplug notifiers installed. While in
principle this could be handled at the PCI level, that would be
suboptimal due to the way in which the ACPI-based PCI hotplug code is
designed.
For this reason, modify ACPICA so that it is possible to install more
than one system notify handler per namespace node. Namely, make
acpi_install_notify_handler(), acpi_remove_notify_handler() and
acpi_ev_notify_dispatch() use a list of system notify handler objects
associated with a namespace node.
Make acpi_remove_notify_handler() call acpi_os_wait_events_complete()
upfront to avoid a situation in which concurrent instance of
acpi_remove_notify_handler() removes the handler from under us while
we're waiting for the event queues to flush.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/acpica/acobject.h | 2
drivers/acpi/acpica/evmisc.c | 12 ++
drivers/acpi/acpica/evxface.c | 175 ++++++++++++++++++++++++++++++++---------
3 files changed, 150 insertions(+), 39 deletions(-)
Index: linux-2.6/drivers/acpi/acpica/acobject.h
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/acobject.h
+++ linux-2.6/drivers/acpi/acpica/acobject.h
@@ -287,8 +287,10 @@ struct acpi_object_buffer_field {
struct acpi_object_notify_handler {
ACPI_OBJECT_COMMON_HEADER struct acpi_namespace_node *node; /* Parent device */
+ u32 handler_type;
acpi_notify_handler handler;
void *context;
+ struct acpi_object_notify_handler *next;
};
struct acpi_object_addr_handler {
Index: linux-2.6/drivers/acpi/acpica/evxface.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evxface.c
+++ linux-2.6/drivers/acpi/acpica/evxface.c
@@ -218,6 +218,72 @@ ACPI_EXPORT_SYMBOL(acpi_remove_fixed_eve
/*******************************************************************************
*
+ * FUNCTION: acpi_populate_handler_object
+ *
+ * PARAMETERS: handler_obj - Handler object to populate
+ * handler_type - The type of handler:
+ * ACPI_SYSTEM_NOTIFY: system_handler (00-7f)
+ * ACPI_DEVICE_NOTIFY: driver_handler (80-ff)
+ * ACPI_ALL_NOTIFY: both system and device
+ * handler - Address of the handler
+ * context - Value passed to the handler on each GPE
+ * next - Address of a handler object to link to
+ *
+ * RETURN: None
+ *
+ * DESCRIPTION: Populate a handler object.
+ *
+ ******************************************************************************/
+static void
+acpi_populate_handler_object(struct acpi_object_notify_handler *handler_obj,
+ u32 handler_type,
+ acpi_notify_handler handler, void *context,
+ struct acpi_object_notify_handler *next)
+{
+ handler_obj->handler_type = handler_type;
+ handler_obj->handler = handler;
+ handler_obj->context = context;
+ handler_obj->next = next;
+}
+
+/*******************************************************************************
+ *
+ * FUNCTION: acpi_add_handler_object
+ *
+ * PARAMETERS: parent_obj - Parent of the new object
+ * handler - Address of the handler
+ * context - Value passed to the handler on each GPE
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Create a new handler object and populate it.
+ *
+ ******************************************************************************/
+static acpi_status
+acpi_add_handler_object(struct acpi_object_notify_handler *parent_obj,
+ acpi_notify_handler handler, void *context)
+{
+ struct acpi_object_notify_handler *handler_obj;
+
+ /* The parent must not be a defice notify handler object. */
+ if (parent_obj->handler_type & ACPI_DEVICE_NOTIFY)
+ return AE_BAD_PARAMETER;
+
+ handler_obj = ACPI_ALLOCATE_ZEROED(sizeof(*handler_obj));
+ if (!handler_obj)
+ return AE_NO_MEMORY;
+
+ acpi_populate_handler_object(handler_obj,
+ ACPI_SYSTEM_NOTIFY,
+ handler, context,
+ parent_obj->next);
+ parent_obj->next = handler_obj;
+
+ return AE_OK;
+}
+
+/*******************************************************************************
+ *
* FUNCTION: acpi_install_notify_handler
*
* PARAMETERS: Device - The device for which notifies will be handled
@@ -316,15 +382,32 @@ acpi_install_notify_handler(acpi_handle
obj_desc = acpi_ns_get_attached_object(node);
if (obj_desc) {
- /* Object exists - make sure there's no handler */
+ /* Object exists. */
- if (((handler_type & ACPI_SYSTEM_NOTIFY) &&
- obj_desc->common_notify.system_notify) ||
- ((handler_type & ACPI_DEVICE_NOTIFY) &&
- obj_desc->common_notify.device_notify)) {
+ /* For a device notify, make sure there's no handler. */
+ if ((handler_type & ACPI_DEVICE_NOTIFY) &&
+ obj_desc->common_notify.device_notify) {
status = AE_ALREADY_EXISTS;
goto unlock_and_exit;
}
+
+ /* System notifies may have more handlers installed. */
+ notify_obj = obj_desc->common_notify.system_notify;
+
+ if ((handler_type & ACPI_SYSTEM_NOTIFY) && notify_obj) {
+ struct acpi_object_notify_handler *parent_obj;
+
+ if (handler_type & ACPI_DEVICE_NOTIFY) {
+ status = AE_ALREADY_EXISTS;
+ goto unlock_and_exit;
+ }
+
+ parent_obj = ¬ify_obj->notify;
+ status = acpi_add_handler_object(parent_obj,
+ handler,
+ context);
+ goto unlock_and_exit;
+ }
} else {
/* Create a new object */
@@ -356,9 +439,10 @@ acpi_install_notify_handler(acpi_handle
goto unlock_and_exit;
}
- notify_obj->notify.node = node;
- notify_obj->notify.handler = handler;
- notify_obj->notify.context = context;
+ acpi_populate_handler_object(¬ify_obj->notify,
+ handler_type,
+ handler, context,
+ NULL);
if (handler_type & ACPI_SYSTEM_NOTIFY) {
obj_desc->common_notify.system_notify = notify_obj;
@@ -418,6 +502,10 @@ acpi_remove_notify_handler(acpi_handle d
goto exit;
}
+
+ /* Make sure all deferred tasks are completed */
+ acpi_os_wait_events_complete(NULL);
+
status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
if (ACPI_FAILURE(status)) {
goto exit;
@@ -445,15 +533,6 @@ acpi_remove_notify_handler(acpi_handle d
goto unlock_and_exit;
}
- /* Make sure all deferred tasks are completed */
-
- (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
- acpi_os_wait_events_complete(NULL);
- status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
- if (ACPI_FAILURE(status)) {
- goto exit;
- }
-
if (handler_type & ACPI_SYSTEM_NOTIFY) {
acpi_gbl_system_notify.node = NULL;
acpi_gbl_system_notify.handler = NULL;
@@ -488,28 +567,60 @@ acpi_remove_notify_handler(acpi_handle d
/* Object exists - make sure there's an existing handler */
if (handler_type & ACPI_SYSTEM_NOTIFY) {
+ struct acpi_object_notify_handler *handler_obj;
+ struct acpi_object_notify_handler *parent_obj;
+
notify_obj = obj_desc->common_notify.system_notify;
if (!notify_obj) {
status = AE_NOT_EXIST;
goto unlock_and_exit;
}
- if (notify_obj->notify.handler != handler) {
+ handler_obj = ¬ify_obj->notify;
+ parent_obj = NULL;
+ while (handler_obj->handler != handler) {
+ if (handler_obj->next) {
+ parent_obj = handler_obj;
+ handler_obj = handler_obj->next;
+ } else {
+ break;
+ }
+ }
+
+ if (handler_obj->handler != handler) {
status = AE_BAD_PARAMETER;
goto unlock_and_exit;
}
- /* Make sure all deferred tasks are completed */
- (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
- acpi_os_wait_events_complete(NULL);
- status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
- if (ACPI_FAILURE(status)) {
- goto exit;
+ /*
+ * Remove the handler. There are three possible cases.
+ * First, we may need to remove a non-embedded object.
+ * Second, we may need to remove the embedded object's
+ * handler data, while non-embedded objects exist.
+ * Finally, we may need to remove the embedded object
+ * entirely along with its container.
+ */
+ if (parent_obj) {
+ /* Non-embedded object is being removed. */
+ parent_obj->next = handler_obj->next;
+ ACPI_FREE(handler_obj);
+ } else if (notify_obj->notify.next) {
+ /*
+ * The handler matches the embedded object, but
+ * there are more handler objects in the list.
+ * Replace the embedded object's data with the
+ * first next object's data and remove that
+ * object.
+ */
+ parent_obj = ¬ify_obj->notify;
+ handler_obj = notify_obj->notify.next;
+ *parent_obj = *handler_obj;
+ ACPI_FREE(handler_obj);
+ } else {
+ /* No more handler objects in the list. */
+ obj_desc->common_notify.system_notify = NULL;
+ acpi_ut_remove_reference(notify_obj);
}
-
- /* Remove the handler */
- obj_desc->common_notify.system_notify = NULL;
- acpi_ut_remove_reference(notify_obj);
}
if (handler_type & ACPI_DEVICE_NOTIFY) {
@@ -523,14 +634,6 @@ acpi_remove_notify_handler(acpi_handle d
status = AE_BAD_PARAMETER;
goto unlock_and_exit;
}
- /* Make sure all deferred tasks are completed */
-
- (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
- acpi_os_wait_events_complete(NULL);
- status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
- if (ACPI_FAILURE(status)) {
- goto exit;
- }
/* Remove the handler */
obj_desc->common_notify.device_notify = NULL;
Index: linux-2.6/drivers/acpi/acpica/evmisc.c
===================================================================
--- linux-2.6.orig/drivers/acpi/acpica/evmisc.c
+++ linux-2.6/drivers/acpi/acpica/evmisc.c
@@ -259,9 +259,15 @@ static void ACPI_SYSTEM_XFACE acpi_ev_no
handler_obj = notify_info->notify.handler_obj;
if (handler_obj) {
- handler_obj->notify.handler(notify_info->notify.node,
- notify_info->notify.value,
- handler_obj->notify.context);
+ struct acpi_object_notify_handler *notifier;
+
+ notifier = &handler_obj->notify;
+ while (notifier) {
+ notifier->handler(notify_info->notify.node,
+ notify_info->notify.value,
+ notifier->context);
+ notifier = notifier->next;
+ }
}
/* All done with the info object */
On Sun, Feb 14, 2010 at 02:51:17PM +0100, Rafael J. Wysocki wrote:
> On Saturday 13 February 2010, Gary Hade wrote:
> > On Sat, Feb 13, 2010 at 01:20:29AM +0100, Rafael J. Wysocki wrote:
> > > On Friday 12 February 2010, Rafael J. Wysocki wrote:
> > > > On Friday 12 February 2010, Gary Hade wrote:
> ...
> > > In fact there are two problems in there. First, the bridge event notification
> > > calls handle_bridge_insertion() which attempts to install a PM notifier for
> > > the bridge and that deadlocks, because it tries to acquire the mutex
> > > recursively. Second, apparently, init_bridge_misc() may be called in the
> > > notification code path and it attempts to unregister the notifier and register
> > > it again, which can't be done with pci_acpi_notify_mtx held.
> > >
> > > I guess there are similar problems on the hot remove notification path.
> > >
> > > Anyway, I have a new version of the patch and I'm going to test it a bit
> > > over the weekend. Unfortunately, I don't have hardware with PCI hotplug
> > > capability, so I'll send you the new patch for testing on Monday, if you don't
> > > mind.
> >
> > I don't mind.
>
> Thanks!
>
> > Although I am concerned that my acpiphp only
> > testing on our IBM System x boxes may not be sufficient to
> > assure that PCI hotplug will work well on other PCI hotplug
> > capable systems. I hope that others will also do some early
> > testing of this code.
>
> The code that you've been testing is not very hardware-dependent. It only
> matters whether or not the hardware is capable of PCI hotplugging
> (ACPI-based), so your testing should be sufficient.
Perhaps the tester-dependent aspect should also be considered. :)
>
> In fact I have two patches to test. The first one is an ACPI CA patch that
> allows us to use more than one system notify handler per device (below).
> Please test it on top of [1-3/9] with the replacement for [4-6/9] I sent
> you earlier (http://patchwork.kernel.org/patch/78814/) and (updated) [7/9].
This seemed to work OK. I did not see any of the previously
reported issues during hot-remove and hot-add.
>
> If this works, please apply the patch from
> http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=patch;h=d42c8b334bafe3a15f2dd43e395dafefe58dc588
> on top of the appended one and see if things still work correctly.
Results still looked good after adding this patch.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc
On Monday 15 February 2010, Gary Hade wrote:
> On Sun, Feb 14, 2010 at 02:51:17PM +0100, Rafael J. Wysocki wrote:
> > On Saturday 13 February 2010, Gary Hade wrote:
> > > On Sat, Feb 13, 2010 at 01:20:29AM +0100, Rafael J. Wysocki wrote:
> > > > On Friday 12 February 2010, Rafael J. Wysocki wrote:
> > > > > On Friday 12 February 2010, Gary Hade wrote:
> > ...
> > > > In fact there are two problems in there. First, the bridge event notification
> > > > calls handle_bridge_insertion() which attempts to install a PM notifier for
> > > > the bridge and that deadlocks, because it tries to acquire the mutex
> > > > recursively. Second, apparently, init_bridge_misc() may be called in the
> > > > notification code path and it attempts to unregister the notifier and register
> > > > it again, which can't be done with pci_acpi_notify_mtx held.
> > > >
> > > > I guess there are similar problems on the hot remove notification path.
> > > >
> > > > Anyway, I have a new version of the patch and I'm going to test it a bit
> > > > over the weekend. Unfortunately, I don't have hardware with PCI hotplug
> > > > capability, so I'll send you the new patch for testing on Monday, if you don't
> > > > mind.
> > >
> > > I don't mind.
> >
> > Thanks!
> >
> > > Although I am concerned that my acpiphp only
> > > testing on our IBM System x boxes may not be sufficient to
> > > assure that PCI hotplug will work well on other PCI hotplug
> > > capable systems. I hope that others will also do some early
> > > testing of this code.
> >
> > The code that you've been testing is not very hardware-dependent. It only
> > matters whether or not the hardware is capable of PCI hotplugging
> > (ACPI-based), so your testing should be sufficient.
>
> Perhaps the tester-dependent aspect should also be considered. :)
>
> >
> > In fact I have two patches to test. The first one is an ACPI CA patch that
> > allows us to use more than one system notify handler per device (below).
> > Please test it on top of [1-3/9] with the replacement for [4-6/9] I sent
> > you earlier (http://patchwork.kernel.org/patch/78814/) and (updated) [7/9].
>
> This seemed to work OK. I did not see any of the previously
> reported issues during hot-remove and hot-add.
>
> >
> > If this works, please apply the patch from
> > http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=patch;h=d42c8b334bafe3a15f2dd43e395dafefe58dc588
> > on top of the appended one and see if things still work correctly.
>
> Results still looked good after adding this patch.
Thanks a lot for testing, it looks like the issues have been resolved, then.
Rafael