- Remove unnecessary forward declarations (Jim Quinlan)

- Prevent config space access when link is down (Jim Quinlan)

- Split post-link up initialization to brcm_pcie_start_link() (Jim Quinlan)

- Enable child bus device regulators described under Root Ports in DT (Jim
  Quinlan)

- Disable/enable regulators in suspend/resume (Jim Quinlan)

- Rename .map_bus() functions to end with 'map_bus' as they do in other
  drivers (Jim Quinlan)

* pci/ctrl/brcmstb:
  PCI: brcmstb: Rename .map_bus() functions to end with 'map_bus'
  PCI: brcmstb: Disable/enable regulators in suspend/resume
  PCI: brcmstb: Enable child bus device regulators from DT
  PCI: brcmstb: Split post-link up initialization to brcm_pcie_start_link()
  PCI: brcmstb: Prevent config space access when link is down
  PCI: brcmstb: Remove unnecessary forward declarations

- Add support for AER capability on emulated bridge (Pali Rohár)

- Add support for Slot capability on emulated bridge (Pali Rohár)

* pci/ctrl/aardvark:
  PCI: aardvark: Fix reporting Slot capabilities on emulated bridge
  PCI: aardvark: Add support for AER registers on emulated bridge

- Add ACS quirk for Broadcom BCM5750x multifunction NICs that isolate the
  functions but don't advertise an ACS capability (Pavan Chebbi)

* pci/virtualization:
  PCI: Add ACS quirk for Broadcom BCM5750x NICs

- Replace sparc pci_mmap_page_range() wrapper.  This still leaves a
  sparc-specific pci_mmap_resource_range(), but it's only one interface
  instead of two (Arnd Bergmann)

- Remove sparc-specific pci_mmap_resource_range() by implementing
  pci_iobar_pfn().  This removes the ability to map the entire PCI I/O
  space using /proc/bus/pci, but we believe that's already been broken
  since v2.6.28 (Arnd Bergmann)

* pci/resource:
  sparc: Use generic pci_mmap_resource_range()
  PCI: Remove pci_mmap_page_range() wrapper

- Convert documentation examples to generic power management (Bjorn
  Helgaas)

* pci/pm:
  PCI/doc: Convert examples to generic power management

- Recognize disconnected devices so we don't bother trying to set them to
  "frozen" or "normal" state (Christoph Hellwig)

- Clear PCI Status register during enumeration in case firmware left errors
  logged (Kai-Heng Feng)

- Configure ECRC for every device, including hot-added ones (Stefan Roese)

- Keep AER error reporting enabled for switches (Stefan Roese)

- Enable error reporting for all devices that support AER (Stefan Roese)

- Iterate over error counters instead of error strings to avoid printing
  junk in AER sysfs counters (Mohamed Khalfella)

* pci/err:
  PCI/AER: Iterate over error counters instead of error strings
  PCI/AER: Enable error reporting when AER is native
  PCI/portdrv: Don't disable AER reporting in get_port_device_capability()
  PCI/AER: Configure ECRC for every device
  PCI: Clear PCI_STATUS when setting up device
  PCI/ERR: Recognize disconnected devices in report_error_detected()

- Split out ARI "next function" handling from the traditional one (Niklas
  Schnelle)

- Move jailhouse "isolated function" (non-zero functions where function 0
  doesn't exist) handling to pci_scan_slot() to avoid duplicating
  multi-function scanning in pci_scan_child_bus_extend() (Niklas Schnelle)

- Extend "isolated function" probing to s390 (Niklas Schnelle).

- Allow s390 zPCI zbus without a function 0 (Niklas Schnelle)

* pci/enumeration:
  s390/pci: allow zPCI zbus without a function zero
  PCI: Extend isolated function probing to s390
  PCI: Move jailhouse's isolated function handling to pci_scan_slot()
  PCI: Split out next_ari_fn() from next_fn()
  PCI: Clean up pci_scan_slot()

- Don't stop an EPC when unbinding an EPF from it (Shunsuke Mie)

* pci/endpoint:
  PCI: endpoint: Don't stop controller when unbinding endpoint function

- Remove pcie_aspm_pm_state_change(), which overwrites ASPM config on power
  state changes (Kai-Heng Feng)

* pci/aspm:
  PCI/ASPM: Unexport pcie_aspm_support_enabled()
  PCI/ASPM: Remove pcie_aspm_pm_state_change()

The main feature of the sparc-specific implementation of
pci_mmap_resource_range() is that it allows mapping the entire PCI I/O
space for a PCI host bridge using the /proc/bus/pci interface on a bridge
device.

The generic implementation cannot do this, but it also appears that this
got broken for sparc by commit 9eff02e2 ("PCI: check mmap range of
/proc/bus/pci files too"), which enforces that each address is part of a
BAR for kernels after 2.6.28.

Remove it all, assuming that the corresponding user space code has already
been changed to access /dev/ioport instead a long time ago.  Add
pci_iobar_pfn() to make it possible to map I/O resources. This is adapted
from the powerpc version.

Link: https://lore.kernel.org/lkml/1519887203.622.3.camel@infradead.org/t/
Link: https://lore.kernel.org/r/20220715153617.3393420-2-arnd@kernel.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The ARCH_GENERIC_PCI_MMAP_RESOURCE symbol came up in a recent discussion,
and I noticed that this was left behind by an unfinished cleanup from 2017.

The only architecture that still relies on providing its own
pci_mmap_page_range() helper instead of using the generic
pci_mmap_resource_range() is sparc. Presumably the reasons for this have
not changed, but at least this can be simplified by converting sparc to use
the same interface as the others.

The only difference between the two is the device-specific offset that gets
added to or subtracted from vma->vm_pgoff.

Change the only caller of pci_mmap_page_range() in common code to subtract
this offset and call the modern interface, while adding it back in the
sparc implementation to preserve the existing behavior.

This removes the complexities of the dual interfaces from the common code,
and keeps it all specific to the sparc architecture code. According to
David Miller, the sparc code lets user space poke into the VGA I/O port
registers by mmapping the I/O space of the parent bridge device, which is
something that the generic pci_mmap_resource_range() code apparently does
not.

Link: https://lore.kernel.org/lkml/1519887203.622.3.camel@infradead.org/t/
Link: https://lore.kernel.org/lkml/20220714214657.2402250-3-shorne@gmail.com/
Link: https://lore.kernel.org/r/20220715153617.3393420-1-arnd@kernel.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Stafford Horne <shorne@gmail.com>

Rename the .map_bus() functions to end with 'map_bus' so they're easy to
find with, e.g., 'git grep "^static.*_map_bus" drivers/pci/'.

[bhelgaas: rename brcm_pcie_map_bus32() to brcm7425_pcie_map_bus() for
better cscope-ability (".*_map_bus" is not the same as ".*_map_bus.*")]
Link: https://lore.kernel.org/r/20220725151258.42574-8-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

If we found power regulators for a device below the Root Port, disable them
during suspend and re-enable them during resume.

If any downstream device can be a wakeup device, do not turn off the
regulators as the device will need them on.

[bhelgaas: drop unused regulator_oops, skip wrapping of .add_bus()/
.remove_bus(), move brcm_pcie_start_link() to .add_bus() in previous patch,
squash WOL checking into this patch]
Link: https://lore.kernel.org/r/20220725151258.42574-6-jim2101024@gmail.com
Link: https://lore.kernel.org/r/20220725151258.42574-7-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Some platforms have power regulators for slots or devices below Root Ports.
On platforms like Raspberry Pi 4, these regulators are described in the
Root Port device tree node, since they logically belong to the Root Port,
not to the host bridge itself.

Add an .add_bus() hook (called when pci_alloc_child_bus() allocates the
secondary ("child") bus for a bridge), and look for such regulators.  If we
find some, enable them before bringing up the link and enumerating devices
on the child bus.

Similarly, when pci_remove_bus() calls the ops->remove_bus() hook, disable
the regulators.

The regulators that may be described in a Root Port DT device are:

  vpcie3v3
  vpcie3v3aux
  vpcie12v

These control power to the device downstream from the Root Port.

[bhelgaas: commit log, name hooks brcm_pcie_add_bus(), etc, since we only
support one set of subregulator info, save info in struct brcm_pcie instead
of dev->driver_data, move brcm_pcie_start_link() from probe to .add_bus()
(from subsequent patch)]
Link: https://lore.kernel.org/r/20220725151258.42574-5-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Previously brcm_pcie_setup() initialized the Root Port itself as well as
doing the actual link-up.  Split brcm_pcie_setup() into two functions:

  - brcm_pcie_setup(), which initializes everything that does not require
    the link itself to be up, and

  - brcm_pcie_start_link(), which brings up the link and initializes things
    that depend on the link being up.

[bhelgaas: condense commit log, deferring details for future changes]
Link: https://lore.kernel.org/r/20220725151258.42574-3-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

When the link is down, config accesses to downstream devices cause CPU
aborts.  Allow config accesses only when the link is up.

As the following scenario shows, this check is racy and cannot completely
avoid CPU aborts, but it makes them less likely:

  pci_generic_config_read
    addr = brcm_pcie_map_conf            # bus->ops->map_bus()
      brcm_pcie_link_up                  # returns "true"; link is up
    <link goes down>
    *val = readb(addr)                   # link is now down
    <CPU abort>

Note that config space accesses to the Root Port are not affected by link
status.

[bhelgaas: commit log, use PCIE_ECAM_REG() instead of magic 0xfff masks;
note that pci_generic_config_read32() masks low two bits already]
Link: https://lore.kernel.org/r/20220725151258.42574-4-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Remove forward function declarations in this driver.  Also move some
constant structure definitions lower in the file.  There are no changes to
the code that has been moved.

Link: https://lore.kernel.org/r/20220725151258.42574-2-jim2101024@gmail.comSigned-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Currently the zPCI code blocks PCI bus creation and probing of a zPCI zbus
unless there is a PCI function with devfn 0. This is always the case for
the PCI functions with hidden RID, but may keep PCI functions from a
multi-function PCI device with RID information invisible until the function
0 becomes visible. Worse, as a PCI bus is necessary to even present a PCI
hotplug slot, even that remains invisible.

With the probing of these so-called isolated PCI functions enabled for s390
in common code, this restriction is no longer necessary. On network cards
with multiple ports and a PF per port this also allows using each port on
its own while still providing the physical PCI topology information in the
devfn needed to associate VFs with their parent PF.

Link: https://lore.kernel.org/r/20220628143100.3228092-6-schnelle@linux.ibm.comSigned-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>

Like the jailhouse hypervisor, s390's PCI architecture allows passing
isolated PCI functions to a guest OS instance. As of now this is was not
utilized even with multi-function support as the s390 PCI code makes sure
that only virtual PCI busses including a function with devfn 0 are
presented to the PCI subsystem. A subsequent change will remove this
restriction.

Allow probing such functions by replacing the existing check for
jailhouse_paravirt() with a new hypervisor_isolated_pci_functions() helper.

Link: https://lore.kernel.org/r/20220628143100.3228092-5-schnelle@linux.ibm.comSigned-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>

The special case of the jailhouse hypervisor passing through individual PCI
functions handles scanning for PCI functions even if function 0 does not
exist. Previously this was done with an extra loop duplicating the one in
pci_scan_slot(). By incorporating the check for jailhouse_paravirt() into
pci_scan_slot() we can instead do this as part of the normal slot scan.
Note that with the assignment of dev->multifunction gated by fn > 0 we set
dev->multifunction unconditionally for all functions if function 0 is
missing just as in the existing jailhouse loop.

The only functional change is that we now call pcie_aspm_init_link_state()
for these functions, but this already happened if function 0 was passed
through and should not be a problem.

Link: https://lore.kernel.org/linux-pci/20220408224514.GA353445@bhelgaas/Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20220628143100.3228092-4-schnelle@linux.ibm.comSigned-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>

In commit b1bd58e4 ("PCI: Consolidate "next-function" functions") the
next_fn() function subsumed the traditional and ARI-based next function
determination. This got rid of some needlessly complex function pointer
handling but also reduced the separation between these very different
methods of finding the next function. With the next_fn() cleaned up a bit
we can re-introduce this separation by moving out the ARI handling while
sticking with direct function calls.

Link: https://lore.kernel.org/r/20220628143100.3228092-3-schnelle@linux.ibm.comSigned-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>

While determining the next PCI function is factored out of pci_scan_slot()
into next_fn(), the former still handles the first function as a special
case, which duplicates the code from the scan loop.

Furthermore the non-ARI branch of next_fn() is generally hard to understand
and especially the check for multifunction devices is hidden in the
handling of NULL devices for non-contiguous multifunction. It also signals
that no further functions need to be scanned by returning 0 via wraparound
and this is a valid function number.

Improve upon this by transforming the conditions in next_fn() to be easier
to understand.

By changing next_fn() to return -ENODEV instead of 0 when there is no next
function we can then handle the initial function inside the loop and
deduplicate the shared handling. This also makes it more explicit that only
function 0 must exist.

No functional change is intended.

Link: https://lore.kernel.org/r/20220628143100.3228092-2-schnelle@linux.ibm.comSigned-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>

Previously we iterated over AER stat *names*, e.g.,
aer_correctable_error_string[32], but the actual stat *counters* may not be
that large, e.g., pdev->aer_stats->dev_cor_errs[16], which means that we
printed junk in the sysfs stats files.

Iterate over the stat counter arrays instead of the names to avoid this
junk.

Also, added a build time check to make sure all
counters have entries in strings array.

Fixes: 0678e310 ("PCI/AER: Simplify __aer_print_error()")
Link: https://lore.kernel.org/r/20220509181441.31884-1-mkhalfella@purestorage.comReported-by: Meeta Saggi <msaggi@purestorage.com>
Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Meeta Saggi <msaggi@purestorage.com>
Reviewed-by: Eric Badger <ebadger@purestorage.com>
Cc: stable@vger.kernel.org

If we have native control of AER, set the following error reporting enable
bits:

  - Correctable Error Reporting Enable
  - Non-Fatal Error Reporting Enable
  - Fatal Error Reporting Enable
  - Unsupported Request Reporting Enable

Note that these bits are all in the Device Control register and are not
AER-specific.

This affects all devices with an AER capability, including hot-added
devices.

Please note that this change is quite invasive, as error reporting now will
be enabled for all available PCIe Endpoints, which was previously not the
case.

When "pci=noaer" is selected, error reporting stays disabled of course.

[bhelgaas: commit log, note error reporting is not AER-specific]
Link: https://lore.kernel.org/r/20220125071820.2247260-4-sr@denx.deSigned-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Yao Hongbo <yaohongbo@linux.alibaba.com>
Cc: Naveen Naidu <naveennaidu479@gmail.com>

AER reporting is currently disabled in the DevCtl registers of all non Root
Port PCIe devices on systems using pcie_ports_native || host->native_aer,
disabling AER completely in such systems. This is because 2bd50dd8
("PCI: PCIe: Disable PCIe port services during port initialization"), added
a call to pci_disable_pcie_error_reporting() *after* the AER setup was
completed for the PCIe device tree.

Here a longer analysis about the current status of AER enabling /
disabling upon bootup provided by Bjorn:

  pcie_portdrv_probe
    pcie_port_device_register
      get_port_device_capability
        pci_disable_pcie_error_reporting
          clear CERE NFERE FERE URRE               # <-- disable for RP USP DSP
      pcie_device_init
        device_register                            # new AER service device
          aer_probe
            aer_enable_rootport                    # RP only
              set_downstream_devices_error_reporting
                set_device_error_reporting         # self (RP)
                  if (RP || USP || DSP)
                    pci_enable_pcie_error_reporting
                      set CERE NFERE FERE URRE     # <-- enable for RP
                pci_walk_bus
                  set_device_error_reporting
                    if (RP || USP || DSP)
                      pci_enable_pcie_error_reporting
                        set CERE NFERE FERE URRE   # <-- enable for USP DSP

In a typical Root Port -> Endpoint hierarchy, the above:
  - Disables Error Reporting for the Root Port,
  - Enables Error Reporting for the Root Port,
  - Does NOT enable Error Reporting for the Endpoint because it is not a
    Root Port or Switch Port.

In a deeper Root Port -> Upstream Switch Port -> Downstream Switch
Port -> Endpoint hierarchy:
  - Disables Error Reporting for the Root Port,
  - Enables Error Reporting for the Root Port,
  - Enables Error Reporting for both Switch Ports,
  - Does NOT enable Error Reporting for the Endpoint because it is not a
    Root Port or Switch Port,
  - Disables Error Reporting for the Switch Ports when pcie_portdrv_probe()
    claims them.  AER does not re-enable it because these are not Root
    Ports.

Remove this call to pci_disable_pcie_error_reporting() from
get_port_device_capability(), leaving the already enabled AER configuration
intact. With this change, AER is enabled in the Root Port and the PCIe
switch upstream and downstream ports. Only the PCIe Endpoints don't have
AER enabled yet. A follow-up patch will take care of this Endpoint
enabling.

Fixes: 2bd50dd8 ("PCI: PCIe: Disable PCIe port services during port initialization")
Link: https://lore.kernel.org/r/20220125071820.2247260-3-sr@denx.deSigned-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Yao Hongbo <yaohongbo@linux.alibaba.com>
Cc: Naveen Naidu <naveennaidu479@gmail.com>

pcie_aspm_support_enabled() is used only by the acpi/pci_root.c driver,
which cannot be built as a module, so it does not need to be exported.
Unexport it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

pcie_aspm_pm_state_change() was introduced at the inception of PCIe ASPM
code, but it can cause some issues. For instance, when ASPM config is
changed via sysfs, those changes won't persist across power state change
because pcie_aspm_pm_state_change() overwrites them.

Also, if the driver restores L1SS [1] after system resume, the restored
state will also be overwritten by pcie_aspm_pm_state_change().

Remove pcie_aspm_pm_state_change().  If there's any hardware that really
needs it to function, a quirk can be used instead.

[1] https://lore.kernel.org/linux-pci/20220201123536.12962-1-vidyas@nvidia.com/
Link: https://lore.kernel.org/r/20220509073639.2048236-1-kai.heng.feng@canonical.com
[bhelgaas: remove additional pcie_aspm_pm_state_change() call in
pci_set_low_power_state(), added by
10aa5377 ("PCI/PM: Split pci_raw_set_power_state()") and moved by
7957d201 ("PCI/PM: Relocate pci_set_low_power_state()")]
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI-specific power management (pci_driver.suspend and pci_driver.resume) is
deprecated.  Convert sample code to the generic power management framework.

Link: https://lore.kernel.org/r/20220607232946.355987-1-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Move pcie_set_ecrc_checking() to pci_aer_init() to make sure that
pcie_set_ecrc_checking() is called for each PCIe device, including
hot-added devices.

Link: https://lore.kernel.org/r/20220125071820.2247260-2-sr@denx.deSigned-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Yao Hongbo <yaohongbo@linux.alibaba.com>
Cc: Naveen Naidu <naveennaidu479@gmail.com>

Unbinding an endpoint function from the endpoint controller shouldn't stop
the controller.  This is especially a problem for multi-function endpoints
where other endpoints may still be active.

Don't stop the controller when unbinding one of its endpoints.  Normally
the controller is stopped via configfs.

Fixes: 349e7a85 ("PCI: endpoint: functions: Add an EP function to test PCI")
Link: https://lore.kernel.org/r/20220622040924.113279-1-mie@igel.co.jpSigned-off-by: Shunsuke Mie <mie@igel.co.jp>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>

We are seeing Master Abort bit is set on Intel I350 ethernet device and its
root port right after boot, probably happened during BIOS phase:

  00:06.0 PCI bridge [0604]: Intel Corporation Device [8086:464d] (rev 05) (prog-if 00 [Normal decode])
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-

  6e:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network Connection [8086:1521] (rev 01)
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-

The Master Abort bit is cleared after S3.

Since there's no functional impact found, clear the PCI_STATUS to treat it
anew at setting up.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215989
Link: https://lore.kernel.org/r/20220517043738.2308499-1-kai.heng.feng@canonical.comSigned-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Slot capabilities are currently not reported because emulated bridge does
not report the PCI_EXP_FLAGS_SLOT flag.

Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers
are supported.

Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read
function to static buffer as it is only statically filled the
PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this
register.

Set Presence State Bit to 1 since there is no support for unplugging the
card and there is currently no platform able to detect presence of a card -
in such a case the bit needs to be set to 1.

Finally correctly set Physical Slot Number to 1 since there is only one
port and zero value is reserved for ports within the same silicon as Root
Port which is not our case for Aardvark HW.

Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.orgSigned-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Aardvark controller supports Advanced Error Reporting configuration
registers.

Export these registers on the emulated root bridge via new .read_ext() and
.write_ext() methods.

Note that in the Advanced Error Reporting Capability header the offset to
the next Extended Capability header is set, but it is not documented in
Armada 3700 Functional Specification. Since this change adds support only
for Advanced Error Reporting, explicitly clear PCI_EXT_CAP_NEXT bits in AER
capability header.

Now the pcieport driver correctly detects AER support and allows PCIe AER
driver to start receiving ERR interrupts. Kernel log now says:

  pcieport 0000:00:00.0: AER: enabled with IRQ 52

Link: https://lore.kernel.org/r/20220524132827.8837-2-kabel@kernel.orgSigned-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The Broadcom BCM5750x NICs may be multi-function devices.  They do not
advertise ACS capability. Peer-to-peer transactions are not possible
between the individual functions, so it is safe to treat them as fully
isolated.

Add an ACS quirk for these devices so the functions can be in independent
IOMMU groups and attached individually to userspace applications using
VFIO.

Link: https://lore.kernel.org/r/1654796507-28610-1-git-send-email-michael.chan@broadcom.comSigned-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

When a device is already unplugged by pciehp by the time the AER handler is
invoked, the PCIe device will already be in the pci_channel_io_perm_failure
state.  In that case simply return PCI_ERS_RESULT_DISCONNECT instead of
trying to do a state transition that will fail.

Also untangle the state transition failure from the lack of methods to
improve the debugging output in case it happens again.

Link: https://lore.kernel.org/r/20220601074024.3481035-1-hch@lst.deSigned-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

Pull file descriptor fix from Al Viro:
 "Fix for breakage in #work.fd this window"

* tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fix the breakage in close_fd_get_file() calling conventions change

Pull mm hotfixes from Andrew Morton:
 "Fixups for various recently-added and longer-term issues and a few
  minor tweaks:

   - fixes for material merged during this merge window

   - cc:stable fixes for more longstanding issues

   - minor mailmap and MAINTAINERS updates"

* tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery
  x86/kexec: fix memory leak of elf header buffer
  mm/memremap: fix missing call to untrack_pfn() in pagemap_range()
  mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock()
  mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON
  MAINTAINERS: add maintainer information for z3fold
  mailmap: update Josh Poimboeuf's email

Pull delay-accounting update from Andrew Morton:
 "A single featurette for delay accounting.

  Delayed a bit because, unusually, it had dependencies on both the
  mm-stable and mm-nonmm-stable queues"

* tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  delayacct: track delays from write-protect copy

The bluetooth code uses our bitmap infrastructure for the two bits (!)
of connection setup flags, and in the process causes odd problems when
it converts between a bitmap and just the regular values of said bits.

It's completely pointless to do things like bitmap_to_arr32() to convert
a bitmap into a u32.  It shoudln't have been a bitmap in the first
place.  The reason to use bitmaps is if you have arbitrary number of
bits you want to manage (not two!), or if you rely on the atomicity
guarantees of the bitmap setting and clearing.

The code could use an "atomic_t" and use "atomic_or/andnot()" to set and
clear the bit values, but considering that it then copies the bitmaps
around with "bitmap_to_arr32()" and friends, there clearly cannot be a
lot of atomicity requirements.

So just use a regular integer.

In the process, this avoids the warnings about erroneous use of
bitmap_from_u64() which were triggered on 32-bit architectures when
conversion from a u64 would access two words (and, surprise, surprise,
only one word is needed - and indeed overkill - for a 2-bit bitmap).

That was always problematic, but the compiler seems to notice it and
warn about the invalid pattern only after commit 0a97953f ("lib: add
bitmap_{from,to}_arr64") changed the exact implementation details of
'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell.

Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags")
Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/
Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/
Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>