Wherever possible, replace constructs that match either
generic_handle_irq(irq_find_mapping()) or
generic_handle_irq(irq_linear_revmap()) to a single call to
generic_handle_domain_irq().

Link: https://lore.kernel.org/r/20210802162630.2219813-4-maz@kernel.orgSigned-off-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>

tegra_pcie_ep_raise_msi_irq() shifted a signed 32-bit value left by 31
bits.  The behavior of this is implementation-defined.

Replace the shift by BIT(), which is well-defined.

Found by cppcheck:

  $ cppcheck --enable=all drivers/pci/controller/dwc/pcie-tegra194.c
  Checking drivers/pci/controller/dwc/pcie-tegra194.c ...

  drivers/pci/controller/dwc/pcie-tegra194.c:1829:23: portability: Shifting signed 32-bit value by 31 bits is implementation-defined behaviour. See condition at line 1826.  [shiftTooManyBitsSigned]

  appl_writel(pcie, (1 << irq), APPL_MSI_CTRL_1);
                     ^

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20210618160219.303092-1-jonathanh@nvidia.com
Fixes: c57247f9 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit 275e88b0 ("PCI: tegra: Fix host link initialization") broke
host initialization during resume as it misses out calling the API
dw_pcie_setup_rc() which is required for host and MSI initialization.

Link: https://lore.kernel.org/r/20210504172157.29712-1-vidyas@nvidia.com
Fixes: 275e88b0 ("PCI: tegra: Fix host link initialization")
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The i.MX8MQ PCIe PHY needs 1.8V in default but can be supplied by either a
1.8V or a 3.3V regulator.

The "vph-supply" DT property tells us which external regulator supplies the
PHY. If that regulator supplies anything over 3V, enable the PHY's internal
3.3V-to-1.8V regulator.

Link: https://lore.kernel.org/r/1622771269-13844-3-git-send-email-hongxing.zhu@nxp.comSigned-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>

Define the length of the DBI registers and limit config space to its
length. This makes sure that the kernel does not access registers beyond
that point that otherwise would lead to an abort on the i.MX 6QuadPlus.

See commit 075af61c ("PCI: imx6: Limit DBI register length") that
resolves a similar issue on the i.MX 6Quad PCIe.

Link: https://lore.kernel.org/r/1613789388-2495-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>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>

When devm_ioremap_resource() fails, __devm_ioremap_resource() prints an
error message including the device name, failure cause, and possibly
resource information.

Remove the error message from imx6_pcie_probe() since it's redundant.

Link: https://lore.kernel.org/r/20210511114547.5601-1-thunder.leizhen@huawei.comReported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
Acked-by: NRichard Zhu <hongxing.zhu@nxp.com>

The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN bits
13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however was
taking (for example) "13" as raw value instead of taking BIT(13).  Define
the legacy PCI interrupt bits using the BIT() macro and then use these in
PCIE_APP_IRN_INT.

Link: https://lore.kernel.org/r/20210106135540.48420-1-martin.blumenstingl@googlemail.com
Fixes: ed22aaae ("PCI: dwc: intel: PCIe RC controller driver")
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRahul Tanwar <rtanwar@maxlinear.com>

7f100744 ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata")
caused a few build regressions:

  - 7f100744 removed the Makefile rule for CONFIG_PCIE_TEGRA194, so
    pcie-tegra.c can no longer be built as a module.  Restore that rule.

  - 7f100744 added "#ifdef CONFIG_PCIE_TEGRA194" around the native
    driver, but that's only set when the driver is built-in (for a module,
    CONFIG_PCIE_TEGRA194_MODULE is defined).

    The ACPI quirk is completely independent of the rest of the native
    driver, so move the quirk to its own file and remove the #ifdef in the
    native driver.

  - 7f100744 added symbols that are always defined but used only when
    CONFIG_PCIEASPM, which causes warnings when CONFIG_PCIEASPM is not set:

      drivers/pci/controller/dwc/pcie-tegra194.c:259:18: warning: ‘event_cntr_data_offset’ defined but not used [-Wunused-const-variable=]
      drivers/pci/controller/dwc/pcie-tegra194.c:250:18: warning: ‘event_cntr_ctrl_offset’ defined but not used [-Wunused-const-variable=]
      drivers/pci/controller/dwc/pcie-tegra194.c:243:27: warning: ‘pcie_gen_freq’ defined but not used [-Wunused-const-variable=]

Fixes: 7f100744 ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata")
Link: https://lore.kernel.org/r/20210610064134.336781-1-jonathanh@nvidia.comSigned-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Add driver for the SiFive FU740 PCIe host controller.
This controller is based on the DesignWare PCIe core.
Co-developed-by: NHenry Styles <hes@sifive.com>
Co-developed-by: NErik Danie <erik.danie@sifive.com>
Co-developed-by: NGreentime Hu <greentime.hu@sifive.com>
Link: https://lore.kernel.org/r/20210504105940.100004-6-greentime.hu@sifive.comSigned-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: NHenry Styles <hes@sifive.com>
Signed-off-by: NErik Danie <erik.danie@sifive.com>
Signed-off-by: NGreentime Hu <greentime.hu@sifive.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

dw_pcie_ep_init() depends on the detected iATU region numbers to allocate
the in/outbound window management bitmap.  It fails after 281f1f99
("PCI: dwc: Detect number of iATU windows").

Move the iATU region detection into a new function, move the detection to
the very beginning of dw_pcie_host_init() and dw_pcie_ep_init().  Also
remove it from the dw_pcie_setup(), since it's more like a software
initialization step than hardware setup.

Link: https://lore.kernel.org/r/20210125044803.4310-1-Zhiqiang.Hou@nxp.com
Link: https://lore.kernel.org/linux-pci/20210407131255.702054-1-dmitry.baryshkov@linaro.org
Link: https://lore.kernel.org/r/20210413142219.2301430-1-dmitry.baryshkov@linaro.org
Fixes: 281f1f99 ("PCI: dwc: Detect number of iATU windows")
Tested-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
[DB: moved dw_pcie_iatu_detect to happen after host_init callback]
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Cc: stable@vger.kernel.org	# v5.11+
Cc: Marek Szyprowski <m.szyprowski@samsung.com>

Fix the following clang warning:

drivers/pci/controller/dwc/pcie-intel-gw.c:84:19: warning: unused
function 'pcie_app_rd' [-Wunused-function].

Link: https://lore.kernel.org/r/1618475577-99198-1-git-send-email-jiapeng.chong@linux.alibaba.comReported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>

If the host which makes use of IP's integrated MSI Receiver losts
power during suspend, we need to reinit the RC and MSI Receiver in
resume. But after we move dw_pcie_msi_init() into the core, we have no
API to do so. Usually the dwc users need to call dw_pcie_setup_rc() to
reinit the RC, we can solve this problem by moving dw_pcie_msi_init()
to dw_pcie_setup_rc().

Link: https://lore.kernel.org/r/20210325152604.6e79deba@xhacker.debianSigned-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>

The PCIe controller in Tegra194 SoC is not ECAM-compliant.  With the
current hardware design, ECAM can be enabled only for one controller (the
C5 controller) with bus numbers starting from 160 instead of 0. A different
approach is taken to avoid this abnormal way of enabling ECAM for just one
controller but to enable configuration space access for all the other
controllers. In this approach, ops are added through MCFG quirk mechanism
which access the configuration spaces by dynamically programming iATU
(internal AddressTranslation Unit) to generate respective configuration
accesses just like the way it is done in DesignWare core sub-system.

This issue is specific to Tegra194 and it would be fixed in the future
generations of Tegra SoCs.

Link: https://lore.kernel.org/r/20210416134537.19474-1-vidyas@nvidia.comSigned-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Link: https://lore.kernel.org/r/20210408072700.15791-1-dinghao.liu@zju.edu.cnSigned-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NThierry Reding <treding@nvidia.com>

In config PCIE_TEGRA194_EP the mode incorrectly is referred to as
host mode. Fix it.

Link: https://lore.kernel.org/r/20201231032539.22322-1-wesley.sheng@amd.comSigned-off-by: NWesley Sheng <wesley.sheng@amd.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
Acked-by: NVidya Sagar <vidyas@nvidia.com>

Replace command with a semicolon to correct syntax and to prevent
potential unspecified behaviour and/or unintended side effects.

Related:
  https://lore.kernel.org/linux-pci/20201216131944.14990-1-zhengyongjun3@huawei.com/Co-authored-by: NZheng Yongjun <zhengyongjun3@huawei.com>
Link: https://lore.kernel.org/r/20210311033745.1547044-1-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NRoy Zang <roy.zang@nxp.com>

Both TI's AM65x (K3) and TI's K2 PCIe driver are implemented in
pci-keystone. However Only K2 PCIe driver should use it's own pci_ops
for configuration space accesses. But commit 10a797c6
("PCI: dwc: keystone: Use pci_ops for config space accessors") used
custom pci_ops for both AM65x and K2. This breaks configuration space
access for AM65x platform. Fix it here.

Link: https://lore.kernel.org/r/20210317131518.11040-1-kishon@ti.com
Fixes: 10a797c6 ("PCI: dwc: keystone: Use pci_ops for config space accessors")
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
Cc: <stable@vger.kernel.org> # v5.10

The only usage of them is to assign their address to the 'ops' field in
the pcie_port and the dw_pcie_ep structs, both which are pointers to
const. Make them const to allow the compiler to put them in read-only
memory.

Link: https://lore.kernel.org/r/20210207221604.48910-1-rikard.falkeborn@gmail.comSigned-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>

Fix kernel-doc formatting errors, function names that don't match the doc,
and some missing parameter documentation.  These are reported by:

  make W=1 drivers/pci/

No functional change intended.

[bhelgaas: squashed into one patch since this only changes comments]
Link: https://lore.kernel.org/r/20210311001724.423356-1-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-2-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-3-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-4-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-5-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-6-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-7-kw@linux.com
Link: https://lore.kernel.org/r/20210311001724.423356-8-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

There are harmless warnings when compile testing the kernel with
CONFIG_TRIM_UNUSED_KSYMS:

  drivers/pci/controller/dwc/pcie-al.o: no symbols
  drivers/pci/controller/pci-thunder-ecam.o: no symbols
  drivers/pci/controller/pci-thunder-pem.o: no symbols

The problem here is that the host drivers get built even when the
configuration symbols are all disabled, as they pretend to not be drivers
but are silently enabled because of the promise that ACPI-based systems
need no drivers.

Add back the normal symbols to have these drivers built, and change the
logic to otherwise only build them when both CONFIG_PCI_QUIRKS and
CONFIG_ACPI are enabled.

As a side-effect, this enables compile-testing the drivers on other
architectures, which in turn needs the acpi_get_rc_resources() function to
be defined.

Link: https://lore.kernel.org/r/20210308152501.2135937-3-arnd@kernel.orgSigned-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRobert Richter <rric@kernel.org>

Compile-testing this driver without ECAM support results in a link failure:

  ld.lld: error: undefined symbol: pci_ecam_map_bus
  >>> referenced by pcie-al.c
  >>>               pci/controller/dwc/pcie-al.o:(al_pcie_map_bus) in archive drivers/built-in.a

Select CONFIG_ECAM like the other drivers do.

Link: https://lore.kernel.org/r/20210308152501.2135937-1-arnd@kernel.orgSigned-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>

After updating pci-dra7xx driver to probe with ti-sysc and genpd, I
noticed that dra7xx_pcie_probe() would not run if a power-domains property
was configured for the interconnect target module.

Turns out that module_platform_driver_probe uses platform_driver_probe(),
while builtin_platform_driver uses platform_driver_register().

Only platform_driver_register() works for deferred probe as noted in the
comments for __platform_driver_probe() in drivers/base/platform.c with a
line saying "Note that this is incompatible with deferred probing".

With module_platform_driver_probe, we have platform_driver_probe() produce
-ENODEV error at device_initcall() level, and no further attempts are done.
Let's fix this by using module_platform_driver instead.

Note this is not an issue currently as we probe devices with simple-bus,
and only is needed as we start probing the device with ti-sysc, or when
probed with simple-pm-bus.

Note that we must now also remove __init for probe related functions to
avoid a section mismatch warning.

Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The use of PHY_REFCLK_USE_PAD introduced a regression for apq8064 devices.
It was tested that while apq doesn't require the padding, ipq SoC must use
it or the kernel hangs on boot.

Link: https://lore.kernel.org/r/20201019165555.8269-1-ansuelsmth@gmail.com
Fixes: de3c4bf6 ("PCI: qcom: Add support for tx term offset for rev 2.1.0")
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NAnsuel Smith <ansuelsmth@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Cc: stable@vger.kernel.org	# v4.19+

On SM8250 additional clock is required for PCIe devices to access NOC.
Update PCIe controller driver to control this clock.

Link: https://lore.kernel.org/r/20210117013114.441973-3-dmitry.baryshkov@linaro.org
Fixes: e1dd639e ("PCI: qcom: Add SM8250 SoC support")
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: NStanimir Varbanov <svarbanov@mm-sol.com>

We have removed the assumption that dw_pcie_ops always exists in the dwc
core driver, so we can remove the useless dw_pcie_ops now.

Link: https://lore.kernel.org/r/20210128144324.2fa8577c@xhacker.debianSigned-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJonathan Chocron <jonnyc@amazon.com>

Some dwc-based device drivers, especially host-only drivers, may work well
with the default read_dbi/write_dbi/link_up implementations in
pcie-designware.c, so remove the assumption that every driver implements
them to simplify those drivers.

Link: https://lore.kernel.org/r/20210128144258.10329aa4@xhacker.debianSigned-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The size parameter is unsigned long type which can accept size > 4GB. In
that case, the upper limit address must be programmed. Add support to
program the upper limit address and set INCREASE_REGION_SIZE in case size >
4GB.

Link: https://lore.kernel.org/r/1612250918-19610-1-git-send-email-shradha.t@samsung.comSigned-off-by: NShradha Todi <shradha.t@samsung.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: NRob Herring <robh@kernel.org>

Since outbound iATU permits size to be greater than 4GB for which the
support is also available, allow EP function to send u64 size instead of
truncating to u32.

Link: https://lore.kernel.org/r/1609929900-19082-1-git-send-email-shradha.t@samsung.comSigned-off-by: NShradha Todi <shradha.t@samsung.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NPankaj Dubey <pankaj.dubey@samsung.com>

Since commit a0fd361d ("PCI: dwc: Move "dbi", "dbi2", and
"addr_space" resource setup into common code"), the code
setting dbi_base when the config space is defined in 'ranges' property
instead of 'reg' is dead code as dbi_base is never NULL.

Rather than fix this, let's just drop the code. Using ranges has been
deprecated since 2014. The only platforms using this were exynos5440,
i.MX6 and Spear13xx. Exynos5440 is dead and has been removed. i.MX6 and
Spear13xx had PCIe support added just before this was deprecated and
were fixed within a kernel release or 2.

Link: https://lore.kernel.org/r/20201215194149.86831-1-robh@kernel.orgReported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

fw_devlink will defer the probe until all suppliers are ready. We can't
use builtin_platform_driver_probe() because it doesn't retry after probe
deferral. Convert it to builtin_platform_driver().

Link: https://lore.kernel.org/r/20210120105246.23218-1-michael@walle.ccSigned-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The LX2160A rev2 uses the same PCIe IP as LS2088A, but LX2160A rev2 PCIe
controller is integrated with different stride between PFs' register
address.

Link: https://lore.kernel.org/r/20201026051448.1913-2-Zhiqiang.Hou@nxp.comSigned-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

DesignWare core has a TLP digest (TD) override bit in one of the control
registers of ATU. This bit also needs to be programmed for proper ECRC
functionality. This is currently identified as an issue with DesignWare
IP version 4.90a.

[bhelgaas: fix typos/grammar errors]
Link: https://lore.kernel.org/r/20201230165723.673-1-vidyas@nvidia.comSigned-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

Call irq_set_chained_handler_and_data() to clear the chained handler
and the handler's data under irq_desc->lock.

See also 2cf5a03c ("PCI/keystone: Fix race in installing chained
IRQ handler").

Link: https://lore.kernel.org/r/20210115212435.19940-2-martin@kaiser.cxSigned-off-by: NMartin Kaiser <martin@kaiser.cx>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Commit 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address
allocation") added dma_mask_set() call to explicitly set 32-bit DMA mask
for MSI message mapping, but for now it throws a warning on ret == 0, while
dma_set_mask() returns 0 in case of success.

Fix this by inverting the condition.

[bhelgaas: join string to make it greppable]
Fixes: 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation")
Link: https://lore.kernel.org/r/20201222150708.67983-1-alobakin@pm.meSigned-off-by: NAlexander Lobakin <alobakin@pm.me>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common
code") broke enumeration of downstream devices on Tegra:

In non-working case (next-20201211):

  0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
  0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
  0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)

In working case (v5.10-rc7):

  0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1)
  0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
  0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1)
  0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
  0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
  0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)

The problem seems to be dw_pcie_setup_rc() is now called twice before and
after the link up handling. The fix is to move Tegra's link up handling to
.start_link() function like other DWC drivers. Tegra is a bit more
complicated than others as it re-inits the whole DWC controller to retry
the link. With this, the initialization ordering is restored to match the
prior sequence.

Fixes: b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code")
Link: https://lore.kernel.org/r/20201218143905.1614098-1-robh@kernel.orgReported-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Tested-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Vidya Sagar <vidyas@nvidia.com>

Add ECAM-related constants to provide a set of standard constants
defining memory address shift values to the byte-level address that can
be used to access the PCI Express Configuration Space, and then move
native PCI Express controller drivers to use the newly introduced
definitions retiring driver-specific ones.

Refactor pci_ecam_map_bus() function to use newly added constants so
that limits to the bus, device function and offset (now limited to 4K as
per the specification) are in place to prevent the defective or
malicious caller from supplying incorrect configuration offset and thus
targeting the wrong device when accessing extended configuration space.

This refactor also allows for the ".bus_shift" initialisers to be
dropped when the user is not using a custom value as a default value
will be used as per the PCI Express Specification.

Thanks to Qian Cai <qcai@redhat.com>, Michael Walle <michael@walle.cc>,
and Vladimir Oltean <olteanv@gmail.com> for reporting a pci_ecam_create()
issue with .bus_shift and to Vladimir for proposing the fix.

[bhelgaas: incorporate Vladimir's fix, update commit log]
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20201129230743.3006978-2-kw@linux.comTested-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJon Derrick <jonathan.derrick@intel.com>
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>

Set DMA mask to 32-bit while allocating the MSI target address so that
the address is usable for both 32-bit and 64-bit MSI capable devices.
Throw a warning if it fails to set the mask to 32-bit to alert that
devices that are only 32-bit MSI capable may not work properly.

Link: https://lore.kernel.org/r/20201117165312.25847-1-vidyas@nvidia.comSigned-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>

For SM8250, we need to write the BDF to SID mapping in PCIe controller
register space for proper working. This is accomplished by extracting
the BDF and SID values from "iommu-map" property in DT and writing those
in the register address calculated from the hash value of BDF. In case
of collisions, the index of the next entry will also be written.

For the sake of it, let's introduce a "config_sid" callback and do it
conditionally for SM8250.

Link: https://lore.kernel.org/r/20201208121402.178011-4-mani@kernel.orgSigned-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The PCIe IP (rev 1.9.0) on SM8250 SoC is similar to the one used on
SDM845. Hence the support is added reusing the members of ops_2_7_0.
The key difference between ops_2_7_0 and ops_1_9_0 is the config_sid
callback, which will be added in successive commit.

Link: https://lore.kernel.org/r/20201208121402.178011-3-mani@kernel.orgSigned-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>

PCIe cards like Marvell SATA controller and some of the Samsung NVMe
drives don't support taking the link to L2 state. When the link doesn't
go to L2 state, Tegra194 requires the LTSSM to be disabled to allow PHY
to start the next link up process cleanly during suspend/resume sequence.
Failing to disable LTSSM results in the PCIe link not coming up in the
next resume cycle.

Link: https://lore.kernel.org/r/20201203133451.17716-6-vidyas@nvidia.comTested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NVidya Sagar <vidyas@nvidia.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NThierry Reding <treding@nvidia.com>