linux-kernel - [PATCH 2/2] ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6623444.enfLAe3lRN@vostro.rjw.lan>
Date:	Tue, 11 Feb 2014 01:18:37 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Linux PCI <linux-pci@...r.kernel.org>
Cc:	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: [PATCH 2/2] ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHP

From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

Currently, ACPIPHP does not add hotplug context to devices that
should be handled by the native PCI hotplug (PCIeHP) code.  The
reason why was because PCIeHP didn't know about the devices'
connections with ACPI and would not clean up things properly
during an eject of an ACPI-backed device, for example.

However, after recent changes that made the ACPI core create struct
acpi_device objects for all namespace nodes regardless of the
underlying devices' status and added PCI rescan-remove locking to
both ACPIPHP and PCIeHP, that concern is not valid any more.
Namely, after those changes PCIeHP need not care about the ACPI
side of things any more and it should be serialized with respect to
ACPIPHP and they won't be running concurrently with each other in
any case.

For this reason, make ACPIPHP to add its hotplug context to
all devices with ACPI companions, even the ones that should be
handled by PCIeHP in principle.  That may work around hotplug
issues on some systems where PCIeHP is supposed to work, but it
doesn't and the ACPI hotplug signaling works instead.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
---
 drivers/pci/hotplug/acpiphp_glue.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===================================================================
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -277,9 +277,6 @@ static acpi_status acpiphp_add_context(a
 	struct pci_dev *pdev = bridge->pci_dev;
 	u32 val;

-	if (pdev && device_is_managed_by_native_pciehp(pdev))
-		return AE_OK;
-
 	status = acpi_evaluate_integer(handle, "_ADR", NULL, &adr);
 	if (ACPI_FAILURE(status)) {
 		if (status != AE_NOT_FOUND)
@@ -338,8 +335,14 @@ static acpi_status acpiphp_add_context(a

 	list_add_tail(&slot->node, &bridge->slots);

-	/* Register slots for ejectable functions only. */
-	if (acpi_pci_check_ejectable(pbus, handle)  || is_dock_device(handle)) {
+	/*
+	 * Expose slots to user space for functions that have _EJ0 or _RMV or
+	 * are located in dock stations.  Do not expose them for devices handled
+	 * by the native PCIe hotplug (PCIeHP), becuase that code is supposed to
+	 * expose slots to user space in those cases.
+	 */
+	if ((acpi_pci_check_ejectable(pbus, handle) || is_dock_device(handle))
+	    && !(pdev && device_is_managed_by_native_pciehp(pdev))) {
 		unsigned long long sun;
 		int retval;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/