PCI run-time PM support (rev. 3)

PATCH Applied Rafael J. Wysocki 4 participants 105 messages Jan 10, 2010 – Feb 15, 2010

Subsystems (6)

Documentation ACPI PCI Suspend to RAM +2 more subsystems

lore

Share & tools

lore

Rafael J. Wysocki

author

2010-01-10 13:31 UTC #0 lore raw

cover PCI run-time PM support (rev. 3)

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

Rafael J. Wysocki

author

2010-01-10 13:35 UTC #1 lore raw

PATCH 1/9 PCI PM: Add function for checking PME status of devices

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(+)

drivers/pci/pci.h +1 -0

Index: 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);

drivers/pci/pci.c +35 -0

Index: 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#.

Rafael J. Wysocki

author

2010-01-10 14:06 UTC #2 lore raw

PATCH 1/9 PCI PM: Add function for checking PME status of devices

In reply to Rafael J. Wysocki

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(+)

drivers/pci/pci.h +1 -0

Index: 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);

drivers/pci/pci.c +35 -0

Index: 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#.

Jesse Barnes

Applied

2010-01-15 17:55 UTC #3 lore raw

Re: [PATCH 1/9] PCI PM: Add function for checking PME status of devices

Quoted 9 lines · 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.

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Jesse Barnes

Applied

2010-01-15 17:55 UTC #4 lore raw

Re: [PATCH 1/9] PCI PM: Add function for checking PME status of devices

In reply to Rafael J. Wysocki

Quoted 9 lines · 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.

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Rafael J. Wysocki

author

2010-01-10 13:36 UTC #5 lore raw

PATCH 2/9 PCI PM: PCIe PME root port service driver (rev. 5)

In reply to Rafael J. Wysocki

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(+)

drivers/pci/pcie/Kconfig +4 -0

Index: 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

drivers/pci/pcie/Makefile +2 -0

Index: 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/

drivers/pci/pcie/pme/pcie_pme.c new file +493 -0

493 lines not on this page · raw message

drivers/pci/pcie/pme/pcie_pme_acpi.c new file +54 -0

54 lines not on this page · raw message

drivers/pci/pcie/pme/Makefile new file +8 -0

Index: 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

drivers/pci/pcie/pme/pcie_pme.h new file +28 -0

Index: 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

include/linux/pci.h +1 -0

Index: 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 */

Documentation/kernel-parameters.txt +6 -0

Index: 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]

Rafael J. Wysocki

author

2010-01-10 14:05 UTC #6 lore raw

PATCH 2/9 PCI PM: PCIe PME root port service driver (rev. 5)

In reply to Rafael J. Wysocki

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.

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(+)

drivers/pci/pcie/Kconfig +4 -0

Index: 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

drivers/pci/pcie/Makefile +2 -0

Index: 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/

drivers/pci/pcie/pme/pcie_pme.c new file +493 -0

493 lines not on this page · raw message

drivers/pci/pcie/pme/pcie_pme_acpi.c new file +54 -0

54 lines not on this page · raw message

drivers/pci/pcie/pme/Makefile new file +8 -0

Index: 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

drivers/pci/pcie/pme/pcie_pme.h new file +28 -0

Index: 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

include/linux/pci.h +1 -0

Index: 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 */

Documentation/kernel-parameters.txt +6 -0

Index: 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]

Rafael J. Wysocki

author

2010-01-10 13:37 UTC #7 lore raw

PATCH 3/9 PCI PM: Make it possible to force using INTx for PCIe PME signaling

In reply to Rafael J. Wysocki

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(-)

drivers/pci/pcie/pme/pcie_pme.c +13 -1

Index: 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 {

drivers/pci/pcie/portdrv_core.c +10 -2

Index: 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;

drivers/pci/pcie/portdrv_pci.c +27 -0

Index: 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);

drivers/pci/pcie/portdrv.h +17 -0

Index: 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_ */

Documentation/kernel-parameters.txt +2 -0

Index: 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

Rafael J. Wysocki

author

2010-01-10 14:05 UTC #8 lore raw

PATCH 3/9 PCI PM: Make it possible to force using INTx for PCIe PME signaling

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

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(-)

drivers/pci/pcie/pme/pcie_pme.c +13 -1

Index: 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 {

drivers/pci/pcie/portdrv_core.c +10 -2

Index: 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;

drivers/pci/pcie/portdrv_pci.c +27 -0

Index: 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);

drivers/pci/pcie/portdrv.h +17 -0

Index: 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_ */

Documentation/kernel-parameters.txt +2 -0

Index: 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

Rafael J. Wysocki

author

2010-01-10 13:38 UTC #9 lore raw

PATCH 4/9 ACPI: Add infrastructure for refcounting GPE consumers

In reply to Rafael J. Wysocki

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(+)

drivers/acpi/acpica/aclocal.h +2 -0

Index: 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 */

drivers/acpi/acpica/evxfevnt.c +161 -0

167 lines not on this page · raw message

include/acpi/acpixf.h +8 -0

Index: 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);

Rafael J. Wysocki

author

2010-01-10 14:04 UTC #10 lore raw

PATCH 4/9 ACPI: Add infrastructure for refcounting GPE consumers

In reply to Rafael J. Wysocki

From: Matthew Garrett <[email protected]>

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(+)

drivers/acpi/acpica/aclocal.h +2 -0

Index: 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 */

drivers/acpi/acpica/evxfevnt.c +161 -0

167 lines not on this page · raw message

include/acpi/acpixf.h +8 -0

Index: 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);

Rafael J. Wysocki

author

2010-01-10 13:39 UTC #11 lore raw

PATCH 5/9 ACPI: Add support for new refcounted GPE API to drivers

In reply to Rafael J. Wysocki

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(-)

drivers/acpi/button.c +12 -0

Index: 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);

drivers/acpi/ec.c +3 -1

Index: 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");

drivers/acpi/wakeup.c +6 -0

Index: 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);

Rafael J. Wysocki

author

2010-01-10 14:06 UTC #12 lore raw

PATCH 5/9 ACPI: Add support for new refcounted GPE API to drivers

In reply to Rafael J. Wysocki

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(-)

drivers/acpi/button.c +12 -0

Index: 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);

drivers/acpi/ec.c +3 -1

Index: 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");

drivers/acpi/wakeup.c +6 -0

Index: 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);

Rafael J. Wysocki

author

2010-01-10 13:40 UTC #13 lore raw

PATCH 6/9 ACPI: Remove old GPE API and transition code entirely to new one

In reply to Rafael J. Wysocki

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(-)

drivers/acpi/acpica/acevents.h +1 -5

Index: 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);

drivers/acpi/acpica/evgpe.c +14 ~~-133~~

194 lines not on this page · raw message

drivers/acpi/acpica/evgpeblk.c +22 ~~-47~~

112 lines not on this page · raw message

drivers/acpi/acpica/evxface.c +0 ~~-14~~

Index: 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);

drivers/acpi/acpica/evxfevnt.c +2 ~~-46~~

66 lines not on this page · raw message

drivers/acpi/button.c +0 -5

Index: 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,

drivers/acpi/ec.c +1 -1

Index: 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,

drivers/acpi/wakeup.c +9 ~~-46~~

77 lines not on this page · raw message

include/acpi/actypes.h +10 ~~-22~~

Index: 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
  */

Rafael J. Wysocki

author

2010-01-10 14:06 UTC #14 lore raw

PATCH 6/9 ACPI: Remove old GPE API and transition code entirely to new one

In reply to Rafael J. Wysocki

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/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(-)

drivers/acpi/acpica/acevents.h +1 -5

Index: 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);

drivers/acpi/acpica/evgpe.c +14 ~~-133~~

194 lines not on this page · raw message

drivers/acpi/acpica/evgpeblk.c +22 ~~-47~~

112 lines not on this page · raw message

drivers/acpi/acpica/evxface.c +0 ~~-14~~

Index: 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);

drivers/acpi/acpica/evxfevnt.c +2 ~~-46~~

66 lines not on this page · raw message

drivers/acpi/button.c +0 -5

Index: 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,

drivers/acpi/ec.c +1 -1

Index: 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,

drivers/acpi/wakeup.c +9 ~~-46~~

77 lines not on this page · raw message

include/acpi/actypes.h +10 ~~-22~~

Index: 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
  */

Rafael J. Wysocki

author

2010-01-10 13:48 UTC #15 lore raw

PATCH 7/9 ACPI / PM: Add more run-time wake-up fields (rev. 2)

In reply to Rafael J. Wysocki

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(-)

drivers/acpi/wakeup.c +2 -1

Index: 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);

include/acpi/acpi_bus.h +2 -0

Index: 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 */

drivers/acpi/button.c +2 -0

Index: 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;
 	}

drivers/acpi/scan.c +27 ~~-10~~

Index: 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;

Rafael J. Wysocki

author

2010-01-10 14:06 UTC #16 lore raw

PATCH 7/9 ACPI / PM: Add more run-time wake-up fields (rev. 2)

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

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(-)

drivers/acpi/wakeup.c +2 -1

Index: 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);

include/acpi/acpi_bus.h +2 -0

Index: 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 */

drivers/acpi/button.c +2 -0

Index: 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;
 	}

drivers/acpi/scan.c +27 ~~-10~~

Index: 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;

Rafael J. Wysocki

author

2010-01-10 14:01 UTC #17 lore raw

PATCH 8/9 PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

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(-)

drivers/pci/pci.h +7 -0

Index: 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);

drivers/pci/pci-acpi.c +341 -0

361 lines not on this page · raw message

drivers/pci/pci.c +67 -0

91 lines not on this page · raw message

include/linux/pci-acpi.h +10 -0

Index: 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;

drivers/acpi/pci_bind.c +13 -1

Index: 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.

drivers/pci/hotplug/acpiphp_glue.c +9 ~~-14~~

Index: 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 ;

include/linux/pci.h +1 -0

Index: 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);

include/acpi/acpi_bus.h +4 -0

Index: 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);

drivers/acpi/pci_root.c +8 -0

Index: 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;
 }

drivers/acpi/internal.h +0 -2

Index: 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;

Rafael J. Wysocki

author

2010-01-10 14:05 UTC #18 lore raw

PATCH 8/9 PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

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(-)

drivers/pci/pci.h +7 -0

Index: 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);

drivers/pci/pci-acpi.c +341 -0

361 lines not on this page · raw message

drivers/pci/pci.c +67 -0

91 lines not on this page · raw message

include/linux/pci-acpi.h +10 -0

Index: 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;

drivers/acpi/pci_bind.c +13 -1

Index: 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.

drivers/pci/hotplug/acpiphp_glue.c +9 ~~-14~~

Index: 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 ;

include/linux/pci.h +1 -0

Index: 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);

include/acpi/acpi_bus.h +4 -0

Index: 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);

drivers/acpi/pci_root.c +8 -0

Index: 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;
 }

drivers/acpi/internal.h +0 -2

Index: 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;

Bjorn Helgaas

2010-02-05 23:57 UTC #19 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 10 lines · Rafael J. Wysocki

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

Bjorn Helgaas

2010-02-05 23:57 UTC #20 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 10 lines · Rafael J. Wysocki

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:

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.

Bjorn

Rafael J. Wysocki

author

2010-02-06 00:20 UTC #21 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 27 lines · Bjorn Helgaas

Quoted 10 lines · Rafael J. Wysocki
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.

Quoted 8 lines

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

Rafael J. Wysocki

author

2010-02-06 00:20 UTC #22 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Bjorn Helgaas

Quoted 27 lines · Bjorn Helgaas

Quoted 10 lines · Rafael J. Wysocki
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.

Quoted 8 lines

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

Rafael J. Wysocki

author

2010-02-06 20:11 UTC #23 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Bjorn Helgaas

Quoted 23 lines · Bjorn Helgaas

Quoted 10 lines · Rafael J. Wysocki
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

Quoted 3 lines

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

Gary Hade

2010-02-08 17:53 UTC #24 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 24 lines · Rafael J. Wysocki

Quoted 23 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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

Quoted 8 lines

Quoted 3 lines
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

Signature · 41 lines

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

Gary Hade

2010-02-08 17:53 UTC #25 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 24 lines · Rafael J. Wysocki

Quoted 23 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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

Quoted 8 lines

Quoted 3 lines
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

Signature · 41 lines

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

Rafael J. Wysocki

author

2010-02-08 19:16 UTC #26 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 29 lines · Gary Hade

Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.

Quoted 7 lines

Quoted 4 lines
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

Gary Hade

2010-02-08 21:12 UTC #27 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 35 lines · Rafael J. Wysocki

Quoted 34 lines · Gary Hade
Quoted 32 lines · Rafael J. Wysocki
Quoted 23 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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
Quoted 3 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 3 lines

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

Signature · 56 lines

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

Gary Hade

2010-02-08 21:12 UTC #28 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 35 lines · Rafael J. Wysocki

Quoted 34 lines · Gary Hade
Quoted 32 lines · Rafael J. Wysocki
Quoted 23 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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
Quoted 3 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 3 lines

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

Signature · 56 lines

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

Rafael J. Wysocki

author

2010-02-08 21:29 UTC #29 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 38 lines · Rafael J. Wysocki

Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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.

Quoted 6 lines

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(-)

drivers/pci/pci-acpi.c +24 -6

Index: 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);

Gary Hade

2010-02-08 23:37 UTC #30 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 41 lines · Rafael J. Wysocki

Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!

Quoted 8 lines

Quoted 4 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-08 23:37 UTC #31 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 41 lines · Rafael J. Wysocki

Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!

Quoted 8 lines

Quoted 4 lines
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

Gary

Signature · 6 lines

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

Gary Hade

2010-02-09 00:53 UTC #32 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 80 lines · Gary Hade

Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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

Quoted 4 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-09 00:53 UTC #33 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 80 lines · Gary Hade

Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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

Quoted 4 lines

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

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-09 12:47 UTC #34 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 86 lines · Gary Hade

Quoted 80 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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
Quoted 4 lines
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.

Quoted 6 lines

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

Rafael J. Wysocki

author

2010-02-09 13:33 UTC #35 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 87 lines · Rafael J. Wysocki

Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
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(+)

drivers/pci/hotplug/acpiphp_glue.c +2 -0

Index: 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);

Rafael J. Wysocki

author

2010-02-09 13:34 UTC #36 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 87 lines · Rafael J. Wysocki

Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
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(+)

drivers/pci/hotplug/acpiphp_glue.c +2 -0

Index: 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);

Gary Hade

2010-02-09 16:41 UTC #37 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 87 lines · Rafael J. Wysocki

Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-09 16:41 UTC #38 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 87 lines · Rafael J. Wysocki

Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
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?

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

Signature · 6 lines

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

Gary Hade

2010-02-09 17:35 UTC #39 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 104 lines · Gary Hade

Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 3 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-09 17:36 UTC #40 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 104 lines · Gary Hade

Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 3 lines

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

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-09 20:19 UTC #41 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 105 lines · Gary Hade

Quoted 104 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 8 lines

Quoted 3 lines
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(-)

drivers/pci/pci-acpi.c +24 -6

Index: 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);

drivers/pci/hotplug/acpiphp_glue.c +4 -0

Index: 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;
 	}

Gary Hade

2010-02-09 20:58 UTC #42 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 110 lines · Rafael J. Wysocki

Quoted 109 lines · Gary Hade
Quoted 107 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 8 lines

Quoted 4 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-09 20:59 UTC #43 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 110 lines · Rafael J. Wysocki

Quoted 109 lines · Gary Hade
Quoted 107 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 8 lines

Quoted 4 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-09 23:31 UTC #44 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 116 lines · Gary Hade

Quoted 115 lines · Rafael J. Wysocki
Quoted 113 lines · Gary Hade
Quoted 104 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-09 23:32 UTC #45 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 116 lines · Gary Hade

Quoted 115 lines · Rafael J. Wysocki
Quoted 113 lines · Gary Hade
Quoted 104 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
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.

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-10 01:07 UTC #46 lore raw

Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 1 line · Gary Hade

On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:

...

Quoted 6 lines

Quoted 4 lines
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.

Quoted 3 lines

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(-)

drivers/pci/pci-acpi.c +124 ~~-116~~

Index: 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(&notify_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(&notify_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(&notify_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(&notify_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(&notify_obj->entry);
+	kfree(notify_obj);
 
  out:
-	mutex_unlock(&pci_acpi_notifier_mtx);
+	mutex_unlock(&pci_acpi_notify_mtx);
 	return status;
 }

include/acpi/acpi_bus.h +0 -1

Index: 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)

Rafael J. Wysocki

author

2010-02-10 01:11 UTC #47 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 16 lines · Rafael J. Wysocki

Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
The new patch when added to the 2.6.33-rc7 tree that included the original patchset unfortunately did not correct the problem.

Quoted 7 lines

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(-)

drivers/pci/pci-acpi.c +124 ~~-116~~

Index: 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(&notify_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(&notify_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(&notify_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(&notify_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(&notify_obj->entry);
+	kfree(notify_obj);
 
  out:
-	mutex_unlock(&pci_acpi_notifier_mtx);
+	mutex_unlock(&pci_acpi_notify_mtx);
 	return status;
 }

include/acpi/acpi_bus.h +0 -1

Index: 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)

Gary Hade

2010-02-10 17:48 UTC #48 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 19 lines · Rafael J. Wysocki

Quoted 18 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
The new patch when added to the 2.6.33-rc7 tree that included the original patchset unfortunately did not correct the problem.
Bad.

Quoted 8 lines

Quoted 5 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-10 17:48 UTC #49 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 19 lines · Rafael J. Wysocki

Quoted 18 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
The new patch when added to the 2.6.33-rc7 tree that included the original patchset unfortunately did not correct the problem.
Bad.

Quoted 8 lines

Quoted 5 lines
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.

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-10 18:00 UTC #50 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 26 lines · Gary Hade

Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 4 lines

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

Gary Hade

2010-02-10 20:38 UTC #51 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 43 lines · Rafael J. Wysocki

Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-10 20:39 UTC #52 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 43 lines · Rafael J. Wysocki

Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

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.

Now I suppose you want me to start reverting 1/9 through 7/9 in reverse order to find the culprit. :)

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-10 21:41 UTC #53 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 50 lines · Gary Hade

Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 8 lines

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

Gary Hade

2010-02-10 22:13 UTC #54 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 57 lines · Rafael J. Wysocki

Quoted 56 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 6 lines

Quoted 2 lines
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

Signature · 6 lines

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

Gary Hade

2010-02-10 22:13 UTC #55 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 57 lines · Rafael J. Wysocki

Quoted 56 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-10 22:57 UTC #56 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 61 lines · Gary Hade

Quoted 60 lines · Rafael J. Wysocki
Quoted 58 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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. :)

Quoted 8 lines

Quoted 3 lines
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

Gary Hade

2010-02-10 23:04 UTC #57 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 66 lines · Rafael J. Wysocki

Quoted 65 lines · Gary Hade
Quoted 63 lines · Rafael J. Wysocki
Quoted 50 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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.

Quoted 6 lines

Quoted 4 lines
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!

Quoted 2 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-10 23:04 UTC #58 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 66 lines · Rafael J. Wysocki

Quoted 65 lines · Gary Hade
Quoted 63 lines · Rafael J. Wysocki
Quoted 50 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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.

Quoted 6 lines

Quoted 4 lines
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!

Quoted 2 lines

What's your kernel command line, BTW?

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-10 23:25 UTC #59 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 2 lines · Gary Hade

Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:

...

Quoted 5 lines

Quoted 5 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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

Rafael J. Wysocki

author

2010-02-11 00:56 UTC #60 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 14 lines · Rafael J. Wysocki

Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
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!
Quoted 1 line

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
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(+)

drivers/acpi/acpica/evxface.c +14 -0

Index: 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);

drivers/acpi/acpica/evgpeblk.c +4 -0

Index: 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));

Gary Hade

2010-02-11 02:07 UTC #61 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 17 lines · Rafael J. Wysocki

Quoted 16 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 12 lines
Quoted 6 lines
Quoted 4 lines
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!
Quoted 2 lines
What's your kernel command line, BTW?

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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

Signature · 6 lines

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

Gary Hade

2010-02-11 02:07 UTC #62 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 17 lines · Rafael J. Wysocki

Quoted 16 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 12 lines
Quoted 6 lines
Quoted 4 lines
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!
Quoted 2 lines
What's your kernel command line, BTW?

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-11 13:26 UTC #63 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 23 lines · Gary Hade

Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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(-)

drivers/acpi/acpica/evgpeblk.c +22 ~~-14~~

Index: 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);
-			}
 		}
 	}

Gary Hade

2010-02-11 18:29 UTC #64 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 33 lines · Rafael J. Wysocki

Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.

Quoted 8 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-11 18:29 UTC #65 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 33 lines · Rafael J. Wysocki

Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.

Quoted 8 lines

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

Signature · 6 lines

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

Bjorn Helgaas

2010-02-11 18:33 UTC #66 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 43 lines · Gary Hade

Quoted 33 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 8 lines
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.

Quoted 6 lines

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

Bjorn Helgaas

2010-02-11 18:33 UTC #67 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 43 lines · Gary Hade

Quoted 33 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 8 lines
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.

Quoted 6 lines

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

Rafael J. Wysocki

author

2010-02-11 20:31 UTC #68 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 39 lines · Gary Hade

Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.

Quoted 6 lines

Quoted 3 lines
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!

Quoted 1 line

Now when you have patch(es) ready for Jesse's linux-next branch

Well, not quite. I had to rework them in the meantime. ;-)

Quoted 2 lines

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]>

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(-)

drivers/acpi/acpica/aclocal.h +2 -0

Index: 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 */

drivers/acpi/acpica/evxfevnt.c +65 ~~-25~~

165 lines not on this page · raw message

include/acpi/acpixf.h +3 -3

Index: 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);

drivers/acpi/button.c +9 -4

Index: 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);

drivers/acpi/ec.c +8 -6

Index: 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;
 }

drivers/acpi/sleep.c +12 -3

Index: 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");

drivers/acpi/wakeup.c +27 ~~-54~~

127 lines not on this page · raw message

drivers/acpi/acpica/acevents.h +1 -5

Index: 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);

drivers/acpi/acpica/evgpe.c +16 ~~-137~~

196 lines not on this page · raw message

drivers/acpi/acpica/evgpeblk.c +33 ~~-54~~

150 lines not on this page · raw message

drivers/acpi/acpica/evxface.c +0 ~~-14~~

Index: 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);

include/acpi/actypes.h +10 ~~-18~~

Index: 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
  */

drivers/acpi/system.c +2 -2

Index: 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);

Rafael J. Wysocki

author

2010-02-11 20:39 UTC #69 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

On Thursday 11 February 2010, Rafael J. Wysocki wrote:
...

Quoted 3 lines

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.

Quoted 1 line

It is a replacement for [4-6/9] with the last fix included.

Rafael

Rafael J. Wysocki

author

2010-02-11 20:40 UTC #70 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

On Thursday 11 February 2010, Rafael J. Wysocki wrote:
...

Quoted 3 lines

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.

Quoted 1 line

It is a replacement for [4-6/9] with the last fix included.

Rafael

Gary Hade

2010-02-11 21:56 UTC #71 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 49 lines · Rafael J. Wysocki

Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!

Quoted 8 lines

Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
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. :)

Quoted 3 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-11 21:56 UTC #72 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 49 lines · Rafael J. Wysocki

Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!

Quoted 8 lines

Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
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. :)

Quoted 3 lines

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

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-11 22:20 UTC #73 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 59 lines · Gary Hade

Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?

Quoted 7 lines

Oh, I guess so. :)
Quoted 3 lines
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)

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(-)

drivers/pci/pci.h +7 -0

Index: 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);

drivers/pci/pci-acpi.c +351 -0

371 lines not on this page · raw message

drivers/pci/pci.c +67 -0

91 lines not on this page · raw message

include/linux/pci-acpi.h +10 -0

Index: 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;

drivers/acpi/pci_bind.c +13 -1

Index: 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.

drivers/pci/hotplug/acpiphp_glue.c +9 ~~-14~~

Index: 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 ;

include/linux/pci.h +1 -0

Index: 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);

include/acpi/acpi_bus.h +3 -0

Index: 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);

drivers/acpi/pci_root.c +8 -0

Index: 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;
 }

drivers/acpi/internal.h +0 -2

Index: 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;

Gary Hade

2010-02-12 01:55 UTC #74 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 68 lines · Rafael J. Wysocki

Quoted 59 lines · Gary Hade
Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?
Quoted 7 lines
Oh, I guess so. :)
Quoted 3 lines
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.

Quoted 8 lines

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

Signature · 51 lines

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

Gary Hade

2010-02-12 01:55 UTC #75 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 68 lines · Rafael J. Wysocki

Quoted 59 lines · Gary Hade
Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?
Quoted 7 lines
Oh, I guess so. :)
Quoted 3 lines
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.

Quoted 8 lines

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.

I don't think I will be able to try to characterize this better or test any more patches until Monday.

Gary

Signature · 51 lines

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

Rafael J. Wysocki

author

2010-02-12 11:19 UTC #76 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 85 lines · Gary Hade

Quoted 68 lines · Rafael J. Wysocki
Quoted 59 lines · Gary Hade
Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?
Quoted 7 lines
Oh, I guess so. :)
Quoted 3 lines
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.
Quoted 8 lines
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.

Quoted 8 lines

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

Rafael J. Wysocki

author

2010-02-13 00:19 UTC #77 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 1 line · Rafael J. Wysocki

On Friday 12 February 2010, Gary Hade wrote:

...

Quoted 13 lines

Quoted 13 lines
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.

Quoted 7 lines

Quoted 2 lines
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

Gary Hade

2010-02-13 01:27 UTC #78 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 31 lines · Rafael J. Wysocki

Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 13 lines
Quoted 13 lines
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 6 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-13 01:27 UTC #79 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 31 lines · Rafael J. Wysocki

Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 13 lines
Quoted 13 lines
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 6 lines

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.

Gary

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-14 13:51 UTC #80 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 3 lines · Gary Hade

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:

...

Quoted 7 lines

Quoted 7 lines
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.

Quoted 8 lines

Quoted 6 lines
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!

Quoted 5 lines

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(-)

drivers/acpi/acpica/acobject.h +2 -0

Index: 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 {

drivers/acpi/acpica/evxface.c +139 ~~-36~~

232 lines not on this page · raw message

drivers/acpi/acpica/evmisc.c +9 -3

Index: 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 */

Gary Hade

2010-02-15 19:22 UTC #81 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 29 lines · Rafael J. Wysocki

Quoted 3 lines · Gary Hade
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 6 lines
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!
Quoted 5 lines
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.

Quoted 3 lines

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. :)

Quoted 5 lines

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.

Quoted 4 lines

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

Signature · 6 lines

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

Gary Hade

2010-02-15 19:23 UTC #82 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 29 lines · Rafael J. Wysocki

Quoted 3 lines · Gary Hade
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 6 lines
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!
Quoted 5 lines
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.

Quoted 3 lines

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. :)

Quoted 5 lines

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.

Quoted 4 lines

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

Signature · 6 lines

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

Rafael J. Wysocki

author

2010-02-15 21:42 UTC #83 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

Quoted 46 lines · Gary Hade

Quoted 29 lines · Rafael J. Wysocki
Quoted 3 lines · Gary Hade
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 6 lines
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!
Quoted 5 lines
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.
Quoted 3 lines
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. :)
Quoted 5 lines
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.
Quoted 1 line

Quoted 5 lines

Quoted 3 lines
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

Rafael J. Wysocki

author

2010-02-15 21:42 UTC #84 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 46 lines · Gary Hade

Quoted 29 lines · Rafael J. Wysocki
Quoted 3 lines · Gary Hade
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:
...
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 6 lines
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!
Quoted 5 lines
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.
Quoted 3 lines
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. :)
Quoted 5 lines
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.
Quoted 1 line

Quoted 5 lines

Quoted 3 lines
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

Rafael J. Wysocki

author

2010-02-14 13:51 UTC #85 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 3 lines · Gary Hade

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Rafael J. Wysocki
On Friday 12 February 2010, Gary Hade wrote:

...

Quoted 7 lines

Quoted 7 lines
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.

Quoted 8 lines

Quoted 6 lines
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!

Quoted 5 lines

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.

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

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(-)

drivers/acpi/acpica/acobject.h +2 -0

Index: 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 {

drivers/acpi/acpica/evxface.c +139 ~~-36~~

232 lines not on this page · raw message

drivers/acpi/acpica/evmisc.c +9 -3

Index: 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 */

Rafael J. Wysocki

author

2010-02-13 00:20 UTC #86 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 1 line · Rafael J. Wysocki

On Friday 12 February 2010, Gary Hade wrote:

...

Quoted 13 lines

Quoted 13 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

I guess there are similar problems on the hot remove notification path.

Rafael

Rafael J. Wysocki

author

2010-02-12 11:19 UTC #87 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 85 lines · Gary Hade

Quoted 68 lines · Rafael J. Wysocki
Quoted 59 lines · Gary Hade
Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?
Quoted 7 lines
Oh, I guess so. :)
Quoted 3 lines
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.
Quoted 8 lines
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.

Quoted 8 lines

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

Rafael J. Wysocki

author

2010-02-11 22:21 UTC #88 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 59 lines · Gary Hade

Quoted 49 lines · Rafael J. Wysocki
Quoted 39 lines · Gary Hade
Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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!
Quoted 8 lines
Quoted 1 line
Now when you have patch(es) ready for Jesse's linux-next branch
Well, not quite. I had to rework them in the meantime. ;-)
Quoted 2 lines
I can get back to my original mission of checking out Bjorn's _CRS enablement changes.
May I still ask you to test something?

Quoted 7 lines

Oh, I guess so. :)
Quoted 3 lines
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)

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(-)

drivers/pci/pci.h +7 -0

Index: 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);

drivers/pci/pci-acpi.c +351 -0

371 lines not on this page · raw message

drivers/pci/pci.c +67 -0

91 lines not on this page · raw message

include/linux/pci-acpi.h +10 -0

Index: 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;

drivers/acpi/pci_bind.c +13 -1

Index: 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.

drivers/pci/hotplug/acpiphp_glue.c +9 ~~-14~~

Index: 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 ;

include/linux/pci.h +1 -0

Index: 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);

include/acpi/acpi_bus.h +3 -0

Index: 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);

drivers/acpi/pci_root.c +8 -0

Index: 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;
 }

drivers/acpi/internal.h +0 -2

Index: 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;

Rafael J. Wysocki

author

2010-02-11 20:32 UTC #89 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 39 lines · Gary Hade

Quoted 38 lines · Rafael J. Wysocki
Quoted 23 lines · Gary Hade
Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.

Quoted 6 lines

Quoted 3 lines
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!

Quoted 1 line

Now when you have patch(es) ready for Jesse's linux-next branch

Well, not quite. I had to rework them in the meantime. ;-)

Quoted 2 lines

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]>

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.

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(-)

drivers/acpi/acpica/aclocal.h +2 -0

Index: 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 */

drivers/acpi/acpica/evxfevnt.c +65 ~~-25~~

165 lines not on this page · raw message

include/acpi/acpixf.h +3 -3

Index: 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);

drivers/acpi/button.c +9 -4

Index: 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);

drivers/acpi/ec.c +8 -6

Index: 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;
 }

drivers/acpi/sleep.c +12 -3

Index: 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");

drivers/acpi/wakeup.c +27 ~~-54~~

127 lines not on this page · raw message

drivers/acpi/acpica/acevents.h +1 -5

Index: 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);

drivers/acpi/acpica/evgpe.c +16 ~~-137~~

196 lines not on this page · raw message

drivers/acpi/acpica/evgpeblk.c +33 ~~-54~~

150 lines not on this page · raw message

drivers/acpi/acpica/evxface.c +0 ~~-14~~

Index: 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);

include/acpi/actypes.h +10 ~~-18~~

Index: 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
  */

drivers/acpi/system.c +2 -2

Index: 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);

Rafael J. Wysocki

author

2010-02-11 13:27 UTC #90 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 23 lines · Gary Hade

Quoted 22 lines · Rafael J. Wysocki
Quoted 21 lines · Rafael J. Wysocki
Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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.

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(-)

drivers/acpi/acpica/evgpeblk.c +22 ~~-14~~

Index: 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);
-			}
 		}
 	}

Rafael J. Wysocki

author

2010-02-11 00:56 UTC #91 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 14 lines · Rafael J. Wysocki

Quoted 2 lines · Gary Hade
Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:
...
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
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!
Quoted 1 line

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
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(+)

drivers/acpi/acpica/evxface.c +14 -0

Index: 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);

drivers/acpi/acpica/evgpeblk.c +4 -0

Index: 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));

Rafael J. Wysocki

author

2010-02-10 23:25 UTC #92 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 2 lines · Gary Hade

Quoted 1 line · Rafael J. Wysocki
On Wednesday 10 February 2010, Gary Hade wrote:

...

Quoted 5 lines

Quoted 5 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 1 line
Thanks for verifying, I've already started to look for bugs in it.
Thanks!
Quoted 2 lines
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

Rafael J. Wysocki

author

2010-02-10 22:58 UTC #93 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 61 lines · Gary Hade

Quoted 60 lines · Rafael J. Wysocki
Quoted 58 lines · Gary Hade
Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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. :)

Quoted 8 lines

Quoted 3 lines
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

Rafael J. Wysocki

author

2010-02-10 21:42 UTC #94 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 50 lines · Gary Hade

Quoted 43 lines · Rafael J. Wysocki
Quoted 26 lines · Gary Hade
Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.

Quoted 8 lines

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

Rafael J. Wysocki

author

2010-02-10 18:00 UTC #95 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 26 lines · Gary Hade

Quoted 25 lines · Rafael J. Wysocki
Quoted 23 lines · Rafael J. Wysocki
Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 4 lines

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

Rafael J. Wysocki

author

2010-02-10 01:12 UTC #96 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 16 lines · Rafael J. Wysocki

Quoted 1 line · Gary Hade
On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
Quoted 6 lines
Quoted 4 lines
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.
Quoted 3 lines
The new patch when added to the 2.6.33-rc7 tree that included the original patchset unfortunately did not correct the problem.

Quoted 7 lines

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(-)

drivers/pci/pci-acpi.c +124 ~~-116~~

Index: 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(&notify_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(&notify_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(&notify_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(&notify_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(&notify_obj->entry);
+	kfree(notify_obj);
 
  out:
-	mutex_unlock(&pci_acpi_notifier_mtx);
+	mutex_unlock(&pci_acpi_notify_mtx);
 	return status;
 }

include/acpi/acpi_bus.h +0 -1

Index: 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)

Rafael J. Wysocki

author

2010-02-10 01:07 UTC #97 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 1 line · Gary Hade

On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:

...

Quoted 6 lines

Quoted 4 lines
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.

Quoted 3 lines

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(-)

drivers/pci/pci-acpi.c +124 ~~-116~~

Index: 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(&notify_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(&notify_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(&notify_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(&notify_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(&notify_obj->entry);
+	kfree(notify_obj);
 
  out:
-	mutex_unlock(&pci_acpi_notifier_mtx);
+	mutex_unlock(&pci_acpi_notify_mtx);
 	return status;
 }

include/acpi/acpi_bus.h +0 -1

Index: 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)

Rafael J. Wysocki

author

2010-02-09 20:19 UTC #98 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 105 lines · Gary Hade

Quoted 104 lines · Gary Hade
Quoted 87 lines · Rafael J. Wysocki
Quoted 86 lines · Gary Hade
Quoted 84 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 8 lines

Quoted 3 lines
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(-)

drivers/pci/pci-acpi.c +24 -6

Index: 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);

drivers/pci/hotplug/acpiphp_glue.c +4 -0

Index: 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;
 	}

Rafael J. Wysocki

author

2010-02-09 12:48 UTC #99 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 86 lines · Gary Hade

Quoted 80 lines · Gary Hade
Quoted 41 lines · Rafael J. Wysocki
Quoted 40 lines · Rafael J. Wysocki
Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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!
Quoted 8 lines
Quoted 4 lines
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
Quoted 4 lines
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.

Quoted 6 lines

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

Rafael J. Wysocki

author

2010-02-08 21:30 UTC #100 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Rafael J. Wysocki

Quoted 38 lines · Rafael J. Wysocki

Quoted 29 lines · Gary Hade
Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.
Quoted 7 lines
Quoted 4 lines
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.

Quoted 6 lines

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(-)

drivers/pci/pci-acpi.c +24 -6

Index: 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);

Rafael J. Wysocki

author

2010-02-08 19:17 UTC #101 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Gary Hade

Quoted 29 lines · Gary Hade

Quoted 28 lines · Rafael J. Wysocki
Quoted 26 lines · Bjorn Helgaas
Quoted 10 lines · Rafael J. Wysocki
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.

Quoted 7 lines

Quoted 4 lines
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

Rafael J. Wysocki

author

2010-02-06 20:11 UTC #102 lore raw

Re: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7)

In reply to Bjorn Helgaas

Quoted 23 lines · Bjorn Helgaas

Quoted 10 lines · Rafael J. Wysocki
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

Quoted 3 lines

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

Rafael J. Wysocki

author

2010-01-10 14:02 UTC #103 lore raw

PATCH 9/9 PCI PM: Run-time callbacks for PCI bus type (rev. 2)

In reply to Rafael J. Wysocki

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(-)

kernel/power/Kconfig +5 -0

Index: 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

drivers/pci/pci-driver.c +100 -5

154 lines not on this page · raw message

drivers/pci/pci.c +37 -6

89 lines not on this page · raw message

include/linux/pci.h +8 -1

Index: 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

drivers/pci/pci.h +1 -0

Index: 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);

Rafael J. Wysocki

author

2010-01-10 14:05 UTC #104 lore raw

PATCH 9/9 PCI PM: Run-time callbacks for PCI bus type (rev. 2)

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

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(-)

kernel/power/Kconfig +5 -0

Index: 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

drivers/pci/pci-driver.c +100 -5

154 lines not on this page · raw message

drivers/pci/pci.c +37 -6

89 lines not on this page · raw message

include/linux/pci.h +8 -1

Index: 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

drivers/pci/pci.h +1 -0

Index: 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);