From 73a0e614580fb650846be1e9315f6b7b6069b9cc Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 6 Apr 2010 13:24:08 -0600 Subject: x86/PCI: ignore Consumer/Producer bit in ACPI window descriptions ACPI Address Space Descriptors (used in _CRS) have a Consumer/Producer bit that is supposed to distinguish regions that are consumed directly by a device from those that are forwarded ("produced") by a bridge. But BIOSes have apparently not used this consistently, and Windows seems to ignore it, so I think Linux should ignore it as well. I can't point to any of these supposed broken BIOSes, but since we now rely on _CRS by default, I think it's safer to ignore this bit from the start. Here are details of my experiments with how Windows handles it: https://bugzilla.kernel.org/show_bug.cgi?id=15701 Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index c7b1ebf..334153c 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -71,8 +71,7 @@ resource_to_addr(struct acpi_resource *resource, if (ACPI_SUCCESS(status) && (addr->resource_type == ACPI_MEMORY_RANGE || addr->resource_type == ACPI_IO_RANGE) && - addr->address_length > 0 && - addr->producer_consumer == ACPI_PRODUCER) { + addr->address_length > 0) { return AE_OK; } return AE_ERROR; -- cgit v0.10.2 From 4352aa5bbf1d0080c2dcf904ce1e4be0a1cb5937 Mon Sep 17 00:00:00 2001 From: Alexander Duyck Date: Thu, 25 Mar 2010 13:03:30 -0700 Subject: PCI aerdrv: use correct bit defines and add 2ms delay to aer_root_reset While testing completion timeouts I found that hardware was not recovering. It looks like the hot reset was never being propagated to the endpoint devices on the bus due to the fact that we were clearing the bit too quickly. The documentation I have states that we should be transmitting hot reset TS1s for 2ms. To achieve this I have added a 2ms delay from the time we set the secondary bus reset bit to the time we clear it. In addition I changed the define used for the secondary bus reset bit to match the register define that was being used. Reviewed-by: Hidetoshi Seto Signed-off-by: Alexander Duyck Signed-off-by: Jesse Barnes diff --git a/drivers/pci/pcie/aer/aerdrv.c b/drivers/pci/pcie/aer/aerdrv.c index aa495ad..7a711ee 100644 --- a/drivers/pci/pcie/aer/aerdrv.c +++ b/drivers/pci/pcie/aer/aerdrv.c @@ -244,11 +244,17 @@ static pci_ers_result_t aer_root_reset(struct pci_dev *dev) /* Assert Secondary Bus Reset */ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &p2p_ctrl); - p2p_ctrl |= PCI_CB_BRIDGE_CTL_CB_RESET; + p2p_ctrl |= PCI_BRIDGE_CTL_BUS_RESET; pci_write_config_word(dev, PCI_BRIDGE_CONTROL, p2p_ctrl); + /* + * we should send hot reset message for 2ms to allow it time to + * propogate to all downstream ports + */ + msleep(2); + /* De-assert Secondary Bus Reset */ - p2p_ctrl &= ~PCI_CB_BRIDGE_CTL_CB_RESET; + p2p_ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET; pci_write_config_word(dev, PCI_BRIDGE_CONTROL, p2p_ctrl); /* -- cgit v0.10.2 From 45aa23b4cbd37408678c96cd113241860d3321f6 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Thu, 22 Apr 2010 09:02:43 -0600 Subject: PCI: revert broken device warning This reverts c519a5a7dab2d. That change added a warning about devices that didn't respond correctly when sizing BARs, which helped diagnose broken devices. But the test wasn't specific enough, so it also complained about working devices with zero-size BARs, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=15822 Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 882bd8d..c82548a 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -174,19 +174,14 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, pci_read_config_dword(dev, pos, &sz); pci_write_config_dword(dev, pos, l); - if (!sz) - goto fail; /* BAR not implemented */ - /* * All bits set in sz means the device isn't working properly. - * If it's a memory BAR or a ROM, bit 0 must be clear; if it's - * an io BAR, bit 1 must be clear. + * If the BAR isn't implemented, all bits must be 0. If it's a + * memory BAR or a ROM, bit 0 must be clear; if it's an io BAR, bit + * 1 must be clear. */ - if (sz == 0xffffffff) { - dev_err(&dev->dev, "reg %x: invalid size %#x; broken device?\n", - pos, sz); + if (!sz || sz == 0xffffffff) goto fail; - } /* * I don't know how l can have all bits set. Copied from old code. @@ -249,17 +244,13 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, pos, res); } } else { - u32 size = pci_size(l, sz, mask); + sz = pci_size(l, sz, mask); - if (!size) { - dev_err(&dev->dev, "reg %x: invalid size " - "(l %#x sz %#x mask %#x); broken device?", - pos, l, sz, mask); + if (!sz) goto fail; - } res->start = l; - res->end = l + size; + res->end = l + sz; dev_printk(KERN_DEBUG, &dev->dev, "reg %x: %pR\n", pos, res); } -- cgit v0.10.2 From 66528fdd45b082bf7c74687d72ae08afa4a446f8 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 20 Apr 2010 13:52:41 -0600 Subject: x86/PCI: parse additional host bridge window resource types This adds support for Memory24, Memory32, and Memory32Fixed descriptors in PCI host bridge _CRS. I experimentally determined that Windows (2008 R2) accepts these descriptors and treats them as windows that are forwarded to the PCI bus, e.g., if it finds any PCI devices with BARs outside the windows, it moves them into the windows. I don't know whether any machines actually use these descriptors in PCI host bridge _CRS methods, but if any exist and they're new enough that we automatically turn on "pci=use_crs", they will work with Windows but not with Linux. Here are the details: https://bugzilla.kernel.org/show_bug.cgi?id=15817 Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 334153c..44f83ce 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -66,13 +66,44 @@ resource_to_addr(struct acpi_resource *resource, struct acpi_resource_address64 *addr) { acpi_status status; - - status = acpi_resource_to_address64(resource, addr); - if (ACPI_SUCCESS(status) && - (addr->resource_type == ACPI_MEMORY_RANGE || - addr->resource_type == ACPI_IO_RANGE) && - addr->address_length > 0) { + struct acpi_resource_memory24 *memory24; + struct acpi_resource_memory32 *memory32; + struct acpi_resource_fixed_memory32 *fixed_memory32; + + memset(addr, 0, sizeof(*addr)); + switch (resource->type) { + case ACPI_RESOURCE_TYPE_MEMORY24: + memory24 = &resource->data.memory24; + addr->resource_type = ACPI_MEMORY_RANGE; + addr->minimum = memory24->minimum; + addr->address_length = memory24->address_length; + addr->maximum = addr->minimum + addr->address_length - 1; + return AE_OK; + case ACPI_RESOURCE_TYPE_MEMORY32: + memory32 = &resource->data.memory32; + addr->resource_type = ACPI_MEMORY_RANGE; + addr->minimum = memory32->minimum; + addr->address_length = memory32->address_length; + addr->maximum = addr->minimum + addr->address_length - 1; return AE_OK; + case ACPI_RESOURCE_TYPE_FIXED_MEMORY32: + fixed_memory32 = &resource->data.fixed_memory32; + addr->resource_type = ACPI_MEMORY_RANGE; + addr->minimum = fixed_memory32->address; + addr->address_length = fixed_memory32->address_length; + addr->maximum = addr->minimum + addr->address_length - 1; + return AE_OK; + case ACPI_RESOURCE_TYPE_ADDRESS16: + case ACPI_RESOURCE_TYPE_ADDRESS32: + case ACPI_RESOURCE_TYPE_ADDRESS64: + status = acpi_resource_to_address64(resource, addr); + if (ACPI_SUCCESS(status) && + (addr->resource_type == ACPI_MEMORY_RANGE || + addr->resource_type == ACPI_IO_RANGE) && + addr->address_length > 0) { + return AE_OK; + } + break; } return AE_ERROR; } -- cgit v0.10.2 From cc2893b6af5265baa1d68b17b136cffca9e40cfa Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Thu, 22 Apr 2010 09:30:51 -0400 Subject: PCI: Ensure we re-enable devices on resume If the firmware puts a device back into D0 state at resume time, we'll update its state in resume_noirq and thus skip the platform resume code. Calling that code twice should be safe and we ought to avoid getting to that point anyway, so remove the check and also allow the platform pci code to be called for D0. Fixes USB not being powered after resume on recent Lenovo machines. Acked-by: Alex Chiang Acked-by: Rafael J. Wysocki Signed-off-by: Matthew Garrett Signed-off-by: Jesse Barnes diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 5ea587e..3749912 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -679,7 +679,7 @@ static void __pci_start_power_transition(struct pci_dev *dev, pci_power_t state) */ int __pci_complete_power_transition(struct pci_dev *dev, pci_power_t state) { - return state > PCI_D0 ? + return state >= PCI_D0 ? pci_platform_power_transition(dev, state) : -EINVAL; } EXPORT_SYMBOL_GPL(__pci_complete_power_transition); @@ -716,10 +716,6 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t state) */ return 0; - /* Check if we're already there */ - if (dev->current_state == state) - return 0; - __pci_start_power_transition(dev, state); /* This device is quirked not to be put into D3, so -- cgit v0.10.2