summaryrefslogtreecommitdiff
path: root/drivers/pci/probe.c
AgeCommit message (Collapse)Author
2012-03-20PCI: fix bridge I/O window bus-to-resource conversionBjorn Helgaas
In 5bfa14ed9f3c, I forgot to initialize res2.flags before calling pcibios_bus_to_resource(), which depends on the resource type to locate the correct aperture. This bug won't hurt x86, which currently never has an offset between bus and CPU addresses, but will affect other architectures. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-24PCI: Move "pci reassigndev resource alignment" out of quirks.cYinghai Lu
This isn't really a quirk; calling it directly from pci_add_device makes more sense. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-24PCI: collapse pcibios_resource_to_busBjorn Helgaas
Everybody uses the generic pcibios_resource_to_bus() supplied by the core now, so remove the ARCH_HAS_GENERIC_PCI_OFFSETS used during conversion. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-24PCI: add generic pcibios_resource_to_bus()Bjorn Helgaas
This replaces the generic versions of pcibios_resource_to_bus() and pcibios_bus_to_resource() in asm-generic/pci.h with versions that use pci_resource_to_bus() and pci_bus_to_resource(). The replacements are equivalent except that they can apply host bridge window offsets when the arch has supplied them by using pci_add_resource_offset(). Each arch can convert to using pci_add_resource_offset() individually by removing its device resource fixups from pcibios_fixup_bus() and supplying ARCH_HAS_GENERIC_PCI_OFFSETS. ARCH_HAS_GENERIC_PCI_OFFSETS can be removed after all have converted. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-24PCI: convert bus addresses to resource when reading BARsBjorn Helgaas
Some PCI host bridges translate CPU addresses to PCI bus addresses. Previously, we initialized pci_dev resources with PCI bus addresses, then converted them to CPU addresses later in arch-specific code (pcibios_fixup_resources()), which leaves a window of time where the pci_dev resources are incorrect. This patch adds support in the core for this address translation. When the arch creates the root bus, it can supply the host bridge address translation information, and the core can use it to set the pci_dev resources correctly from the beginning. This gives us a way to fix the problem that quirks that run between device discovery and pcibios_fixup_resources() fail because they use pci_dev resources that haven't been converted. The reference below is to one such problem that affected ARM and ia64. Note that this patch has no effect until an arch starts using pci_add_resource_offset() with a non-zero offset: before that, all all host bridge windows have a zero offset and pci_bus_to_resource() copies the pci_bus_region directly to the struct resource. Reference: https://lkml.org/lkml/2009/10/12/405 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-24PCI: add struct pci_host_bridge_window with CPU/bus address offsetBjorn Helgaas
Some PCI host bridges apply an address offset, so bus addresses on PCI are different from CPU addresses. This patch adds a way for architectures to tell the PCI core about this offset. For example: LIST_HEAD(resources); pci_add_resource_offset(&resources, host->io_space, host->io_offset); pci_add_resource_offset(&resources, host->mem_space, host->mem_offset); pci_scan_root_bus(parent, bus, ops, sysdata, &resources); Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-24PCI: add struct pci_host_bridge and a list of all bridges foundBjorn Helgaas
This adds a list of all PCI host bridges we find and a way to look up the host bridge from a pci_dev. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-24PCI: don't publish new root bus until it's fully initializedBjorn Helgaas
When pci_create_root_bus() adds the new struct pci_bus to the global pci_root_buses list, the bus becomes visible to other parts of the kernel, so it should be fully initialized. This patch delays adding the bus to the pci_root_buses list until after all the struct pci_bus initialization is finished. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-02-23PCI: fix memleak for pci dev removing during hotplugYinghai Lu
unreferenced object 0xffff880276d17700 (size 64): comm "swapper/0", pid 1, jiffies 4294897182 (age 3976.028s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 18 f9 de 76 02 88 ff ff ...........v.... 10 00 00 00 0e 00 00 00 0f 28 40 00 00 00 00 00 .........(@..... backtrace: [<ffffffff81c8aede>] kmemleak_alloc+0x26/0x43 [<ffffffff811385f0>] __kmalloc+0x121/0x183 [<ffffffff813cf821>] pci_add_cap_save_buffer+0x35/0x7c [<ffffffff813d12b7>] pci_allocate_cap_save_buffers+0x1d/0x65 [<ffffffff813cdb52>] pci_device_add+0x92/0xf1 [<ffffffff81c8afe6>] pci_scan_single_device+0x9f/0xa1 [<ffffffff813cdbd2>] pci_scan_slot.part.20+0x21/0x106 [<ffffffff813cdce2>] pci_scan_slot+0x2b/0x35 [<ffffffff81c8dae4>] __pci_scan_child_bus+0x51/0x107 [<ffffffff81c8d75b>] pci_scan_bridge+0x376/0x6ae [<ffffffff81c8db60>] __pci_scan_child_bus+0xcd/0x107 [<ffffffff81c8dbab>] pci_scan_child_bus+0x11/0x2a [<ffffffff81cca58c>] pci_acpi_scan_root+0x18b/0x21c [<ffffffff81c916be>] acpi_pci_root_add+0x1e1/0x42a [<ffffffff81406210>] acpi_device_probe+0x50/0x190 [<ffffffff814a0227>] really_probe+0x99/0x126 Need to free saved_buffer for capabilities. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-23PCI: Fix device class print outYinghai Lu
Found debug print of class is shifted. | pci 0000:f8:15.2: [8086:2b56] type 0 class 0x000600 Code is trying to print class with 6 digits, but use shifted class with 4 digits valid value as variable. Change to original dev->class directly. Also remove not needed calculating of local variable class, because it will be updated after pci_fixup_device(pci_fixup_early...) Also unify type print out when class and header is not matched. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-14PCI: Separate pci_bus_read_dev_vendor_id from pci_scan_deviceYinghai Lu
We can reuse it for pciehp probing. -v2: according to Kenji, fix crs timeout checking, and export the function for later use when pciehp is compiled as a module. Suggested-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-14PCI: Make pci_rescan_bus handle add_listYinghai Lu
This allows us to allocate resources to hotplug bridges during remove/rescan. We need to move the function to setup-bus.c so it can use __pci_bus_size_bridges and __pci_bus_assign_resources directly to take the add_list resource tracking list. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-14PCI: Make rescan bus increase bridge resource size if neededYinghai Lu
Current rescan will not touch bridge MMIO and IO. Try to reuse pci_assign_unassigned_bridge_resources(bridge) to update bridge resources, if child devices need more resources. Only do that for bridges whose children are all removed already; i.e. don't release resources that could already be in use by drivers on child devices. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-10PCI: workaround hard-wired bus number V2Yinghai Lu
Fixes PCI device detection on IBM xSeries IBM 3850 M2 / x3950 M2 when using ACPI resources (_CRS). This is default, a manual workaround (without this patch) would be pci=nocrs boot param. V2: Add dev_warn if the workaround is hit. This should reveal how common such setups are (via google) and point to possible problems if things are still not working as expected. -> Suggested by Jan Beulich. Cc: stable@vger.kernel.org Tested-by: garyhade@us.ibm.com Signed-off-by: Yinghai Lu <yinghai.lu@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: remove pci_create_bus()Bjorn Helgaas
All users of pci_create_bus() have been converted to pci_create_root_bus(), so remove it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: deprecate pci_scan_bus_parented()Bjorn Helgaas
Users of pci_scan_bus_parented() should be converted to use either pci_scan_root_bus() (preferred, but also calls pci_bus_add_devices) or pci_create_root_bus() pci_scan_child_bus() Since pci_scan_bus_parented(), I'm marking it deprecated now and will actually remove it later. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: convert pci_scan_bus_parented() to use pci_create_root_bus()Bjorn Helgaas
This converts pci_scan_bus_parented() to use pci_create_root_bus() instead of pci_create_bus(). The new bus still has the default (incorrect) resources, so this patch doesn't help fix that problem, but it does remove one more use of pci_create_bus(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: convert pci_scan_bus() to use pci_create_root_bus()Bjorn Helgaas
I plan to deprecate pci_scan_bus_parented(), so use pci_create_root_bus() directly instead. pci_scan_bus() itself will be removed as soon as all callers are gone, so this is just an interim step. v2: export pci_scan_bus Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: add pci_scan_root_bus() that accepts resource listBjorn Helgaas
"Early" and "header" quirks often use incorrect bus resources because they see the default resources assigned by pci_create_bus(), before the architecture fixes them up (typically in pcibios_fixup_bus()). Regions reserved by these quirks end up with the wrong parents. Here's the standard path for scanning a PCI root bus: pci_scan_bus or pci_scan_bus_parented pci_create_bus <-- A create with default resources pci_scan_child_bus pci_scan_slot pci_scan_single_device pci_scan_device pci_setup_device pci_fixup_device(early) <-- B pci_device_add pci_fixup_device(header) <-- C pcibios_fixup_bus <-- D fill in correct resources Early and header quirks at B and C use the default (incorrect) root bus resources rather than those filled in at D. This patch adds a new pci_scan_root_bus() function that sets the bus resources correctly from a supplied list of resources. I intend to remove pci_scan_bus() and pci_scan_bus_parented() after fixing all callers. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: add pci_create_root_bus() that accepts resource listBjorn Helgaas
pci_create_bus() assigns ioport_resource and iomem_resource as the default bus resources, i.e., the entire address space. Architectures fix these later, typically in pcibios_fixup_bus() or after pci_scan_bus_parented() returns, but code that runs in the interim sees incorrect resource information. This patch adds a new pci_create_root_bus() that sets the bus resources correctly from a supplied list of resources. I intend to remove pci_create_bus() after changing all callers. Based on original patch by Deng-Cheng Zhu. Reference: http://www.spinics.net/lists/mips/msg41654.html Reference: https://lkml.org/lkml/2011/8/26/88 Signed-off-by: Deng-Cheng Zhu <dczhu@mips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-01-06PCI: show host bridges and root bus resourcesBjorn Helgaas
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>
2012-01-06PCI: fix a brace coding style issue in probe.cZac Storer
Fixed a brace coding style issue. Signed-off-by: Zac Storer <zac.3.14159@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-27PCI: Clean-up MPS debug outputJon Mason
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>
2011-10-27PCI: enable MPS "performance" setting to properly handle bridge MPSJon Mason
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>
2011-10-04PCI: Disable MPS configuration by defaultJon Mason
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>
2011-09-13pci: Don't crash when reading mpss from root complexBenjamin Herrenschmidt
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>
2011-09-10PCI: Remove MRRS modification from MPS setting codeJon Mason
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>
2011-09-10Fix pointer dereference before call to pcie_bus_configure_settingsShyam Iyer
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>
2011-08-02PCI: export pcie_bus_configure_settings symbolJon Mason
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>
2011-08-01PCI: Set PCI-E Max Payload Size on fabricJon Mason
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>
2011-07-30Merge branch 'linux-next' of ↵Linus Torvalds
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
2011-07-22Merge branch 'of-pci' of ↵Linus Torvalds
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
2011-07-22PCI: remove printks about disabled bridge windowsBjorn Helgaas
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>
2011-07-22PCI: fold pci_calc_resource_flags() into decode_bar()Bjorn Helgaas
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>
2011-07-22PCI: treat mem BAR type "11" (reserved) as 32-bit, not 64-bit, BARBjorn Helgaas
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>
2011-07-22PCI: enumerate the PCI device only removed out PCI hieratchy of OS when ↵Tiejun Chen
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>
2011-06-07pci/of: Match PCI devices to OF nodes dynamicallyBenjamin Herrenschmidt
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>
2011-05-31PCI: Fix warning in drivers/pci/probe.c on sparc64David S. Miller
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>
2011-05-21PCI/sysfs: move bus cpuaffinity to class dev_attrsYinghai Lu
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>
2011-05-21PCI: add rescan to /sys/.../pci_bus/.../Yinghai Lu
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>
2011-02-08PCI: Avoid potential NULL pointer dereference in pci_scan_bridgeJesper Juhl
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>
2010-10-18PCI: log vendor/device ID alwaysBjorn Helgaas
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>
2010-07-30PCI: disable mmio during bar sizingJacob Pan
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>
2010-05-20ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setupHuang Ying
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>
2010-04-22PCI: revert broken device warningBjorn Helgaas
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>
2010-03-24PCI: complain about devices that seem to be brokenBjorn Helgaas
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>
2010-03-24PCI: make disabled window printk style match the enabled onesBjorn Helgaas
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>
2010-03-24PCI: break out primary/secondary/subordinate for readabilityBjorn Helgaas
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>
2010-02-26PM: Allow PCI devices to suspend/resume asynchronouslyRafael J. Wysocki
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>
2010-02-23PCI: augment bus resource table with a listBjorn Helgaas
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>