According to the PCIe standard the PERST# signal (reset-gpio in
fsl,imx* compatible dts) should be kept asserted for at least 100 usec
before the PCIe refclock is stable, should be kept asserted for at
least 100 msec after the power rails are stable and the host should wait
at least 100 msec after it is de-asserted before accessing the
configuration space of any attached device.

From PCIe CEM r2.0, sec 2.6.2

  T-PVPERL: Power stable to PERST# inactive - 100 msec
  T-PERST-CLK: REFCLK stable before PERST# inactive - 100 usec.

From PCIe r5.0, sec 6.6.1

  With a Downstream Port that does not support Link speeds greater than
  5.0 GT/s, software must wait a minimum of 100 ms before sending a
  Configuration Request to the device immediately below that Port.

Failure to do so could prevent PCIe devices to be working correctly,
and this was experienced with real devices.

Move reset assert to imx6_pcie_assert_core_reset(), this way we ensure
that PERST# is asserted before enabling any clock, move de-assert to the
end of imx6_pcie_deassert_core_reset() after the clock is enabled and
deemed stable and add a new delay of 100 msec just afterward.

Link: https://lore.kernel.org/all/20220211152550.286821-1-francesco.dolcini@toradex.com
Link: https://lore.kernel.org/r/20220404081509.94356-1-francesco.dolcini@toradex.com
Fixes: bb38919e ("PCI: imx6: Add support for i.MX6 PCIe controller")
Signed-off-by: NFrancesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NRichard Zhu <hongxing.zhu@nxp.com>

Fix the following build error:

  drivers/pci/controller/pci-hyperv.c:769:13: error: ‘hv_set_msi_entry_from_desc’ defined but not used [-Werror=unused-function]
    769 | static void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry,

The arm64 implementation of hv_set_msi_entry_from_desc() is not used after
d06957d7 ("PCI: hv: Avoid the retarget interrupt hypercall in
irq_unmask() on ARM64"), so remove it.

Fixes: d06957d7 ("PCI: hv: Avoid the retarget interrupt hypercall in irq_unmask() on ARM64")
Link: https://lore.kernel.org/r/20220317085130.36388-1-yuehaibing@huawei.comSigned-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Acked-by: NBoqun Feng <boqun.feng@gmail.com>

fu740_pcie_host_init() assigned "ret", but never used the value.  Drop it.

Found by Krzysztof using cppcheck:

  $ cppcheck --enable=all --force
  unreadVariable drivers/pci/controller/dwc/pcie-fu740.c:227 Variable 'ret' is assigned a value that is never used.
Reported-by: NKrzysztof Wilczyński <kw@linux.com>
Link: https://lore.kernel.org/r/20220313192933.434746-4-helgaas@kernel.orgSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>

hi3660_pcie_phy_init() assigned "pdev", but never used the value.  Drop it.

Found by Krzysztof using cppcheck:

  $ cppcheck --enable=all --force
  unreadVariable drivers/pci/controller/dwc/pcie-kirin.c:336 Variable 'pdev' is assigned a value that is never used.
Reported-by: NKrzysztof Wilczyński <kw@linux.com>
Link: https://lore.kernel.org/r/20220313192933.434746-3-helgaas@kernel.orgSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>

The fu740 PCIe core does not probe any devices on the SiFive Unmatched
board without this fix (or having U-Boot explicitly start the PCIe via
either boot-script or user command). The fix is to start the link at
2.5GT/s speeds and once the link is up then change the maximum speed back
to the default.

The U-Boot driver claims to set the link-speed to 2.5GT/s to get the probe
to work (and U-Boot does print link up at 2.5GT/s) in the following code:
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pci/pcie_dw_sifive.c?id=v2022.01#L271

Link: https://lore.kernel.org/r/20220318152430.526320-1-ben.dooks@codethink.co.ukSigned-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NPalmer Dabbelt <palmer@rivosinc.com>

Commit c7a75d07 ("PCI: xgene: Fix IB window setup") tried to
fix the damages that 6dce5aa5 ("PCI: xgene: Use inbound resources
for setup") caused, but actually didn't improve anything for some
plarforms (at least Mustang and m400 are still broken).

Given that 6dce5aa5 has been reverted, revert this patch as well,
restoring the PCIe support on XGene to its pre-5.5, working state.

Link: https://lore.kernel.org/r/YjN8pT5e6/8cRohQ@xps13.dannf
Link: https://lore.kernel.org/r/20220321104843.949645-3-maz@kernel.org
Fixes: c7a75d07 ("PCI: xgene: Fix IB window setup")
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Cc: Toan Le <toan@os.amperecomputing.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stéphane Graber <stgraber@ubuntu.com>
Cc: dann frazier <dann.frazier@canonical.com>

Commit 6dce5aa5 ("PCI: xgene: Use inbound resources for setup")
killed PCIe on my XGene-1 box (a Mustang board). The machine itself
is still alive, but half of its storage (over NVMe) is gone, and the
NVMe driver just times out.

Note that this machine boots with a device tree provided by the
UEFI firmware (2016 vintage), which could well be non conformant
with the spec, hence the breakage.

With the patch reverted, the box boots 5.17-rc8 with flying colors.

Link: https://lore.kernel.org/all/Yf2wTLjmcRj+AbDv@xps13.dannf
Link: https://lore.kernel.org/r/20220321104843.949645-2-maz@kernel.org
Fixes: 6dce5aa5 ("PCI: xgene: Use inbound resources for setup")
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Cc: Toan Le <toan@os.amperecomputing.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stéphane Graber <stgraber@ubuntu.com>
Cc: dann frazier <dann.frazier@canonical.com>

The CLKREQ# signal is an open drain, active low signal that is driven
low by the remote Endpoint device. But it might not be driven low if no
Endpoint device is connected.

On i.MX8MM PCIe, phy_init() may fail and system boot may hang if no
Endpoint is connected to assert CLKREQ#.

Handle this as on i.MX8MQ, where we explicitly assert CLKREQ# so the
PHY can be initialized.

Link: https://lore.kernel.org/r/1645672013-8949-1-git-send-email-hongxing.zhu@nxp.com
Fixes: 178e244c ("PCI: imx: Add the imx8mm pcie support")
Signed-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>

To balance phy->init_count, invoke the phy_exit() after phy_power_off().

Link: https://lore.kernel.org/r/1646289275-17813-1-git-send-email-hongxing.zhu@nxp.com
Fixes: 178e244c ("PCI: imx: Add the imx8mm pcie support")
Signed-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>

In case the controller is transitioning to L1 in rcar_pcie_config_access(),
any read/write access to PCIECDR triggers asynchronous external abort. This
is because the transition to L1 link state must be manually finished by the
driver. The PCIe IP can transition back from L1 state to L0 on its own.

The current asynchronous external abort hook implementation restarts
the instruction which finally triggered the fault, which can be a
different instruction than the read/write instruction which started
the faulting access. Usually the instruction which finally triggers
the fault is one which has some data dependency on the result of the
read/write. In case of read, the read value after fixup is undefined,
while a read value of faulting read should be PCI_ERROR_RESPONSE.

It is possible to enforce the fault using 'isb' instruction placed
right after the read/write instruction which started the faulting
access. Add custom register accessors which perform the read/write
followed immediately by 'isb'.

This way, the fault always happens on the 'isb' and in case of read,
which is located one instruction before the 'isb', it is now possible
to fix up the return value of the read in the asynchronous external
abort hook and make that read return PCI_ERROR_RESPONSE.

Link: https://lore.kernel.org/r/20220312212349.781799-2-marek.vasut@gmail.comTested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org

In case the controller is transitioning to L1 in rcar_pcie_config_access(),
any read/write access to PCIECDR triggers asynchronous external abort. This
is because the transition to L1 link state must be manually finished by the
driver. The PCIe IP can transition back from L1 state to L0 on its own.

Avoid triggering the abort in rcar_pcie_config_access() by checking whether
the controller is in the transition state, and if so, finish the transition
right away. This prevents a lot of unnecessary exceptions, although not all
of them.

Link: https://lore.kernel.org/r/20220312212349.781799-1-marek.vasut@gmail.comTested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org

If a host that uses the IP's integrated MSI Receiver lost power
during suspend, we call dw_pcie_setup_rc() to reinit the RC. But
dw_pcie_setup_rc() always sets pp->irq_mask[ctrl] to ~0, so the mask
register is always set as 0xffffffff incorrectly, thus the MSI can't
work after resume.

Fix this issue by moving pp->irq_mask[ctrl] initialization to
dw_pcie_host_init() so we can correctly set the mask reg during both
boot and resume.
Tested-by: NRichard Zhu <hongxing.zhu@nxp.com>
Link: https://lore.kernel.org/r/20211226074019.2556-1-jszhang@kernel.orgSigned-off-by: NJisheng Zhang <jszhang@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The calls to devm_gpiod_get_optional() have the -gpios at the end of the
name but the GPIO core code is already adding the suffix during the lookup.
This means the PCIe driver is not finding the necessary reset or power
lines to allow initialisation of the PCIe.

Drop the redundant '-gpios' when we look up GPIOs from the DT.

This bug has not been noticed because if U-Boot has setup the GPIO lines
for the hardware when it does the PCIe initialisation (either by booting
from PCIe or user command to access PCIe) then the PCIe will work in Linux.
The U-Boot as supplied by SiFive does not by default initialise any PCIe
component.

Link: https://lore.kernel.org/r/20220221210347.1335004-1-ben.dooks@codethink.co.ukSigned-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

AIC2 changes the IRQ fwspec to add a cell. Always use the second-to-last
cell for the MSI handling, so it will work for both AIC1 and AIC2 devices.
Signed-off-by: NHector Martin <marcan@marcan.st>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220309192123.152028-2-marcan@marcan.st

i.MX6QP PCIe supports the reset logic, thus it can reset itself to the
initialized state when exit from L2 or L3 states.

Enable the i.MX6QP PCIe suspend/resume operations support.

Link: https://lore.kernel.org/r/1645425237-4071-2-git-send-email-hongxing.zhu@nxp.comSigned-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>

On ARM64 Hyper-V guests, SPIs are used for the interrupts of virtual PCI
devices, and SPIs can be managed directly via GICD registers. Therefore
the retarget interrupt hypercall is not needed on ARM64.

An arch-specific interface hv_arch_irq_unmask() is introduced to handle
the architecture level differences on this. For x86, the behavior
remains unchanged, while for ARM64 no hypercall is invoked when
unmasking an irq for virtual PCI devices.

Link: https://lore.kernel.org/r/20220217034525.1687678-1-boqun.feng@gmail.comSigned-off-by: NBoqun Feng <boqun.feng@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>

This reverts commit b0c6ae0f.

Armada 3720 phy driver (phy-mvebu-a3700-comphy.c) does not return
-EOPNOTSUPP from phy_power_on() callback anymore.

So remove dead code which handles -EOPNOTSUPP return value.
Signed-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Link: https://lore.kernel.org/r/20220203214444.1508-6-kabel@kernel.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

Today drivers/pci/controller/pci-xgene.c defines SZ_1T

Move it into linux/sizes.h so that it can be re-used elsewhere.

Link: https://lore.kernel.org/r/575cb7164cf124c75df7cb9242ea7374733942bf.1642752946.git.christophe.leroy@csgroup.euSigned-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Toan Le <toan@os.amperecomputing.com>
Cc: linux-pci@vger.kernel.org

On SM8450 platform PCIe hosts do not use all the clocks (and add several
additional clocks), so expand the driver to handle these requirements.

PCIe0 and PCIe1 hosts use different sets of clocks, so separate entries
are required.

Link: https://lore.kernel.org/r/20220223101435.447839-5-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NStanimir Varbanov <svarbanov@mm-sol.com>

Qualcomm PCIe driver uses compatible string to check if the ddrss_sf_tbu
clock should be used. Since sc7280 support has added flags, switch to
the new mechanism to check if this clock should be used.

Link: https://lore.kernel.org/r/20220223101435.447839-4-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NStanimir Varbanov <svarbanov@mm-sol.com>

In preparation to adding more flags to configuration data, use pointer
to struct qcom_pcie_cfg directly inside struct qcom_pcie, rather than
duplicating all its fields. This would save us from the boilerplate code
that just copies flag values from one struct to another one.

Link: https://lore.kernel.org/r/20220223101435.447839-3-dmitry.baryshkov@linaro.orgSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NStanimir Varbanov <svarbanov@mm-sol.com>

This adds support for legacy INTx interrupts received from other PCIe
devices and which are reported by a new INTx irq chip.

With this change, kernel can distinguish between INTA, INTB, INTC and INTD
interrupts.

Note that for this support, device tree files has to be properly adjusted
to provide "interrupts" or "interrupts-extended" property with intx
interrupt source, "interrupt-names" property with "intx" string and also
'interrupt-controller' subnode must be defined.

If device tree files do not provide these nodes then driver would work as
before.

Link: https://lore.kernel.org/r/20220222155030.988-12-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Register 0x1910 unmasks interrupts and legacy INTx interrupts are unmasked
because driver does not support individual masking yet.

Link: https://lore.kernel.org/r/20220222155030.988-11-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Split struct pci_ops between ops and child_ops. Member ops is used for
accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for
accessing real PCIe cards.

There is no need to mix these two struct pci_ops into one as PCI core code
already provides separate callbacks via bridge->ops and bridge->child_ops.

Link: https://lore.kernel.org/r/20220222155030.988-9-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND,
PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP
hardware and returns zeros.

Note that AER interrupt is not supported yet as mvebu emulated bridge does
not implement interrupts support at all yet.

Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and
correctly this register should be referenced via standard macros with
offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4.

Link: https://lore.kernel.org/r/20220222155030.988-8-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via
emulated bridge.

After this change Subsystem ID is visible in lspci output at line:

  Capabilities: [40] Subsystem

Link: https://lore.kernel.org/r/20220222155030.988-7-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

If x1/x4 mode is not set correctly then link with endpoint card is not
established.

Use DTS property 'num-lanes' to deteriminate x1/x4 mode.

Link: https://lore.kernel.org/r/20220222155030.988-6-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Tejas reported the following recursive locking issue:

 swapper/0/1 is trying to acquire lock:
 ffff8881074fd0a0 (&md->mutex){+.+.}-{3:3}, at: msi_get_virq+0x30/0xc0
 
 but task is already holding lock:
 ffff8881017cd6a0 (&md->mutex){+.+.}-{3:3}, at: __pci_enable_msi_range+0xf2/0x290
 
 stack backtrace:
  __mutex_lock+0x9d/0x920
  msi_get_virq+0x30/0xc0
  pci_irq_vector+0x26/0x30
  vmd_msi_init+0xcc/0x210
  msi_domain_alloc+0xbf/0x150
  msi_domain_alloc_irqs_descs_locked+0x3e/0xb0
  __pci_enable_msi_range+0x155/0x290
  pci_alloc_irq_vectors_affinity+0xba/0x100
  pcie_port_device_register+0x307/0x550
  pcie_portdrv_probe+0x3c/0xd0
  pci_device_probe+0x95/0x110

This is caused by the VMD MSI code which does a lookup of the Linux
interrupt number for an VMD managed MSI[X] vector. The lookup function
tries to acquire the already held mutex.

Avoid that by caching the Linux interrupt number at initialization time
instead of looking it up over and over.

Fixes: 82ff8e6b ("PCI/MSI: Use msi_get_virq() in pci_get_vector()")
Reported-by: N"Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: N"Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com>
Cc: linux-pci@vger.kernel.org
Link: https://lore.kernel.org/r/87a6euub2a.ffs@tglx

Register 0x43c in its low 24 bits contains PCI class code.

Update code to set all 24 bits of PCI class code and not only upper 16 bits
of PCI class code.

Use a new macro PCI_CLASS_BRIDGE_PCI_NORMAL which represents whole 24 bits
of normal PCI bridge class.

Link: https://lore.kernel.org/r/20220214114109.26809-2-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRoman Bacik <roman.bacik@broadcom.com>
Acked-by: NRay Jui <ray.jui@broadcom.com>

Add these PCI class codes to pci_ids.h:

  PCI_CLASS_BRIDGE_PCI_NORMAL
  PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

Use these defines in all kernel code for describing PCI class codes for
normal and subtractive PCI bridges.

[bhelgaas: similar change in pci-mvebu.c]
Link: https://lore.kernel.org/r/20220214114109.26809-1-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Jan reported that on Turris Omnia (Armada 385), no PCIe devices were
detected after upgrading from v5.16.1 to v5.16.3 and identified the cause
as the backport of 91a8d79f ("PCI: mvebu: Fix configuring secondary bus
of PCIe Root Port via emulated bridge"), which appeared in v5.17-rc1.

91a8d79f was incorrectly applied from mailing list patch [1] to the
linux git repository [2] probably due to resolving merge conflicts
incorrectly. Fix it now.

[1] https://lore.kernel.org/r/20211125124605.25915-12-pali@kernel.org
[2] https://git.kernel.org/linus/91a8d79fc797

[bhelgaas: commit log]
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215540
Fixes: 91a8d79f ("PCI: mvebu: Fix configuring secondary bus of PCIe Root Port via emulated bridge")
Link: https://lore.kernel.org/r/20220214110228.25825-1-pali@kernel.org
Link: https://lore.kernel.org/r/20220127234917.GA150851@bhelgaasReported-by: NJan Palus <jpalus@fastmail.com>
Signed-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add basic support for UniPhier NX1 SoC as non-legacy SoC. This includes
a compatible string, SoC-dependent data containing init() and wait()
functions for the controller.

Link: https://lore.kernel.org/r/1644480596-20037-4-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>

Define SoC data structure that includes pci_epc_features, SoC-dependent
callback functions and flags to distinguish the behavior of each SoC.
The callback functions define init() to initialize the controller and
wait() to wait until initialization is completed.

Rename uniphier_pcie_init_ep() to uniphier_pcie_pro5_init_ep() for
initializing PCIe controller implemented in Pro5 SoC. And Pro5 SoC
doesn't have wait() function.

Link: https://lore.kernel.org/r/1644480596-20037-3-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>

Update the comment about what happens when link goes down after we have
checked for link-up. If a PIO request is done while link-down, we have
a serious problem.

Link: https://lore.kernel.org/r/20220110015018.26359-23-kabel@kernel.orgSigned-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

This function is now always used in driver remove method, drop the
__maybe_unused attribute.

Link: https://lore.kernel.org/r/20220110015018.26359-22-kabel@kernel.orgSigned-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

By default, all Legacy INTx interrupts are masked, so there is no need to
mask this interrupt during irq_map() callback.

Link: https://lore.kernel.org/r/20220110015018.26359-21-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Callback for irq_mask_ack() is the same as for irq_mask(). As there is no
special handling for irq_ack(), there is no need to define irq_mask_ack()
too.

Link: https://lore.kernel.org/r/20220110015018.26359-20-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NMarc Zyngier <maz@kernel.org>

Emulated root bridge currently provides only one Legacy INTA interrupt
which is used for reporting PCIe PME and ERR events and handled by kernel
PCIe PME and AER drivers.

Aardvark HW reports these PME and ERR events separately, so there is no
need to mix real INTA interrupt and emulated INTA interrupt for PCIe PME
and AER drivers.

Register a new advk-RP (as in Root Port) irq chip and a new irq domain
for emulated root bridge and use this new separate irq domain for
providing INTA interrupt from emulated root bridge for PME and ERR events.

The real INTA interrupt from real devices is now separate.

A custom map_irq callback function on PCI host bridge structure is used to
allocate IRQ mapping for emulated root bridge from new irq domain. Original
callback of_irq_parse_and_map_pci() is used for all other devices as before.

Link: https://lore.kernel.org/r/20220110015018.26359-19-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Enable aardvark PME interrupt unconditionally by unmasking it and read PME
requester ID to emulated bridge config space immediately after receiving
interrupt.

PME requester ID is stored in the PCIE_MSG_LOG_REG register, which contains
the last inbound message. So when new inbound message is received by HW
(including non-PM), the content in PCIE_MSG_LOG_REG register is replaced by
a new value.

PCIe specification mandates that subsequent PMEs are kept pending until the
PME Status Register bit is cleared by software by writing a 1b.

Support for masking/unmasking PME interrupt on emulated bridge via
PCI_EXP_RTCTL_PMEIE bit is now implemented only in emulated bridge config
space, to ensure that we do not miss any aardvark PME interrupt.

Reading of PCI_EXP_RTCAP and PCI_EXP_RTSTA registers is simplified as final
value is now always stored into emulated bridge config space by the
interrupt handler, so there is no need to implement support for these
registers in read_pcie callback.

Clearing of W1C bit PCI_EXP_RTSTA_PME is now also simplified as it is done
by pci-bridge-emul.c code for emulated bridge config space. So there is no
need to implement support for clearing this bit in write_pcie callback.

Link: https://lore.kernel.org/r/20220110015018.26359-18-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Currently enabling PCI_EXP_RTSTA_PME bit in PCI_EXP_RTCTL register does
nothing. This is because PCIe PME driver expects to receive PCIe interrupt
defined in PCI_EXP_FLAGS_IRQ register, but aardvark hardware does not
trigger PCIe INTx/MSI interrupt for PME event, rather it triggers custom
aardvark interrupt which this driver is not processing yet.

Fix this issue by handling PME interrupt in advk_pcie_handle_int() and
chaining it to PCIe interrupt 0 with generic_handle_domain_irq() (since
aardvark sets PCI_EXP_FLAGS_IRQ to zero). With this change PCIe PME driver
finally starts receiving PME interrupt.

Link: https://lore.kernel.org/r/20220110015018.26359-17-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>