- 09 Sep, 2009 40 commits
-
-
Hidetoshi Seto authored
Before: drivers/pci/pcie/aer/aer_inject.c total: 4 errors, 4 warnings, 473 lines checked drivers/pci/pcie/aer/aerdrv.c total: 5 errors, 2 warnings, 333 lines checked drivers/pci/pcie/aer/aerdrv.h total: 1 errors, 0 warnings, 139 lines checked drivers/pci/pcie/aer/aerdrv_core.c total: 4 errors, 3 warnings, 872 lines checked drivers/pci/pcie/aer/aerdrv_errprint.c total: 12 errors, 11 warnings, 248 lines checked After: drivers/pci/pcie/aer/aer_inject.c total: 0 errors, 0 warnings, 466 lines checked drivers/pci/pcie/aer/aerdrv.c total: 0 errors, 0 warnings, 335 lines checked drivers/pci/pcie/aer/aerdrv.h total: 0 errors, 0 warnings, 139 lines checked drivers/pci/pcie/aer/aerdrv_core.c total: 0 errors, 0 warnings, 869 lines checked drivers/pci/pcie/aer/aerdrv_errprint.c total: 0 errors, 10 warnings, 247 lines checked Signed-off-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Reviewed-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Tejun Heo authored
Add ids module parameter which allows specifying initial IDs for the pci-stub driver. When built into the kernel, pci-stub is linked before any real pci drivers and by setting up IDs from initialization it can prevent built-in drivers from attaching to specific devices. While at it, make pci_stub_probe() print out about devices it grabbed to weed out "but my controller isn't being probed" bug reports. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Tejun Heo authored
Separate out pci_add_dynid() from store_new_id() and export it so that in-kernel code can add PCI IDs dynamically. As the function will be available regardless of HOTPLUG, put it and pull pci_free_dynids() outside of CONFIG_HOTPLUG. This will be used by pci-stub to initialize initial IDs via module param. While at it, remove bogus get_driver() failure check. Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Reviewed-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Kenji Kaneshige authored
Add support for PCI-E 5.0 GT/s in max_bus_speed and cur_bus_speed. Reviewed-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
Fix typo in PCI-E link speed. Reviewed-by:
-
Kenji Kaneshige authored
The L0s state can be managed separately for each direction (upstream direction and downstream direction) of the link. But in the current implementation, those are mixed up. With this patch, L0s for each direction are managed separately. To maintain three states (upstream direction L0s, downstream L0s and L1), 'aspm_support', 'aspm_enabled', 'aspm_capable', 'aspm_disable' and 'aspm_default' fields in struct pcie_link_state are changed to 3-bit from 2-bit. The 'latency' field is separated to two 'latency_up' and 'latency_dw' fields to maintain exit latencies for each direction of the link. For L0, 'latency_up.l0' and 'latency_dw.l0' are used to configure upstream direction L0s and downstream direction L0s respectively. For L1, larger value of 'latency_up.l1' and 'latency_dw.l1' is considered as L1 exit latency. Acked-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Kenji Kaneshige authored
In the current implementation, ASPM L0s/L1 is disabled for all links in the hierarchy if one of the link doesn't meet latency requirement. But we can partially enable ASPM L0s/L1 on sub-tree in the hierarchy. This patch allows partial L0s/L1 enablement in the hierarchy. And it also reduce the calculation cost of ASPM configuration very much. In the previous implementation, all links were enabled with the same state. With this patch, enabled state for each link is determined simply as follows (the 'requested' is from policy_to_aspm_state()). enabled = requested & (link->aspm_capable & link->aspm_disable) Acked-by: -
Kenji Kaneshige authored
Introduce 'aspm_capable' field to maintain the capable ASPM setting of the link. By the 'aspm_capable', we don't need to recheck latency every time ASPM policy is changed. Each bit in 'aspm_capable' is associated to ASPM state (L0S/L1). The bit is set if the associated ASPM state is supported by the link and it satisfies the latency requirement (i.e. exit latency < endpoint acceptable latency). The 'aspm_capable' is updated when - an endpoint device is added (boot time or hot-plug time) - an endpoint device is removed (hot-unplug time) - PCI power state is changed. Acked-by:
-
Kenji Kaneshige authored
Introduce 'aspm_disable' flag to manage disabled ASPM state more robust way. Acked-by:
-
Kenji Kaneshige authored
Fix possible NULL dereference in pcie_aspm_exit_link_state(). This patch also cleanup some code. Acked-by:
-
Kenji Kaneshige authored
Remove the following check in __pcie_aspm_config_link() because it nerver be true. Acked-by:
-
Kenji Kaneshige authored
We must not clear bits in 'aspm_enabled' using 'aspm_support', or 'aspm_enabled' and 'aspm_default' might be different from the actual state. In addtion, 'aspm_default' should be intialized even if 'aspm_support' is 0. Acked-by:
-
Alexander Duyck authored
This patch adds the most recent additions to the list of 82576 device IDs to the list of devices needing the SR-IOV quirk. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tiago Vignatti authored
Document the new VGA arbiter. Signed-off-by:
Tiago Vignatti <tiago.vignatti@nokia.com> Signed-off-by:
-
Dave Airlie authored
Fix some warnings reported in linux-next + also cleanup some comment errors noticed by Pekka Paalanen. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Mike Mason authored
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch makes changes to EEH to utilize the new bit field. Signed-off-by:
Mike Mason <mmlnx@us.ibm.com> Signed-off-by:
Richard Lary <rlary@us.ibm.com> Signed-off-by:
-
Mike Mason authored
The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates. Signed-off-by:
Linas Vepstas <linasvepstas@gmail.com> Signed-off-by:
-
Mike Mason authored
This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Signed-off-by:
-
Benjamin Herrenschmidt authored
Background: Graphic devices are accessed through ranges in I/O or memory space. While most modern devices allow relocation of such ranges, some "Legacy" VGA devices implemented on PCI will typically have the same "hard-decoded" addresses as they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware Revision 2.1" Section 7, Legacy Devices. The Resource Access Control (RAC) module inside the X server currently does the task of arbitration when more than one legacy device co-exists on the same machine. But the problem happens when these devices are trying to be accessed by different userspace clients (e.g. two server in parallel). Their address assignments conflict. Therefore an arbitration scheme _outside_ of the X server is needed to control the sharing of these resources. This document introduces the operation of the VGA arbiter implemented for Linux kernel. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Hidetoshi Seto authored
Cleanups (nearly based on checkpatch). Before: total: 11 errors, 2 warnings, 0 checks, 842 lines checked After: total: 0 errors, 0 warnings, 0 checks, 842 lines checked v2: fix it's/its mistakes in comment Reviewed-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Move it from the middle of the function to the end. Reviewed-by:
-
Hidetoshi Seto authored
Unify msi_free_irqs() and msix_free_all_irqs(), and rename it to a common void function free_msi_irqs(). And relocate the common function to where the prototype is located now. Reviewed-by:
-
Hidetoshi Seto authored
use list_first_entry() instead of list_entry(). Reviewed-by:
-
Hidetoshi Seto authored
The msi_list never have MSI-X's msi_desc while MSI is enabled, and also it never have MSI's msi_desc while MSI-X is enabled. This patch remove check for MSI-X entry from the pci_disable_msi(), referring that pci_disable_msix() does not have any check for MSI entry. Reviewed-by:
-
Alex Williamson authored
This avoids a "Malformed early option 'iommu'" on boot when trying to use pass-through mode. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Signed-off-by:
-
Dave Jones authored
IDs should generally only be added to pci_ids.h when they're shared across several files in the tree. IDs that are just used by a single driver should be defined in the driver instead. Perhaps documenting this is a good idea to prevent things being moved there, as it still seems to be happening judging from the git log. (based on discussion w/gregkh and others). Acked-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Yinghai Lu authored
We already print it out for pci bridges, so also print it out for pci devices. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Tejun Heo authored
http://bugzilla.kernel.org/show_bug.cgi?id=12542 reports that with the quirk not applied on resume, msi stops working after resuming and mcp78s ahci fails due to IRQ mis-delivery. Apply it on resume too. Signed-off-by:
Nicolas Derive <kalon33@ubuntu.com> Cc: Greg KH <greg@kroah.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andi Kleen authored
Shut off the long standing linux/drivers/pci/search.c:144: warning: 'pci_find_device' is deprecated (declared at linux/drivers/pci/search.c:136) linux/drivers/pci/search.c:144: warning: 'pci_find_device' is deprecated (declared at linux/drivers/pci/search.c:136) warnings that appear on every build when CONFIG_PCI_LEGACY is enabled. gcc warns for the use in EXPORT_SYMBOL I moved these to a separate file and disabled the warning in the Makefile for that file. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Jean Delvare authored
One more form factor for Compaq Evo D510, which needs the same quirk as the other form factors. Apparently there's no hardware monitoring chip on that one, but SPD EEPROMs, so it's still worth unhiding the SMBus. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
Nuzhna Pomoshch <nuzhna_pomoshch@yahoo.com> Signed-off-by:
-
Michael S. Tsirkin authored
Some devices allow an individual function to be reset without affecting other functions in the same device: that's what pci_reset_function does. For devices that have this support, expose reset attribite in sysfs. This is useful e.g. for virtualization, where a qemu userspace process wants to reset the device when the guest is reset, to emulate machine reboot as closely as possible. Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Alex Chiang authored
We cannot simply call acpi_get_pci_dev() on any random ACPI handle and hope that it works, because a PCI root bridge may not have an associated struct pci_dev. This is allowed per the PCI specification, and is referred to as a non-materialized bridge. So, depending on the type of PCI bridge that the handle points to, use the appropriate interface to return the struct pci_bus correctly. Reviewed-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Alex Chiang authored
We can simplify ACPI drivers if we can tell whether a handle is an ACPI PCI root or not. Reviewed-by:
-
Jesse Barnes authored
The current mp_bus_to_node array is initialized only by AMD specific code, since AMD platforms have registers that can be used for determining mode numbers. On new Intel platforms it's necessary to initialize this array as well though, otherwise all PCI node numbers will be 0, when in fact they should be -1 (indicating that I/O isn't tied to any particular node). So move the mp_bus_to_node code into the common PCI code, and initialize it early with a default value of -1. This may be overridden later by arch code (e.g. the AMD code). With this change, PCI consistent memory and other node specific allocations (e.g. skbuff allocs) should occur on the "current" node. If, for performance reasons, applications want to be bound to specific nodes, they should open their devices only after being pinned to the CPU where they'll run, for maximum locality. Acked-by:
Jesse Brandeburg <jesse.brandeburg@gmail.com> Signed-off-by:
-
Jesse Barnes authored
yenta needs this for example. Acked-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Matthew Wilcox authored
Instead of open-coding pci_find_parent_resource and request_resource, just call pci_claim_resource. Signed-off-by:
-
Matthew Wilcox authored
Instead of open-coding pci_find_parent_resource and request_resource, just call pci_claim_resource. Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
