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>

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>

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>

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>

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 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>

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>

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>

Bean reported that a622435f ("PCI: kirin: Prefer
of_device_get_match_data()") broke kirin_pcie_probe() because it assumed
match data of 0 was a failure when in fact, it meant the match data was
"(void *)PCIE_KIRIN_INTERNAL_PHY".

Therefore, probing of "hisilicon,kirin960-pcie" devices failed with -EINVAL
and an "OF data missing" message.

Add a struct kirin_pcie_data to encode the PHY type.  Then the result of
of_device_get_match_data() should always be a non-NULL pointer to a struct
kirin_pcie_data that contains the PHY type.

Fixes: a622435f ("PCI: kirin: Prefer of_device_get_match_data()")
Link: https://lore.kernel.org/r/20220202162659.GA12603@bhelgaas
Link: https://lore.kernel.org/r/20220201215941.1203155-1-huobean@gmail.comReported-by: NBean Huo <beanhuo@micron.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The intention of commit 886a9c13 ("PCI: dwc: Move link handling into
common code") was to standardize the behavior of link down as explained
in its commit log:

"The behavior for a link down was inconsistent as some drivers would fail
probe in that case while others succeed. Let's standardize this to
succeed as there are usecases where devices (and the link) appear later
even without hotplug. For example, a reconfigured FPGA device."

The pci-imx6 still fails to probe when the link is not present, which
causes the following warning:

imx6q-pcie 8ffc000.pcie: Phy link never came up
imx6q-pcie: probe of 8ffc000.pcie failed with error -110
------------[ cut here ]------------
WARNING: CPU: 0 PID: 30 at drivers/regulator/core.c:2257 _regulator_put.part.0+0x1b8/0x1dc
Modules linked in:
CPU: 0 PID: 30 Comm: kworker/u2:2 Not tainted 5.15.0-next-20211103 #1
Hardware name: Freescale i.MX6 SoloX (Device Tree)
Workqueue: events_unbound async_run_entry_fn
[<c0111730>] (unwind_backtrace) from [<c010bb74>] (show_stack+0x10/0x14)
[<c010bb74>] (show_stack) from [<c0f90290>] (dump_stack_lvl+0x58/0x70)
[<c0f90290>] (dump_stack_lvl) from [<c012631c>] (__warn+0xd4/0x154)
[<c012631c>] (__warn) from [<c0f87b00>] (warn_slowpath_fmt+0x74/0xa8)
[<c0f87b00>] (warn_slowpath_fmt) from [<c076b4bc>] (_regulator_put.part.0+0x1b8/0x1dc)
[<c076b4bc>] (_regulator_put.part.0) from [<c076b574>] (regulator_put+0x2c/0x3c)
[<c076b574>] (regulator_put) from [<c08c3740>] (release_nodes+0x50/0x178)

Fix this problem by ignoring the dw_pcie_wait_for_link() error like
it is done on the other dwc drivers.

Tested on imx6sx-sdb and imx6q-sabresd boards.

Link: https://lore.kernel.org/r/20220106103645.2790803-1-festevam@gmail.com
Fixes: 886a9c13 ("PCI: dwc: Move link handling into common code")
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NRichard Zhu <hongxing.zhu@nxp.com>
Cc: <stable@vger.kernel.org>

find_first{,_zero}_bit is a more effective analogue of 'next' version if
start == 0. This patch replaces 'next' with 'first' where things look
trivial.
Signed-off-by: NYury Norov <yury.norov@gmail.com>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>

Get "syscon" pcie_mode and pcie_id offset from the argument of
"ti,syscon-pcie-id" and "ti,syscon-pcie-mode" phandle respectively.
Previously a subnode to "syscon" node was added which has the
exact memory mapped address of pcie_mode and pcie_id but now the
offset of pcie_mode and pcie_id within "syscon" is now being passed
as argument to "ti,syscon-pcie-id" and "ti,syscon-pcie-mode" phandle.

If the offset is not provided in "ti,syscon-pcie-id"/"ti,syscon-pcie-mode",
the full memory mapped address of pcie_ctrl is used in order to maintain
old DT compatibility.

Similar change for J721E is as discussed in [1]

[1] -> http://lore.kernel.org/r/CAL_JsqKiUcO76bo1GoepWM1TusJWoty_BRy2hFSgtEVMqtrvvQ@mail.gmail.com

Link: https://lore.kernel.org/r/20211126083119.16570-3-kishon@ti.comSigned-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

The current Layerscape PCIe driver directly uses the physical layer
LTSSM code to check the link-up state, which treats the > L0 states
as link-up. This is not correct, since there is not explicit map
between link-up state and LTSSM. So this patch changes to use the
DWC common link-up check function.

Link: https://lore.kernel.org/r/20211224094000.8513-1-Zhiqiang.Hou@nxp.comSigned-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>

The only usage of pci_ep_ops is to assign its address to the ops field
in the dw_pcie_ep struct which is a pointer to const struct dw_pcie_ep_ops.
Make it const to allow the compiler to put it in read-only memory.

Link: https://lore.kernel.org/r/20211204220316.88655-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>

The sparse checker complains about converting pointers between address
spaces.  We correctly stored an __iomem pointer in struct spear13xx_pcie,
but discarded the __iomem when extracting app_base, causing one warning.
Then we passed the non-__iomem pointer to writel(), which expects an
__iomem pointer, causing another warning.

Add the appropriate annotations.

The sparse warnings look like this:

  $ make C=2 drivers/pci/controller/
  drivers/pci/controller/dwc/pcie-spear13xx.c:72:54: warning: incorrect type in initializer (different address spaces)
  drivers/pci/controller/dwc/pcie-spear13xx.c:72:54:    expected struct pcie_app_reg *app_reg
  drivers/pci/controller/dwc/pcie-spear13xx.c:72:54:    got void [noderef] __iomem *app_base
  drivers/pci/controller/dwc/pcie-spear13xx.c:78:26: warning: incorrect type in argument 2 (different address spaces)
  drivers/pci/controller/dwc/pcie-spear13xx.c:78:26:    expected void volatile [noderef] __iomem *addr
  drivers/pci/controller/dwc/pcie-spear13xx.c:78:26:    got unsigned int *

Link: https://lore.kernel.org/r/20211223213749.1314142-3-helgaas@kernel.orgSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@gmail.com>

The sparse checker complains about converting pointers between address
spaces.  The pci_config_window.priv pointer is a generic void *, but
hisi_pcie_map_bus() needs a void __iomem *.

This isn't a problem in other drivers because they store the __iomem
pointer in a driver struct.  Add a trivial struct hisi_pcie to avoid the
warning.

The sparse warning looks like this:

  $ make C=2 drivers/pci/controller/
  drivers/pci/controller/dwc/pcie-hisi.c:61:37: warning: incorrect type in initializer (different address spaces)
  drivers/pci/controller/dwc/pcie-hisi.c:61:37:    expected void [noderef] __iomem *reg_base
  drivers/pci/controller/dwc/pcie-hisi.c:61:37:    got void *priv

Link: https://lore.kernel.org/r/20211223213749.1314142-2-helgaas@kernel.orgSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>

Rename struct uniphier_pcie_priv to uniphier_pcie to match the convention
of <driver>_pcie. No functional change intended.

[bhelgaas: drop extraneous uniphier_pcie_irq_ack() from patch]
Link: https://lore.kernel.org/r/20211223011054.1227810-21-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>

Rename tegra_pcie_dw to tegra194_pcie to match the convention of
<driver>_pcie. No functional change intended.

[bhelgaas: rename functions similarly]
Link: https://lore.kernel.org/r/20211223011054.1227810-20-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>

Rename struct intel_pcie_port to intel_pcie to match the convention of
<driver>_pcie. No functional change intended.

Link: https://lore.kernel.org/r/20211223011054.1227810-11-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Rahul Tanwar <rtanwar@maxlinear.com>

The kirin driver only needs the device data, not the whole struct
of_device_id.  Use of_device_get_match_data() instead of of_match_device().
No functional change intended.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20211223011054.1227810-8-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Xiaowei Song <songxiaowei@hisilicon.com>
Cc: Binghui Wang <wangbinghui@hisilicon.com>

The keystone driver only needs the device data, not the whole struct
of_device_id.  Use of_device_get_match_data() instead of of_match_device().
No functional change intended.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20211223011054.1227810-7-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>

The dra7xx driver only needs the device data, not the whole struct
of_device_id.  Use of_device_get_match_data() instead of of_match_device().
No functional change intended.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20211223011054.1227810-6-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>

The designware-plat driver only needs the device data, not the whole struct
of_device_id.  Use of_device_get_match_data() instead of of_match_device().
No functional change intended.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20211223011054.1227810-5-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>

The artpec6 driver only needs the device data, not the whole struct
of_device_id.  Use of_device_get_match_data() instead of of_match_device().
No functional change intended.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20211223011054.1227810-3-helgaas@kernel.orgSigned-off-by: NFan Fei <ffclaire1224@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>

i.MX8MM PCIe works mostly like the i.MX8MQ one, but has a different PHY
and allows to output the internal PHY reference clock via the refclk pad.
Add the i.MX8MM PCIe support based on the standalone PHY driver.

Link: https://lore.kernel.org/r/1640312885-31142-2-git-send-email-hongxing.zhu@nxp.comTested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NTim Harvey <tharvey@gateworks.com>

There is no need to call the dev_err() function directly to print a
custom message when handling an error from either the platform_get_irq()
or platform_get_irq_byname() functions as both are going to display an
appropriate error message in case of a failure.

This change is as per suggestions from Coccinelle, e.g.,
  drivers/pci/controller/dwc/pcie-qcom-ep.c:556:2-9: line 556 is redundant because platform_get_irq() already prints an error

Related:
  https://lore.kernel.org/all/20210310131913.2802385-1-kw@linux.com/
  https://lore.kernel.org/all/20200802142601.1635926-1-kw@linux.com/

Link: https://lore.kernel.org/r/20211027112931.37182-1-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

cpu_to_be16() returns __be16 value but the driver uses u16 and that's
incorrect. Fix it by using __be16 as the data type of bdf_be variable.

The issue was spotted by the below sparse warning:

sparse warnings: (new ones prefixed by >>)
>> drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse: sparse: incorrect type in initializer (different base types) @@     expected unsigned short [usertype] bdf_be @@     got restricted __be16 [usertype] @@
   drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse:     expected unsigned short [usertype] bdf_be
   drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse:     got restricted __be16 [usertype]

Link: https://lore.kernel.org/r/20211130080924.266116-1-manivannan.sadhasivam@linaro.orgReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>

cgroup.h (therefore swap.h, therefore half of the universe)
includes bpf.h which in turn includes module.h and slab.h.
Since we're about to get rid of that dependency we need
to clean things up.

v2: drop the cpu.h include from cacheinfo.h, it's not necessary
and it makes riscv sensitive to ordering of include files.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NKrzysztof Wilczyński <kw@linux.com>
Acked-by: NPeter Chen <peter.chen@kernel.org>
Acked-by: NSeongJae Park <sj@kernel.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/all/20211120035253.72074-1-kuba@kernel.org/  # v1
Link: https://lore.kernel.org/all/20211120165528.197359-1-kuba@kernel.org/ # cacheinfo discussion
Link: https://lore.kernel.org/bpf/20211202203400.1208663-1-kuba@kernel.org

On imx6 and perhaps others when pcie probes you get a:
imx6q-pcie 33800000.pcie: invalid resource

This occurs because the atu is not specified in the DT and as such it
should not be remapped.

Link: https://lore.kernel.org/r/20211101180243.23761-1-tharvey@gateworks.com
Fixes: 281f1f99 ("PCI: dwc: Detect number of iATU windows")
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NRichard Zhu <hongxing.zhu@nxp.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>

If 'of_device_get_match_data()' fails, previous 'pm_runtime_get_sync()/
pm_runtime_enable()' should be undone.

To fix it, the easiest is to move this block of code before the memory
allocations and the pm_runtime_xxx calls.

Link: https://lore.kernel.org/r/4d03c636193f64907c8dacb17fa71ed05fd5f60c.1636220582.git.christophe.jaillet@wanadoo.fr
Fixes: b89ff410 ("PCI: qcom: Replace ops with struct pcie_cfg in pcie match data")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>

Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment about
identifying config read errors. This makes checks for config read errors
easier to find. Comment change only.

Link: https://lore.kernel.org/r/6ae6b071d92052dc511407513e2a7c0035aff9e7.1637243717.git.naveennaidu479@gmail.comSigned-off-by: NNaveen Naidu <naveennaidu479@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If config pci_ops.read() methods return failure, the PCI_OP_READ() and
PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the
data value, so there's no need to set it in the pci_ops.read() methods
themselves.

Drop the unnecessary data value fabrication when pci_ops.read() fails.

Link: https://lore.kernel.org/r/f87e22bc09a471d2cf15ad05dfd6432f57739aed.1637243717.git.naveennaidu479@gmail.comSigned-off-by: NNaveen Naidu <naveennaidu479@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If config pci_ops.read() methods return failure, the PCI_OP_READ() and
PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the
data value, so there's no need to set it in the pci_ops.read() methods
themselves.

Drop the unnecessary data value fabrication when pci_ops.read() fails.

Link: https://lore.kernel.org/r/7da7ea760abc5f85cad6e9b0d3e59eebd93f50d3.1637243717.git.naveennaidu479@gmail.comSigned-off-by: NNaveen Naidu <naveennaidu479@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>