- 16 Jul, 2014 8 commits
-
-
Bjorn Helgaas authored
Merge branches 'pci/host-generic', 'pci/host-mvebu', 'pci/host-rcar', 'pci/host-tegra', 'pci/msi', 'pci/misc', 'pci/resource' and 'pci/virtualization' into next * pci/host-generic: PCI: generic: Fix GPL v2 license string typo * pci/host-mvebu: PCI: mvebu: Fix GPL v2 license string typo * pci/host-rcar: PCI: rcar: Fix GPL v2 license string typo * pci/host-tegra: PCI: tegra: Fix GPL v2 license string typo * pci/msi: PCI/MSI: Use irq_get_msi_desc() to simplify code PCI/MSI: Remove unused list access in __pci_restore_msix_state() PCI/MSI: Retrieve first MSI IRQ from msi_desc rather than pci_dev PCI/MSI: Remove unused function msi_remove_pci_irq_vectors() PCI/MSI: Add msi_setup_entry() to clean up MSI initialization * pci/misc: PCI: Configure ASPM when enabling device x86: don't exclude low BIOS area when allocating address space for non-PCI cards PCI: Add include guard to include/linux/pci_ids.h x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() * pci/resource: PCI: Tidy resource assignment messages PCI: Return conventional error values from pci_revert_fw_address() PCI: Cleanup control flow PCI: Support BAR sizes up to 128GB PCI: Keep original resource if we fail to expand it * pci/virtualization: powerpc/pci: Remove duplicate logic PCI: Make resetting secondary bus logic common
-
Yijing Wang authored
Use irq_get_msi_desc() to get MSI IRQ related msi_desc directly instead of searching the dev->msi_list. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
In __pci_restore_msix_state(), we get the first element from msi_list, but we never use it. Remove this useless code. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
Retrieve the first MSI IRQ to compute the MSI index from struct msi_desc rather than the struct pci_dev to avoid an additional memory access. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
msi_remove_pci_irq_vectors() is unused, so remove it. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
Move MSI entry stuff to a new function, msi_setup_entry(), to simplify msi_capability_init() as MSI-X does. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Vidya Sagar authored
We can't do ASPM configuration at enumeration-time because enabling it makes some defective hardware unresponsive, even if ASPM is disabled later (see 41cd766b ("PCI: Don't enable aspm before drivers have had a chance to veto it"). Therefore, we have to do it after a driver claims the device. We previously configured ASPM in pci_set_power_state(), but that's not a very good place because it's not really related to setting the PCI device power state, and doing it there means: - We incorrectly skipped ASPM config when setting a device that's already in D0 to D0. - We unnecessarily configured ASPM when setting a device to a low-power state (the ASPM feature only applies when the device is in D0). - We unnecessarily configured ASPM when called from a .resume() method (ASPM configuration needs to be restored during resume, but pci_restore_pcie_state() should already do this). Move ASPM configuration from pci_set_power_state() to do_pci_enable_device() so we do it when a driver enables a device. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621 Fixes: db288c9c ("PCI / PM: restore the original behavior of pci_set_power_state()") Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Vidya Sagar <sagar.tv@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.6+
-
Christoph Schulz authored
Commit 30919b0b ("x86: avoid low BIOS area when allocating address space") moved the test for resource allocations that fall within the first 1MB of address space from the PCI-specific path to a generic path, such that all resource allocations will avoid this area. However, this breaks ISA cards which need to allocate a memory region within the first 1MB. An example is the i82365 PCMCIA controller and derivatives like the Ricoh RF5C296/396 which map part of the PCMCIA socket memory address space into the first 1MB of system memory address space. They do not work anymore as no usable memory region exists due to this change: Intel ISA PCIC probe: Ricoh RF5C296/396 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (scanned) = 3,4,5,9,10 status change on irq 10 pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: clean. pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff pcmcia_socket pcmcia_socket1: cs: memory probe 0x0d0000-0x0dffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0e0000-0x0effff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: clean. pcmcia_socket pcmcia_socket1: cs: memory probe 0x0cc000-0x0effff: excluding 0xe0000-0xeffff pcmcia_socket pcmcia_socket1: cs: unable to map card memory! If filtering out the first 1MB is reverted, everything works as expected. Tested-by: Robert Resch <fli4l@robert.reschpara.de> Signed-off-by: Christoph Schulz <develop@kristov.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v2.6.37+
-
- 15 Jul, 2014 4 commits
-
-
Bjorn Helgaas authored
Per license_is_gpl_compatible(), the MODULE_LICENSE() string for GPL v2 is "GPL v2", not "GPLv2". Use "GPL v2" so this module doesn't taint the kernel. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Will Deacon <will.deacon@arm.com>
-
Bjorn Helgaas authored
Per license_is_gpl_compatible(), the MODULE_LICENSE() string for GPL v2 is "GPL v2", not "GPLv2". Use "GPL v2" so this module doesn't taint the kernel. Based-on-work-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Thierry Reding authored
Per license_is_gpl_compatible(), the MODULE_LICENSE() string for GPL v2 is "GPL v2", not "GPLv2". Use "GPL v2" so this module doesn't taint the kernel. [bhelgaas: changelog] Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jingoo Han <jg1.han@samsung.com>
-
Thierry Reding authored
Per license_is_gpl_compatible(), the MODULE_LICENSE() string for GPL v2 is "GPL v2", not "GPLv2". Use "GPL v2" so this module doesn't taint the kernel. [bhelgaas: changelog] Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
- 10 Jul, 2014 2 commits
-
-
Rasmus Villemoes authored
Adding an include guard frees the preprocessor from reparsing over 2600 #defines in the cases where pci_ids.h is somehow included more than once. This gives a tiny-but-measurable performance improvement when compiling such files. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bruno Prémont authored
Commit b4aa0163 ("efifb: Implement vga_default_device() (v2)") added efifb vga_default_device() so EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such as MacBookAir2,1. Xorg detects the GPU and finds the DRI device but then bails out with "no devices detected". Note: When vga_default_device() is set boot_vga PCI sysfs attribute reflects its state. When unset this attribute is 1 whenever IORESOURCE_ROM_SHADOW flag is set. With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete while having native drivers for the GPU also makes selecting sysfb/efifb optional. Remove the efifb implementation of vga_default_device() and initialize vgaarb's vga_default_device() with the PCI GPU that matches boot screen_info in pci_fixup_video(). [bhelgaas: remove unused "dev" in efifb_setup()] Fixes: b4aa0163 ("efifb: Implement vga_default_device() (v2)") Tested-by: Anibal Francisco Martinez Cortina <linuxkid.zeuz@gmail.com> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Matthew Garrett <matthew.garrett@nebula.com> CC: stable@vger.kernel.org # v3.5+
-
- 09 Jul, 2014 1 commit
-
-
Bjorn Helgaas authored
* pci/host-rcar: PCI: rcar: Remove rcar_pcie_setup_window() resource argument PCI: rcar: Cleanup style and formatting PCI: rcar: Use correct initial HW settings PCI: rcar: Remove redundant config accessor register number checks * pci/hotplug: PCI: cpqphp: Remove unnecessary null test before debugfs_remove() PCI: pciehp: Clear Data Link Layer State Changed during init PCI: pciehp: Remove struct controller.no_cmd_complete PCI: pciehp: Remove assumptions about which commands cause completion events PCI: pciehp: Compute timeout from hotplug command start time PCI: pciehp: Wait for hotplug command completion lazily PCI: pciehp: Make pcie_wait_cmd() self-contained PCI: Prevent NULL dereference during pciehp probe * pci/iommu: PCI: Add bridge DMA alias quirk for Intel 82801 bridge * pci/misc: ACPI / PCI: Fix sysfs acpi_index and label errors PCI/portdrv: Remove warning about invalid IRQ for hot-added PCIe ports * pci/msi: PCI/MSI: Cache Multiple Message Capable in struct msi_desc PCI/MSI: Remove unused msi_enabled_mask() PCI/MSI: Add internal msix_clear_and_set_ctrl() function
-
- 08 Jul, 2014 4 commits
-
-
Bjorn Helgaas authored
Print messages about failures in pci_assign_resource(). We can drop the "by-hand" message from _pci_assign_resource() because %pR now prints the size rather than the address if the resource hasn't been assigned. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Previously we returned zero for success or 1 for failure. This changes that so we return zero for success or a negative errno for failure. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Return errors immediately so the straightline path is the normal, no-error path. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Increase the maximum BAR size from 8GB to 128GB. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 07 Jul, 2014 2 commits
-
-
Fabian Frederick authored
Fix checkpatch warning: "WARNING: debugfs_remove(NULL) is safe this check is probably not required" Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Ryan Desfosses <ryan@desfo.org>
-
Myron Stowe authored
During PCIe hot-plug initialization - pciehp_probe() - data structures related to slot capabilities are set up. As part of this set up, ISRs are put in place to handle slot events and all event bits are cleared out. This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC) Slot Status bit to the event bits that are cleared out during initialization. If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices that it's set and interprets it as a new Link Up event, which results in spurious messages: pciehp 0000:82:04.0:pcie24: slot(4): Link Up event pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00 Prior to e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal"), pciehp ignored DLLSC. Reference: PCI-SIG. PCI Express Base Specification Revision 4.0 Version 0.3 (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah). [bhelgaas: add e48f1b67 ref and stable tag] Fixes: e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal") Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+
-
- 05 Jul, 2014 6 commits
-
-
Alex Williamson authored
This bridge sometimes shows up as a root complex device and sometimes as a discrete PCIe-to-PCI bridge. Testing indicates that in the latter case, we need to enable the PCIe bridge DMA alias quirk. Reported-by: Milos Kaurin <milos.kaurin@gmail.com> Tested-by: Milos Kaurin <milos.kaurin@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Phil Edworthy authored
rcar_pcie_setup_window() took both the window number and the resource, which was redundant because we can look up the resource from the window number. Remove the "res" argument. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
-
Phil Edworthy authored
This patch just makes symbol and function name changes to avoid potential conflicts, along with minor formatting changes. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
-
Phil Edworthy authored
Although the R-Car PCIe driver works as it is, there are a number of incorrect settings that this patch corrects. It corrects: - enabling the PCI Express Extended Cap ID. - setting Data Link Layer Link Active Reporting Capable. - terminating list of capabilities. It also removes enabling the MAC data scrambling as this is the default HW setting, and removes incorrect code to enable slave bus mastering as this is done by the PCI core. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
-
Sergei Shtylyov authored
The PCI core will have already checked the configuration register address before calling the {read|write}() methods; so don't check it again in these methods. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Phil Edworthy <phil.edworthy@renesas.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
-
Rajat Jain authored
"no_cmd_complete" is only used once, and it duplicates read-only information we already have in the cached Slot Capabilities value. Remove the field and use the existing macro NO_CMD_CMPL() instead. [bhelgaas: changelog] Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 04 Jul, 2014 1 commit
-
-
Guo Chao authored
If we have space assigned to a resource, we try to expand the resource (e.g., to accommodate SR-IOV resources), and the expansion attempt fails, we should keep the original assignment. After bd064f0a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them"), we left the resource marked IORESOURCE_UNSET when the expansion failed, even if it had originally been set. That caused errors like this: pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit pref] not assigned pci 0003:00:00.0: Error enabling bridge (-22), continuing Fix this by restoring the original flags when reassignment fails. [bhelgaas: reworked to simplify, changelog] Fixes: bd064f0a ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them") Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+
-
- 03 Jul, 2014 5 commits
-
-
Yijing Wang authored
The Multiple Message Capable field in the MSI Message Control register indicates how many vectors the device supports. This field is read-only, so cache it in msi_desc to avoid reading it repeatedly. Since we cache the extracted field (not the entire Message Control register), we can use msi_mask() instead of msi_capable_mask(), which is then unused, so remove it. [bhelgaas: fix whitespace, changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
No one uses msi_enabled_mask(); remove the dead code. No functional change. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
Add msix_clear_and_set_ctrl() simplify code. No functional change. [bhelgaas: fix whitespace] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Gavin Shan authored
Since the logic to reset PCI secondary bus by PCI config register PCI_BRIDGE_CTL_BUS_RESET is included in pci_reset_secondary_bus(), we needn't implement another one. Remove the duplicate implementation and call pci_reset_secondary_bus(). Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Gavin Shan authored
Commit d92a208d ("powerpc/pci: Mask linkDown on resetting PCI bus") implemented same logic (resetting PCI secondary bus by bridge's config register PCI_BRIDGE_CTL_BUS_RESET) in PCI core and arch-dependent code. To avoid the duplication, move the logic to pci_reset_secondary_bus(). That commit did not declare the pcibios_reset_secondary_bus() interface in linux/include/pci.h. Add the declaration. No functional change. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 02 Jul, 2014 2 commits
-
-
Simone Gotti authored
Fix errors in handling "device label" _DSM return values. If _DSM returns a Unicode string, the ACPI type is ACPI_TYPE_BUFFER, not ACPI_TYPE_STRING. Fix dsm_label_utf16s_to_utf8s() to convert UTF-16 from acpi_object->buffer instead of acpi_object->string. Prior to v3.14, we accepted Unicode labels (ACPI_TYPE_BUFFER return values). But after 1d0fcef7, we accepted only ASCII (ACPI_TYPE_STRING) (and we incorrectly tried to convert those ASCII labels from UTF-16 to UTF-8). Rejecting Unicode labels made us return -EPERM when reading sysfs "acpi_index" or "label" files, which in turn caused on-board network interfaces on a Dell PowerEdge E420 to be renamed (by udev net_id internal) from eno1/eno2 to enp2s0f0/enp2s0f1. Fix this by accepting either ACPI_TYPE_STRING (and treating it as ASCII) or ACPI_TYPE_BUFFER (and converting from UTF-16 to UTF-8). [bhelgaas: changelog] Fixes: 1d0fcef7 ("ACPI / PCI: replace open-coded _DSM code with helper functions") Signed-off-by: Simone Gotti <simone.gotti@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com> CC: stable@vger.kernel.org # v3.14+
-
Jiang Liu authored
For hot-added PCIe ports on x86 platforms, we always warned about an invalid IRQ, e.g., pci 0000:00:00.0: device [8086:0e0b] has invalid IRQ; check vendor BIOS This was because we check pci_dev->irq before actually allocating the IRQ for the device, which happens in this path: pcie_port_device_register pci_enable_device pci_enable_device_flags do_pci_enable_device pcibios_enable_device (on x86) pcibios_enable_irq This warning message isn't generated for PCIe ports present at boot time because x86 arch code has called acpi_pci_irq_enable() in pci_acpi_init() for each PCI device for safety. [bhelgaas: changelog] Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 17 Jun, 2014 3 commits
-
-
Bjorn Helgaas authored
We use incorrect logic to decide whether a PCIe hotplug controller generates command completion events. 5808639b ("pciehp: fix slow probing") assumed that the Slot Status "Command Completed" bit was set only for commands affecting slot power, indicators, or electromechanical interlock. That assumption is false: per sec. 6.7.3.2 of PCIe spec r3.0, a write targeting any portion of the Slot Control register is a command, and (if command completed events are supported) software must wait for a command to complete before issuing the next command. 5808639b was to fix boot-time timeouts (see bugzilla below) on a Lenovo Thinkpad R61 with an Intel hotplug controller. The controller probably has the Intel CF118 erratum, which means it doesn't report Command Completed unless the Slot Control power, indicator, or interlock bits are changed. This causes a timeout because pciehp always waits for Command Complete (if supported), regardless of which bits are changed. Remove the incorrect logic because the timeouts have been addressed differently by these changes: PCI: pciehp: Wait for hotplug command completion lazily PCI: pciehp: Compute timeout from hotplug command start time Link: https://bugzilla.kernel.org/show_bug.cgi?id=10751 Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
If we issue a hotplug command, go do something else, then come back and wait for the command to complete, we don't have to wait the whole timeout period, because some of it elapsed while we were doing something else. Keep track of the time we issued the command, and wait only until the timeout period from that point has elapsed. For controllers with errata like Intel CF118, we previously timed out before issuing the second hotplug command: At time T1 (during boot): - Write DLLSCE, ABPE, PDCE, etc. to Slot Control At time T2 (hotplug event): - Wait for command completion (CC) in Slot Status - Timeout at T2 + 1 second because CC is never set in Slot Status - Write PCC, PIC, etc. to Slot Control With this change, we wait until T1 + 1 second instead of T2 + 1 second. If the hotplug event is more than 1 second after the boot-time initialization, we won't wait for the timeout at all. We still emit a "Timeout on hotplug command" message if it timed out; we should see this on the first hotplug event on every controller with this erratum, as well as on real errors on controllers without the erratum. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
Previously we issued a hotplug command and waited for it to complete. But there's no need to wait until we're ready to issue the *next* command. The next command will probably be much later, so the first one may have already completed and we may not have to actually wait at all. Because of hardware errata, some controllers generate command completion events for some commands but not others. In the case of Intel CF118 (see spec update reference), the controller indicates command completion only for Slot Control writes that change the value of the following bits: Power Controller Control Power Indicator Control Attention Indicator Control Electromechanical Interlock Control Changes to other bits, e.g., the interrupt enable bits, do not cause the Command Completed bit to be set. Controllers from AMD and Nvidia are reported to have similar errata. These errata cause timeouts when pcie_enable_notification() enables interrupts. Previously that timeout occurred at boot-time. With this change, the timeout occurs later, when we change the state of the slot power, indicators, or interlock. This speeds up boot but causes a timeout at the first hotplug event on the slot. Subsequent events don't timeout because only the first (boot-time) hotplug command updates Slot Control without touching the power/indicator/interlock controls. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
- 16 Jun, 2014 2 commits
-
-
Bjorn Helgaas authored
pcie_wait_cmd() waits for the controller to finish a hotplug command. Move the associated logic (to determine whether waiting is required and whether we're using interrupts or polling) from pcie_write_cmd() to pcie_wait_cmd(). No functional change. Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Andreas Noever authored
pciehp assumes that dev->subordinate exists. But we do not assign a bus if we run out of bus numbers during enumeration. This leads to a NULL dereference in init_slot() (and other places). Change pciehp_probe() to return -ENODEV when no subordinate bus is present. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-