linux.git/drivers/pci/setup-bus.c, branch v5.4.156

PCI: Avoid double hpmemsize MMIO window assignment

2020-10-01T11:17:19+00:00

[ Upstream commit c13704f5685deb7d6eb21e293233e0901ed77377 ]

Previously, the kernel sometimes assigned more MMIO or MMIO_PREF space than
desired.  For example, if the user requested 128M of space with
"pci=realloc,hpmemsize=128M", we sometimes assigned 256M:

  pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0xa00fffff] = 256M
  pci 0000:06:04.0: BAR 14: assigned [mem 0xa0200000-0xb01fffff] = 256M

With this patch applied:

  pci 0000:06:01.0: BAR 14: assigned [mem 0x90100000-0x980fffff] = 128M
  pci 0000:06:04.0: BAR 14: assigned [mem 0x98200000-0xa01fffff] = 128M

This happened when in the first pass, the MMIO_PREF succeeded but the MMIO
failed. In the next pass, because MMIO_PREF was already assigned, the
attempt to assign MMIO_PREF returned an error code instead of success
(nothing more to do, already allocated). Hence, the size which was actually
allocated, but thought to have failed, was placed in the MMIO window.

The bug resulted in the MMIO_PREF being added to the MMIO window, which
meant doubling if MMIO_PREF size = MMIO size. With a large MMIO_PREF, the
MMIO window would likely fail to be assigned altogether due to lack of
32-bit address space.

Change find_free_bus_resource() to do the following:

  - Return first unassigned resource of the correct type.
  - If there is none, return first assigned resource of the correct type.
  - If none of the above, return NULL.

Returning an assigned resource of the correct type allows the caller to
distinguish between already assigned and no resource of the correct type.

Add checks in pbus_size_io() and pbus_size_mem() to return success if
resource returned from find_free_bus_resource() is already allocated.

This avoids pbus_size_io() and pbus_size_mem() returning error code to
__pci_bus_size_bridges() when a resource has been successfully assigned in
a previous pass. This fixes the existing behaviour where space for a
resource could be reserved multiple times in different parent bridge
windows.

Link: https://lore.kernel.org/lkml/20190531171216.20532-2-logang@deltatee.com/T/#u
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203243
Link: https://lore.kernel.org/r/PS2P216MB075563AA6AD242AA666EDC6A80760@PS2P216MB0755.KORP216.PROD.OUTLOOK.COM
Reported-by: Kit Chow 
Reported-by: Nicholas Johnson 
Signed-off-by: Nicholas Johnson 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Mika Westerberg 
Reviewed-by: Logan Gunthorpe 
Signed-off-by: Sasha Levin

PCI: Don't disable bridge BARs when assigning bus resources

2020-02-14T21:34:09+00:00

commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 upstream.

Some PCI bridges implement BARs in addition to bridge windows.  For
example, here's a PLX switch:

  04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
            Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
	    (prog-if 00 [Normal decode])
      Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
      Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
      Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
      I/O behind bridge: 00002000-00003fff
      Memory behind bridge: 90000000-909fffff
      Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff

Previously, when the kernel assigned resource addresses (with the
pci=realloc command line parameter, for example) it could clear the struct
resource corresponding to the BAR.  When this happened, lspci would report
this BAR as "ignored":

   Region 0: Memory at  (32-bit, non-prefetchable) [size=256K]

This is because the kernel reports a zero start address and zero flags
in the corresponding sysfs resource file and in /proc/bus/pci/devices.
Investigation with 'lspci -x', however, shows the BIOS-assigned address
will still be programmed in the device's BAR registers.

It's clearly a bug that the kernel lost track of the BAR value, but in most
cases, this still won't result in a visible issue because nothing uses the
memory, so nothing is affected.  However, when an IOMMU is in use, it will
not reserve this space in the IOVA because the kernel no longer thinks the
range is valid.  (See dmar_init_reserved_ranges() for the Intel
implementation of this.)

Without the proper reserved range, a DMA mapping may allocate an IOVA that
matches a bridge BAR, which results in DMA accesses going to the BAR
instead of the intended RAM.

The problem was in pci_assign_unassigned_root_bus_resources().  When any
resource from a bridge device fails to get assigned, the code set the
resource's flags to zero.  This makes sense for bridge windows, as they
will be re-enabled later, but for regular BARs, it makes the kernel
permanently lose track of the fact that they decode address space.

Change pci_assign_unassigned_root_bus_resources() and
pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
for bridge *windows*, not bridge BARs.

Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com
[bhelgaas: commit log, check for pci_is_bridge()]
Reported-by: Kit Chow 
Signed-off-by: Logan Gunthorpe 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: Use PCI_SRIOV_NUM_BARS in loops instead of PCI_IOV_RESOURCE_END

2019-08-08T20:12:12+00:00

Writing loop conditions as "i < NUM" is a common C idiom; using "i <= END"
is unusual and thus prone to errors.  Change loops to use the former.

Link: https://lore.kernel.org/r/20190806140715.19847-1-efremov@linux.com
Signed-off-by: Denis Efremov 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Kuppuswamy Sathyanarayanan

PCI: Skip resource distribution when no hotplug bridges

2019-07-02T18:56:54+00:00

If "hotplug_bridges == 0", "!dev->is_hotplug_bridge" is always true, so the
loop that divides the remaining resources among hotplug-capable bridges
does nothing.

Check for "hotplug_bridges == 0" earlier, so we don't even have to compute
the amount of remaining resources.  No functional change intended.

Link: https://lore.kernel.org/r/PS2P216MB0642C7A485649D2D787A1C6F80000@PS2P216MB0642.KORP216.PROD.OUTLOOK.COM
Link: https://lore.kernel.org/r/20190622210310.180905-3-helgaas@kernel.org
Signed-off-by: Nicholas Johnson 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Logan Gunthorpe 
Reviewed-by: Mika Westerberg

PCI: Simplify pci_bus_distribute_available_resources()

2019-07-02T18:56:26+00:00

Reorder pci_bus_distribute_available_resources() to group related code
together.  No functional change intended.

Link: https://lore.kernel.org/r/PS2P216MB0642C7A485649D2D787A1C6F80000@PS2P216MB0642.KORP216.PROD.OUTLOOK.COM
Link: https://lore.kernel.org/r/20190622210310.180905-2-helgaas@kernel.org
Signed-off-by: Nicholas Johnson 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Mika Westerberg 
Reviewed-by: Logan Gunthorpe

PCI: Don't auto-realloc if we're preserving firmware config

2019-06-21T23:11:53+00:00

Prevent auto-enabling of bridges reallocation when the FW tells us that the
initial configuration must be preserved for a given host bridge.

Link: https://lore.kernel.org/r/20190615002359.29577-3-benh@kernel.crashing.org
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Bjorn Helgaas

Merge branch 'pci/trivial'

2019-05-13T23:34:48+00:00

  - Cleanup PCI register definitions, typos, etc (Bjorn Helgaas)

  - Remove unnecessary use of user-space types in CPER (Bjorn Helgaas)

  - Cleanup setup-bus.c comments & whitespace (Nicholas Johnson)

* pci/trivial:
  PCI: Cleanup setup-bus.c comments and whitespace
  CPER: Remove unnecessary use of user-space types
  CPER: Add UEFI spec references
  PCI: Fix comment typos
  PCI: Cleanup register definition width and whitespace

# Conflicts:
#	drivers/pci/pci.c
#	drivers/pci/setup-bus.c

PCI: Replace dev_printk(KERN_DEBUG) with dev_info(), etc

2019-05-09T12:49:58+00:00

Replace dev_printk(KERN_DEBUG) with dev_info(), etc to be more consistent
with other logging and avoid checkpatch warnings.

The KERN_DEBUG messages could be converted to dev_dbg(), but that depends
on CONFIG_DYNAMIC_DEBUG and DEBUG, and we want most of these messages to
*always* be in the dmesg log.

Link: https://lore.kernel.org/lkml/1555733240-19875-1-git-send-email-mohankumar718@gmail.com
Signed-off-by: Mohan Kumar 
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas

PCI: Cleanup setup-bus.c comments and whitespace

2019-05-07T20:53:08+00:00

Cleanup comments, kernel-doc, coding style.  No functional changes
intended; comment and whitespace changes only.

Link: https://lore.kernel.org/lkml/PS2P216MB06427E290A68CDB921FB4B2980250@PS2P216MB0642.KORP216.PROD.OUTLOOK.COM
Signed-off-by: Nicholas Johnson 
[bhelgaas: tidy related things throughout the file]
Signed-off-by: Bjorn Helgaas

PCI: Rely on config space header type, not class code

2019-01-30T16:57:08+00:00

The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).

When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code.  The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.

Suggested-by: Bjorn Helgaas 
Signed-off-by: Honghui Zhang 
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas