A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".
Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* pci/host-rockchip:
PCI: rockchip: Move the deassert of pm/aclk/pclk after phy_init()
PCI: rockchip: Split out rockchip_cfg_atu()
PCI: rockchip: Clean up bit definitions for PCIE_RC_CONFIG_LCS
PCI: rockchip: Correct the use of FTS mask
PCI: rockchip: Remove the pointer to L1 substate cap
PCI: rockchip: Specify the link capability
PCI: rockchip: Fix negotiated lanes calculation
PCI: rockchip: Add Kconfig COMPILE_TEST
PCI: rockchip: Mark RC as common clock architecture
PCI: rockchip: Provide captured slot power limit and scale
PCI: rockchip: Add three new resets as required properties
PCI: Don't attempt to claim shadow copies of ROM
PCI: designware: Check for iATU unroll support after initializing host
PCI: qcom: Fix pp->dev usage before assignment
PCI: designware-plat: Update author email address
PCI: layerscape: Fix drvdata usage before assignment
PCI: designware-plat: Change maintainer to Jose Abreu
pci_update_resource() updates a hardware BAR so its address matches the
kernel's struct resource UNLESS it's a disabled ROM BAR. We only update
those when we enable the ROM.
It's not obvious from the code why ROM BARs should be handled specially.
Apparently there are Matrox devices with defective ROM BARs that read as
zero when disabled. That means that if pci_enable_rom() reads the disabled
BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and
writes it back, it would enable the ROM at address zero.
Add comments and references to explain why we can't make the code look more
rational.
The code changes are from 755528c860 ("Ignore disabled ROM resources at
setup") and 8085ce084c ("[PATCH] Fix PCI ROM mapping").
Link: https://lkml.org/lkml/2005/8/30/138
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
pci_std_update_resource() only deals with standard BARs, so we don't have
to worry about the complications of VF BARs in an SR-IOV capability.
Compute the BAR address inline and remove pci_resource_bar(). That makes
pci_iov_resource_bar() unused, so remove that as well.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
The BAR property bits (0-3 for memory BARs, 0-1 for I/O BARs) are supposed
to be read-only, but we do save them in res->flags and include them when
updating the BAR.
Mask the I/O property bits with ~PCI_BASE_ADDRESS_IO_MASK (0x3) instead of
PCI_REGION_FLAG_MASK (0xf) to make it obvious that we can't corrupt bits
2-3 of I/O addresses.
Use PCI_ROM_ADDRESS_MASK for ROM BARs. This means we'll only check the top
21 bits (instead of the 28 bits we used to check) of a ROM BAR to see if
the update was successful.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
VF BARs are read-only zero, so updating VF BARs will not have any effect.
See the SR-IOV spec r1.1, sec 3.4.1.11.
We already ignore these updates because of 70675e0b6a ("PCI: Don't try to
restore VF BARs"); this merely restructures it slightly to make it easier
to split updates for standard and SR-IOV BARs.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM
and the device never sees accesses to it and doesn't respond to it. We
don't have to route the shadow range to the PCI device, and the device
doesn't have to claim the range.
Previously we treated the shadow copy as though it were the ROM BAR, and we
failed to claim it because the region wasn't routed to the device:
pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
pci_bus 0000:01: Allocating resources
pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window
The failure path of pcibios_allocate_dev_rom_resource() cleared out the
resource start address, which also caused the following ioremap() warning:
WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370
ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff
Handle an option ROM shadow copy as RAM, without trying to insert it into
the iomem resource tree.
This fixes a regression caused by 0c0e0736ac ("PCI: Set ROM shadow
location in arch code, not in PCI core"), which appeared in v4.6. The
regression causes video device initialization to fail. This was reported
on AMD Turks, but it likely affects others as well.
Fixes: 0c0e0736ac ("PCI: Set ROM shadow location in arch code, not in PCI core")
Reported-and-tested-by: Vecu Bosseur <vecu.bosseur@gmail.com>
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496
Link: https://bugzilla.kernel.org/show_bug.cgi?id=175391
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1352272
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.6+
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* pci/aer:
PCI/AER: Clear error status registers during enumeration and restore
* pci/hotplug:
PCI: pciehp: Queue power work requests in dedicated function
* pci/misc:
PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum
x86/PCI: Make pci_subsys_init() static
PCI: Add builtin_pci_driver() to avoid registration boilerplate
PCI: Remove unnecessary "if" statement
* pci/msi:
x86/PCI: Don't alloc pcibios-irq when MSI is enabled
PCI/MSI: Export all remapped MSIs to sysfs attributes
PCI: Disable MSI on SiS 761
* pci/resource:
sparc/PCI: Add mem64 resource parsing for root bus
PCI: Expand Enhanced Allocation BAR output
PCI: Make Enhanced Allocation bitmasks more obvious
PCI: Handle Enhanced Allocation capability for SR-IOV devices
PCI: Add support for Enhanced Allocation devices
PCI: Add Enhanced Allocation register entries
PCI: Handle IORESOURCE_PCI_FIXED when assigning resources
PCI: Handle IORESOURCE_PCI_FIXED when sizing resources
PCI: Clear IORESOURCE_UNSET when reverting to firmware-assigned address
* pci/virtualization:
PCI: Fix sriov_enable() error path for pcibios_enable_sriov() failures
PCI: Wait 1 second between disabling VFs and clearing NumVFs
PCI: Reorder pcibios_sriov_disable()
PCI: Remove VFs in reverse order if virtfn_add() fails
PCI: Remove redundant validation of SR-IOV offset/stride registers
PCI: Set SR-IOV NumVFs to zero after enumeration
PCI: Enable SR-IOV ARI Capable Hierarchy before reading TotalVFs
PCI: Don't try to restore VF BARs
If pci_assign_resource() fails to assign space for a BAR, we may restore
the BAR to whatever firmware left there at boot-time (this depends on
whether the arch implements pcibios_retrieve_fw_addr()). The messages we
print are not as useful as they could be:
pci 0000:00:01.0: BAR 15: assigned [mem 0xc0000000-0xc01fffff 64bit pref]
pci 0000:01:00.0: BAR 0: no space for [mem size 0x10000000 pref]
pci 0000:01:00.0: BAR 0: trying firmware assignment [mem size 0x10000000 pref]
pci 0000:01:00.0: BAR 0: [mem size 0x10000000 pref] conflicts with PCI Bus 0000:00 [mem 0xc0000000-0xffffffff window]
The last two lines should contain the actual BAR address, not the size.
Clear IORESOURCE_UNSET so we print the address. If requesting the
firmware-assigned resource fails, mark it IORESOURCE_UNSET again.
This is a cosmetic change to clarify the message: previously, if
pci_revert_fw_address() succeeded, pci_assign_resource() cleared
IORESOURCE_UNSET anyway, so this isn't really a functional change.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c50
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
VF BARs are read-only zero, so updating VF BARs will not have any effect.
See the SR-IOV spec r1.1, sec 3.4.1.11.
Don't update VF BARs in pci_restore_bars().
This avoids spurious "BAR %d: error updating" messages that we see when
doing vfio pass-through after 6eb7018705 ("vfio-pci: Move idle devices to
D3hot power state").
[bhelgaas: changelog, fix whitespace]
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If a BAR is not inside any upstream bridge window, or if it conflicts with
another resource, mark it as IORESOURCE_UNSET so we don't try to use it.
We may be able to assign a different address for it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Print messages about failures in pci_assign_resource(). We can drop the
"by-hand" message from _pci_assign_resource() because %pR now prints the
size rather than the address if the resource hasn't been assigned.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Previously we returned zero for success or 1 for failure. This changes
that so we return zero for success or a negative errno for failure.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Return errors immediately so the straightline path is the normal,
no-error path. No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If we have space assigned to a resource, we try to expand the resource
(e.g., to accommodate SR-IOV resources), and the expansion attempt fails,
we should keep the original assignment.
After bd064f0a23 ("PCI: Mark resources as IORESOURCE_UNSET if we can't
assign them"), we left the resource marked IORESOURCE_UNSET when the
expansion failed, even if it had originally been set. That caused errors
like this:
pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit pref] not assigned
pci 0003:00:00.0: Error enabling bridge (-22), continuing
Fix this by restoring the original flags when reassignment fails.
[bhelgaas: reworked to simplify, changelog]
Fixes: bd064f0a23 ("PCI: Mark resources as IORESOURCE_UNSET if we can't assign them")
Signed-off-by: Guo Chao <yan@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.15+
Merge quoted strings that are broken across lines into a single entity.
The compiler merges them anyway, but checkpatch complains about it, and
merging them makes it easier to grep for strings.
No functional change.
[bhelgaas: changelog, do the same for everything under drivers/pci]
Signed-off-by: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move EXPORT_SYMBOL so it immediately follows the function or variable.
No functional change.
[bhelgaas: squash similar changes, fix hotplug, probe, rom, search, too]
Signed-off-by: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* dma-api:
iommu/exynos: Remove unnecessary "&" from function pointers
DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions
DMA-API: Fix duplicated word in DMA-API-HOWTO.txt
DMA-API: Capitalize "CPU" consistently
sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory()
DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t
DMA-API: Clarify physical/bus address distinction
* pci/virtualization:
PCI: Mark RTL8110SC INTx masking as broken
* pci/msi:
PCI/MSI: Remove pci_enable_msi_block()
* pci/misc:
PCI: Remove pcibios_add_platform_entries()
s390/pci: use pdev->dev.groups for attribute creation
PCI: Move Open Firmware devspec attribute to PCI common code
* pci/resource:
PCI: Add resource allocation comments
PCI: Simplify __pci_assign_resource() coding style
PCI: Change pbus_size_mem() return values to be more conventional
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
PCI: Support BAR sizes up to 8GB
resources: Clarify sanity check message
PCI: Don't add disabled subtractive decode bus resources
PCI: Don't print anything while decoding is disabled
PCI: Don't set BAR to zero if dma_addr_t is too small
PCI: Don't convert BAR address to resource if dma_addr_t is too small
PCI: Reject BAR above 4GB if dma_addr_t is too small
PCI: Fail safely if we can't handle BARs larger than 4GB
x86/gart: Tidy messages and add bridge device info
x86/gart: Replace printk() with pr_info()
x86/PCI: Move pcibios_assign_resources() annotation to definition
x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED
x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources
x86/PCI: Fix Broadcom CNB20LE unintended sign extension
Add comments in the code to match the allocation strategy of 7c671426dfc3
("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources").
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If an allocation succeeds, we can return success immediately. Then we
don't have to test for success in the subsequent code.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
None of these files are actually using any __init type directives and hence
don't need to include <linux/init.h>. Most are just a left over from
__devinit and __cpuinit removal, or simply due to code getting copied from
one driver to the next.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Don't enable memory or I/O decoding if we haven't assigned or claimed the
BAR's resource.
If we enable decoding for a BAR that hasn't been assigned an address, we'll
likely cause bus conflicts. This declines to enable decoding for resources
with IORESOURCE_UNSET.
Note that drivers can use pci_enable_device_io() or pci_enable_device_mem()
if they only care about specific types of BARs. In that case, we don't
bother checking whether the corresponding resources are assigned or
claimed.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If the IORESOURCE_UNSET bit is set, it means we haven't assigned an address
yet, so don't try to claim the region.
Also, make the error messages more uniform and add info about which BAR is
involved.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Check to make sure we don't update a BAR with an address we haven't
assigned.
If we haven't assigned an address to a resource, we shouldn't write it to a
BAR. This isn't a problem for the usual path via pci_assign_resource(),
which clears IORESOURCE_UNSET before calling pci_update_resource(), but
paths like pci_restore_bars() can call this for resources we haven't
assigned.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Clear IORESOURCE_UNSET when we assign an address to a resource, not when we
write the address to the BAR.
Also, drop the "BAR %d: set to %pR" message; this is mostly redundant with
the "BAR %d: assigned %pR" message from pci_assign_resource().
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When assigning addresses to resources, mark them with IORESOURCE_UNSET
before we start and clear IORESOURCE_UNSET if assignment is successful.
That means that if we print the resource during assignment, we will show
the size, not a meaningless address.
Also, clear IORESOURCE_UNSET if we do assign an address, so we print the
address when it is valid.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Fix whitespace, capitalization, and spelling errors. No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.
Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reorder functions so __pci_assign_resource(), _pci_assign_resource(),
and pci_assign_resource() are closer together. No code change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
_pci_assign_resource() took an int "size" argument, which meant that
sizes larger than 4GB were truncated. Change type to resource_size_t.
[bhelgaas: changelog]
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When we update 64-bit BARs, we have to perform two config writes. Between
the writes, the half-written BAR value could match a MEM access intended
for another device. This could result in corruption of this device (for
writes) or an unexpected response machine check (for reads).
To prevent this, disable MEM decoding while updating such BARs. This uses
the same safety test as 253d2e5498, which disables both MEM and IO while
sizing BARs, namely, we don't disable decoding for host bridge devices.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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>
This allows us to move the definition of struct resource_list to
setup_bus.c and later convert resource_list to a regular list.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
During debug of one SRIOV enabled hotplug device, we found found that
add_size is not passed properly.
The device has devices under two level bridges:
+-[0000:80]-+-00.0-[81-8f]--
| +-01.0-[90-9f]--
| +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0 Oracle Corporation Device
| | \-03.0-[a3]--+-00.0 Oracle Corporation Device
Which means later the parent bridge will not try to add a big enough range:
[ 557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff]
[ 557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref]
[ 557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff]
[ 557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref]
[ 557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff]
[ 557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref]
[ 557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000)
[ 557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff]
[ 557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000)
[ 557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]
It turns out we did not calculate size1 properly.
static resource_size_t calculate_memsize(resource_size_t size,
resource_size_t min_size,
resource_size_t size1,
resource_size_t old_size,
resource_size_t align)
{
if (size < min_size)
size = min_size;
if (old_size == 1 )
old_size = 0;
if (size < old_size)
size = old_size;
size = ALIGN(size + size1, align);
return size;
}
We should not pass add_size with min_size in calculate_memsize since
that will make add_size not contribute final add_size.
So just pass add_size with size1 to calculate_memsize().
With this change, we should have chance to remove extra addon in
pci_reassign_resource.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch converts the underlying maintenance aspects of FW-assigned
BIOS BAR values from a statically allocated array within struct pci_dev
to a list of temporary, stand alone, entries.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
pci_revert_fw_address() is used to reinstate a PCI device's original
FW-assigned BIOS BAR value(s) if normal resource assignment fails.
When attempting to reinstate an address, the point within the resource
tree from which to attempt the new resource request should be the parent
resource corresponding to the device, not the base of the resource tree
(ioport_resource or iomem_resource). For PCI devices this would
typically be the resource corresponding to the upstream PCI host bridge
or P2P bridge aperture.
This patch sets the point within the resource tree to attempt a new
resource assignment request to the PCI device's parent resource and only
if that fails does it fall back to the base ioport_resource or
iomem_resource.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
When the runtime PM is activated on PCI, if a device switches state
frequently (e.g. an EHCI controller with autosuspending USB devices
connected) the PCI configuration traces might be very verbose in the
kernel log. Let's guard those traces with DEBUG condition.
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
They were implicitly getting it from device.h --> module.h but
we want to clean that up. So add the minimal header for these
macros.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Currently pci-bridges are allocated enough resources to satisfy their immediate
requirements. Any additional resource-requests fail if additional free space,
contiguous to the one already allocated, is not available. This behavior is not
reasonable since sufficient contiguous resources, that can satisfy the request,
are available at a different location.
This patch provides the ability to expand and relocate a allocated resource.
v2: Changelog: Fixed size calculation in pci_reassign_resource()
v3: Changelog : Split this patch. The resource.c changes are already
upstream. All the pci driver changes are in here.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
If we fail to assign resources to a PCI BAR, this patch makes us try the
original address from BIOS rather than leaving it disabled.
Linux tries to make sure all PCI device BARs are inside the upstream
PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
Windows does similar reassignment.
Before this patch, if we could not move a BAR into an aperture, we left
the resource unassigned, i.e., at address zero. Windows leaves such BARs
at the original BIOS addresses, and this patch makes Linux do the same.
This is a bit ugly because we disable the resource long before we try to
reassign it, so we have to keep track of the BIOS BAR address somewhere.
For lack of a better place, I put it in the struct pci_dev.
I think it would be cleaner to attempt the assignment immediately when the
claim fails, so we could easily remember the original address. But we
currently claim motherboard resources in the middle, after attempting to
claim PCI resources and before assigning new PCI resources, and changing
that is a fairly big job.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263
Reported-by: Andrew <nitr0@seti.kr.ua>
Tested-by: Andrew <nitr0@seti.kr.ua>
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We can often deal with PCI resource issues by moving devices around. In
that case, there's no point in alarming the user with messages like these.
There are many bug reports where the message itself is the only problem,
e.g., https://bugs.launchpad.net/ubuntu/+source/linux/+bug/413419 .
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With request_resource_conflict(), we can learn what the actual conflict is,
so print that info for debugging purposes.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
