* pci/host-hv:
PCI: hv: Allocate physically contiguous hypercall params buffer
PCI: hv: Delete the device earlier from hbus->children for hot-remove
PCI: hv: Fix hv_pci_remove() for hot-remove
PCI: hv: Use the correct buffer size in new_pcichild_device()
PCI: hv: Make unnecessarily global IRQ masking functions static
* pci/host-altera:
PCI: altera: Remove redundant error message in altera_pcie_parse_dt()
PCI: altera: Use builtin_platform_driver() to simplify the code
PAXC and PAXCv2 buses do not support legacy IRQs so there is no reason to
even try and map them. Without a change like this, one cannot create VFs
on Nitro ports since legacy interrupts are checked as part of the PCI
device creation process. Testing on PAXC hardware showed that VFs are
properly created with only the change to not set pcie->map_irq, but just to
be safe the change in iproc_pcie_setup() will ensure that pdev_fixup_irq()
will not panic.
Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
Add fallback compatibility string for the R-Car Gen 3 family. This is in
keeping with the both the existing fallback compatibility string for the
R-Car Gen 2 family and the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Improve readability by listing fallback compatibility strings after the
more-specific compatibility strings they provide a fallback for.
This does not affect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Improve readability by listing fallback compatibility strings after the
more-specific compatibility strings they provide a fallback for.
This does not affect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move deassert of pm/aclk/pclk after phy_init() as we want to optimize the
logic of reset control and reuse rockchip_pcie_init_port() later which
should fully follow the cold boot procedure of ROM code.
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>
Split out a new function, rockchip_cfg_atu(), in order to re-configure the
ATU when missing these information after wakeup from S3.
[bhelgaas: add "dev" temporary, return 0 when known]
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>
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>
Add support for the next generation of the iProc PAXB host controller, used
in Stingray.
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>
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>
Add support for the second generation of the iProc PCIe PAXC host
controller.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Anup Patel <anup.patel@broadcom.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>
Body of an "if" statement wasn't indented. Add a tab.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Only interfaces used from outside the driver, e.g., those called by the
DesignWare core, need to accept pointers to the generic struct pcie_port.
Internal interfaces can accept pointers to the device-specific struct,
which makes them more straightforward. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Include the PCIE_HIP06_CTRL_OFF block base in the PCIE_SYS_STATE4 register
address so reads of PCIE_SYS_STATE4 don't have to mention both. No
functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xilinx-nwl driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
xilinx_pcie_assign_msi() doesn't use the struct xilinx_pcie_port pointer
passed to it, so remove the argument completely. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xilinx driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Pass the struct xgene_pcie_port pointer, not addresses, to setup functions.
This enables future simplifications. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xgene driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The tegra driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The tegra_pcie_phy_disable() path called pads_writel() with arguments in
the wrong order. Swap them to be the "value, offset" order expected by
pads_writel().
Fixes: 6fe7c187e0 ("PCI: tegra: Support per-lane PHYs")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thierry Reding <treding@nvidia.com>
CC: stable@vger.kernel.org # v4.7+
The rockchip driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
The DRV_NAME macro is only used once, so there's no real advantage to
having the macro at all. Remove it and use the "rcar-pcie" name directly
in the struct platform_driver. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
rcar_pcie_get_resources() doesn't use the platform_device pointer passed to
it, so remove it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
The rcar driver never uses the platform drvdata pointer, so don't bother
setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Remove the struct qcom_pcie.dev member, which is a duplicate of the generic
pp.dev member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Remove the struct qcom_pcie.dbi member, which is a duplicate of the generic
pp.dbi_base member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The qcom driver never uses the platform drvdata pointer, so don't bother
setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use the existing "np" pointer instead of looking up dev->of_node again. No
functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
ls_add_pcie_port() doesn't use the platform_device pointer passed to it, so
remove it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Do the basic pcie_port setup in the probe function for consistency with
other drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Only interfaces used from outside the driver, e.g., those called by the
DesignWare core, need to accept pointers to the generic struct pcie_port.
Internal interfaces can accept pointers to the device-specific struct,
which makes them more straightforward. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Remove the struct ls_pcie.dbi member, which is a duplicate of the generic
pp.dbi_base member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The layerscape driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use a local "struct device *dev" for brevity and consistency with other
drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Bjorn Helgaas