- Add j721e DT and driver support for 'num-lanes' for devices that support
  x1, x2, or x4 Links (Matt Ranostay)

- Add j721e DT compatible strings and driver support for j784s4 (Matt Ranostay)

- Make TI J721E Kconfig depend on ARCH_K3 since the hardware is specific to
  those TI SoC parts (Peter Robinson)

* pci/controller/cadence:
  PCI: j721e: Make TI J721E depend on ARCH_K3
  PCI: j721e: Add TI J784S4 PCIe configuration
  PCI: j721e: Add PCIe 4x lane selection support
  PCI: j721e: Add per platform maximum lane settings
  dt-bindings: PCI: ti,j721e-pci-*: Add j784s4-pci-* compatible strings
  dt-bindings: PCI: ti,j721e-pci-*: Add checks for num-lanes

- Add DT property "brcm,clkreq-mode" and driver support for different
  CLKREQ# modes (Jim Quinlan)

* pci/controller/broadcom:
  PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
  dt-bindings: PCI: brcmstb: Add property "brcm,clkreq-mode"

- Add ACS quirk for more Zhaoxin Root Ports (LeoLiuoc)

* pci/virtualization:
  PCI: Add ACS quirk for more Zhaoxin Root Ports

- Do dma_mrpc cleanup during switchtec_pci_remove() to match its devm
  ioremapping in switchtec_pci_probe().  Previously the cleanup was done in
  stdev_release(), which used stale pointers if stdev->cdev happened to be
  open when the PCI device was removed (Daniel Stodden)

* pci/switchtec:
  PCI: switchtec: Fix stdev_release() crash after surprise hot remove

- Restructure pci_dev_for_each_resource() to avoid computing the address of
  an out-of-bounds array element (the bounds check was performed later so
  the element was never actually *read*, but it's nicer to avoid even
  computing an out-of-bounds address) (Andy Shevchenko)

* pci/resource:
  PCI: Avoid potential out-of-bounds read in pci_dev_for_each_resource()

- Remove documentation for obsolete pci_p2pdma_map_sg() (Tadeusz Struk)

* pci/p2pdma:
  PCI/P2PDMA: Remove reference to pci_p2pdma_map_sg()

- Log device type (Root Port, Switch Port, etc) during enumeration (Bjorn
  Helgaas)

- Log resource names (BAR 0, VF BAR 0, bridge window, etc) consistently
  instead of a mix of names and "reg 0x10" (Puranjay Mohan, Bjorn Helgaas)

- Log bridges before devices below the bridges (Bjorn Helgaas)

* pci/enumeration-logging:
  PCI: Log bridge info when first enumerating bridge
  PCI: Log bridge windows conditionally
  PCI: Supply bridge device, not secondary bus, to read window details
  PCI: Move pci_read_bridge_windows() below individual window accessors
  PCI: Use resource names in PCI log messages
  PCI: Update BAR # and window messages
  PCI: Log device type during enumeration

- Convert pci-host-common.c platform .remove() callback to .remove_new()
  returning 'void' since it's not useful to return error codes here (Uwe
  Kleine-König)

- Log a message about updating AMD USB controller class code (so dwc3, not
  xhci, claims it) only when we actually change it (Guilherme G.  Piccoli)

- Use PCI_HEADER_TYPE_* instead of literals in x86, powerpc, SCSI lpfc
  (Ilpo Järvinen)

- Clean up open-coded PCIBIOS return code mangling (Ilpo Järvinen)

- Fix 64GT/s effective data rate calculation to use 1b/1b encoding rather
  than the 8b/10b or 128b/130b used by lower rates (Ilpo Järvinen)

* pci/enumeration:
  PCI: Fix 64GT/s effective data rate calculation
  x86/pci: Clean up open-coded PCIBIOS return code mangling
  scsi: lpfc: Use PCI_HEADER_TYPE_MFD instead of literal
  powerpc/fsl-pci: Use PCI_HEADER_TYPE_MASK instead of literal
  x86/pci: Use PCI_HEADER_TYPE_* instead of literals
  PCI: Only override AMD USB controller if required
  PCI: host-generic: Convert to platform remove callback returning void

- Reserve ECAM if BIOS didn't include it in PNP0C02 _CRS (Bjorn Helgaas)

- Add MMCONFIG/ECAM debug logging (Bjorn Helgaas)

- Rename 'MMCONFIG' to 'ECAM' to match spec usage (Bjorn Helgaas)

* pci/ecam:
  x86/pci: Reorder pci_mmcfg_arch_map() definition before calls
  x86/pci: Return pci_mmconfig_add() failure early
  x86/pci: Comment pci_mmconfig_insert() obscure MCFG dependency
  x86/pci: Rename pci_mmcfg_check_reserved() to pci_mmcfg_reserved()
  x86/pci: Rename acpi_mcfg_check_entry() to acpi_mcfg_valid_entry()
  x86/pci: Rename 'MMCONFIG' to 'ECAM', use pr_fmt
  x86/pci: Add MCFG debug logging
  x86/pci: Reword ECAM EfiMemoryMappedIO logging to avoid 'reserved'
  x86/pci: Reserve ECAM if BIOS didn't include it in PNP0C02 _CRS

- Log AER errors as "Correctable" (not "Corrected") or "Uncorrectable" to
  match spec terminology (Bjorn Helgaas)

- Decode Requester ID when no error info found instead of printing the raw
  hex value (Bjorn Helgaas)

* pci/aer:
  PCI/AER: Use explicit register sizes for struct members
  PCI/AER: Decode Requester ID when no error info found
  PCI/AER: Use 'Correctable' and 'Uncorrectable' spec terms for errors

The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:

"safe" -- No CLKREQ# expected or required, refclk is always provided.  This
    mode should work for all devices but is not be capable of any refclk
    power savings.

"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
    CPM and ASPM L0s and L1.  Provides Clock Power Management, L0s, and L1,
    but cannot provide L1 substate (L1SS) power savings. If the downstream
    device connected to the RC is L1SS capable AND the OS enables L1SS, all
    PCIe traffic may abruptly halt, potentially hanging the system.

"default" -- Bidirectional CLKREQ# between the RC and downstream device.
    Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
    Power Management; specifically, may not be able to meet the T_CLRon max
    timing of 400ns as specified in "Dynamic Clock Control", section
    3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification.  This
    situation is atypical and should happen only with older devices.

Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode.  But now there is interest in
activating L1SS power savings from STB/CM customers, which requires "aspm"
mode.  In addition, a bug was filed for RPi4 CM platform because most
devices did not work in "no-l1ss" mode.

Note that the mode is specified by the DT property "brcm,clkreq-mode".  If
this property is omitted, then "default" mode is chosen.

Note: Since L1 substates are now possible, a modification was made
regarding an internal bus timeout: During long periods of the PCIe RC HW
being in an L1SS sleep state, there may be a timeout on an internal bus
access, even though there may not be any PCIe access involved.  Such a
timeout will cause a subsequent CPU abort.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Link: https://lore.kernel.org/linux-pci/20231113185607.1756-3-james.quinlan@broadcom.comTested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

The Broadcom STB/CM PCIe HW -- a core that is also used by RPi SOCs --
requires the driver to deliberately place the RC HW one of three CLKREQ#
modes.  The "brcm,clkreq-mode" property allows the user to override the
default setting.  If this property is omitted, the default mode shall be
"default".

Link: https://lore.kernel.org/linux-pci/20231113185607.1756-2-james.quinlan@broadcom.comTested-by: Cyril Brulebois <cyril@debamax.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>

The J721E PCIe is hardware specific to TI SoC parts so add a dependency
on that so it's available for those SoC parts and for compile testing but
not necessarily everyone who enables the Cadence PCIe controller.

Link: https://lore.kernel.org/linux-pci/20240104213910.1426843-1-pbrobinson@gmail.comSigned-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

Add PCIe configuration for J784S4 SoC platform which has 4x lane
support.

Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-6-s-vadapalli@ti.comTested-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Roger Quadros <rogerq@kernel.org>

aer_irq() reads the AER Root Error Status and Error Source Identification
(PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC) registers directly into
struct aer_err_source.  Both registers are 32 bits, so declare the members
explicitly as "u32" instead of "unsigned int".

Similarly, aer_get_device_error_info() reads the AER Header Log
(PCI_ERR_HEADER_LOG) registers, which are also 32 bits, into struct
aer_header_log_regs.  Declare those members as "u32" as well.

No functional changes intended.

Link: https://lore.kernel.org/r/20231206224231.732765-4-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

When a device with AER detects an error, it logs error information in its
own AER Error Status registers.  It may send an Error Message to the Root
Port (RCEC in the case of an RCiEP), which logs the fact that an Error
Message was received (Root Error Status) and the Requester ID of the
message source (Error Source Identification).

aer_print_port_info() prints the Requester ID from the Root Port Error
Source in the usual Linux "bb:dd.f" format, but when find_source_device()
finds no error details in the hierarchy below the Root Port, it printed the
raw Requester ID without decoding it.

Decode the Requester ID in the usual Linux format so it matches other
messages.

Sample message changes:

  - pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5
  - pcieport 0000:00:1c.5: AER: can't find device of ID00e5
  + pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5
  + pcieport 0000:00:1c.5: AER: found no error details for 0000:00:1c.5

Link: https://lore.kernel.org/r/20231206224231.732765-3-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

The PCIe spec classifies errors as either "Correctable" or "Uncorrectable".
Previously we printed these as "Corrected" or "Uncorrected".  To avoid
confusion, use the same terms as the spec.

One confusing situation is when one agent detects an error, but another
agent is responsible for recovery, e.g., by re-attempting the operation.
The first agent may log a "correctable" error but it has not yet been
corrected.  The recovery agent must report an uncorrectable error if it is
unable to recover.  If we print the first agent's error as "Corrected", it
gives the false impression that it has already been resolved.

Sample message change:

  - pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
  + pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5

Link: https://lore.kernel.org/r/20231206224231.732765-2-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

Unlike the lower rates, the PCIe 64GT/s Data Rate uses 1b/1b encoding, not
128b/130b (PCIe r6.1 sec 1.2, Table 1-1).  Correct the PCIE_SPEED2MBS_ENC()
calculation to reflect that.

Link: https://lore.kernel.org/r/20240102172701.65501-1-ilpo.jarvinen@linux.intel.comSigned-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Log bridge secondary/subordinate bus and window information at the same
time we log the bridge BARs, just after discovering the bridge and before
scanning the bridge's secondary bus.  This logs the bridge and downstream
devices in a more logical order:

  - pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
  - pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
  - pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
  - pci 0000:00:01.0: PCI bridge to [bus 01]
  - pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]

  + pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
  + pci 0000:00:01.0: PCI bridge to [bus 01]
  + pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
  + pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
  + pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]

Note that we read the windows into a temporary struct resource that is
thrown away, not into the resources in the struct pci_bus.

The windows may be adjusted after we know what downstream devices require,
and those adjustments are logged as they are made.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Previously pci_read_bridge_io(), pci_read_bridge_mmio(), and
pci_read_bridge_mmio_pref() unconditionally logged the bridge window
resource.  A future change will call these functions earlier and more
often.  Add a "log" parameter so callers can control whether to generate
the log message.  No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Previously we logged information about devices *below* the bridge before
logging information about the bridge itself, e.g.,

  pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
  pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200
  pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
  pci 0000:00:01.0: PCI bridge to [bus 01]
  pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]

This is partly because the bridge windows are read in this path:

  pci_scan_child_bus_extend
    for (devfn = 0; devfn < 256; devfn += 8)
      pci_scan_slot(bus, devfn)       # scan below bridge
    pcibios_fixup_bus(bus)
      pci_read_bridge_bases(bus)      # read bridge windows
        pci_read_bridge_io(bus)

Remove the assumption that the secondary (child) pci_bus already exists by
passing in the bridge device (instead of the pci_bus) and a resource
pointer when reading bridge windows.  A future change can use this to log
the bridge details before we enumerate the devices below the bridge.

No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Move pci_read_bridge_windows() below the functions that read the I/O,
memory, and prefetchable memory windows, so pci_read_bridge_windows() can
use them in the future.  No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Use the pci_resource_name() to get the name of the resource and use it
while printing log messages.

[bhelgaas: rename to match struct resource * names, also use names in other
BAR messages]
Link: https://lore.kernel.org/r/20211106112606.192563-3-puranjay12@gmail.comSigned-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The PCI log messages print the register offsets at some places and BAR
numbers at other places. There is no uniformity in this logging mechanism.
It would be better to print names than register offsets.

Add a helper function that aids in printing more meaningful information
about the BAR numbers like "VF BAR", "ROM", "bridge window", etc.  This
function can be called while printing PCI log messages.

[bhelgaas: fold in Lukas' static array suggestion from
https://lore.kernel.org/all/20211106115831.GA7452@wunner.de/]
Link: https://lore.kernel.org/r/20211106112606.192563-2-puranjay12@gmail.comSigned-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Log the device type when enumeration a device.  Sample output changes:

  - pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
  + pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 conventional PCI endpoint

  - pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400
  + pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400 PCIe Root Port
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Add support for setting of two-bit field that allows selection of 4x lane
PCIe which was previously limited to only 2x lanes.

Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-5-s-vadapalli@ti.comSigned-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>

Various platforms have different maximum amount of lanes that can be
selected. Add max_lanes to struct j721e_pcie to allow for detection of this
which is needed to calculate the needed bitmask size for the possible lane
count.

Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-4-s-vadapalli@ti.comSigned-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>

Add definition for j784s4-pci-ep and j784s4-pci-host devices along with
schema checks for num-lanes.

Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-3-s-vadapalli@ti.comSigned-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Add num-lanes schema checks based on compatible string on available lanes
for that platform.

Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-2-s-vadapalli@ti.comSigned-off-by: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Achal Verma <a-verma1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Add more Root Port Device IDs to pci_quirk_zhaoxin_pcie_ports_acs() for
some new Zhaoxin platforms.

Fixes: 299bd044 ("PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports")
Link: https://lore.kernel.org/r/20231211091543.735903-1-LeoLiu-oc@zhaoxin.comSigned-off-by: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
[bhelgaas: update subject, drop changelog, add Fixes, add stable tag, fix
whitespace, wrap code comment]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: <stable@vger.kernel.org>	# 5.7

The typical style is to define functions before calling them.  Move
pci_mmcfg_arch_map() and pci_mmcfg_arch_unmap() earlier so they're defined
before they're called.  No functional change intended.

Link: https://lore.kernel.org/r/20231121183643.249006-10-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

If pci_mmconfig_alloc() fails, return the failure early so it's obvious
that the failure is the exception, and the success is the normal case.  No
functional change intended.

Link: https://lore.kernel.org/r/20231121183643.249006-9-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

In pci_mmconfig_insert(), there's no reference to "addr" between locking
pci_mmcfg_lock and testing "addr", so it *looks* like we should move the
test before the lock.

But 07f9b61c ("x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at
address zero") did that, which broke things by returning -EINVAL when
"addr" is zero instead of -EEXIST.

So 07f9b61c was reverted by 67d470e0 ("Revert "x86/PCI: MMCONFIG:
Check earlier for MMCONFIG region at address zero"").

Add a comment about this issue to prevent it from happening again.

Link: https://lore.kernel.org/r/20231121183643.249006-8-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

"pci_mmcfg_check_reserved()" doesn't give a hint about what the boolean
return value means.  Rename it to pci_mmcfg_reserved() so testing
"if (pci_mmcfg_reserved())" makes sense.

Update callers to treat the return value as boolean instead of comparing
with 0.

Link: https://lore.kernel.org/r/20231121183643.249006-7-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

"acpi_mcfg_check_entry()" doesn't give a hint about what the return value
means.  Rename it to "acpi_mcfg_valid_entry()", convert the return value to
bool, and update the return values and callers to match so testing
"if (acpi_mcfg_valid_entry())" makes sense.

Link: https://lore.kernel.org/r/20231121183643.249006-6-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The "MMCONFIG" term is not used in PCI/PCIe specs.  Replace it with "ECAM",
the term used in PCIe r6.0, sec 7.2.2.

Define pr_fmt() instead of repeating PREFIX in every log message.

Link: https://lore.kernel.org/r/20231121183643.249006-5-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

MCFG handling is a frequent source of problems.  Add more logging to aid in
debugging.

Enable the logging with CONFIG_DYNAMIC_DEBUG=y and the kernel boot
parameter 'dyndbg="file arch/x86/pci +p"'.

Link: https://lore.kernel.org/r/20231121183643.249006-4-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

fd3a8cff ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM
space") added the concept of using the EFI memory map to help decide
whether ECAM space mentioned in the MCFG table is valid.

Unfortunately it described that EfiMemoryMappedIO space as "reserved", but
it is actually not *reserved* by the EFI memory map.  EfiMemoryMappedIO
only means the firmware requested that the OS map this space for use by
firmware runtime services.

Change the dmesg logging to describe it as simply "EfiMemoryMappedIO", not
as "reserved as EfiMemoryMappedIO".  A previous commit actually *does*
reserve the space if ACPI PNP0C01/02 devices haven't done so:

  - PCI: ECAM at [mem 0xe0000000-0xefffffff] reserved as EfiMemoryMappedIO
  + PCI: ECAM at [mem 0xe0000000-0xefffffff] is EfiMemoryMappedIO; assuming valid
    PCI: ECAM [mem 0xe0000000-0xefffffff] reserved to work around lack of ACPI motherboard _CRS

Link: https://lore.kernel.org/r/20231121183643.249006-3-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Tomasz, Sebastian, and some Proxmox users reported problems initializing
ixgbe NICs.

I think the problem is that ECAM space described in the ACPI MCFG table is
not reserved via a PNP0C02 _CRS method as required by the PCI Firmware spec
(r3.3, sec 4.1.2), but it *is* included in the PNP0A03 host bridge _CRS as
part of the MMIO aperture.

If we allocate space for a PCI BAR, we're likely to allocate it from that
ECAM space, which obviously cannot work.

This could happen for any device, but in the ixgbe case it happens because
it's an SR-IOV device and the BIOS didn't allocate space for the VF BARs,
so Linux reallocated the bridge window leading to ixgbe and put it on top
of the ECAM space.  From Tomasz' system:

  PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
  PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources
  pci_bus 0000:00: root bus resource [mem 0x80000000-0xfbffffff window]

  pci 0000:00:01.1: PCI bridge to [bus 02-03]
  pci 0000:00:01.1:   bridge window [mem 0xfb900000-0xfbbfffff]
  pci 0000:02:00.0: [8086:10fb] type 00 class 0x020000  # ixgbe
  pci 0000:02:00.0: reg 0x10: [mem 0xfba80000-0xfbafffff 64bit]
  pci 0000:02:00.0: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit] (contains BAR0 for 64 VFs)
  pci 0000:02:00.0: BAR 7: no space for [mem size 0x00100000 64bit]   # VF BAR 0

  pci_bus 0000:00: No. 2 try to assign unassigned res
  pci 0000:00:01.1: resource 14 [mem 0xfb900000-0xfbbfffff] released
  pci 0000:00:01.1: BAR 14: assigned [mem 0x80000000-0x806fffff]
  pci 0000:02:00.0: BAR 0: assigned [mem 0x80000000-0x8007ffff 64bit]
  pci 0000:02:00.0: BAR 7: assigned [mem 0x80204000-0x80303fff 64bit] # VF BAR 0

Fixes: 07eab090 ("efi/x86: Remove EfiMemoryMappedIO from E820 map")
Fixes: fd3a8cff ("x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM space")
Reported-by: Tomasz Pala <gotar@polanet.pl>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218050Reported-by: Sebastian Manciulea <manciuleas@protonmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218107
Link: https://forum.proxmox.com/threads/proxmox-8-kernel-6-2-16-4-pve-ixgbe-driver-fails-to-load-due-to-pci-device-probing-failure.131203/
Link: https://lore.kernel.org/r/20231121183643.249006-2-helgaas@kernel.orgTested-by: Tomasz Pala <gotar@polanet.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v6.2+

Per PCI Firmware spec r3.3, sec 2.5.2, 2.6.2, and 2.7, the return code for
these PCI BIOS interfaces is in 8 bits of the EAX register.  Previously it
was extracted by open-coded masks and shifting.

Name the return code bits with a #define and add pcibios_get_return_code()
to extract the return code to improve code readability. In addition,
replace zero test with PCIBIOS_SUCCESSFUL.

No functional changes intended.

Link: https://lore.kernel.org/r/20231124085924.13830-1-ilpo.jarvinen@linux.intel.comSigned-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>