From bbef98ab0f019f1b0c25c1acdf1683c68933d41b Mon Sep 17 00:00:00 2001 From: Ram Pai Date: Sun, 6 Nov 2011 10:33:10 +0800 Subject: PCI: defer enablement of SRIOV BARS All the PCI BARs of a device are enabled when the device is enabled using pci_enable_device(). This unnecessarily enables SRIOV BARs of the device. On some platforms, which do not support SRIOV as yet, the pci_enable_device() fails to enable the device if its SRIOV BARs are not allocated resources correctly. The following patch fixes the above problem. The SRIOV BARs are now enabled when IOV capability of the device is enabled in sriov_enable(). NOTE: Note, there is subtle change in the pci_enable_device() API. Any driver that depends on SRIOV BARS to be enabled in pci_enable_device() can fail. The patch has been touch tested on power and x86 platform. Tested-by: Michael Wang Signed-off-by: Ram Pai Signed-off-by: Jesse Barnes --- drivers/pci/iov.c | 7 +++++++ drivers/pci/pci.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) (limited to 'drivers/pci') diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index b82c155d7b3..1969a3ee305 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -283,6 +283,7 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn) struct resource *res; struct pci_dev *pdev; struct pci_sriov *iov = dev->sriov; + int bars = 0; if (!nr_virtfn) return 0; @@ -307,6 +308,7 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn) nres = 0; for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) { + bars |= (1 << (i + PCI_IOV_RESOURCES)); res = dev->resource + PCI_IOV_RESOURCES + i; if (res->parent) nres++; @@ -324,6 +326,11 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn) return -ENOMEM; } + if (pci_enable_resources(dev, bars)) { + dev_err(&dev->dev, "SR-IOV: IOV BARS not allocated\n"); + return -ENOMEM; + } + if (iov->link != dev->devfn) { pdev = pci_get_slot(dev->bus, iov->link); if (!pdev) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 6f45a73c6e9..4788413f43d 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1126,7 +1126,7 @@ static int __pci_enable_device_flags(struct pci_dev *dev, if (atomic_add_return(1, &dev->enable_cnt) > 1) return 0; /* already enabled */ - for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) + for (i = 0; i < PCI_ROM_RESOURCE; i++) if (dev->resource[i].flags & flags) bars |= (1 << i); -- cgit v1.2.3-70-g09d2 From 8c4519456713628cbb457c77bf06684aace67f69 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Tue, 29 Nov 2011 19:20:23 +0000 Subject: PCI: fix ats compile failure I get this compile failure on parisc: drivers/pci/ats.c: In function 'ats_alloc_one': drivers/pci/ats.c:29: error: implicit declaration of function 'kzalloc' drivers/pci/ats.c:29: warning: assignment makes pointer from integer without a cast drivers/pci/ats.c: In function 'ats_free_one': drivers/pci/ats.c:45: error: implicit declaration of function 'kfree' Because ats.c is missing linux/slab.h as an include. This patch fixes it Signed-off-by: James Bottomley Signed-off-by: Jesse Barnes --- drivers/pci/ats.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/pci') diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index 7ec56fb0bd7..b0dd08e6a9d 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -13,6 +13,7 @@ #include #include #include +#include #include "pci.h" -- cgit v1.2.3-70-g09d2 From 619a5182d1f38a3d629ee48e04fa182ef9170052 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 13 Dec 2011 00:02:28 +0100 Subject: PCI hotplug: Always allow acpiphp to handle non-PCIe bridges Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug) added code that made the acpiphp driver completely ignore PCIe root complexes for which the kernel had been granted control of the native PCIe hotplug feature by the BIOS through _OSC. Unfortunately, however, this was a mistake, because on some systems there were PCI bridges supporting PCI (non-PCIe) hotplug under such root complexes and those bridges should have been handled by acpiphp. For this reason, revert the changes made by the commit mentioned above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c avoid registering hotplug slots for PCIe ports that belong to root complexes with native PCIe hotplug enabled (which means that the BIOS has granted the kernel control of this feature for the given root complex). This is reported to address the original issue fixed by commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a and to work on the system where that commit broke things. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes --- drivers/pci/hotplug/acpiphp_glue.c | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) (limited to 'drivers/pci') diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index fce1c54a0c8..68360d5b494 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -132,6 +132,18 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv) if (!acpi_pci_check_ejectable(pbus, handle) && !is_dock_device(handle)) return AE_OK; + pdev = pbus->self; + if (pdev && pci_is_pcie(pdev)) { + tmp = acpi_find_root_bridge_handle(pdev); + if (tmp) { + struct acpi_pci_root *root = acpi_pci_find_root(tmp); + + if (root && (root->osc_control_set & + OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)) + return AE_OK; + } + } + acpi_evaluate_integer(handle, "_ADR", NULL, &adr); device = (adr >> 16) & 0xffff; function = adr & 0xffff; @@ -459,17 +471,8 @@ static int add_bridge(acpi_handle handle) { acpi_status status; unsigned long long tmp; - struct acpi_pci_root *root; acpi_handle dummy_handle; - /* - * We shouldn't use this bridge if PCIe native hotplug control has been - * granted by the BIOS for it. - */ - root = acpi_pci_find_root(handle); - if (root && (root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)) - return -ENODEV; - /* if the bridge doesn't have _STA, we assume it is always there */ status = acpi_get_handle(handle, "_STA", &dummy_handle); if (ACPI_SUCCESS(status)) { @@ -1385,19 +1388,11 @@ static void handle_hotplug_event_func(acpi_handle handle, u32 type, static acpi_status find_root_bridges(acpi_handle handle, u32 lvl, void *context, void **rv) { - struct acpi_pci_root *root; int *count = (int *)context; if (!acpi_is_root_bridge(handle)) return AE_OK; - root = acpi_pci_find_root(handle); - if (!root) - return AE_OK; - - if (root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL) - return AE_OK; - (*count)++; acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY, handle_hotplug_event_bridge, NULL); -- cgit v1.2.3-70-g09d2 From b51306c63449d7f06ffa689036ba49eb46e898b5 Mon Sep 17 00:00:00 2001 From: Ajaykumar Hotchandani Date: Mon, 12 Dec 2011 13:57:36 +0530 Subject: PCI: Set device power state to PCI_D0 for device without native PM support During test of one IB card with guest VM, found that, msi is not initialized properly. It turns out __write_msi_msg will do nothing if device current_state is not PCI_D0. And, that pci device does not have pm_cap in guest VM. There is an error in setting of power state to PCI_D0 in pci_enable_device(), but error is not returned for this. Following is code flow: pci_enable_device() --> __pci_enable_device_flags() --> do_pci_enable_device() --> pci_set_power_state() --> __pci_start_power_transition() We have following condition inside __pci_start_power_transition(): if (platform_pci_power_manageable(dev)) { error = platform_pci_set_power_state(dev, state); if (!error) pci_update_current_state(dev, state); } else { error = -ENODEV; /* Fall back to PCI_D0 if native PM is not supported */ if (!dev->pm_cap) dev->current_state = PCI_D0; } Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is getting called and that is failing with ENODEV because of following condition: if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp))) return -ENODEV; Because of that, pci_update_current_state() is not getting called. With this patch, if device power state can not be set via platform_pci_set_power_state and that device does not have native pm support, then PCI device power state will be set to PCI_D0. -v2: This also reverts 47e9037ac16637cd7f12b8790ea7ce6680e42168, as it's not needed after this change. Acked-by: "Rafael J. Wysocki" Signed-off-by: Ajaykumar Hotchandani Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes --- drivers/pci/hotplug/acpiphp_glue.c | 1 - drivers/pci/pci.c | 3 +++ 2 files changed, 3 insertions(+), 1 deletion(-) (limited to 'drivers/pci') diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index 68360d5b494..9ddf69e3bbe 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -225,7 +225,6 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv) pdev = pci_get_slot(pbus, PCI_DEVFN(device, function)); if (pdev) { - pdev->current_state = PCI_D0; slot->flags |= (SLOT_ENABLED | SLOT_POWEREDON); pci_dev_put(pdev); } diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 4788413f43d..faccb893770 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -664,6 +664,9 @@ static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state) error = platform_pci_set_power_state(dev, state); if (!error) pci_update_current_state(dev, state); + /* Fall back to PCI_D0 if native PM is not supported */ + if (!dev->pm_cap) + dev->current_state = PCI_D0; } else { error = -ENODEV; /* Fall back to PCI_D0 if native PM is not supported */ -- cgit v1.2.3-70-g09d2 From 497f16f21a04060098c0da6ed522fbcafb90c0db Mon Sep 17 00:00:00 2001 From: Yinghai Lu Date: Sat, 17 Dec 2011 18:33:37 -0800 Subject: pci: Fix hotplug of Express Module with pci bridges I noticed that hotplug of one setup does not work with recent change in pci tree. After checking the bridge conf setup, I noticed that the bridges get assigned but do not get enabled. The reason is the following commit, while simply ignores bridge resources when enabling a pci device: | commit bbef98ab0f019f1b0c25c1acdf1683c68933d41b | Author: Ram Pai | Date: Sun Nov 6 10:33:10 2011 +0800 | | PCI: defer enablement of SRIOV BARS |... | NOTE: Note, there is subtle change in the pci_enable_device() API. Any | driver that depends on SRIOV BARS to be enabled in pci_enable_device() | can fail. Put back bridge resource and ROM resource checking to fix the problem. That should fix regression like BIOS does not assign correct resource to bridge. Discussion can be found at: http://www.spinics.net/lists/linux-pci/msg12874.html Signed-off-by: Yinghai Lu Acked-by: Jesse Barnes Signed-off-by: Linus Torvalds --- drivers/pci/pci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'drivers/pci') diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index faccb893770..6d4a5319148 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1129,7 +1129,11 @@ static int __pci_enable_device_flags(struct pci_dev *dev, if (atomic_add_return(1, &dev->enable_cnt) > 1) return 0; /* already enabled */ - for (i = 0; i < PCI_ROM_RESOURCE; i++) + /* only skip sriov related */ + for (i = 0; i <= PCI_ROM_RESOURCE; i++) + if (dev->resource[i].flags & flags) + bars |= (1 << i); + for (i = PCI_BRIDGE_RESOURCES; i < DEVICE_COUNT_RESOURCE; i++) if (dev->resource[i].flags & flags) bars |= (1 << i); -- cgit v1.2.3-70-g09d2