pci_bus_alloc_from_region() allocates MMIO space by iterating through all
the resources available on the bus.  The available resource might be
reduced if the caller requires 32-bit space or we're avoiding BIOS or E820
areas.

Don't bother calling allocate_resource() if we need more space than is
available in this resource.  This prevents some pointless and annoying
messages about avoided areas.

Link: https://lore.kernel.org/r/20221208190341.1560157-3-helgaas@kernel.orgSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>

Previously portdrv allowed the AER service for any device with an AER
capability (assuming Linux had control of AER) even though the AER service
driver only attaches to Root Port and RCECs.

Because get_port_device_capability() included AER for non-RP, non-RCEC
devices, we tried to initialize the AER IRQ even though these devices
don't generate AER interrupts.

Intel DG1 and DG2 discrete graphics cards contain a switch leading to a
GPU.  The switch supports AER but not MSI, so initializing an AER IRQ
failed, and portdrv failed to claim the switch port at all.  The GPU itself
could be suspended, but the switch could not be put in a low-power state
because it had no driver.

Don't allow the AER service on non-Root Port, non-Root Complex Event
Collector devices.  This means we won't enable Bus Mastering if the device
doesn't require MSI, the AER service will not appear in sysfs, and the AER
service driver will not bind to the device.

Link: https://lore.kernel.org/r/20221207084105.84947-1-mika.westerberg@linux.intel.com
Link: https://lore.kernel.org/r/20221210002922.1749403-1-helgaas@kernel.orgBased-on-patch-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

The No Command Completed Support bit in the Slot Capabilities register
indicates whether Command Completed Interrupt Enable is unsupported.

We already check whether No Command Completed Support bit is set in
pcie_wait_cmd(), and do not wait in this case.

Don't enable this Command Completed Interrupt at all if NCCS is set, so
that when users dump configuration space from userspace, the dump does not
confuse them by saying that Command Completed Interrupt is not supported,
but it is enabled.

Link: https://lore.kernel.org/r/20220927141926.8895-2-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>

Current driver is missing a sentinel in the struct soc_device_attribute
array, which causes an oops when assessed by the
soc_device_match(mt7621_pcie_quirks_match) call.

This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr
was fixed to register the SOC as a device, in:

commit 7c18b64b ("mips: ralink: mt7621: do not use kzalloc too early")

Fix it by adding the required sentinel.

Link: https://lore.kernel.org/lkml/26ebbed1-0fe9-4af9-8466-65f841d0b382@app.fastmail.com
Link: https://lore.kernel.org/r/20221205204645.301301-1-git@johnthomson.fastmail.com.au
Fixes: b483b4e4 ("staging: mt7621-pci: add quirks for 'E2' revision using 'soc_device_attribute'")
Signed-off-by: NJohn Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NSergio Paracuellos <sergio.paracuellos@gmail.com>

  pci-epf-vntb.c:1128:33: sparse:     expected void [noderef] __iomem *base
  pci-epf-vntb.c:1128:33: sparse:     got struct epf_ntb_ctrl *reg

Add __iomem type cast in vntb_epf_peer_spad_read() and
vntb_epf_peer_spad_write().

Link: https://lore.kernel.org/r/20221102141014.1025893-8-Frank.Li@nxp.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NManivannan Sadhasivam <mani@kernel.org>

Use epf_db[i] dereference instead of readl() because epf_db is
in memory allocated by dma_alloc_coherent(), not I/O.

Remove useless/duplicated readl() in the process.

Link: https://lore.kernel.org/r/20221102141014.1025893-7-Frank.Li@nxp.comSigned-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

NTB spad entry item size is sizeof(u32), replace hardcoded 4 with it.

Link: https://lore.kernel.org/r/20221102141014.1025893-6-Frank.Li@nxp.comSigned-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NManivannan Sadhasivam <mani@kernel.org>

epf_db_phy member in struct epf_ntb is not used, remove it.

Link: https://lore.kernel.org/r/20221102141014.1025893-5-Frank.Li@nxp.comSigned-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NManivannan Sadhasivam <mani@kernel.org>

Replace pci_epc_mem_free_addr() with pci_epf_free_space() in the
error handle path to match pci_epf_alloc_space().

Link: https://lore.kernel.org/r/20221102141014.1025893-4-Frank.Li@nxp.com
Fixes: e35f56bb ("PCI: endpoint: Support NTB transfer between RC and EP")
Signed-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

Align the indentation of struct epf_ntb_ctrl with other structs in
the driver.

Link: https://lore.kernel.org/r/20221102141014.1025893-3-Frank.Li@nxp.comSigned-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

Cleanup warning found by scripts/kernel-doc.

Consolidate terms:

- host, host1 to HOST
- vhost, vHost, Vhost, VHOST2 to VHOST

Link: https://lore.kernel.org/r/20221102141014.1025893-2-Frank.Li@nxp.comSigned-off-by: NFrank Li <frank.li@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NManivannan Sadhasivam <mani@kernel.org>

Baikal-T1 SoC is equipped with DWC PCIe v4.60a host controller. It can be
trained to work up to Gen.3 speed over up to x4 lanes. The host controller
is attached to the DW PCIe 3.0 PCS via the PIPE-4 interface, which in its
turn is connected to the DWC 10G PHY. The whole system is supposed to be
fed up with four clock sources: DBI peripheral clock, AXI application
clocks and external PHY/core reference clock generating the 100MHz signal.
In addition to that the platform provide a way to reset each part of the
controller: sticky/non-sticky bits, host controller core, PIPE interface,
PCS/PHY and Hot/Power reset signal. The driver also provides a way to
handle the GPIO-based PERST# signal.

Note due to the Baikal-T1 MMIO peculiarity we have to implement the DBI
interface accessors which make sure the IO operations are dword-aligned.

Link: https://lore.kernel.org/r/20221113191301.5526-21-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

Currently almost each platform driver uses its own resets and clocks
naming in order to get the corresponding descriptors. It makes the code
harder to maintain and comprehend especially seeing the DWC PCIe core main
resets and clocks signals set hasn't changed much for about at least one
major IP-core release. So in order to organize things around these signals
we suggest to create a generic interface for them in accordance with the
naming introduced in the DWC PCIe IP-core reference manual:

Application clocks:
- "dbi"  - data bus interface clock (on some DWC PCIe platforms it's
           referred as "pclk", "pcie", "sys", "ahb", "cfg", "iface",
           "gio", "reg", "pcie_apb_sys");
- "mstr" - AXI-bus master interface clock (some DWC PCIe glue drivers
           refer to this clock as "port", "bus", "pcie_bus",
           "bus_master/master_bus/axi_m", "pcie_aclk");
- "slv"  - AXI-bus slave interface clock (also called as "port", "bus",
           "pcie_bus", "bus_slave/slave_bus/axi_s", "pcie_aclk",
           "pcie_inbound_axi").

Core clocks:
- "pipe" - core-PCS PIPE interface clock coming from external PHY (it's
           normally named by the platform drivers as just "pipe");
- "core" - primary clock of the controller (none of the platform drivers
           declare such a clock but in accordance with the ref. manual
           the devices may have it separately specified);
- "aux"  - auxiliary PMC domain clock (it is named by some platforms as
           "pcie_aux" and just "aux");
- "ref"  - Generic reference clock (it is a generic clock source, which
           can be used as a signal source for multiple interfaces, some
           platforms call it as "ref", "general", "pcie_phy",
           "pcie_phy_ref").

Application resets:
- "dbi"  - Data-bus interface reset (it's CSR interface clock and is
           normally called as "apb" though technically it's not APB but
           DWC PCIe-specific interface);
- "mstr" - AXI-bus master reset (some platforms call it as "port", "apps",
           "bus", "axi_m");
- "slv"  - ABI-bus slave reset (some platforms call it as "port", "apps",
           "bus", "axi_s").

Core resets:
- "non-sticky" - non-sticky CSR flags reset;
- "sticky"     - sticky CSR flags reset;
- "pipe"       - PIPE-interface (Core-PCS) logic reset (some platforms
                 call it just "pipe");
- "core"       - controller primary reset (resets everything except PMC
                 module, some platforms refer to this signal as "soft",
                 "pci");
- "phy"        - PCS/PHY block reset (strictly speaking it is normally
                 connected to the input of an external block, but the
                 reference manual says it must be available for the PMC
                 working correctly, some existing platforms call it
                 "pciephy", "phy", "link");
- "hot"        - PMC hot reset signal (also called as "sleep");
- "pwr"        - cold reset signal (can be referred as "pwr", "turnoff").

Bus reset:
- "perst" - PCIe standard signal used to reset the PCIe peripheral
            devices.

As you can see each platform uses it's own naming for basically the same
set of the signals. In the framework of this commit we suggest to add a
set of the clocks and reset signals resources, corresponding names and
identifiers for each denoted entity. At current stage the platforms will
be able to use the provided infrastructure to automatically request all
these resources and manipulate with them in the Host/EP init callbacks.
Alas it isn't that easy to create a common cold/hot reset procedure due to
too many platform-specifics in the procedure, like the external flags
exposure and the delays requirement.

Link: https://lore.kernel.org/r/20221113191301.5526-20-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

Since the iATU CSR region is now retrieved in the DW PCIe resources getter
there is no much benefits in the iATU detection procedures splitting up.
Therefore let's join the iATU unroll/viewport detection procedure with the
rest of the iATU parameters detection code. The resultant method will be
as coherent as before, while the redundant functions will be eliminated
thus producing more readable code.

Link: https://lore.kernel.org/r/20221113191301.5526-19-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in
the separate parts of the DW PCIe core driver. It doesn't really make
sense since the both controller types have identical set of the core CSR
regions: DBI, DBI CS2 and iATU/eDMA. Thus we can simplify the DW PCIe Host
and EP initialization methods by moving the platform-specific registers
space getting and mapping into a common method. It gets to be even more
justified seeing the CSRs base address pointers are preserved in the
common DW PCIe descriptor. Note all the OF-based common DW PCIe settings
initialization will be moved to the new method too in order to have a
single function for all the generic platform properties handling in single
place.

A nice side-effect of this change is that the pcie-designware-host.c and
pcie-designware-ep.c drivers are cleaned up from all the direct dw_pcie
storage modification, which makes the DW PCIe core, Root Port and Endpoint
modules more coherent.

Link: https://lore.kernel.org/r/20221113191301.5526-18-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>

Since in addition to the already available iATU unrolled mapping we are
about to add a few more DW PCIe platform-specific capabilities (CDM-check
and generic clocks/resets resources) let's add a generic interface to set
and get the flags indicating their availability. The new interface shall
improve maintainability of the platform-specific code.

Link: https://lore.kernel.org/r/20221113191301.5526-17-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges"
property has the same format as the "ranges" property. The only difference
is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU
memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges"
property. Even though the DW PCIe controllers are normally equipped with
the internal Address Translation Unit which inbound and outbound tables
can be used to implement both properties semantics, it was surprising for
me to discover that the host-related part of the DW PCIe driver currently
supports the "ranges" property only while the "dma-ranges" windows are
just ignored. Having the "dma-ranges" supported in the driver would be
very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory
mapping and require a customized PCIe memory layout. So let's fix that by
introducing the "dma-ranges" property support.

First of all we suggest to rename the dw_pcie_prog_inbound_atu() method to
dw_pcie_prog_ep_inbound_atu() and create a new version of the
dw_pcie_prog_inbound_atu() function. Thus we'll have two methods for the
RC and EP controllers respectively in the same way as it has been
developed for the outbound ATU setup methods.

Secondly aside with the memory window index and type the new
dw_pcie_prog_inbound_atu() function will accept CPU address, PCIe address
and size as its arguments. These parameters define the PCIe and CPU memory
ranges which will be used to setup the respective inbound ATU mapping. The
passed parameters need to be verified against the ATU ranges constraints
in the same way as it is done for the outbound ranges.

Finally the DMA-ranges detected for the PCIe controller need to be
converted to the inbound ATU entries during the host controller
initialization procedure. It will be done in the framework of the
dw_pcie_iatu_setup() method. Note before setting the inbound ranges up we
need to disable all the inbound ATU entries in order to prevent unexpected
PCIe TLPs translations defined by some third party software like
bootloaders.

Link: https://lore.kernel.org/r/20221113191301.5526-16-Sergey.Semin@baikalelectronics.ruSigned-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

The ->get_mode1_ECC_cap callback in the shpchp_hpc_ops struct is never
called, so remove it.

[bhelgaas: squash]
Link: https://lore.kernel.org/r/20221112142859.319733-2-ian@linux.cowan.aero
Link: https://lore.kernel.org/r/20221112142859.319733-3-ian@linux.cowan.aero
Link: https://lore.kernel.org/r/20221112142859.319733-4-ian@linux.cowan.aeroSigned-off-by: NIan Cowan <ian@linux.cowan.aero>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

It is reported that on some systems pciehp binds to an Upstream Port and
attempts to operate it which causes devices below the Port to disappear
from the bus.

This happens because acpiphp sets dev->is_hotplug_bridge for that Port
(after receiving a Device Check notification on it from the platform
firmware via ACPI) during the enumeration of PCI devices.

get_port_device_capability() sees that dev->is_hotplug_bridge is set and
adds PCIE_PORT_SERVICE_HP to Port services, which allows pciehp to bind to
the Port in question.

Even though this particular problem can be addressed by making the
portdrv_core checks more robust, it also causes power management to work
differently on the affected systems which generally is not desirable (PCIe
Ports with dev->is_hotplug_bridge set have to pass additional tests to be
allowed to go into the D3hot/cold power states which affects runtime PM of
devices below these Ports).

For this reason, amend check_hotplug_bridge() with a PCIe type check to
prevent it from setting dev->is_hotplug_bridge for Upstream Ports.
Suggested-by: NLukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/2262230.ElGaqSPkdT@kreacherReported-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>

It is reported that on some systems pciehp binds to an Upstream Port and
attempts to operate it which causes devices below the Port to disappear
from the bus.

This happens because acpiphp sets dev->is_hotplug_bridge for that Port
(after receiving a Device Check notification on it from the platform
firmware via ACPI) during the enumeration of PCI devices.

get_port_device_capability() sees that dev->is_hotplug_bridge is set and
adds PCIE_PORT_SERVICE_HP to Port services (which allows pciehp to bind to
the Port in question) without consulting the PCIe type, which should be
either Root Port or Downstream Port for the hotplug capability to be
present.

Per PCIe r6.0, sec 7.5.3.2, the Slot Implemented bit is only valid for
Downstream Ports (including Root Ports), and PCIe hotplug depends on the
Slot Capabilities / Control / Status registers.

Make get_port_device_capability() more robust by adding a PCIe type check
to it before adding PCIE_PORT_SERVICE_HP to Port services which helps to
avoid the problem.

[bhelgaas: add spec citation]
Suggested-by: NLukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/4786090.31r3eYUQgx@kreacherReported-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>

When kvasprintf() fails to allocate memory, it returns a NULL pointer.
Return error from pci_request_irq() so we don't dereference it.

[bhelgaas: commit log]
Fixes: 704e8953 ("PCI/irq: Add pci_request_irq() and pci_free_irq() helpers")
Link: https://lore.kernel.org/r/20221121020029.3759444-1-zengheng4@huawei.comSigned-off-by: NZeng Heng <zengheng4@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>

Per PCIe r6.0, sec 6.30.1, a data object Length of 0x0 indicates 2^18
DWORDs (256K DW or 1MB) being transferred.  Adjust the value of data object
length for this case on both sending side and receiving side.

Don't bother checking whether Length is greater than SZ_1M because all
values of the 18-bit Length field are valid, and it is impossible to
represent anything larger than SZ_1M:

  0x00000    256K DW (1M bytes)
  0x00001       1 DW (4 bytes)
  ...
  0x3ffff  256K-1 DW (1M - 4 bytes)

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20221116015637.3299664-1-ming4.li@intel.com
Fixes: 9d24322e ("PCI/DOE: Add DOE mailbox support functions")
Signed-off-by: NLi Ming <ming4.li@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org	# v6.0+

Thunderbolt/USB4 PCIe tunneling depends on native PCIe hotplug.  Enable
pciehp by default if USB4 is enabled.

[bhelgaas: squash, update subject, commit logs, tidy whitespace]
Link: https://lore.kernel.org/r/20221115113857.35800-2-albert.zhou.50@gmail.com
Link: https://lore.kernel.org/r/20221115113857.35800-3-albert.zhou.50@gmail.comSigned-off-by: NAlbert Zhou <albert.zhou.50@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

This patch switches the driver away from legacy gpio/of_gpio API to
gpiod API, and removes use of of_get_named_gpio_flags() which I want to
make private to gpiolib.

Link: https://lore.kernel.org/r/20220906204301.3736813-1-dmitry.torokhov@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

pci_device_is_present() previously didn't work for VFs because it reads the
Vendor and Device ID, which are 0xffff for VFs, which looks like they
aren't present.  Check the PF instead.

Wei Gong reported that if virtio I/O is in progress when the driver is
unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O
operation hangs, which may result in output like this:

  task:bash state:D stack:    0 pid: 1773 ppid:  1241 flags:0x00004002
  Call Trace:
   schedule+0x4f/0xc0
   blk_mq_freeze_queue_wait+0x69/0xa0
   blk_mq_freeze_queue+0x1b/0x20
   blk_cleanup_queue+0x3d/0xd0
   virtblk_remove+0x3c/0xb0 [virtio_blk]
   virtio_dev_remove+0x4b/0x80
   ...
   device_unregister+0x1b/0x60
   unregister_virtio_device+0x18/0x30
   virtio_pci_remove+0x41/0x80
   pci_device_remove+0x3e/0xb0

This happened because pci_device_is_present(VF) returned "false" in
virtio_pci_remove(), so it called virtio_break_device().  The broken vq
meant that vring_interrupt() skipped the vq.callback() that would have
completed the virtio I/O operation via virtblk_done().

[bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]
Link: https://lore.kernel.org/r/20221026060912.173250-1-mst@redhat.comReported-by: NWei Gong <gongwei833x@gmail.com>
Tested-by: NWei Gong <gongwei833x@gmail.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

When the PHY is the reference clock provider then it must be initialized
and powered on before the reset on the client is deasserted, otherwise
the link will never come up. The order was changed in cf236e0c.
Restore the correct order to make the driver work again on boards where
the PHY provides the reference clock. This also changes the order for
boards where the Soc is the PHY reference clock divider, but this
shouldn't do any harm.

Link: https://lore.kernel.org/r/20221101095714.440001-1-s.hauer@pengutronix.de
Fixes: cf236e0c ("PCI: imx6: Do not hide PHY driver callbacks and refine the error handling")
Tested-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>

On Qualcomm platforms like SC8280XP and SA8540P, interconnect bandwidth
must be requested before enabling interconnect clocks.

Add basic support for managing an optional "pcie-mem" interconnect path
by setting a low constraint before enabling clocks and updating it after
the link is up.

Note that it is not possible for a controller driver to set anything but
a maximum peak bandwidth as expected average bandwidth will vary with
use case and actual use (and power policy?). This very much remains an
unresolved problem with the interconnect framework.

Also note that no constraint is set for the SC8280XP/SA8540P "cpu-pcie"
path for now as it is not clear what an appropriate constraint would be
(and the system does not crash when left unspecified).

Link: https://lore.kernel.org/r/20221102090705.23634-3-johan+linaro@kernel.org
Fixes: 70574511 ("PCI: qcom: Add support for SC8280XP")
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NBrian Masney <bmasney@redhat.com>
Reviewed-by: NManivannan Sadhasivam <mani@kernel.org>
Acked-by: NGeorgi Djakov <djakov@kernel.org>

Set RCB_MPS mode bit so that data for PCIe read requests up to the size of
the Maximum Payload Size (MPS) are returned in one completion, and data for
PCIe read requests greater than the MPS are split at the specified Read
Completion Boundary setting.

Set RCB_64B so that the Read Compeletion Boundary is 64B.

Link: https://lore.kernel.org/r/20221011184211.18128-6-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

A number of inline functions are called rarely and/or are not
time-critical.  Take out the "inline" and let the compiler do its work.

Link: https://lore.kernel.org/r/20221011184211.18128-5-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

It would be nice to replace the PCIe link-up loop as well but
there are too many uses of this that do not poll (and the
read_poll_timeout uses "timeout==0" to loop forever).

Link: https://lore.kernel.org/r/20221011184211.18128-4-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

Be prudent and give some time for power and clocks to become stable.  As
described in the PCIe CEM specification sections 2.2 and 2.2.1; as well as
PCIe r5.0, 6.6.1.

Link: https://lore.kernel.org/r/20221011184211.18128-3-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

We always wanted to enable Multi-MSI but didn't have a test device until
recently.  In addition, there are some devices out there that will ask for
multiple MSI but refuse to work if they are only granted one.

Link: https://lore.kernel.org/r/20221011184211.18128-2-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>

Some of the platforms (like Tegra194 and Tegra234) have open slots and
not having an endpoint connected to the slot is not an error.
So, changing the macro from dev_err to dev_info to log the event.

Link: https://lore.kernel.org/r/20220913101237.4337-1-vidyas@nvidia.comTested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Fix the error message to mention "assert" instead of "deassert".

Link: https://lore.kernel.org/r/20221109094039.25753-1-manivannan.sadhasivam@linaro.orgSigned-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NVinod Koul <vkoul@kernel.org>

When pci_create_attr() fails, pci_remove_resource_files() is called which
will iterate over the res_attr[_wc] arrays and frees every non NULL entry.
To avoid a double free here set the array entry only after it's clear we
successfully initialized it.

Fixes: b562ec8f ("PCI: Don't leak memory if sysfs_create_bin_file() fails")
Link: https://lore.kernel.org/r/20221007070735.GX986@pengutronix.de/Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

Replace assignment of PCI domain IDs from atomic_inc_return() to
ida_alloc().

Use two IDAs, one for static domain allocations (those which are defined in
device tree) and second for dynamic allocations (all other).

During removal of root bus / host bridge, also release the domain ID.  The
released ID can be reused again, for example when dynamically loading and
unloading native PCI host bridge drivers.

This change also allows to mix static device tree assignment and dynamic by
kernel as all static allocations are reserved in dynamic pool.

[bhelgaas: set "err" if "bus->domain_nr < 0"]
Link: https://lore.kernel.org/r/20220714184130.5436-1-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This reverts commit 6cd514e5.

Christophe Fergeau reported that 6cd514e5 ("PCI: Clear PCI_STATUS when
setting up device") causes boot failures when trying to start linux guests
with Apple's virtualization framework (for example using
https://developer.apple.com/documentation/virtualization/running_linux_in_a_virtual_machine?language=objc)

6cd514e5 only solved a cosmetic problem, so revert it to fix the boot
failures.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2137803Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Replace the string "_UID" with the METHOD_NAME__UID macro so instances are
easier to find.

Link: https://lore.kernel.org/r/20221104032430.186424-1-zouyipeng@huawei.comSigned-off-by: NYipeng Zou <zouyipeng@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCIe r2.0, sec 7.8 added Link Capabilities/Status/Control 2 registers to
the PCIe Capability with Capability Version 2.

Previously we assumed these registers were implemented for all PCIe
Capabilities of version 2 or greater, but in fact they are only
implemented for devices with Links.

Update pcie_capability_reg_implemented() to check whether the device has
a Link.

[bhelgaas: commit log, squash export]
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057070.2275@angie.orcam.me.uk
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057300.2275@angie.orcam.me.ukSigned-off-by: NMaciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Since there is no release callback defined for the PCI EPC device,
the below warning is thrown by driver core when a PCI endpoint driver is
removed:

  Device 'e65d0000.pcie-ep' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst.
  WARNING: CPU: 0 PID: 139 at drivers/base/core.c:2232 device_release+0x78/0x8c

Hence, add the release callback and also move the kfree(epc) from
pci_epc_destroy() so that the epc memory is freed when all references are
dropped.

Link: https://lore.kernel.org/r/20220623003817.298173-1-yoshihiro.shimoda.uh@renesas.comTested-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NLorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>