linux-toradex.git/drivers/pci/setup-res.c, branch v4.9.97

PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

2018-04-08T10:12:43+00:00

commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.

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 
Signed-off-by: Bjorn Helgaas 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

PCI: Ignore BAR updates on virtual functions

2017-03-22T11:43:37+00:00

[ Upstream commit 63880b230a4af502c56dde3d4588634c70c66006 ]

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 70675e0b6a1a ("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 
Reviewed-by: Gavin Shan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Update BARs using property bits appropriate for type

2017-03-22T11:43:37+00:00

[ Upstream commit 45d004f4afefdd8d79916ee6d97a9ecd94bb1ffe ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Add comments about ROM BAR updating

2017-03-22T11:43:36+00:00

[ Upstream commit 0b457dde3cf8b7c76a60f8e960f21bbd4abdc416 ]

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 755528c860b0 ("Ignore disabled ROM resources at
setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping").

Link: https://lkml.org/lkml/2005/8/30/138
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Gavin Shan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Remove pci_resource_bar() and pci_iov_resource_bar()

2017-03-22T11:43:36+00:00

[ Upstream commit 286c2378aaccc7343ebf17ec6cd86567659caf70 ]

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 
Reviewed-by: Gavin Shan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Separate VF BAR updates from standard BAR updates

2017-03-22T11:43:36+00:00

[ Upstream commit 6ffa2489c51da77564a0881a73765ea2169f955d ]

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 
Reviewed-by: Gavin Shan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Don't attempt to claim shadow copies of ROM

2016-11-08T20:25:24+00:00

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 0c0e0736acad ("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: 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core")
Reported-and-tested-by: Vecu Bosseur 
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 
CC: stable@vger.kernel.org	# v4.6+

PCI: Don't assign or reassign immutable resources

2016-03-08T18:14:31+00:00

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

Merge branches 'pci/aer', 'pci/hotplug', 'pci/misc', 'pci/msi', 'pci/resource' and 'pci/virtualization' into next

2015-11-02T21:57:03+00:00

* 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

PCI: Clear IORESOURCE_UNSET when reverting to firmware-assigned address

2015-09-23T19:14:02+00:00

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