aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/probe.c
Commit message (Collapse)AuthorAge
...
* PCI: show host bridges and root bus resourcesBjorn Helgaas2012-01-06
| | | | | | | | | Show the bus number and resources for every root bus we create. This will become more interesting when we supply the correct resources instead of using the defaults (ioport_resource and iomem_resource). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: fix a brace coding style issue in probe.cZac Storer2012-01-06
| | | | | | | Fixed a brace coding style issue. Signed-off-by: Zac Storer <zac.3.14159@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Clean-up MPS debug outputJon Mason2011-10-27
| | | | | | | | | | | Clean-up MPS debug output to make it a single line and aligned, thus making it more readable for a large number of buses and devices in a single system. Suggested by Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jon Mason <mason@myri.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: enable MPS "performance" setting to properly handle bridge MPSJon Mason2011-10-27
| | | | | | | | | | | | | | Rework the "performance" MPS option to configure the device MPS with the smaller of the device MPSS or the bridge MPS (which is assumed to be properly configured at this point to the largest allowable MPS based on its parent bus). Also, rework the MRRS setting to report an inability to set the MRRS to a valid setting. Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Disable MPS configuration by defaultJon Mason2011-10-04
| | | | | | | | | | | | | | | | Add the ability to disable PCI-E MPS turning and using the BIOS configured MPS defaults. Due to the number of issues recently discovered on some x86 chipsets, make this the default behavior. Also, add the option for peer to peer DMA MPS configuration. Peer to peer DMA is outside the scope of this patch, but MPS configuration could prevent it from working by having the MPS on one root port different than the MPS on another. To work around this, simply make the system wide MPS the smallest possible value (128B). Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pci: Don't crash when reading mpss from root complexBenjamin Herrenschmidt2011-09-13
| | | | | | | | | | | | | | | | | In pcie_find_smpss(), we have the following statement: if (dev->is_hotplug_bridge && (!list_is_singular(&dev->bus->devices) || dev->bus->self->pcie_type != PCI_EXP_TYPE_ROOT_PORT)) The problem is that at least on my machine, this gets called for the root complex (virtual P2P bridge), and dev->bus->self is NULL since the parent bus for this is not itself anchor to a PCI device. This adds the necessary NULL check. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jon Mason <mason@myri.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: Remove MRRS modification from MPS setting codeJon Mason2011-09-09
| | | | | | | | | | | | | | | | | | Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has massive negative ramifications on some devices. Without knowing which devices have this issue, do not modify from the default value when walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe the default procedure. Tested-by: Sven Schnelle <svens@stackframe.org> Tested-by: Simon Kirby <sim@hostway.ca> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com> Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.de> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162 Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Fix pointer dereference before call to pcie_bus_configure_settingsShyam Iyer2011-09-09
| | | | | | | | | | | | | | | | Commit b03e7495a862 ("PCI: Set PCI-E Max Payload Size on fabric") introduced a potential NULL pointer dereference in calls to pcie_bus_configure_settings due to attempts to access pci_bus self variables when the self pointer is NULL. To correct this, verify that the self pointer in pci_bus is non-NULL before dereferencing it. Reported-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Shyam Iyer <shyam_iyer@dell.com> Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: export pcie_bus_configure_settings symbolJon Mason2011-08-02
| | | | | | | | | pcie_bus_configure_settings needs to be exported if the PCI hotplug driver is being compiled as a module. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jon Mason <mason@myri.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Set PCI-E Max Payload Size on fabricJon Mason2011-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a given PCI-E fabric, each device, bridge, and root port can have a different PCI-E maximum payload size. There is a sizable performance boost for having the largest possible maximum payload size on each PCI-E device. However, if improperly configured, fatal bus errors can occur. Thus, it is important to ensure that PCI-E payloads sends by a device are never larger than the MPS setting of all devices on the way to the destination. This can be achieved two ways: - A conservative approach is to use the smallest common denominator of the entire tree below a root complex for every device on that fabric. This means for example that having a 128 bytes MPS USB controller on one leg of a switch will dramatically reduce performances of a video card or 10GE adapter on another leg of that same switch. It also means that any hierarchy supporting hotplug slots (including expresscard or thunderbolt I suppose, dbl check that) will have to be entirely clamped to 128 bytes since we cannot predict what will be plugged into those slots, and we cannot change the MPS on a "live" system. - A more optimal way is possible, if it falls within a couple of constraints: * The top-level host bridge will never generate packets larger than the smallest TLP (or if it can be controlled independently from its MPS at least) * The device will never generate packets larger than MPS (which can be configured via MRRS) * No support of direct PCI-E <-> PCI-E transfers between devices without some additional code to specifically deal with that case Then we can use an approach that basically ignores downstream requests and focuses exclusively on upstream requests. In that case, all we need to care about is that a device MPS is no larger than its parent MPS, which allows us to keep all switches/bridges to the max MPS supported by their parent and eventually the PHB. In this case, your USB controller would no longer "starve" your 10GE Ethernet and your hotplug slots won't affect your global MPS. Additionally, the hotplugged devices themselves can be configured to a larger MPS up to the value configured in the hotplug bridge. To choose between the two available options, two PCI kernel boot args have been added to the PCI calls. "pcie_bus_safe" will provide the former behavior, while "pcie_bus_perf" will perform the latter behavior. By default, the latter behavior is used. NOTE: due to the location of the enablement, each arch will need to add calls to this function. This patch only enables x86. This patch includes a number of changes recommended by Benjamin Herrenschmidt. Tested-by: Jordan_Hargrave@dell.com Signed-off-by: Jon Mason <mason@myri.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'linux-next' of ↵Linus Torvalds2011-07-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: remove printks about disabled bridge windows PCI: fold pci_calc_resource_flags() into decode_bar() PCI: treat mem BAR type "11" (reserved) as 32-bit, not 64-bit, BAR PCI: correct pcie_set_readrq write size PCI: pciehp: change wait time for valid configuration access x86/PCI: Preserve existing pci=bfsort whitelist for Dell systems PCI: ARI is a PCIe v2 feature x86/PCI: quirks: Use pci_dev->revision PCI: Make the struct pci_dev * argument of pci_fixup_irqs const. PCI hotplug: cpqphp: use pci_dev->vendor PCI hotplug: cpqphp: use pci_dev->subsystem_{vendor|device} x86/PCI: config space accessor functions should not ignore the segment argument PCI: Assign values to 'pci_obff_signal_type' enumeration constants x86/PCI: reduce severity of host bridge window conflict warnings PCI: enumerate the PCI device only removed out PCI hieratchy of OS when re-scanning PCI PCI: PCIe AER: add aer_recover_queue x86/PCI: select direct access mode for mmconfig option PCI hotplug: Rename is_ejectable which also exists in dock.c
| * PCI: remove printks about disabled bridge windowsBjorn Helgaas2011-07-22
| | | | | | | | | | | | | | | | I don't think there's enough value in the fact of a bridge window being disabled to justify cluttering the dmesg log with it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: fold pci_calc_resource_flags() into decode_bar()Bjorn Helgaas2011-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decode_bar() and pci_calc_resource_flags() both looked at the PCI BAR type information, and it's simpler to just do it all in one place. decode_bar() sets IORESOURCE_IO, IORESOURCE_MEM, and IORESOURCE_MEM_64 as appropriate, so res->flags contains all the information pci_bar_type does, so we don't need to test the pci_bar_type return value. decode_bar() used to return pci_bar_type, which we no longer need. We can simplify it a bit by returning the struct resource flags rather than updating them internally. In pci_update_resource(), there's no need to decode the BAR type bits again; we can just test for IORESOURCE_MEM_64 directly. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: treat mem BAR type "11" (reserved) as 32-bit, not 64-bit, BARBjorn Helgaas2011-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a minor regression where broken PCI devices that use the reserved "11" memory BAR type worked before e354597cce but not after. The low four bits of a memory BAR are "PTT0" where P=1 for prefetchable BARs, and TT is as follows: 00 32-bit BAR, anywhere in lower 4GB 01 anywhere below 1MB (reserved as of PCI 2.2) 10 64-bit BAR 11 reserved Prior to e354597cce, we treated "0100" as a 64-bit BAR and all others, including prefetchable 64-bit BARs ("1100") as 32-bit BARs. The e354597cce fix, which appeared in 2.6.28, treats "x1x0" as 64-bit BARs, so the reserved "x110" types are treated as 64-bit instead of 32-bit. This patch returns to treating the reserved "11" type as a 32-bit BAR and adds a warning if we see it. It also logs a note if we see a 1M BAR. This is not a warning, because such hardware conforms to pre-PCI 2.2 spec, but I think it's worth noting because Linux ignores the 1M restriction if it ever has to assign the BAR. CC: Peter Chubb <peterc@gelato.unsw.edu.au> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=35952 Reported-by: Jan Zwiegers <jan@radicalsystems.co.za> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: enumerate the PCI device only removed out PCI hieratchy of OS when ↵Tiejun Chen2011-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | re-scanning PCI When hot-plugging a root bridge, we always prevent assigning a bus number that already exists. This makes sure we don't step over an existing bus. But sometimes we only remove PCI device in PCI hieratchy of OS, i,e. echo 1 > /sys/bus/pci/devices/.../remove but actually don't hotplug this device out the platform, so in this case we still should re-scan this bus to enumerate this device when re-scanning PCI again. Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | Merge branch 'of-pci' of ↵Linus Torvalds2011-07-22
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc * 'of-pci' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: pci/of: Consolidate pci_bus_to_OF_node() pci/of: Consolidate pci_device_to_OF_node() x86/devicetree: Use generic PCI <-> OF matching microblaze/pci: Move the remains of pci_32.c to pci-common.c microblaze/pci: Remove powermac originated cruft pci/of: Match PCI devices to OF nodes dynamically
| * pci/of: Match PCI devices to OF nodes dynamicallyBenjamin Herrenschmidt2011-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | powerpc has two different ways of matching PCI devices to their corresponding OF node (if any) for historical reasons. The ppc64 one does a scan looking for matching bus/dev/fn, while the ppc32 one does a scan looking only for matching dev/fn on each level in order to be agnostic to busses being renumbered (which Linux does on some platforms). This removes both and instead moves the matching code to the PCI core itself. It's the most logical place to do it: when a pci_dev is created, we know the parent and thus can do a single level scan for the matching device_node (if any). The benefit is that all archs now get the matching for free. There's one hook the arch might want to provide to match a PHB bus to its device node. A default weak implementation is provided that looks for the parent device device node, but it's not entirely reliable on powerpc for various reasons so powerpc provides its own. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Michal Simek <monstr@monstr.eu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | PCI: Fix warning in drivers/pci/probe.c on sparc64David S. Miller2011-05-31
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IO_SPACE_LIMIT is currently used in two ways: 1) As a way to mask I/O port values read out of PCI base address registers. This value should be 64-bit. 2) As a value which is the upper limit for all I/O "ports" in the system. On sparc64 we store the full 64-bit physical I/O address in the resources. For this reason we define IO_SPACE_LIMIT at a 64-bit "all 1's". This is the right value to use for ioport_resource.end and for the check made in drivers/pcmcia/rsrc_nonstatic.c:adjust_io(). But in driver/pci/probe.c:__pci_read_base() we mask this against a "u32" variable and thus get the following warning: drivers/pci/probe.c: In function ¡__pci_read_base¢: drivers/pci/probe.c:207: warning: large integer implicitly truncated to unsigned type Fix this by using an explicit "u32" cast. I considered changing sparc64 to define a 32-bit "all 1's" like most other systems do, but this wouldn't work because the checks in PCMCIA's rsrc_nonstatic.c would no longer be right since they are testing against fully formed 64-bit resources. As described above, on sparc64 such resources will hold full 64-bit physical I/O addresses, not bus-centric 32-bit ones. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI/sysfs: move bus cpuaffinity to class dev_attrsYinghai Lu2011-05-21
| | | | | | | | | Requested by Greg KH to fix a race condition in the creating of PCI bus cpuaffinity files. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add rescan to /sys/.../pci_bus/.../Yinghai Lu2011-05-21
| | | | | | | | | | | | | | | | | | | | | After remove the device from /sys, we have to rescan all or find out the bridge and access /sys../device/rescan there. this patch add /sys/.../pci_bus/.../rescan. So user can rescan more easy. that is more clean and easy to understand. like after remove 0000:c4:00.0, you can rescan 0000:c4 directly. -v2: According to Jesse, use function instead of exposing attr, so could hide #ifdef in header file. also add code to remove rescan file in remove path. -v3: GregKH pointed out that we should use dev_attrs to avoid racing. So add pcibus_attrs and make it to be member of pcibus_attrs. -v4: Change name to pcibus_dev_attrs according to GregKH Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Avoid potential NULL pointer dereference in pci_scan_bridgeJesper Juhl2011-02-08
| | | | | | | | | | | | | | | pci_add_new_bus() calls pci_alloc_child_bus() which calls pci_alloc_bus() that allocates memory dynamically with kzalloc(). The return value of kzalloc() is the pointer that's eventually returned from pci_add_new_bus(), so since kzalloc() can fail and return NULL so can pci_add_new_bus(). Thus we may end up dereferencing a NULL pointer in drivers/pci/probe.c::pci_scan_bridge(). Seems to me we should test for this and bail out if it happens rather than crashing. Also removed some trailing whitespace that bugged me while looking at this. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: log vendor/device ID alwaysBjorn Helgaas2010-10-17
| | | | | | | | | Previously we had to have CONFIG_PCI_DEBUG=y or CONFIG_DYNAMIC_DEBUG=y to turn on this printk, but I think the IDs are valuable enough that it's worth putting them in the log always. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: disable mmio during bar sizingJacob Pan2010-07-30
| | | | | | | | | | | | | | | | | It is a known issue that mmio decoding shall be disabled while doing PCI bar sizing. Host bridge and other devices (PCI PIC) shall be excluded for certain platforms. This patch mainly comes from Mathew Willcox's patch in http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/258969. A new flag bit "mmio_alway_on" is added to pci_dev with the intention that devices with their mmio decoding cannot be disabled during BAR sizing shall have this bit set, preferrablly in their quirks. Without this patch, Intel Moorestown platform graphics unit will be corrupted during bar sizing activities. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setupHuang Ying2010-05-19
| | | | | | | | | | | | | Now, a dedicated HEST tabling parsing code is used for PCIE AER firmware_first setup. It is rebased on general HEST tabling parsing code of APEI. The firmware_first setup code is moved from PCI core to AER driver too, because it is only AER related. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Len Brown <len.brown@intel.com>
* PCI: revert broken device warningBjorn Helgaas2010-04-22
| | | | | | | | | | | 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 <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: complain about devices that seem to be brokenBjorn Helgaas2010-03-24
| | | | | | | | | | If we can tell that a device isn't working correctly, we should tell the user to make debugging easier. Otherwise, it can take a lot of work to determine whether the problem is in the driver, PCMCIA, PCI, hardware, etc., as in http://bugzilla.kernel.org/show_bug.cgi?id=12006 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: make disabled window printk style match the enabled onesBjorn Helgaas2010-03-24
| | | | | | | | | | No functional change; this just tweaks the changes from 349e1823a405 so the new printks for disabled PCI-to-PCI bridge windows match the ones for the enabled windows. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: break out primary/secondary/subordinate for readabilityBjorn Helgaas2010-03-24
| | | | | | | | No functional change; just add names for the primary/secondary/subordinate bus numbers read from config space rather than repeatedly masking/shifting. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PM: Allow PCI devices to suspend/resume asynchronouslyRafael J. Wysocki2010-02-26
| | | | | | | | | | | | | | Set power.async_suspend for all PCI devices and PCIe port services, so that they can be suspended and resumed in parallel with other devices they don't depend on in a known way (i.e. devices which are not their parents or children). This only affects the "regular" suspend and resume stages, which means in particular that the restoration of the PCI devices' standard configuration registers during resume will still be carried out synchronously (at the "early" resume stage). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* PCI: augment bus resource table with a listBjorn Helgaas2010-02-23
| | | | | | | | | | | | | | | | | | | | | | | | Previously we used a table of size PCI_BUS_NUM_RESOURCES (16) for resources forwarded to a bus by its upstream bridge. We've increased this size several times when the table overflowed. But there's no good limit on the number of resources because host bridges and subtractive decode bridges can forward any number of ranges to their secondary buses. This patch reduces the table to only PCI_BRIDGE_RESOURCE_NUM (4) entries, which corresponds to the number of windows a PCI-to-PCI (3) or CardBus (4) bridge can positively decode. Any additional resources, e.g., PCI host bridge windows or subtractively-decoded regions, are kept in a list. I'd prefer a single list rather than this split table/list approach, but that requires simultaneous changes to every architecture. This approach only requires immediate changes where we set up (a) host bridges with more than four windows and (b) subtractive-decode P2P bridges, and we can incrementally change other architectures to use the list. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: read bridge windows before filling in subtractive decode resourcesBjorn Helgaas2010-02-23
| | | | | | | | | | No functional change; this fills in the bus subtractive decode resources after reading the bridge window information rather than before. Also, print out the subtractive decode resources as we already do for the positive decode windows. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: split up pci_read_bridge_bases()Bjorn Helgaas2010-02-23
| | | | | | | | | No functional change; this breaks up pci_read_bridge_bases() into separate pieces for the I/O, memory, and prefetchable memory windows, similar to how Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: reject mmio ranges starting at 0 on pci_bridge readYinghai Lu2010-02-22
| | | | | | | | | We already track unassigned resources in struct resource, and this prevents us from overwriting resource flags and info in the unassigned case. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Make pci_scan_slot more robustMatthew Wilcox2010-02-22
| | | | | | | | | | | | | | Yinghai pointed out that the new pci_scan_slot() crashes when called on an ARI-capable slot that is empty. Fix this by exiting early from pci_scan_slot if there is no device in the slot. Also make next_ari_func() robust against devices not existing in case the ARI capability is corrupt. ARI also requires that the devices be listed in order, so if we find a function listed that is out of order, stop scanning to prevent loops. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Add support for reporting PCIe 3.0 speedsMatthew Wilcox2010-02-22
| | | | | | | Add the 8.0 GT/s speed. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Add support for AGP in cur/max bus speedMatthew Wilcox2010-02-22
| | | | | | | Take advantage of some gaps in the table to fit in support for AGP speeds. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Add support for detection of PCIe and PCI-X bus speedsMatthew Wilcox2010-02-22
| | | | | | | | Both PCIe and PCI-X bridges report their secondary bus speed in their respective capabilities. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Make current and maximum bus speeds part of the PCI coreMatthew Wilcox2010-02-22
| | | | | | | | | | Move the max_bus_speed and cur_bus_speed into the pci_bus. Expose the values through the PCI slot driver instead of the hotplug slot driver. Update all the hotplug drivers to use the pci_bus instead of their own data structures. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Rewrite pci_scan_slotMatthew Wilcox2010-02-22
| | | | | | | | | | | | | | | | | | The Alternate Routing-ID Interpretation capability allows a single device to have up to 256 functions. They can be populated sparsely, so the current technique of scanning every eighth function is not guaranteed to find them all. By introducing a 'next_fn' function pointer, we can use the linked list of functions in the ARI capability to scan all the functions which exist. We can then speed up the pci_scan_slot by skipping the scan of subsequent devfns for PCIe devices which are the direct children of Root Ports or Downstream Ports. These devices are only permitted to implement device 0, unless they are ARI devices, in which case they'll be scanned by the ARI code above. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()Benjamin Herrenschmidt2010-01-29
| | | | | | | | We are missing these when building the pci_dev from scratch off the Open Firmware device-tree Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add pci_request_acsChris Wright2009-12-04
| | | | | | | | | | | | | | | | | | | | Commit ae21ee65e8bc228416bbcc8a1da01c56a847a60c "PCI: acs p2p upsteram forwarding enabling" doesn't actually enable ACS. Add a function to pci core to allow an IOMMU to request that ACS be enabled. The existing mechanism of using iommu_found() in the pci core to know when ACS should be enabled doesn't actually work due to initialization order; iommu has only been detected not initialized. Have Intel and AMD IOMMUs request ACS, and Xen does as well during early init of dom0. Cc: Allen Kay <allen.m.kay@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: use pci_pcie_cap() in pci coreKenji Kaneshige2009-11-24
| | | | | | | | | 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>
* PCI: cache PCIe capability offsetKenji Kaneshige2009-11-06
| | | | | | | | | | | 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>
* PCI: improve discovery/configuration messagesBjorn Helgaas2009-11-04
| | | | | | | | | | | 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>
* PCI: replace pr_debug with dev_dbgBjorn Helgaas2009-11-04
| | | | | | | | | 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>
* vsprintf: use %pR, %pr instead of %pRt, %pRfBjorn Helgaas2009-11-04
| | | | | | | | | | | | | | | | | 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/441 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: populate subsystem vendor and device IDs for PCI bridgesGabe Black2009-11-04
| | | | | | | | | 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>
* PCI: PCIe AER: honor ACPI HEST FIRMWARE FIRST modeMatt Domsch2009-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* PCI: fix nit in ROM BAR size probingMichael S. Tsirkin2009-11-04
| | | | | | | | | | | | 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>
* PCI: add xen dom0 checking before ACS initializationAllen Kay2009-11-04
| | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-14 17:22:10 -0400