An error occurred fetching the project authors.
- 12 Apr, 2013 1 commit
-
-
Jiang Liu authored
Now pci_bus->is_added is only used to guard invoking of pcibios_fixup_bus() in pci_scan_child_bus(), so just set it directly after the fixups and remove the other test and set in pci_bus_add_devices(). [bhelgaas: changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org>
-
- 25 Jan, 2013 5 commits
-
-
Yinghai Lu authored
We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Jiang Liu authored
According to device model documentation, the way to create/destroy PCI devices should be symmetric. The rule is to either use 1) device_register()/device_unregister() or 2) device_initialize()/device_add()/device_del()/put_device(). So change PCI core logic to follow the rule and get rid of the redundant pci_dev_get()/pci_dev_put() pair. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Yinghai Lu authored
Otherwise irq_desc for PCI bridge with hot-added IOAPIC may not be allocated on the local node. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Yijing Wang authored
There are several next_fn functions (no_next_fn, next_trad_fn, next_ari_fn); consolidate them in next_fn() to simplify the code. [bhelgaas: make next_fn() static, rework control flow] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
pci_enable_ari() now supports enabling or disabling ARI forwarding. So rename pci_enable_ari() to pci_configure_ari() for easy understanding. No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 14 Jan, 2013 1 commit
-
-
Rafael J. Wysocki authored
The ACPI handles of PCI root bridges need to be known to acpi_bind_one(), so that it can create the appropriate "firmware_node" and "physical_node" files for them, but currently the way it gets to know those handles is not exactly straightforward (to put it lightly). This is how it works, roughly: 1. acpi_bus_scan() finds the handle of a PCI root bridge, creates a struct acpi_device object for it and passes that object to acpi_pci_root_add(). 2. acpi_pci_root_add() creates a struct acpi_pci_root object, populates its "device" field with its argument's address (device->handle is the ACPI handle found in step 1). 3. The struct acpi_pci_root object created in step 2 is passed to pci_acpi_scan_root() and used to get resources that are passed to pci_create_root_bus(). 4. pci_create_root_bus() creates a struct pci_host_bridge object and passes its "dev" member to device_register(). 5. platform_notify(), which for systems with ACPI is set to acpi_platform_notify(), is called. So far, so good. Now it starts to be "interesting". 6. acpi_find_bridge_device() is used to find the ACPI handle of the given device (which is the PCI root bridge) and executes acpi_pci_find_root_bridge(), among other things, for the given device object. 7. acpi_pci_find_root_bridge() uses the name (sic!) of the given device object to extract the segment and bus numbers of the PCI root bridge and passes them to acpi_get_pci_rootbridge_handle(). 8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI root bridges and finds the one that matches the given segment and bus numbers. Its handle is then used to initialize the ACPI handle of the PCI root bridge's device object by acpi_bind_one(). However, this is *exactly* the ACPI handle we started with in step 1. Needless to say, this is quite embarassing, but it may be avoided thanks to commit f3fd0c8a (ACPI: Allow ACPI handles of devices to be initialized in advance), which makes it possible to initialize the ACPI handle of a device before passing it to device_register(). Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(), defaulting to an empty implementation that can be replaced by the interested architecutres (x86 and ia64 at the moment) with functions that will set the root bridge's ACPI handle before its dev member is passed to device_register(). Make both x86 and ia64 provide such implementations of pcibios_root_bridge_prepare() and remove acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that aren't necessary any more. Included is a fix for breakage on systems with non-ACPI PCI host bridges from Bjorn Helgaas. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 03 Jan, 2013 1 commit
-
-
Rafael J. Wysocki authored
Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
-
- 07 Dec, 2012 1 commit
-
-
Bjorn Helgaas authored
Use the standard #defines for PCIe Link Status and Capability registers rather than bare numbers. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 05 Dec, 2012 1 commit
-
-
Bjorn Helgaas authored
Add and use #defines for PCI-X Capability registers and fields. Note that the PCI-X Capability has a different layout for type 0 (endpoint) and type 1 (bridge) devices. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 28 Nov, 2012 2 commits
-
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint, __devinitdata, __devinitconst, and _devexit are no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bill Pemberton authored
Remove conditional code based on CONFIG_HOTPLUG being false. It's always on now in preparation of it going away as an option. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 Nov, 2012 1 commit
-
-
Yinghai Lu authored
Need type filled in device structure so it can be used for visible attribute control in sysfs for pci_dev. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 03 Nov, 2012 2 commits
-
-
Yinghai Lu authored
So could use assign_unassigned_bus_res pci root bus add Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
We have pci_assign_unassigned_bus_resources() in as global function now. Move pci_rescan_bus() back to probe.c where it should be. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 18 Sep, 2012 1 commit
-
-
Yinghai Lu authored
For bridges with "secondary > subordinate", i.e., invalid bus number apertures, we don't enumerate anything behind the bridge unless the user specified "pci=assign-busses". This patch makes us automatically try to reassign the downstream bus numbers in this case (just for that bridge, not for all bridges as "pci=assign-busses" does). We don't discover all the devices on the Intel DP43BF motherboard without this change (or "pci=assign-busses") because its BIOS configures a bridge as: pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode) [bhelgaas: changelog, change message to dev_info] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754Reported-by: Brian C. Huffman <bhuffman@graze.net> Reported-by: VL <vl.homutov@gmail.com> Tested-by: VL <vl.homutov@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
-
- 24 Aug, 2012 1 commit
-
-
Bjorn Helgaas authored
These messages don't seem to add much value. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 23 Aug, 2012 4 commits
-
-
Bjorn Helgaas authored
If we try to print to the console device while its decoding is disabled, the system will hang. Reported-and-tested-by: Olof Johansson <olof@lixom.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Olof Johansson <olof@lixom.net>
-
Jiang Liu authored
Use PCI Express Capability access functions to simplify core. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
With introduction of pci_pcie_type(), pci_dev->pcie_type field becomes redundant, so remove it. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
Introduce an inline function pci_pcie_type(dev) to extract PCIe device type from pci_dev->pcie_flags_reg field, and prepare for removing pci_dev->pcie_type. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 20 Aug, 2012 1 commit
-
-
Yijing Wang authored
Since PCI Express Capabilities Register is read only, cache its value into struct pci_dev to avoid repeatedly calling pci_read_config_*(). Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 10 Jul, 2012 2 commits
-
-
Bjorn Helgaas authored
9d265124 and 15a260d5 added quirks for P2P bridges that support I/O windows that start/end at 1K boundaries, not just the 4K boundaries defined by the PCI spec. For details, see the IOBL_ADR register and the EN1K bit in the CNF register in the Intel 82870P2 (P64H2). These quirks complicate the code that reads P2P bridge windows (pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(), in pci_setup_bridge(), and again in the FINAL quirk. This is confusing and makes it impossible to reassign the bridge windows after FINAL quirks are run. This patch adds support for 1K windows in the generic paths, so the HEADER quirk only has to enable this support. The FINAL quirk, which used to undo damage done by pci_setup_bridge(), is no longer needed. This removes "if (!res->start) res->start = ..." from pci_read_bridge_io(); that was part of 9d265124 to avoid overwriting the resource filled in by the quirk. Since pci_read_bridge_io() itself now knows about granularity, the quirk no longer updates the resource and this test is no longer needed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
After 253d2e54, we disable MEM and IO decoding for most devices while we size 32-bit BARs. However, we restore the original COMMAND register before we size the upper 32 bits of 64-bit BARs, so we can still cause a conflict. This patch waits to restore the original COMMAND register until we're completely finished sizing the BAR. Reference: https://lkml.org/lkml/2007/8/25/154Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 09 Jul, 2012 1 commit
-
-
Bjorn Helgaas authored
cd81e1ea added checks that prevent us from using P2P bridge windows that start at PCI bus address zero. The reason was to "prevent us from overwriting resources that are unassigned." But generic code should allow address zero in both BARs and bridge windows, so I think that commit was a mistake. Windows at bus address zero are legal and likely to exist on machines with an offset between bus addresses and CPU addresses. For example, in the following hypothetical scenario, the bridge at 00:01.0 has a window at bus address zero and the device at 01:00.0 has a BAR at bus address zero, and I think both are perfectly valid: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [mem 0x100000000-0x1ffffffff] (bus address [0x00000000-0xffffffff]) pci 0000:00:01.0: PCI bridge to [bus 01] pci 0000:00:01.0: bridge window [mem 0x100000000-0x100ffffff] pci 0000:01:00.0: reg 10: [mem 0x100000000-0x100ffffff] Acked-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 20 Jun, 2012 1 commit
-
-
Bjorn Helgaas authored
On P2P bridges with 32-bit I/O decoding, we incorrectly sign-extended windows starting at 0x80000000 or above. In "base |= (io_base_hi << 16)", "io_base_hi" is promoted to a signed int before being extended to an unsigned long. This would cause a window starting at I/O address 0x80000000 to be treated as though it started at 0xffffffff80008000 instead, which should cause "no compatible bridge window" errors when we enumerate devices using that I/O space. The mmio and mmio_pref casts are not strictly necessary, but without them, correctness depends on the types of the PCI_MEMORY_RANGE_MASK and PCI_PREF_RANGE_MASK constants, which are not obvious from reading the local code. Found by Coverity (CID 138747 and CID 138748). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 13 Jun, 2012 8 commits
-
-
Yinghai Lu authored
Now we can insert busn_res now, after all root bus's get inserted. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
also do not need to shrink busn_res. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
We need to put into the resources list for legacy system. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Some callers do not supply the bus number aperture, usually because they do not know the end. In this case, we assume the aperture extends from the root bus number to bus 255, scan the bus, and shrink the bus number resource so it ends at the largest bus number we found. This is obviously not correct because the actual end of the aperture may well be larger than the largest bus number we found. But I guess it's all we have for now. Also print out one info about that, so we could find out which path does not have busn_res in resources list. [bhelgaas: changelog, _safe iterator unnecessary, use %pR format for bus] Signed-off-by: Yinghai Lu <yinghai@kernel.org>
-
Yinghai Lu authored
That busn_res is from resources list. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Will use them insert/update busn res in pci_bus struct. [bhelgaas: print conflicting entry if insertion fails] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
This adds get_pci_domain_busn_res(), which returns the root of the bus number resource tree for a domain, creating it if necessary. We will later populate the tree with the bus numbers used by host bridges and P2P bridges in the domain. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Replace the struct pci_bus secondary/subordinate members with the struct resource busn_res. Later we'll build a resource tree of these bus numbers. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 30 Apr, 2012 4 commits
-
-
Bjorn Helgaas authored
A PCIe downstream port is a P2P bridge. Its secondary interface is a link that should lead only to device 0 (unless ARI is enabled)[1], so we don't probe for non-zero device numbers. Some Stratus ftServer systems have a PCIe downstream port (02:00.0) that leads to both an upstream port (03:00.0) and a downstream port (03:01.0), and 03:01.0 has important devices below it: [0000:02]-+-00.0-[03-3c]--+-00.0-[04-09]--... \-01.0-[0a-0d]--+-[USB] +-[NIC] +-... Previously, we didn't enumerate device 03:01.0, so USB and the network didn't work. This patch adds a DMI quirk to scan all device numbers, not just 0, below a downstream port. Based on a patch by Prarit Bhargava. [1] PCIe spec r3.0, sec 7.3.1 CC: Myron Stowe <mstowe@redhat.com> CC: Don Dutile <ddutile@redhat.com> CC: James Paradis <james.paradis@stratus.com> CC: Matthew Wilcox <matthew.r.wilcox@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
We need a hook to release host bridge resources allocated when creating root bus. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Use that device for pci_root_bus bridge pointer. Use pci_release_bus_bridge_dev() to release allocated pci_host_bridge in remove path. Use root bus bridge pointer to get host bridge pointer instead of searching host bridge list. That leaves the host bridge list unused, so remove it. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Yinghai Lu authored
Move host bridge-related code from probe.c to a new host-bridge.c. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 20 Mar, 2012 1 commit
-
-
Bjorn Helgaas authored
In 5bfa14ed, 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>
-
- 24 Feb, 2012 1 commit
-
-
Yinghai Lu authored
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>
-