summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-09-05PCI: Add pci_info_ratelimited() to ratelimit PCI separatelyKrzysztof Wilczynski
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 a88a7b3eb076 ("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-05PCI/IOV: Remove group write permission from sriov_numvfs, ↵Kelsey Skunberg
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-04PCI: iproc: Propagate errors for optional PHYsThierry Reding
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-04PCI: histb: Propagate errors for optional regulatorsThierry Reding
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-04PCI: armada8x: Propagate errors for optional PHYsThierry Reding
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-04PCI: imx6: Propagate errors for optional regulatorsThierry Reding
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-04PCI: exynos: Propagate errors for optional PHYsThierry Reding
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-04PCI: rockchip: Propagate errors for optional regulatorsThierry Reding
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-08-30PCI: Remove unnecessary returnsKrzysztof Wilczynski
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-30PCI: OF: Correct of_irq_parse_pci() documentationLubomir Rintel
530210c7814e ("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-30PCI: Fix typos and whitespace errorsBjorn Helgaas
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-28PCI/ACPI: Remove unnecessary struct hotplug_program_opsKrzysztof Wilczynski
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 87fcf12e846a ("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 f873c51a155a ("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-28PCI/ACPI: Move _HPP & _HPX functions to pci-acpi.cKrzysztof Wilczynski
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-28PCI/ACPI: Rename _HPX structs from hpp_* to hpx_*Krzysztof Wilczynski
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-28PCI: Move ASPM declarations to linux/pci.hKrzysztof Wilczynski
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-22arm64: dts: fsl: Remove num-lanes property from PCIe nodesHou Zhiqiang
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-22ARM: dts: ls1021a: Remove num-lanes property from PCIe nodesHou Zhiqiang
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-22PCI: dwc: Return directly when num-lanes is not foundHou Zhiqiang
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-22dt-bindings: PCI: designware: Remove the num-lanes from Required propertiesHou Zhiqiang
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-21PCI: mobiveil: Fix the CPU base address setup in inbound windowHou Zhiqiang
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: 9af6bcb11e12 ("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-21PCI: kirin: Make structure kirin_dw_pcie_ops constantNishka Dasgupta
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-21PCI: hv: Detect and fix Hyper-V PCI domain number collisionHaiyang Zhang
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-20PCI/IOV: Move sysfs SR-IOV functions to iov.cKelsey Skunberg
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-20PCI: sysfs: Change permissions from symbolic to octalKelsey Skunberg
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-20PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()Kelsey Skunberg
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-20PCI: sysfs: Define device attributes with DEVICE_ATTR*()Kelsey Skunberg
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-16PCI/P2PDMA: Update pci_p2pdma_distance_many() documentationLogan Gunthorpe
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-16PCI/P2PDMA: Allow IOMMU for host bridge whitelistLogan Gunthorpe
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-16PCI/P2PDMA: dma_map() requests that traverse the host bridgeLogan Gunthorpe
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-16PCI/P2PDMA: Store mapping method in an xarrayLogan Gunthorpe
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-16PCI/P2PDMA: Factor out __pci_p2pdma_map_sg()Logan Gunthorpe
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-16PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()Logan Gunthorpe
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-16PCI/P2PDMA: Add attrs argument to pci_p2pdma_map_sg()Logan Gunthorpe
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-16PCI/P2PDMA: Whitelist some Intel host bridgesLogan Gunthorpe
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-16PCI/P2PDMA: Factor out host_bridge_whitelist()Logan Gunthorpe
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-16PCI/P2PDMA: Apply host bridge whitelist for ACSLogan Gunthorpe
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-16PCI/P2PDMA: Factor out __upstream_bridge_distance()Logan Gunthorpe
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-16PCI/P2PDMA: Add constants for map type results to upstream_bridge_distance()Logan Gunthorpe
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-16PCI/P2PDMA: Add provider's pci_dev to pci_p2pdma_pagemap structLogan Gunthorpe
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-16PCI/P2PDMA: Introduce private pagemap structureLogan Gunthorpe
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-15PCI: imx6: Limit DBI register lengthStefan Agner
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-15PCI: pci-hyperv: Fix build errors on non-SYSFS configRandy Dunlap
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: a15f2c08c708 ("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-14PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separatelyXiaowei Bao
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-14PCI: layerscape: Add the bar_fixed_64bit property to the endpoint driverXiaowei Bao
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-13phy: tegra: Add PCIe PIPE2UPHY supportVidya Sagar
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-13dt-bindings: PHY: P2U: Add Tegra194 P2U blockVidya Sagar
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-13dt-bindings: PCI: tegra: Add device tree support for Tegra194Vidya Sagar
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-13dt-bindings: Add PCIe supports-clkreq propertyVidya Sagar
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-13PCI: dwc: Add support to enable CDM register checkVidya Sagar
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-13dt-bindings: PCI: designware: Add binding for CDM register checkVidya Sagar
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>
generated by cgit (git 2.34.1) at 2025-07-18 05:55:44 +0000