- 24 Nov, 2009 2 commits
-
-
Kenji Kaneshige authored
Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI core code. This avoids unnecessary search in PCI configuration space. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Kenji Kaneshige authored
Introduce pci_pcie_cap() API that returns saved PCIe capability offset (currently it is saved in 'pcie_cap' field in the struct PCI dev). Using pci_pcie_cap() instead of pci_find_capability() avoids unnecessary search in PCI configuration space. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 11 Nov, 2009 1 commit
-
-
Linus Torvalds authored
I'm not entirely sure it needs to go into 32, but it's probably the right thing to do. Another way of explaining the patch is: - we currently pick the _first_ exactly matching bus resource entry, but the _last_ inexactly matching one. Normally first/last shouldn't matter, but bus resource entries aren't actually all created equal: in a transparent bus, the last resources will be the parent resources, which we should generally try to avoid unless we have no choice. So "first matching" is the thing we should always aim for. - the patch is a bit bigger than it needs to be, because I simplified the logic at the same time. It used to be a fairly incomprehensible if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH)) best = r; /* Approximating prefetchable by non-prefetchable */ and technically, all the patch did was to make that complex choice be even more complex (it basically added a "&& !best" to say that if we already gound a non-prefetchable window for the prefetchable resource, then we won't override an earlier one with that later one: remember "first matching"). - So instead of that complex one with three separate conditionals in one, I split it up a bit, and am taking advantage of the fact that we already handled the exact case, so if 'res->flags' has the PREFETCH bit, then we already know that 'r->flags' will _not_ have it. So the simplified code drops the redundant test, and does the new '!best' test separately. It also uses 'continue' as a way to ignore the bus resource we know doesn't work (ie a prefetchable bus resource is _not_ acceptable for anything but an exact match), so it turns into: /* We can't insert a non-prefetch resource inside a prefetchable parent .. */ if (r->flags & IORESOURCE_PREFETCH) continue; /* .. but we can put a prefetchable resource inside a non-prefetchable one */ if (!best) best = r; instead. With the comments, it's now six lines instead of two, but it's conceptually simpler, and I _could_ have written it as two lines: if ((res->flags & IORESOURCE_PREFETCH) && !best) best = r; /* Approximating prefetchable by non-prefetchable */ but I thought that was too damn subtle. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 06 Nov, 2009 6 commits
-
-
Thomas Gleixner authored
SPIN_LOCK_UNLOCKED is deprecated. Use DEFINE_SPINLOCK instead. Make the lock static while at it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 04 Nov, 2009 31 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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Bjorn Helgaas authored
Use the dev_printk-like "%04x:%02x" format for printing PCI bus numbers. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Huang Ying <ying.huang@intel.com> Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Andrew Patterson authored
Add support for PCI domains (segments) to aer_inject. Acked-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Huang Ying <ying.huang@intel.com> Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Kenji Kaneshige authored
Fix typo that might cause memory leak in pciehp_probe(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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 <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Kenji Kaneshige authored
Remove wrong workaround for BAD DLLP error, which confused surprise down error with DLL errors. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Allen Kay <allen.m.kay@intel.com> Reviewed-by: Mathew Wilcox <willy@linux.intel.com> Reviewed-by: Chris Wright <chris@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Matthew Wilcox <willy@linux.intel.com> CC: John Keller <jpk@sgi.com> CC: Yinghai Lu <yhlu.kernel@gmail.com> CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> CC: Andi Kleen <andi@firstfloor.org> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
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: 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: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-