- 06 Nov, 2009 5 commits
-
-
Isaku Yamahata authored
This patch fixes the following compilation error introduced by a PCI related features. The change set of 5dd1af9f84c79bedd589db89e71ca733f3bf0ebd moves some xen related definitions from the arch header file (x86/include/asm/xen/hypervisor.h) to the common header file (include/xen/xen.h). So ia64/xen also follows it. In file included from linux-next/include/xen/grant_table.h:41, from linux-next/drivers/block/xen-blkfront.c:48: linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: nested redefinition of 'enum xen_domain_type' linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: redeclaration of 'enum xen_domain_type' linux-next/arch/ia64/include/asm/xen/hypervisor.h:44: error: redeclaration of enumerator 'XEN_NATIVE' linux-next/include/xen/xen.h:5: error: previous definition of 'XEN_NATIVE' was here linux-next/arch/ia64/include/asm/xen/hypervisor.h:45: error: redeclaration of enumerator 'XEN_PV_DOMAIN' linux-next/include/xen/xen.h:6: error: previous definition of 'XEN_PV_DOMAIN' was here linux-next/arch/ia64/include/asm/xen/hypervisor.h:46: error: redeclaration of enumerator 'XEN_HVM_DOMAIN' linux-next/include/xen/xen.h:7: error: previous definition of 'XEN_HVM_DOMAIN' was here Signed-off-by:Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Kenji Kaneshige authored
If firmware doesn't grant over native hotplug control through ACPI _OSC method, we must not evaluate OSHP. Acked-by:
Andrew Patterson <andrew.patterson@hp.com> Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Andreas Herrmann authored
In case of AMD CPU northbridge functions this NUMA information might differ. Here is an example from a 4-socket system. Currently Linux shows root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat numa_node 0 root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat local_cpu* 0-3 00000000,0000000f which is not correct for northbridge functions as the local CPUs are those of the same socket. With this patch and a quirk for AMD CPU NB functions Linux can do better and correctly show root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat numa_node 2 root@hagen:/sys/devices/pci0000:00/0000:00:1a.4# cat local_cpu* 8-11 00000000,00000f00 Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
-
Bjorn Helgaas authored
The roundup() caused a build error (undefined reference to `__udivdi3'). We're aligning to power-of-two boundaries, so it's simpler to just use ALIGN() anyway, which avoids the division. Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Kenji Kaneshige authored
There are a lot of codes that searches PCI express capability offset in the PCI configuration space using pci_find_capability(). Caching it in the struct pci_dev will reduce unncecessary search. This patch adds an additional 'pcie_cap' fields into struct pci_dev, which is initialized at pci device scan time (in set_pcie_port_type()). Signed-off-by:
-
- 04 Nov, 2009 35 commits
-
-
Bjorn Helgaas authored
When "allocate_resource(root, new, size, ...)" fails, we currently clobber "new". This is inconvenient for the caller, who might care about the original contents of the resource. For example, when pci_bus_alloc_resource() fails, the "can't allocate mem resource %pR" message from pci_assign_resources() currently contains junk for the resource start/end. This patch delays the "new" update until we're about to return success. Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Bjorn Helgaas authored
PCI device BARs are guaranteed to start and end on at least a four-byte (I/O) or a sixteen-byte (MMIO) boundary because they're aligned on their size and the low BAR bits are reserved. PCI-to-PCI bridge apertures have even larger alignment restrictions. However, some BIOSes (e.g., HP DL360 BIOS P31) report host bridge windows like "[io 0x0000-0x2cfe]". This is wrong because it excludes the last port at 0x2cff: it's impossible for a downstream device to claim 0x2cfe without also claiming 0x2cff. In fact, this BIOS configures a device behind the bridge to "[io 0x2c00-0x2cff]", so we know the window actually does include 0x2cff. This patch rounds the start and end of apertures to the appropriate boundary. I experimentally determined that Windows contains a similar workaround; details here: http://bugzilla.kernel.org/show_bug.cgi?id=14337Signed-off-by: -
Bjorn Helgaas authored
We have occasional problems with PCI resource allocation, and sometimes they could be avoided by paying attention to what ACPI tells us about the host bridges. This patch doesn't change the behavior, but it prints window information that should make debugging easier. Signed-off-by:
-
Bjorn Helgaas authored
This makes PCI resource management messages more consistent and adds a few new messages to aid debugging. Whenever we assign resources to a device, update a BAR, or change a bridge aperture, it's worth noting it. Signed-off-by:
-
Bjorn Helgaas authored
Since we have a struct device, we might as well use dev_printk. Note that both pr_debug() and dev_dbg() are completely compiled out unless DEBUG or DYNAMIC_DEBUG is defined. Signed-off-by:
-
Bjorn Helgaas authored
Use the dev_printk-like "%04x:%02x" format for printing PCI bus numbers. Signed-off-by:
-
Bjorn Helgaas authored
Messages about PME# being supported and enabled/disabled are probably useful for debug, but maybe don't need to be on the console. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Commit 3b073eda has removed pci_find_slot, so there's no point in mentioning it in the config description as one of the deprecated APIs there are enabled by PCI_LEGACY and still used by some drivers. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by:
-
Bjorn Helgaas authored
Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This is the diff between v1 and v2. The changes in this patch are: - tidied vsprintf stack buffer to shrink and compute size more accurately - use %pR for decoding and %pr for "raw" (with type and flags) instead of adding %pRt and %pRf [1] http://lkml.org/lkml/2009/10/6/491 [2] http://lkml.org/lkml/2009/10/13/441Signed-off-by: -
Stefan Assmann authored
AMD 813x rev. B1 (like rev. B2) devices generate no interrupts if quirk_disable_amd_813x_boot_interrupt is executed, add an exception. http://bugzilla.kernel.org/show_bug.cgi?id=14159 Patch also adds missing cases for DECLARE_PCI_FIXUP_RESUME and DECLARE_PCI_FIXUP_FINAL calls to quirk_disable_amd_813x_boot_interrupt. Signed-off-by:
Stefan Assmann <sassmann@redhat.com> Tested-by:
Gabriele Giorgetti <g.giorgetti@teamsystem.com> Signed-off-by:
-
Alex Chiang authored
Using list_for_each_entry instead of list_for_each allows us to enhance readability and minorly reduce some stack usage. Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Bjorn Helgaas authored
This patch moves PCI I/O APIC support from acpiphp to a separate driver. Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and removal of PCI adapters. But in addition, acpiphp handles some ACPI hotplug, such as the addition of new host bridges, and the I/O APIC support was tangled up with that. I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs usually appear as a function on a PCI host bridge, and we'll enumerate the APIC before any of the devices behind the bridge that use it. As far as I know, nobody actually uses I/O APIC hotplug. It depends on acpi_register_ioapic(), which is only implemented for ia64, and I don't think any vendors have supported I/O chassis hotplug yet. Signed-off-by:
-
Andrew Patterson authored
Fixed probable typo in aer_inject cleanup code resulting in a memory leak. Acked-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
-
Andrew Patterson authored
Replaced some error return values in aer_inject. Use -ENODEV when we can't find a device and -ENOTTY when the device does not support PCIe AER. Acked-by:
-
Andrew Patterson authored
Add support for PCI domains (segments) to aer_inject. Acked-by:
-
Andrew Patterson authored
Added the pci_get_domain_and_slot_function which is analogous to pci_get_bus_and_slot. It returns a pci_dev given a domain (segment) number, bus number, and devnr. Like pci_get_bus_and_slot, pci_get_domain_bus_and_slot holds a reference to the returned pci_dev. Converted pci_get_bus_and_slot to a wrapper that calls pci_get_domain_bus_and_slot with the domain hard-coded to 0. This routine was patterned off code suggested by Bjorn Helgaas. Acked-by:
-
Gabe Black authored
Change to populate the subsystem vendor and subsytem device IDs for PCI-PCI bridges that implement the PCI Subsystem Vendor ID capability. Previously bridges left subsystem vendor IDs unpopulated. Signed-off-by:
Gabe Black <gabe.black@ni.com> Signed-off-by:
-
Matt Domsch authored
Feedback from Hidetoshi Seto and Kenji Kaneshige incorporated. This correctly handles PCI-X bridges, PCIe root ports and endpoints, and prints debug messages when invalid/reserved types are found in the HEST. PCI devices not in domain/segment 0 are not represented in HEST, thus will be ignored. Today, the PCIe Advanced Error Reporting (AER) driver attaches itself to every PCIe root port for which BIOS reports it should, via ACPI _OSC. However, _OSC alone is insufficient for newer BIOSes. Part of ACPI 4.0 is the new APEI (ACPI Platform Error Interfaces) which is a way for OS and BIOS to handshake over which errors for which components each will handle. One table in ACPI 4.0 is the Hardware Error Source Table (HEST), where BIOS can define that errors for certain PCIe devices (or all devices), should be handled by BIOS ("Firmware First mode"), rather than be handled by the OS. Dell PowerEdge 11G server BIOS defines Firmware First mode in HEST, so that it may manage such errors, log them to the System Event Log, and possibly take other actions. The aer driver should honor this, and not attach itself to devices noted as such. Furthermore, Kenji Kaneshige reminded us to disallow changing the AER registers when respecting Firmware First mode. Platform firmware is expected to manage these, and if changes to them are allowed, it could break that firmware's behavior. The HEST parsing code may be replaced in the future by a more feature-rich implementation. This patch provides the minimum needed to prevent breakage until that implementation is available. Reviewed-by:Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
-
Kenji Kaneshige authored
Prevent unnecessary power off at initialization time. If slot power is already off, we don't need to power off the slot. Signed-off-by:
-
Kenji Kaneshige authored
Fix typo that might cause memory leak in pciehp_probe(). Signed-off-by:
-
Kenji Kaneshige authored
Current pciehp returns successfully on read/write failure with dummy state values. It should return error instead. With this patch, pciehp no longer uses hotplug_slot_info data structure. So this also removes hotplug_slot_info related code. But note that it still allocates hotplug_slot_info because it is required by pci hotplug core. Signed-off-by:
-
Kenji Kaneshige authored
Current pciehp driver creates 'attention' and 'latch' files even if the controller doesn't support them. In this case, the contents of those files are meaningless and unpredictable. Those files should be created only if the controller has the corresponding capabilities. Signed-off-by:
-
Kenji Kaneshige authored
Remove wrong workaround for BAD DLLP error, which confused surprise down error with DLL errors. Signed-off-by:
-
Kenji Kaneshige authored
Current pciehp doesn't handle Data Link Layer State Changed Event notification. So it needs to be disabled at initialization time, otherwise other event notifications are not generated. Signed-off-by:
-
Michael S. Tsirkin authored
When probing for ROM BAR size, we should not change bits 1:10 in this BAR, because these bits are marked as "reserved for future use" in PCI spec, so changing them might have side effects. No such issue for I/O or memory, as there is an implementation note in PCI spec which explicitly allows writing 0xfffffffff there. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
We use dev_dbg() in arch/x86/pci, but there's no easy way to turn it on. Add -DDEBUG when CONFIG_PCI_DEBUG=y, just like we do in drivers/pci. Signed-off-by:
-
Allen Kay authored
This patch is predicated on Jeremy's patch in include/xen/xen.h. It'll prevent ACS init unless the platform has both an IOMMU and we're running as dom0. Signed-off-by:
Allen Kay <allen.m.kay@intel.com> Signed-off-by:
-
Allen Kay authored
Note: dom0 checking in v4 has been separated out into 2/2. This patch enables P2P upstream forwarding in ACS capable PCIe switches. It solves two potential problems in virtualization environment where a PCIe device is assigned to a guest domain using a HW iommu such as VT-d: 1) Unintentional failure caused by guest physical address programmed into the device's DMA that happens to match the memory address range of other downstream ports in the same PCIe switch. This causes the PCI transaction to go to the matching downstream port instead of go to the root complex to get translated by VT-d as it should be. 2) Malicious guest software intentionally attacks another downstream PCIe device by programming the DMA address into the assigned device that matches memory address range of the downstream PCIe port. We are in process of implementing device filtering software in KVM/XEN management software to allow device assignment of PCIe devices behind a PCIe switch only if it has ACS capability and with the P2P upstream forwarding bits enabled. This patch is intended to work for both KVM and Xen environments. Signed-off-by:
Mathew Wilcox <willy@linux.intel.com> Reviewed-by:
Chris Wright <chris@sous-sol.org> Signed-off-by:
-
Jeremy Fitzhardinge authored
Move xen_domain and related tests out of asm-x86 to xen/xen.h so they can be included whenever they are necessary. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Bjorn Helgaas authored
The current whitelist requires a kernel change for every machine that has MMCONFIG regions above 4GB, even if BIOS provides a correct MCFG table. This patch expands the whitelist to include machines with a rev 1 or newer MCFG table and a DMI_BIOS_DATE of 2010 or later. That way, we only need kernel changes for new machines that provide incorrect MCFG tables. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Suresh Siddha authored
Thomas Schlichter reported: > X.org uses libpciaccess which tries to mmap with write combining enabled via > /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the > kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded > mapping with write combining enabled and does not set up suited MTRR entries. > ;-( Instead of silently mapping pci mmap region as UC minus in the case of !pat_enabled and wc request, we can return error. Eric Anholt mentioned that caller (like X) typically follows up with UC minus pci mmap request and if there is a free mtrr slot, caller will manage adding WC mtrr. Jesse Barnes says: > Older versions of libpciaccess will behave better if we do it that way > (iirc it only allocates an MTRR if the resource_wc file doesn't exist or > fails to get mapped). Reported-by:
Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
-
Bjorn Helgaas authored
This uses %pRt and %pRf to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by:
-
Bjorn Helgaas authored
This uses %pRt to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by:
-
Bjorn Helgaas authored
This uses %pRt to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by:
-
Bjorn Helgaas authored
This uses %pRt to print additional resource information (type, size, prefetchability, etc.) consistently. Signed-off-by:
-
