If clk_prepare_enable() fails, we must not call clk_disable_unprepare() in
the error path.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
devm_ioremap_resource() fails gracefully when given a NULL resource
pointer, so we don't need to check separately for failure from
platform_get_resource_byname(). Remove the redundant check.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Previously we used a PCI early fixup to initiate a link retrain on Altera
devices. But Altera PCIe IP can be configured as either a Root Port or an
Endpoint, and they might have same vendor ID, so the fixup would be run for
both.
We only want to initiate a link retrain for Altera Root Port devices, not
for Endpoints, so move the link retrain functionality from the fixup to
altera_pcie_host_init().
[bhelgaas: changelog]
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ley Foon Tan <lftan@altera.com>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI tegra host bridge driver adds the PCI IO resource retrieved from
firmware to the host bridge resource windows even if the
pci_remap_iospace() call fails; this is an actual bug in that the PCI host
bridge would consider the PCI IO resource valid (and possibly assign it to
downstream devices) even if the kernel was not able to map the PCI host
bridge memory address driving IO cycle to the CPU virtual address space (ie
pci_remap_iospace() failures).
Add the PCI host bridge driver pci_remap_iospace() failure path and do not
add the corresponding PCI host bridge PCI IO resources retrieved through
firmware when the pci_remap_iospace() function call fails, fixing the
issue.
Fixes: e6e9f471f5 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thierry Reding <treding@nvidia.com>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI common host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 4e64dbe226 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI rcar host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 5d2917d469 ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Phil Edworthy <phil.edworthy@renesas.com>
CC: Simon Horman <horms+renesas@verge.net.au>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI versatile host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: b7e78170ef ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Rob Herring <robh@kernel.org>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI designware host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: cbce790059 ("PCI: designware: Make driver arch-agnostic")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridge's memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI aardvark host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 8c39d71036 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
'completion_status' is used in some places, e.g.,
hv_pci_protocol_negotiation(), so we should make sure it's initialized in
error case too, though the error is unlikely here.
[bhelgaas: fix changelog typo and nearby whitespace]
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
Add support for the Rockchip PCIe controller found on RK3399 SoC platform.
[bhelgaas: fold in Brian's rockchip_pcie_client_irq_handler() OR fix, other
fixes and cleanups from Guenter Roeck <linux@roeck-us.net> and me,
uninitialized variable fix from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Rework configs accessors so a future patch can use them in _probe() with
struct altera_pcie instead of struct pci_bus.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_XILINX_NWL
drivers/pci/host/Kconfig: bool "NWL PCIe Core"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers. Delete several functions only used by the remove function.
Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
CC: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_XILINX
drivers/pci/host/Kconfig: bool "Xilinx AXI PCIe host bridge support"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_QCOM
drivers/pci/host/Kconfig: bool "Qualcomm PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver() uses the same init level priority as
module_platform_driver(), so this doesn't change init ordering.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Stanimir Varbanov <svarbanov@mm-sol.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCI_DRA7XX
drivers/pci/host/Kconfig: bool "TI DRA7xx PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver_probe() uses the same init level priority as
module_platform_driver_probe(), so this doesn't change init ordering.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Kishon Vijay Abraham I <kishon@ti.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCI_HOST_COMMON
drivers/pci/host/Kconfig: bool
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Will Deacon <will.deacon@arm.com>
devm_ioremap_resource() fails gracefully when given a NULL resource
pointer, so we don't need to check separately for failure from
platform_get_resource_byname(). Remove the redundant check.
[bhelgaas: changelog]
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When we have only two view ports in a DesignWare PCIe platform, iatu0
is used for both CFG and IO accesses. When CFGs are sent to peripherals
(e.g., lspci), iatu0 frequently switches between CFG and IO.
For such scenarios, a MEMORY might be sent as an IOs by mistake.
Considering the following configurations:
MEMORY -> BASE_ADDR: 0xb4100000, LIMIT: 0xb4100FFF, TYPE=mem
CFG -> BASE_ADDR: 0xb4000000, LIMIT: 0xb4000FFF, TYPE=cfg
IO -> BASE_ADDR: 0xFFFFFFFF, LIMIT: 0xFFFFFFFE, TYPE=io
Suppose PCIe has just completed a CFG access. To switch back to IO, it
sets the BASE_ADDR to 0xFFFFFFFF, LIMIT 0xFFFFFFFE and TYPE to IO. When
another CFG comes, the BASE_ADDR is set to 0xb4000000 to switch to CFG. At
this moment, a MEMORY access shows up, since it matches with iatu0 (due to
0xb4000000 <= MEMORY BASE_ADDR <= MEMORY LIMIT <= 0xFFFFFFF), it is treated
as an IO access by mistake, then sent to perpheral.
This patch fixes the problem by exchanging the assignments of `MEMORYs' and
`CFGs/IOs', which assigning MEMORYs to iatu0, CFGs and IOs to iatu1.
We can still have issues with IO transfer, however memory transfer is used
predominantly therefore we are just minimizing the risk of failure.
Actually, we can not do much when we have only two viewports. We can
either not allow the less frequent IO transfers at all, or can live with a
remote possibility of getting it corrupted.
Signed-off-by: Dong Bo <dongbo4@huawei.com>
[pratyush.anand@gmail.com: Modified commit log to capture remote risk]
Signed-off-by: Pratyush Anand <pratyush.anand@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCI_EXYNOS
drivers/pci/host/Kconfig: bool "Samsung Exynos PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Kukjin Kim <kgene@kernel.org>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_DW
drivers/pci/host/Kconfig: bool
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_SPEAR13XX
drivers/pci/host/Kconfig: bool "STMicroelectronics SPEAr PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
module_init() translates to device_initcall().
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCI_IMX6
drivers/pci/host/Kconfig: bool "Freescale i.MX6 PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
module_init() translates to device_initcall().
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Richard Zhu <Richard.Zhu@freescale.com>
CC: Lucas Stach <l.stach@pengutronix.de>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_ALTERA
drivers/pci/host/Kconfig: bool "Altera PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
module_init() translates to device_initcall().
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Ley Foon Tan <lftan@altera.com>
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_ALTERA_MSI
drivers/pci/host/Kconfig: bool "Altera PCIe MSI feature"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Ley Foon Tan <lftan@altera.com>
devm_ioremap_resource() emits an error message already, so remove the
dev_err() call in advk_pcie_probe() to avoid redundant error messages.
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move the devm_ioremap_resource() of R-Car register space next to the
of_address_to_resource() that extracts the resource. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Most of the platforms have 3 or more viewports. For such platforms, We do
not need to share viewports between IO and CFG. Assign viewport 2 to IO
transactions in such cases.
Tested-by: Dong Bo <dongbo4@huawei.com>
Signed-off-by: Pratyush Anand <pratyush.anand@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rob Herring <robh@kernel.org>
of_device_get_match_data() was added in v4.2 to reduce the the boilerplate
required to get at SoC-specific data. Use it to simplify the code
slightly.
[bhelgaas: changelog]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The struct tegra_pcie_soc_data represents SoC-specific data. The shorter
name tegra_pcie_soc already describes that accurately enough, so the extra
five characters are redundant. Also remove the suffix from various
variable names to shorten the code a little.
This also makes this driver more consistent with the naming used in other
drivers that use a similar mechanism to differentiate between various SoC
generations.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Poll for link training status is cleared before poll for link up status.
This can help to get the reliable link up status, especially when PCIe is
in Gen 3 speed.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The link may be up but still in link training. In this case, we can't
think the link is up and operating correctly. Teach dw_pcie_link_up() to
be aware of the PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING bit.
Also rewrite PCIE_PHY_DEBUG_R1_LINK_UP definition so that it's consistent
with other macros.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Joao Pinto <jpinto@synopsys.com>
Add support for the new iATU Unroll mechanism that will be used from Core
version 4.80. The new Cores can support either iATU Unroll or the "old"
iATU method, now called Legacy Mode. The driver is perfectly capable of
performing well for both.
[bhelgaas: split ATU enable timeout to separate patch]
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add a loop with timeout to make sure the iATU is really enabled before
subsequent config and I/O accesses.
[bhelgaas: split to separate patch, use dev_err() instead of dev_dbg()]
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move the link wait sleep definitions to the .c file as suggested by
Jisheng Zhang in a previous patch.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Jisheng Zhang <jszhang@marvell.com>
dw_pcie_readl_rc() reads a u32 value. Previously we stored that value in
space supplied by the caller. Return the u32 value directly instead.
This makes the calling code read better and makes it obvious that the
caller need not initialize the storage. In the following example it isn't
clear whether "val" is initialized before being used:
dw_pcie_readl_rc(pp, PCI_COMMAND, &val);
if (val & PCI_COMMAND_MEMORY)
...
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* pci/host-aardvark:
arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700
PCI: aardvark: Add Aardvark PCI host controller driver
dt-bindings: add DT binding for the Aardvark PCIe controller
* pci/host-altera:
PCI: altera: Poll for link up status after retraining the link
PCI: altera: Check link status before retrain link
PCI: altera: Reorder read/write functions
* pci/host-dra7xx:
PCI: dra7xx: Fix return value in case of error
* pci/host-hv:
PCI: hv: Fix interrupt cleanup path
PCI: hv: Handle all pending messages in hv_pci_onchannelcallback()
PCI: hv: Don't leak buffer in hv_pci_onchannelcallback()
* pci/host-vmd:
x86/PCI: VMD: Separate MSI and MSI-X vector sharing
x86/PCI: VMD: Use x86_vector_domain as parent domain
x86/PCI: VMD: Use lock save/restore in interrupt enable path
x86/PCI: VMD: Initialize list item in IRQ disable
x86/PCI: VMD: Select device dma ops to override
* pci/host-xilinx:
PCI: xilinx: Fix return value in case of error
Manually apply changes from pci/demodularize-hosts and
pci/host-request-windows to drivers/pci/host/pci-aardvark.c
* pci/host-tegra:
PCI: tegra: Program PADS_REFCLK_CFG* registers with per-SoC values
PCI: tegra: Program PADS_REFCLK_CFG* always, not just on legacy SoCs
PCI: tegra: Stop setting pcibios_min_mem
PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one
PCI: tegra: Use lower-case hex consistently for register definitions
Conflicts:
drivers/pci/host/pci-tegra.c
Drop stray pci_ioremap_io() per Thierry Reding <treding@nvidia.com>;
removal tested by Jon Hunter <jonathanh@nvidia.com>.
* pci/resource:
unicore32/PCI: Remove pci=firmware command line parameter handling
ARM/PCI: Remove arch-specific pcibios_enable_device()
ARM64/PCI: Remove arch-specific pcibios_enable_device()
MIPS/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups
ARM/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups
PCI: generic: Claim bus resources on PCI_PROBE_ONLY set-ups
PCI: Add generic pci_bus_claim_resources()
alx: Use pci_(request|release)_mem_regions
ethernet/intel: Use pci_(request|release)_mem_regions
GenWQE: Use pci_(request|release)_mem_regions
lpfc: Use pci_(request|release)_mem_regions
NVMe: Use pci_(request|release)_mem_regions
PCI: Add helpers to request/release memory and I/O regions
PCI: Extending pci=resource_alignment to specify device/vendor IDs
sparc/PCI: Implement pci_resource_to_user() with pcibios_resource_to_bus()
powerpc/pci: Implement pci_resource_to_user() with pcibios_resource_to_bus()
microblaze/PCI: Implement pci_resource_to_user() with pcibios_resource_to_bus()
PCI: Unify pci_resource_to_user() declarations
microblaze/PCI: Remove useless __pci_mmap_set_pgprot()
powerpc/pci: Remove __pci_mmap_set_pgprot()
PCI: Ignore write combining when mapping I/O port space
