PCIE_RC_CONFIG_LCS contains control and status bits specific to the PCIe
link. The layout for this register looks the same as the existing
PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's reuse them.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but we're
doing the inverse. That doesn't have too much effect, since we're setting
all the [23:8] bits to 1, and the other bits are only relevant for modes
we're currently not using. But we should get this right.
Fixes: ca19890840 ("PCI: rockchip: Fix wrong transmitted FTS count")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Per the errata of TRM, the RC can't support L1 substate, so remove the L1
substate cap as well as operation for PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2.
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500ms
waiting for training that will never happen, let's use the helper function,
of_pci_get_max_link_speed(), to get the max link speed from DT and specify
link capability.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The calculation of negotiated lanes is wrong: it should be shifted by
PCIE_CORE_PL_CONF_LANE_SHIFT, but it is shifted by
PCIE_CORE_PL_CONF_LANE_MASK instead. Let's fix it.
Fixes: e77f847df5 ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Allow selection of the Rockchip driver for compile testing, even if we
aren't building for ARCH_ROCKCHIP.
[bhelgaas: changelog]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The default value of common clock configuration is zero indicating
Rockchip's RC is using asynchronous clock architecture but actually we are
using common clock. This will confuse some EP drivers if they need some
different settings referring to this value.
Set the Common Clock Configuration bit in the Link Control Register.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If vpcie3v3 is available, we could provide these information via RC's
configure register to make EP able to know the power limit.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add Makefile comments to explain the Kconfig and build strategy for ARM64
drivers that work around not-quite-ECAM issues. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Fix the following warnings:
drivers/pci/host/vmd.c:731:12: warning: ‘vmd_suspend’ defined but not used [-Wunused-function]
static int vmd_suspend(struct device *dev)
^
drivers/pci/host/vmd.c:739:12: warning: ‘vmd_resume’ defined but not used [-Wunused-function]
static int vmd_resume(struct device *dev)
^
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
Reviewed-by: Keith Busch <keith.busch@intel.com>
SRCU lets synchronize_srcu() depend on VMD-local RCU primitives, preventing
long delays from locking up RCU in other systems. VMD performs a
synchronize when removing a device, but will hit all IRQ lists if the
device uses all VMD vectors. This patch will not help VMD's RCU
synchronization, but will isolate the read side delays to the VMD
subsystem. Additionally, the use of SRCU in VMD's ISR will keep it
isolated from any other RCU waiters in the rest of the system.
Tested using concurrent FIO and NVMe resets:
[global]
rw=read
bs=4k
direct=1
ioengine=libaio
iodepth=32
norandommap
timeout=300
runtime=1000000000
[nvme0]
cpus_allowed=0-63
numjobs=8
filename=/dev/nvme0n1
[nvme1]
cpus_allowed=0-63
numjobs=8
filename=/dev/nvme1n1
while (true) do
for i in /sys/class/nvme/nvme*; do
echo "Resetting ${i##*/}"
echo 1 > $i/reset_controller;
sleep 5
done;
done
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
The Tegra PCI host controller driver no longer relies on any of the 32-bit
ARM glue for PCI, so it can be enabled on 64-bit configurations.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
The PCIe host controller found on Tegra X1 is very similar to its
predecessor on Tegra K1. A bug was introduced in the new revision that
is worked around by always enabling the performance counter, otherwise
accesses to configuration space will block for a number of seconds.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
Tegra210's PCIe controller has a bug that requires the PCA (performance
counter) feature to be enabled. If this isn't done, accesses to device
configuration space will hang the chip for tens of seconds. Implement the
workaround.
Based on commit 514e19138af2 ("pci: tegra: implement PCA enable
workaround") from U-Boot by Stephen Warren <swarren@nvidia.com>.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
Tegra is one of the remaining platforms that still use the traditional
pci_common_init_dev() interface for probing PCI host bridges.
This demonstrates how to convert it to the pci_register_host interface I
just added in a previous patch. This leads to a more linear probe sequence
that can handle errors better because we avoid callbacks into the driver,
and it makes the driver architecture independent.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
PCIe controllers in X-Gene SoCs are not ECAM compliant: software needs to
configure additional controller's register to address device at
bus:dev:function.
Add a quirk to discover controller MMIO register space and configure
controller registers to select and address the target secondary device.
The quirk will only be applied for X-Gene PCIe MCFG table with
OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
Tested-by: Jon Masters <jcm@redhat.com>
Signed-off-by: Duc Dang <dhdang@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
ThunderX pass1.x requires to emulate the EA headers for on-chip devices
hence it has to use custom pci_thunder_ecam_ops for accessing PCI config
space (pci-thunder-ecam.c). Add new entries to MCFG quirk array where it
can be applied while probing ACPI based PCI host controller.
ThunderX pass1.x is using the same way for accessing off-chip devices
(so-called PEM) as silicon pass-2.x so we need to add PEM quirk entries
too.
Quirk is considered for ThunderX silicon pass1.x only which is identified
via MCFG revision 2.
ThunderX pass 1.x requires the following accessors:
NUMA node 0 PCI segments 0- 3: pci_thunder_ecam_ops (MCFG quirk)
NUMA node 0 PCI segments 4- 9: thunder_pem_ecam_ops (MCFG quirk)
NUMA node 1 PCI segments 10-13: pci_thunder_ecam_ops (MCFG quirk)
NUMA node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)
[bhelgaas: change Makefile/ifdefs so quirk doesn't depend on
CONFIG_PCI_HOST_THUNDER_ECAM]
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see thunder_pem_ecam_ops) and custom configuration space
granulation (see bus_shift = 24). In order to access configuration space
and probe PEM as ACPI-based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. A new thunder_pem_acpi_init() init function to locate PEM-specific
register ranges using ACPI.
2. Export PEM thunder_pem_ecam_ops structure so it is visible to MCFG quirk
code.
3. New quirk entries for each PEM segment. Each contains platform IDs,
mentioned thunder_pem_ecam_ops and CFG resources.
Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.
ThunderX pass 2.x requires the following accessors:
NUMA Node 0 PCI segments 0- 3: pci_generic_ecam_ops (ECAM-compliant)
NUMA Node 0 PCI segments 4- 9: thunder_pem_ecam_ops (MCFG quirk)
NUMA Node 1 PCI segments 10-13: pci_generic_ecam_ops (ECAM-compliant)
NUMA Node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)
[bhelgaas: adapt to use acpi_get_rc_resources(), update Makefile/ifdefs so
quirk doesn't depend on CONFIG_PCI_HOST_THUNDER_PEM]
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Pull the register resource lookup out of thunder_pem_init() so we can
easily add a corresponding lookup using ACPI. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The PCIe controller in Hip05/Hip06/Hip07 SoCs is not completely
ECAM-compliant. It is non-ECAM only for the RC bus config space; for any
other bus underneath the root bus it does support ECAM access.
Add specific quirks for PCI config space accessors. This involves:
1. New initialization call hisi_pcie_init() to obtain RC base
addresses from PNP0C02 at the root of the ACPI namespace (under \_SB).
2. New entry in common quirk array.
[bhelgaas: move to pcie-hisi.c and change Makefile/ifdefs so quirk doesn't
depend on CONFIG_PCI_HISI]
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
hv_do_hypercall() assumes that we pass a segment from a physically
contiguous buffer. A buffer allocated on the stack may not work if
CONFIG_VMAP_STACK=y is set.
Use kmalloc() to allocate this buffer.
Reported-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
In the code to handle PAXB v2 based MSI steering, the logic aligns the MSI
register address to the size of supported inbound mapping range. This is
incorrect since it rounds "up" the starting address to the next aligned
address, but what we want is the starting address to be rounded "down" to
the aligned address.
This patch fixes the issue and allows MSI writes to be properly steered to
the GIC.
Fixes: 4b073155fbd3 ("PCI: iproc: Add support for the next-gen PAXB controller")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add support for the MSM8996/APQ8096 PCIe controller. MSM8996 supports Gen
1/2, one lane, 3 PCIe root complexes with support for MSI and legacy
interrupts, and it conforms to PCI Express Base 2.1 specification.
Add a post_init callback to qcom_pcie_ops, as the PCIe pipe clocks are only
setup after the phy is powered on. It also adds an ltssm_enable callback
as it is very much different from other supported SoCs in the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Hardware that supports only 32-bit config writes is not spec-compliant.
For example, if software performs a 16-bit write, we must do a 32-bit read,
merge in the 16 bits we intend to write, followed by a 32-bit write. If
the 16 bits we *don't* intend to write happen to have any RW1C (write-one-
to-clear) bits set, we just inadvertently cleared something we shouldn't
have.
Add a rate-limited warning when we do sub-32 bit config writes. Remove
similar probe-time warnings from some of the affected host bridge drivers.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Enthusiastically-Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com> # rockchip
Acked-by: Thierry Reding <treding@nvidia.com>
Add support for inbound DMA mapping. The range of the inbound mapping is
configured by the optional device tree property 'dma-ranges'.
While inbound mapping is done automatically in the ASIC on most iProc-based
SoCs, newer ASICs (e.g., Stingray) require inbound mapping to be configured
explicitly in software.
[bhelgaas: fold in fixes to avoid 32-bit division in iproc_pcie_ib_write()
and uninitialized return value in iproc_pcie_setup_ib() from Arnd Bergmann
<arnd@arndb.de>]
Signed-off-by: Oza Oza <oza.oza@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Improve the iProc PCIe outbound mapping code by making it more generic and
removing redundant device tree properties 'brcm,pcie-ob-window-size' and
'brcm,pcie-ob-oarr-size'. The driver is still backward compatible to
device tree binaries with the two properties specified.
The driver now automatically configures the correct mapping window size and
number of mapping windows based on the value of device tree property
'ranges' and the capability of of the iProc PCIe controller.
Signed-off-by: Oza Oza <oza.oza@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
After we send a PCI_EJECTION_COMPLETE message to the host, the host will
immediately send us a PCI_BUS_RELATIONS message with
relations->device_count == 0, so pci_devices_present_work(), running on
another thread, can find the being-ejected device, mark the
hpdev->reported_missing to true, and run list_move_tail()/list_del() for
the device -- this races hv_eject_device_work() -> list_del().
Move the list_del() in hv_eject_device_work() to an earlier place, i.e.,
before we send PCI_EJECTION_COMPLETE, so later the
pci_devices_present_work() can't see the device.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jake Oshins <jakeo@microsoft.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
1. We don't really need such a big on-stack buffer when sending the
teardown_packet: vmbus_sendpacket() here only uses sizeof(struct
pci_message).
2. In the hot-remove case (PCI_EJECT), after we send PCI_EJECTION_COMPLETE
to the host, the host will send a RESCIND_CHANNEL message to us and the
host won't access the per-channel ringbuffer any longer, so we needn't send
PCI_RESOURCES_RELEASED/PCI_BUS_D0EXIT to the host, and we shouldn't expect
the host's completion message of PCI_BUS_D0EXIT, which will never come.
3. We should send PCI_BUS_D0EXIT after hv_send_resources_released().
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jake Oshins <jakeo@microsoft.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
We don't really need such a big on-stack buffer. vmbus_sendpacket() here
only uses sizeof(struct pci_child_message).
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jake Oshins <jakeo@microsoft.com>
I returned to Synopsys and so I am sending this patch to update the email
address of the pcie-designware-plat author.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
During enumeration with multi-function EP devices, access to the
configuration space of a non-existent function results in an unsupported
request being returned as expected. By default the PAXB-based iProc PCIe
controller forwards this as an APB error to the host system and that causes
an exception, which is undesired.
Disable this undesired behaviour and let the kernel PCI stack deal with an
access to the non-existent function, in which case a vendor ID of 0xffff is
returned and handled gracefully.
Reported-by: JD Zheng <jiandong.zheng@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
Reviewed-by: Oza Oza <oza.oza@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
The iProc PCIe driver is currently using type IPROC_PCIE_PAXB for the
following SoCs: NS, NSP, Cygnus, NS2, and Pegasus. In fact, the BCMA-based
NS uses a legacy PAXB controller that is slightly different from the PAXB
controller used in the rest of SoCs, e.g., some registers are missing and
it does not require software configuration of outbound/inbound address
mapping.
Add a new type, IPROC_PCIE_PAXB_BCMA, to allow us to properly support the
BCMA-based NS along with other iProc-based SoCs going forward.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
During initialization, the current iProc PCIe host driver resets PAXC and
the downstream internal endpoint device that PAXC connects to. If the
endpoint device is already loaded with firmware and has started running
from the bootloader stage, this downstream reset causes the endpoint device
to stop working.
Signed-off-by: Ray Jui <raj.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
As the number of iProc PCIe core registers starts to grow and differ
between different revisions of the iProc PCIe controllers, the
current way of populating each individual unsupported register with
value 'IPROC_PCIE_REG_INVALID' with a table entry has become a bit
messy and is difficult to scale up in the future.
Improve the current driver by populating the invalid entries with code
instead of through individual table entries. This helps to avoid a
significant number of invalid table entries when support for the next
revision of the iProc controller is added.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Add support for the LS1046a PCIe controller. This device has a different
LUT_DBG offset, so add "lut_dbg" to ls_pcie_drvdata to
describe this difference.
[bhelgaas: changelog, remove now-unused PCIE_LUT_DBG]
Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The driver core clears the driver data to NULL after device_release or on
probe failure. Thus, it is not needed to manually clear the device driver
data to NULL.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
There is an error message from devm_ioremap_resource() already, so remove
the dev_err() call to avoid redundant error messages.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
There is an error message from devm_ioremap_resource() already, so remove
the dev_err() call to avoid redundant error messages.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
There is an error message from devm_ioremap_resource() already, so remove
the dev_err() call to avoid redundant error messages.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ley Foon Tan <lftan@altera.com>
Use the builtin_platform_driver() macro to make the code simpler.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
pm_rst, aclk_rst, pclk_rst was controlled by ROM code so the software
wasn't needed to control it again in theory. But it didn't work properly,
so we do need to do it again and add enough delay between the assert of
pm_rst and the deassert of pm_rst. The Soc intergrated with this
controller, rk3399, is still under MP test internally, so the backward
compatibility won't be a big deal.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
dw_pcie_iatu_unroll_enabled() reads a dbi_base register. Reading any
dbi_base register before pp->ops->host_init has been called causes
"imprecise external abort" on platforms like ARTPEC-6, where the PCIe
module is disabled at boot and first enabled in pp->ops->host_init. Move
dw_pcie_iatu_unroll_enabled() to dw_pcie_setup_rc(), since it is after
pp->ops->host_init, but before pp->iatu_unroll_enabled is actually used.
Fixes: a0601a4705 ("PCI: designware: Add iATU Unroll feature")
Tested-by: James Le Cuirot <chewi@gentoo.org>
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Joao Pinto <jpinto@synopsys.com>
Acked-by: Olof Johansson <olof@lixom.net>
Make hv_irq_mask() and hv_irq_unmask() static as they are only used in
pci-hyperv.c
This fixes a sparse warning.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
Although I am leaving Synopsys, I would like to keep working with the linux
kernel community and help in what you might find useful. For that I am
sending this patch to change my contact e-mail.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Commit fefe6733e5 ("PCI: layerscape: Move struct pcie_port setup
to probe function") changed the init ordering of the pcie structure,
but started to use the pcie->drvdata field before initializing it.
Mayhem follows.
Fix this by moving the drvdata assignment right before the first use.
Tested on LS2085a.
Fixes: efe6733e516 ("PCI: layerscape: Move struct pcie_port setup to probe function")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
