Commit graph

855414 commits

Author SHA1 Message Date
Krzysztof Wilczynski
7f1c62c443 PCI: Add pci_info_ratelimited() to ratelimit PCI separately
Do not use printk_ratelimit() in drivers/pci/pci.c as it shares the rate
limiting state with all other callers to the printk_ratelimit().

Add pci_info_ratelimited() (similar to pci_notice_ratelimited() added in
the commit a88a7b3eb0 ("vfio: Use dev_printk() when possible")) and use
it instead of printk_ratelimit() + pci_info().

Link: https://lore.kernel.org/r/20190825224616.8021-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-09-05 13:26:46 -05:00
Kelsey Skunberg
244c06c3b6 PCI/IOV: Remove group write permission from sriov_numvfs, sriov_drivers_autoprobe
Previously the sriov_numvfs and sriov_drivers_autoprobe sysfs files had
0664 permissions, which allowed group write.  libvirt runs as root when
dealing with PCI, and it chowns files needed by qemu, so group write
permission should not be needed.

Change these permissions from 0664 to 0644, which is what DEVICE_ATTR_RW()
does by default.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20190905063226.43269-1-skunberg.kelsey@gmail.com
Link: https://lore.kernel.org/r/850cf536-0b72-d78c-efaf-855dcb391087@redhat.com
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Donald Dutile <ddutile@redhat.com>
2019-09-05 13:26:23 -05:00
Thierry Reding
c1e33666c9 PCI: iproc: Propagate errors for optional PHYs
devm_phy_get() can fail for a number of reasons besides probe deferral.
It can for example return -ENOMEM if it runs out of memory as it tries
to allocate devres structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "PHY not specified in DT".

What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_phy_optional_get() is a function that exactly
does what's required here, so use that instead.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
2019-09-04 15:44:05 +01:00
Thierry Reding
8f9e1641ba PCI: histb: Propagate errors for optional regulators
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".

What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
2019-09-04 15:43:09 +01:00
Thierry Reding
e7a877b2fa PCI: armada8x: Propagate errors for optional PHYs
devm_of_phy_get_by_index() can fail for a number of reasons besides
probe deferral. It can for example return -ENOMEM if it runs out of
memory as it tries to allocate devres structures. Propagating only
-EPROBE_DEFER is problematic because it results in these legitimately
fatal errors being treated as "PHY not specified in DT".

What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_of_phy_get_by_index() returns -ENODEV in this
case, so that's the special case that we need to handle. So we propagate
all errors, except -ENODEV, so that real failures will still cause the
driver to fail probe.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-09-04 15:42:38 +01:00
Thierry Reding
2170a09fb4 PCI: imx6: Propagate errors for optional regulators
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".

What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: kernel@pengutronix.de
Cc: linux-imx@nxp.com
2019-09-04 15:40:24 +01:00
Thierry Reding
ddd6960087 PCI: exynos: Propagate errors for optional PHYs
devm_of_phy_get() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate devres structures. Propagating only -EPROBE_DEFER
is problematic because it results in these legitimately fatal errors
being treated as "PHY not specified in DT".

What we really want is to ignore the optional PHYs only if they have not
been specified in DT. devm_of_phy_get() returns -ENODEV in this case, so
that's the special case that we need to handle. So we propagate all
errors, except -ENODEV, so that real failures will still cause the
driver to fail probe.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04 15:39:41 +01:00
Thierry Reding
0e3ff0ac5f PCI: rockchip: Propagate errors for optional regulators
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".

What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.

Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org
2019-09-04 15:37:47 +01:00
Krzysztof Wilczynski
55507aea58 PCI: Remove unnecessary returns
Remove unnecessary "return" statements at the end of void functions.  No
functional change intended.

Link: https://lore.kernel.org/r/20190825221039.6977-1-kw@linux.com
Link: https://lore.kernel.org/r/20190826095143.21353-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-30 14:00:34 -05:00
Lubomir Rintel
b071c1fd7a PCI: OF: Correct of_irq_parse_pci() documentation
530210c781 ("of/irq: Replace of_irq with of_phandle_args") changed the
of_irq_parse_pci() parameter type but didn't change the corresponding
documentation.  Update the function doc to match.

Link: https://lore.kernel.org/r/20190807132049.10304-1-lkundrak@v3.sk
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-30 14:00:34 -05:00
Bjorn Helgaas
d1bbf38aaf PCI: Fix typos and whitespace errors
Fix typos in drivers/pci.  Comment and whitespace changes only.

Link: https://lore.kernel.org/r/20190819115306.27338-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>	# armada8k
2019-08-30 14:00:12 -05:00
Krzysztof Wilczynski
4a2dbeddd3 PCI/ACPI: Remove unnecessary struct hotplug_program_ops
Move the ACPI-specific structs hpx_type0, hpx_type1, hpx_type2 and
hpx_type3 to drivers/pci/pci-acpi.c as they are not used anywhere else.
Then remove the struct hotplug_program_ops that has been shared between
drivers/pci/probe.c and drivers/pci/pci-acpi.c from drivers/pci/pci.h as it
is no longer needed.

The struct hotplug_program_ops was added by 87fcf12e84 ("PCI/ACPI: Remove
the need for 'struct hotplug_params'") and replaced previously used struct
hotplug_params enabling the support for the _HPX Type 3 Setting Record that
was added by f873c51a15 ("PCI/ACPI: Implement _HPX Type 3 Setting
Record").

The new struct allowed for the static functions such program_hpx_type0(),
program_hpx_type1(), etc., from the drivers/pci/probe.c to be called from
the function pci_acpi_program_hp_params() in the drivers/pci/pci-acpi.c.

Previously a programming of _HPX Type 0 was as follows:

  drivers/pci/probe.c:

    program_hpx_type0()
    ...
    pci_configure_device()
      hp_ops = {
        .program_type0 = program_hpx_type0,
        ...
      }
      pci_acpi_program_hp_params(&hp_ops)

  drivers/pci/pci-acpi.c:

    pci_acpi_program_hp_params(&hp_ops)
      acpi_run_hpx(hp_ops)
        decode_type0_hpx_record()
          hp_ops->program_type0     # program_hpx_type0() called via hp_ops

After the ACPI-specific functions, structs, enums, etc., have been moved to
drivers/pci/pci-acpi.c there is no need for the hotplug_program_ops as all
of the _HPX Type 0, 1, 2 and 3 are directly accessible.

Link: https://lore.kernel.org/r/20190827094951.10613-4-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-28 15:29:14 -05:00
Krzysztof Wilczynski
8c3aac6e1b PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.c
Move program_hpx_type0(), program_hpx_type1(), etc., and enums
hpx_type3_dev_type, hpx_type3_fn_type and hpx_type3_cfg_loc to
drivers/pci/pci-acpi.c as these functions and enums are ACPI-specific.

Move structs hpx_type0, hpx_type1, hpx_type2 and hpx_type3 to
drivers/pci/pci.h as these are shared between drivers/pci/pci-acpi.c and
drivers/pci/probe.c.

Link: https://lore.kernel.org/r/20190827094951.10613-3-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-28 15:25:53 -05:00
Krzysztof Wilczynski
e2797ad31f PCI/ACPI: Rename _HPX structs from hpp_* to hpx_*
The names of the hpp_type0, hpp_type1 and hpp_type2 structs suggest that
they're related to _HPP, when in fact they're related to _HPX.

The struct hpp_type0 denotes an _HPX Type 0 setting record that supersedes
the _HPP setting record, and it has been used interchangeably for _HPP as
per the ACPI specification (see version 6.3, section 6.2.9.1) which states
that it should be applied to PCI, PCI-X and PCI Express devices, with
settings being ignored if they are not applicable.

Rename them to hpx_type0, hpx_type1 and hpx_type2 to reflect their relation
to _HPX rather than _HPP.

Link: https://lore.kernel.org/r/20190827094951.10613-2-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-28 15:09:45 -05:00
Krzysztof Wilczynski
7ce2e76a04 PCI: Move ASPM declarations to linux/pci.h
Move ASPM definitions and function prototypes from include/linux/pci-aspm.h
to include/linux/pci.h so users only need to include <linux/pci.h>:

  PCIE_LINK_STATE_L0S
  PCIE_LINK_STATE_L1
  PCIE_LINK_STATE_CLKPM
  pci_disable_link_state()
  pci_disable_link_state_locked()
  pcie_no_aspm()

No functional changes intended.

Link: https://lore.kernel.org/r/20190827095620.11213-1-kw@linux.com
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-08-28 08:28:39 -05:00
Hou Zhiqiang
4035ff36a6 arm64: dts: fsl: Remove num-lanes property from PCIe nodes
Remove the num-lanes property to avoid the driver setting the
link width.

On FSL Layerscape SoCs, the number of lanes assigned to PCIe
controller is not fixed, it is determined by the selected SerDes
protocol in the RCW (Reset Configuration Word).

The PCIe link training is completed automatically through the selected
SerDes protocol - the link width set-up is updated by hardware after
power on reset, so the num-lanes property is not needed for Layerscape
PCIe.

The current num-lanes property was added erroneously, which actually
indicates the maximum lanes the PCIe controller can support up to,
instead of the lanes assigned to the PCIe controller. The link width set
by SerDes protocol will be overridden by the num-lanes property, hence
the subsequent re-training will fail when the assigned lanes do not
match the value in the num-lanes property.

Remove the property to fix the issue

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-08-22 18:25:55 +01:00
Hou Zhiqiang
568adba9eb ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
Remove the num-lanes property to avoid the driver setting the
link width.

On FSL Layerscape SoCs, the number of lanes assigned to PCIe
controller is not fixed, it is determined by the selected SerDes
protocol in the RCW (Reset Configuration Word).

The PCIe link training is completed automatically through the selected
SerDes protocol - the link width set-up is updated by hardware after
power on reset, so the num-lanes property is not needed for Layerscape
PCIe.

The current num-lanes property was added erroneously, which actually
indicates the maximum lanes the PCIe controller can support up to,
instead of the lanes assigned to the PCIe controller. The link width set
by SerDes protocol will be overridden by the num-lanes property, hence
the subsequent re-training will fail when the assigned lanes do not
match the value in the num-lanes property.

Remove the property to fix the issue.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-08-22 18:20:47 +01:00
Hou Zhiqiang
66de33f09f PCI: dwc: Return directly when num-lanes is not found
The num-lanes is optional since it is not needed on some platforms
that bring up the link in firmware.

The link programming is based on the num-lanes properties (which is
optional); if it is not present code must return instead of fiddling
with the lanes value to print an error message.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-08-22 18:16:24 +01:00
Hou Zhiqiang
ee4ea764ea dt-bindings: PCI: designware: Remove the num-lanes from Required properties
The num-lanes is not a mandatory property, e.g. on FSL
Layerscape SoCs, the PCIe link training is completed
automatically based on the selected SerDes protocol, it
does not need the num-lanes to set-up the link width.

Currently it is both a Required and Optional property,
let's remove it from the Required properties.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-08-22 18:15:23 +01:00
Hou Zhiqiang
df901c85cc PCI: mobiveil: Fix the CPU base address setup in inbound window
Current code erroneously sets-up the CPU base address through the
parameter 'pci_addr', which is passed to initialize the CPU (AXI) base
address of the inbound window where the controller maps the PCI address
space into CPU physical address space; furthermore, it also truncates it
by programming only the lower 32-bit value into the inbound CPU address
register.

Fix both issues by introducing a new parameter 'u64 cpu_addr' to
initialize both lower 32-bit and upper 32-bit of the CPU physical
base address mapping PCI inbound transactions into CPU (AXI) ones.

Fixes: 9af6bcb11e ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver")
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Reviewed-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
2019-08-21 17:40:48 +01:00
Nishka Dasgupta
5ae6393e6d PCI: kirin: Make structure kirin_dw_pcie_ops constant
Static variable kirin_dw_pcie_ops, of type dw_pcie_ops, is used only
once, when it is assigned to the constant field ops of variable pci
(having type dw_pcie) so kirin_dw_pcie_ops is never modified.

Make it constant to protect it from unintended modification.

Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
2019-08-21 11:45:14 +01:00
Haiyang Zhang
be700103ef PCI: hv: Detect and fix Hyper-V PCI domain number collision
Currently in Azure cloud, for passthrough devices, the host sets the
device instance ID's bytes 8 - 15 to a value derived from the host HWID,
which is the same on all devices in a VM. So, the device instance ID's
bytes 8 and 9 provided by the host are no longer unique. This affects
all Azure hosts since July 2018, and can cause device passthrough to VMs
to fail because the bytes 8 and 9 are used as PCI domain number.
Collision of domain numbers will cause the second device with the same
domain number fail to load.

In the cases of collision, we will detect and find another number that is
not in use.

Suggested-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Sasha Levin <sashal@kernel.org>
2019-08-21 08:15:19 +01:00
Kelsey Skunberg
aaee0c1ffd PCI/IOV: Move sysfs SR-IOV functions to iov.c
The sysfs SR-IOV functions are only needed when the kernel is built with
SR-IOV support.  Rather than put them in pci-sysfs.c under #ifdef
CONFIG_PCI_IOV, move them to iov.c, which is only compiled when
CONFIG_PCI_IOV=y.

Link: https://lore.kernel.org/r/20190813204513.4790-4-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2019-08-20 14:05:05 -05:00
Kelsey Skunberg
e2154044dd PCI: sysfs: Change permissions from symbolic to octal
We prefer octal permissions over symbolic permissions such as "(S_IWUSR |
S_IWGRP)".  Change all symbolic permissions to octal permissions, e.g.,

  - (S_IWUSR | S_IWGRP)
  + 0220

Link: https://lore.kernel.org/r/20190813204513.4790-3-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
2019-08-20 14:05:00 -05:00
Kelsey Skunberg
4e2b79436e PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()
DEVICE_ATTR() should only be used when files have unusual permissions.
Change DEVICE_ATTR() with '0220' write-only permissions to
DEVICE_ATTR_WO(), e.g.,

  - static DEVICE_ATTR(_name, (S_IWUSR | S_IWGRP), NULL, _store);
  + static DEVICE_ATTR_WO(_name);

Since _store is no longer passed, make the _name passed by DEVICE_ATTR_WO()
and the related _name##_store() name match with each other, e.g.,

  DEVICE_ATTR_WO(bus_rescan) must be able to call bus_rescan_store()

Link: https://lore.kernel.org/r/20190815153352.86143-4-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
2019-08-20 14:04:55 -05:00
Kelsey Skunberg
8bdfa145f5 PCI: sysfs: Define device attributes with DEVICE_ATTR*()
Device attributes should be defined using DEVICE_ATTR*(_name, _mode, _show,
_store).  Convert them all from __ATTR*() to DEVICE_ATTR*(), e.g.,

  - struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show,
                                                      _store)
  + static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo)

Link: https://lore.kernel.org/r/20190813204513.4790-2-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
2019-08-20 14:04:45 -05:00
Logan Gunthorpe
27235b15e4 PCI/P2PDMA: Update pci_p2pdma_distance_many() documentation
The comment describing pci_p2pdma_distance_many() still referred to
the devices being behind the same root port. This no longer applies
so reword the documentation.

Link: https://lore.kernel.org/r/20190730163545.4915-15-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-15-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:59 -05:00
Logan Gunthorpe
5daf40b039 PCI/P2PDMA: Allow IOMMU for host bridge whitelist
Now that we map the requests correctly we can remove the iommu_present()
restriction.

Link: https://lore.kernel.org/r/20190730163545.4915-14-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-14-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:54 -05:00
Logan Gunthorpe
5d52e1abcd PCI/P2PDMA: dma_map() requests that traverse the host bridge
Any requests that traverse the host bridge will need to be mapped into the
IOMMU, so call dma_map_sg() inside pci_p2pdma_map_sg() when appropriate.

Similarly, call dma_unmap_sg() inside pci_p2pdma_unmap_sg().

Link: https://lore.kernel.org/r/20190730163545.4915-13-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-13-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:48 -05:00
Logan Gunthorpe
110203bee0 PCI/P2PDMA: Store mapping method in an xarray
When upstream_bridge_distance() is called, store the method required to map
the DMA transfers in an xarray so it can be looked up efficiently on the
hot path in pci_p2pdma_map_sg().

Link: https://lore.kernel.org/r/20190730163545.4915-12-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-12-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:43 -05:00
Logan Gunthorpe
142c242e6f PCI/P2PDMA: Factor out __pci_p2pdma_map_sg()
Factor out the bus-only mapping into its own static function.  No
functional changes. The original pci_p2pdma_map_sg_attrs() will be used to
decide whether this is an appropriate way to map.

Link: https://lore.kernel.org/r/20190730163545.4915-11-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-11-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:35 -05:00
Logan Gunthorpe
7f73eac3a7 PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()
Add pci_p2pdma_unmap_sg() to the two places that call pci_p2pdma_map_sg().

This is a prep patch to introduce correct mappings for p2pdma transactions
that go through the root complex.

Link: https://lore.kernel.org/r/20190730163545.4915-10-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-10-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:26 -05:00
Logan Gunthorpe
2b9f4bb2a4 PCI/P2PDMA: Add attrs argument to pci_p2pdma_map_sg()
This is to match the dma_map_sg() API which this function will have to call
in an future patch.

Add a pci_p2pdma_map_sg_attrs() function and helper to call it with no
attributes just like the dma_map_sg() function.

Link: https://lore.kernel.org/r/20190730163545.4915-9-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-9-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:15 -05:00
Logan Gunthorpe
494d63b0d5 PCI/P2PDMA: Whitelist some Intel host bridges
Intel devices do not have good support for P2P requests that span different
host bridges as the transactions will cross the QPI/UPI bus and this does
not perform well.

Therefore, enable support for these devices only if the host bridges match.

Add Intel devices that have been tested and are known to work. There are
likely many others out there that will need to be tested and added.

Link: https://lore.kernel.org/r/20190730163545.4915-8-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-8-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:41:07 -05:00
Logan Gunthorpe
2c84d818ae PCI/P2PDMA: Factor out host_bridge_whitelist()
Push both PCI devices into the whitelist checking function seeing some
hardware will require us ensuring they are on the same host bridge.

At the same time we rename root_complex_whitelist() to
host_bridge_whitelist() to match the terminology used in the code.

Link: https://lore.kernel.org/r/20190730163545.4915-7-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-7-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:40:59 -05:00
Logan Gunthorpe
e2cbfbf789 PCI/P2PDMA: Apply host bridge whitelist for ACS
When a P2PDMA transfer is rejected due to ACS being set, we can also check
the whitelist and allow the transactions.

Do this by pushing the whitelist check into the upstream_bridge_distance()
function.

Link: https://lore.kernel.org/r/20190730163545.4915-6-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-6-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:40:50 -05:00
Logan Gunthorpe
c6bfaeb573 PCI/P2PDMA: Factor out __upstream_bridge_distance()
This is a prep patch to create a second level helper. There are no
functional changes.

The root complex whitelist code will be moved into this function in a
subsequent patch.

Link: https://lore.kernel.org/r/20190730163545.4915-5-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-5-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:40:38 -05:00
Logan Gunthorpe
72583084e3 PCI/P2PDMA: Add constants for map type results to upstream_bridge_distance()
Add constant flags to indicate how two devices will be mapped or if they
are unsupported. upstream_bridge_distance() will now return the
mapping type and the distance in a passed-by-reference argument.

This helps annotate the code better, but the main reason is so we can use
the information to store the required mapping method in an xarray.

Link: https://lore.kernel.org/r/20190730163545.4915-4-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-4-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:40:23 -05:00
Logan Gunthorpe
0afea38143 PCI/P2PDMA: Add provider's pci_dev to pci_p2pdma_pagemap struct
The provider will be needed to figure out how to map a device.

Link: https://lore.kernel.org/r/20190730163545.4915-3-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-3-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:40:05 -05:00
Logan Gunthorpe
a6e6fe6549 PCI/P2PDMA: Introduce private pagemap structure
Move the PCI bus offset from the generic dev_pagemap structure to a
specific pci_p2pdma_pagemap structure.

This structure will grow in subsequent patches.

Link: https://lore.kernel.org/r/20190730163545.4915-2-logang@deltatee.com
Link: https://lore.kernel.org/r/20190812173048.9186-2-logang@deltatee.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
2019-08-16 08:38:52 -05:00
Stefan Agner
075af61c19 PCI: imx6: Limit DBI register length
Define the length of the DBI registers and limit config space to its
length. This makes sure that the kernel does not access registers
beyond that point, avoiding the following abort on a i.MX 6Quad:

  # cat /sys/devices/soc0/soc/1ffc000.pcie/pci0000\:00/0000\:00\:00.0/config
  [  100.021433] Unhandled fault: imprecise external abort (0x1406) at 0xb6ea7000
  ...
  [  100.056423] PC is at dw_pcie_read+0x50/0x84
  [  100.060790] LR is at dw_pcie_rd_own_conf+0x44/0x48
  ...

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
2019-08-15 11:51:37 +01:00
Randy Dunlap
f58ba5e3f6 PCI: pci-hyperv: Fix build errors on non-SYSFS config
Fix build errors when building almost-allmodconfig but with SYSFS
not set (not enabled). Fixes these build errors:

ERROR: "pci_destroy_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!
ERROR: "pci_create_slot" [drivers/pci/controller/pci-hyperv.ko] undefined!

drivers/pci/slot.o is only built when SYSFS is enabled, so
pci-hyperv.o has an implicit dependency on SYSFS.
Make that explicit.

Also, depending on X86 && X86_64 is not needed, so just change that
to depend on X86_64.

Fixes: a15f2c08c7 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jake Oshins <jakeo@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-hyperv@vger.kernel.org
Cc: Dexuan Cui <decui@microsoft.com>
2019-08-15 10:50:05 +01:00
Xiaowei Bao
b5b2461798 PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
Add CONFIG_PCI_LAYERSCAPE_EP so that endpoint and host controller
drivers can be built separately.

Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-08-14 10:54:13 +01:00
Xiaowei Bao
fd5d16531a PCI: layerscape: Add the bar_fixed_64bit property to the endpoint driver
The layerscape PCIe controller have 4 BARs.

 BAR0 and BAR1 are 32bit, BAR2 and BAR4 are 64bit and that's a
fixed hardware configuration.

Set the bar_fixed_64bit variable accordingly.

Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-08-14 10:48:10 +01:00
Vidya Sagar
5dae15b21d phy: tegra: Add PCIe PIPE2UPHY support
Synopsys DesignWare core based PCIe controllers in Tegra 194 SoC
interface with Universal PHY (UPHY) module through a PIPE2UPHY (P2U)
module. For each PCIe lane of a controller, there is a P2U unit
instantiated at hardware level. This driver provides support for the
programming required for each P2U that is going to be used for a PCIe
controller.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Thierry Reding <treding@nvidia.com>
2019-08-13 16:01:15 +01:00
Vidya Sagar
813c6fbcb7 dt-bindings: PHY: P2U: Add Tegra194 P2U block
Add support for Tegra194 P2U (PIPE to UPHY) module block which is a glue
module instantiated once for each PCIe lane between Synopsys DesignWare
core based PCIe IP and Universal PHY block.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-08-13 16:01:14 +01:00
Vidya Sagar
42c253ecaa dt-bindings: PCI: tegra: Add device tree support for Tegra194
Add support for Tegra194 PCIe controllers. These controllers are based
on Synopsys DesignWare core IP.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
2019-08-13 16:01:11 +01:00
Vidya Sagar
7b31a72e71 dt-bindings: Add PCIe supports-clkreq property
Some host controllers need to know the existence of clkreq signal routing
to downstream devices to be able to advertise low power features like
ASPM L1 substates. Without clkreq signal routing being present, enabling
ASPM L1 substates might lead to downstream devices being disconnected
from the bus. Hence a new device tree property 'supports-clkreq' is added
to make such host controllers aware of clkreq signal routing to
downstream devices.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
2019-08-13 16:00:58 +01:00
Vidya Sagar
07f123def7 PCI: dwc: Add support to enable CDM register check
Add support to enable CDM (Configuration Dependent Module) register
check for any data corruption based on the DT property
'snps,enable-cdm-check'.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
2019-08-13 16:00:46 +01:00
Vidya Sagar
f4e84a5d9d dt-bindings: PCI: designware: Add binding for CDM register check
Add support to enable CDM (Configuration Dependent Module) registers check
for any data corruption. CDM registers include standard PCIe configuration
space registers, Port Logic registers and iATU and DMA registers.
Refer Section S.4 of Synopsys DesignWare Cores PCI Express Controller Databook
Version 4.90a.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Herring <robh@kernel.org>
2019-08-13 15:53:31 +01:00