summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-08-19PCI: endpoint: Add support to link a physical function to a virtual functionKishon Vijay Abraham I
While the physical function has to be linked to endpoint controller, the virtual function has to be linked to a physical function. Add support to link a physical function to a virtual function in pci-ep-cfs. Link: https://lore.kernel.org/r/20210819123343.1951-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: endpoint: Add support to add virtual function in endpoint coreKishon Vijay Abraham I
Add support to add virtual function in endpoint core. The virtual function can only be associated with a physical function instead of a endpoint controller. Provide APIs to associate a virtual function with a physical function here. [weiyongjun1@huawei.com: PCI: endpoint: Fix missing unlock on error in pci_epf_add_vepf() - Reported-by: Hulk Robot <hulkci@huawei.com>] Link: https://lore.kernel.org/r/20210819123343.1951-3-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19dt-bindings: PCI: pci-ep: Add binding to specify virtual functionKishon Vijay Abraham I
Add binding to specify virtual function (associated with each physical function) in endpoint mode. Link: https://lore.kernel.org/r/20210819123343.1951-2-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2021-08-18PCI: Change the type of probe argument in reset functionsAmey Narkhede
Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-18PCI: Add support for ACPI _RST reset methodShanker Donthineni
_RST is a standard ACPI method that performs a function level reset of a device (ACPI v6.3, sec 7.3.25). Add pci_dev_acpi_reset() to probe for _RST method and execute if present. The default priority of this reset is set to below device-specific and above hardware resets. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-9-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-18PCI: Setup ACPI fwnode early and at the same time with OFShanker Donthineni
Previously, the ACPI_COMPANION() of a pci_dev was usually set by acpi_bind_one() in this path: pci_device_add pci_configure_device pci_init_capabilities device_add device_platform_notify acpi_platform_notify acpi_device_notify # KOBJ_ADD acpi_bind_one ACPI_COMPANION_SET However, things like pci_configure_device() and pci_init_capabilities() that run before device_add() need the ACPI_COMPANION, e.g., acpi_pci_bridge_d3() uses a _DSD method to learn about D3 support. These places had special-case code to manually look up the ACPI_COMPANION. Set the ACPI_COMPANION earlier, in pci_setup_device(), so it will be available while configuring the device. This covers both paths to creating pci_dev objects: pci_scan_single_device # for normal non-SR-IOV devices pci_scan_device pci_setup_device pci_set_acpi_fwnode pci_device_add pci_iov_add_virtfn # for SR-IOV virtual functions pci_setup_device pci_set_acpi_fwnode Also move the OF fwnode setup to the same spot. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210817180500.1253-8-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-18PCI: Use acpi_pci_power_manageable()Shanker Donthineni
Use acpi_pci_power_manageable() instead of duplicating the logic in acpi_pci_bridge_d3(). No functional change intended. [bhelgaas: split out from https://lore.kernel.org/r/20210817180500.1253-8-ameynarkhede03@gmail.com] Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-18PCI: Add pci_set_acpi_fwnode() to set ACPI_COMPANIONShanker Donthineni
Move the existing logic from acpi_pci_bridge_d3() to a separate function pci_set_acpi_fwnode() to set the ACPI fwnode. No functional change intended. Link: https://lore.kernel.org/r/20210817180500.1253-7-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-18PCI: Allow userspace to query and set device reset mechanismAmey Narkhede
Add "reset_method" sysfs attribute to enable user to query and set preferred device reset methods and their ordering. [bhelgaas: on invalid sysfs input, return error and preserve previous config, as in earlier patch versions] Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-6-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Remove reset_fn field from pci_devAmey Narkhede
"reset_fn" indicates whether the device supports any reset mechanism. Remove the use of reset_fn in favor of the reset_methods array that tracks supported reset mechanisms of a device and their ordering. The octeon driver incorrectly used reset_fn to detect whether the device supports FLR or not. Use pcie_reset_flr() to probe whether it supports FLR. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-5-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Add array to track reset method orderingAmey Narkhede
Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Add pcie_reset_flr() with 'probe' argumentAmey Narkhede
Most reset methods are of the form "pci_*_reset(dev, probe)". pcie_flr() was an exception because it relied on a separate pcie_has_flr() function instead of taking a "probe" argument. Add "pcie_reset_flr(dev, probe)" to follow the convention. Remove pcie_has_flr(). Some pcie_flr() callers that did not use pcie_has_flr() remain. [bhelgaas: commit log, rework pcie_reset_flr() to use dev->devcap directly] Link: https://lore.kernel.org/r/20210817180500.1253-3-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Cache PCIe Device Capabilities registerAmey Narkhede
Add a new member called devcap in struct pci_dev for caching the PCIe Device Capabilities register to avoid reading PCI_EXP_DEVCAP multiple times. Refactor pcie_has_flr() to use cached device capabilities. Link: https://lore.kernel.org/r/20210817180500.1253-2-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-16PCI: rcar: Add L1 link state fix into data abort hookMarek Vasut
When the link is in L1, hardware should return it to L0 automatically whenever a transaction targets a component on the other end of the link (PCIe r5.0, sec 5.2). The R-Car PCIe controller doesn't handle this transition correctly. If the link is not in L0, an MMIO transaction targeting a downstream device fails, and the controller reports an ARM imprecise external abort. Work around this by hooking the abort handler so the driver can detect this situation and help the hardware complete the link state transition. When the R-Car controller receives a PM_ENTER_L1 DLLP from the downstream component, it sets PMEL1RX bit in PMSR register, but then the controller enters some sort of in-between state. A subsequent MMIO transaction will fail, resulting in the external abort. The abort handler detects this condition and completes the link state transition by setting the L1IATN bit in PMCTLR and waiting for the link state transition to complete. Link: https://lore.kernel.org/r/20210815181650.132579-1-marek.vasut@gmail.com Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2021-08-13PCI: hv: Support for create interrupt v3Sunil Muthuswamy
Hyper-V vPCI protocol version 1_4 adds support for create interrupt v3. Create interrupt v3 essentially makes the size of the vector field bigger in the message, thereby allowing bigger vector values. For example, that will come into play for supporting LPI vectors on ARM, which start at 8192. Link: https://lore.kernel.org/r/MW4PR21MB20026A6EA554A0B9EC696AA8C0159@MW4PR21MB2002.namprd21.prod.outlook.com Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Wei Liu <wei.liu@kernel.org>
2021-08-13PCI: xilinx-nwl: Enable the clock through CCFHyun Kwon
Enable PCIe reference clock. There is no remove function that's why this should be enough for simple operation. Normally this clock is enabled by default by firmware but there are usecases where this clock should be enabled by driver itself. It is also good that PCIe clock is recorded in a clock framework. Link: https://lore.kernel.org/r/ee6997a08fab582b1c6de05f8be184f3fe8d5357.1624618100.git.michal.simek@xilinx.com Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com> Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-08-13dt-bindings: pci: xilinx-nwl: Document optional clock propertyMichal Simek
Clock property hasn't been documented in binding document but it is used for quite a long time where clock was specified by commit 9c8a47b484ed ("arm64: dts: xilinx: Add the clock nodes for zynqmp"). Link: https://lore.kernel.org/r/67aa2c189337181bb2d7721fb616db5640587d2a.1624618100.git.michal.simek@xilinx.com Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org>
2021-08-12PCI: Fix pci_dev_str_match_path() alloc while atomic bugDan Carpenter
pci_dev_str_match_path() is often called with a spinlock held so the allocation has to be atomic. The call tree is: pci_specified_resource_alignment() <-- takes spin_lock(); pci_dev_str_match() pci_dev_str_match_path() Fixes: 45db33709ccc ("PCI: Allow specifying devices using a base bus and path of devfns") Link: https://lore.kernel.org/r/20210812070004.GC31863@kili Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2021-08-12x86/PCI: Add pci_numachip_init() declarationKrzysztof Wilczyński
numachip.c defines pci_numachip_init(), but neglected to include its declaration, causing the following sparse and compile time warnings: arch/x86/pci/numachip.c:108:12: warning: no previous prototype for function 'pci_numachip_init' [-Wmissing-prototypes] arch/x86/pci/numachip.c:108:12: warning: symbol 'pci_numachip_init' was not declared. Should it be static? Include asm/numachip/numachip.h, which includes the missing declaration. Link: https://lore.kernel.org/r/20210812171717.1471243-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Treat invalid VPD like missing VPD capabilityHeiner Kallweit
Exporting sysfs files that can't be accessed doesn't make much sense. Therefore, if either a quirk or the dynamic size calculation result in VPD being marked as invalid, treat this as though the device has no VPD capability. One consequence is that the "vpd" sysfs file is not visible. Link: https://lore.kernel.org/r/6a02b204-4ed2-4553-c3b2-eacf9554fa8d@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Determine VPD size in pci_vpd_init()Heiner Kallweit
Determine VPD size in pci_vpd_init(). Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the dynamic size calculation. Prerequisite is that we move the quirks from FINAL to HEADER so they are run before pci_vpd_init(). Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Embed struct pci_vpd in struct pci_devHeiner Kallweit
Now that struct pci_vpd is really small, simplify the code by embedding struct pci_vpd directly in struct pci_dev instead of dynamically allocating it. Link: https://lore.kernel.org/r/d898489e-22ba-71f1-2f31-f1a78dc15849@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Remove struct pci_vpd.valid memberHeiner Kallweit
Instead of having a separate flag, use vp->len != 0 as indicator that VPD validity has been checked. Now vpd->len == PCI_VPD_SZ_INVALID indicates that VPD is invalid. Link: https://lore.kernel.org/r/9f777bc7-5316-e1b8-e5d4-f9f609bdb5dd@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Remove struct pci_vpd_opsHeiner Kallweit
Some multi-function devices share VPD hardware across functions and don't work correctly for concurrent VPD accesses to different functions. Struct pci_vpd_ops was added by 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") so that on these devices, VPD accesses to any function would always go to function 0. It's easier to just check for the PCI_DEV_FLAGS_VPD_REF_F0 quirk bit in the two places we need it than to deal with the struct pci_vpd_ops. Simplify the code by removing struct pci_vpd_ops and removing the indirect calls. [bhelgaas: check for !func0_dev earlier, commit log] Link: https://lore.kernel.org/r/b2532a41-df8b-860f-461f-d5c066c819d0@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Reorder pci_read_vpd(), pci_write_vpd()Heiner Kallweit
Reorder pci_read_vpd() and pci_write_vpd() to prepare for future patches. No functional change intended. Link: https://lore.kernel.org/r/89f0f5a2-293b-a017-fc67-a36473a792bf@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-09PCI/VPD: Remove struct pci_vpd.flagHeiner Kallweit
The struct pci_vpd.flag member was used only to communicate between pci_vpd_wait() and its callers. Remove the flag member and pass the value directly to pci_vpd_wait() to simplify the code. [bhelgaas: commit log] Link: https://lore.kernel.org/r/e4ef6845-6b23-1646-28a0-d5c5a28347b6@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-09PCI/VPD: Make pci_vpd_wait() uninterruptibleHeiner Kallweit
Reading/writing 4 bytes should be fast enough even on a slow bus, therefore pci_vpd_wait() doesn't have to be interruptible. Making it uninterruptible allows to simplify the code. In addition make VPD writes uninterruptible in general. It's about vital data, and allowing writes to be interruptible may leave the VPD in an inconsistent state. Link: https://lore.kernel.org/r/258bf994-bc2a-2907-9181-2c7a562986d5@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-09PCI/VPD: Remove pci_vpd_size() old_size argumentHeiner Kallweit
vpd->len is initialized to PCI_VPD_MAX_SIZE, and if a quirk is used to set a specific VPD size, then pci_vpd_set_size() sets vpd->valid, resulting in pci_vpd_size() not being called. Therefore we can remove the old_size argument. Note that we don't have to check off < PCI_VPD_MAX_SIZE because that's implicitly done by pci_read_vpd(). Link: https://lore.kernel.org/r/ede36c16-5335-6867-43a1-293641348430@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-09PCI/VPD: Allow access to valid parts of VPD if some is invalidBjorn Helgaas
Previously, if we found any error in the VPD, we returned size 0, which prevents access to all of VPD. But there may be valid resources in VPD before the error, and there's no reason to prevent access to those. "off" covers only VPD resources known to have valid header tags. In case of error, return "off" (which may be zero if we haven't found any valid header tags at all). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
2021-08-09PCI/VPD: Don't check Large Resource Item Names for validityBjorn Helgaas
VPD consists of a series of Small and Large Resources. Computing the size of VPD requires only the length of each, which is specified in the generic tag of each resource. We only expect to see ID_STRING, RO_DATA, and RW_DATA in VPD, but it's not a problem if it contains other resource types because all we care about is the size. Drop the validity checking of Large Resource items. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
2021-08-09PCI/VPD: Reject resource tags with invalid sizeBjorn Helgaas
VPD is limited in size by the 15-bit VPD Address field in the VPD Capability. Each resource tag includes a length that determines the overall size of the resource. Reject any resources that would extend past the maximum VPD size. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
2021-08-05PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe()Dinghao Liu
pm_runtime_get_sync() will increase the runtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Link: https://lore.kernel.org/r/20210408072402.15069-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-08-05PCI: xgene-msi: Remove redundant dev_err() call in xgene_msi_probe()ErKun Yang
devm_ioremap_resource() internally calls __devm_ioremap_resource() which is where error checking and handling is actually taking place. i Therefore, the dev_err() call in xgene_msi_probe() is redundant. Remove it. Link: https://lore.kernel.org/r/20210408132751.1198171-1-yangerkun@huawei.com Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: ErKun Yang <yangerkun@huawei.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-08-05PCI: tegra: make const array err_msg staticChristophe JAILLET
Don't populate the array err_msg on the stack but instead make it static. Makes the object code smaller by 64 bytes. While at it, add a missing const, as reported by checkpatch. Compiled with gcc 11.0.1 Before: $ size drivers/pci/controller/pci-tegra.o text data bss dec hex filename 25623 2844 32 28499 6f53 drivers/pci/controller/pci-tegra.o After: $ size drivers/pci/controller/pci-tegra.o text data bss dec hex filename 25559 2844 32 28435 6f13 drivers/pci/controller/pci-tegra.o Link: https://lore.kernel.org/r/5f3f35296b944b94546cc7d1e9cc6186484620d8.1620148539.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-05PCI: tegra: Use 'seq_puts' instead of 'seq_printf'Christophe JAILLET
As spotted by checkpatch, use 'seq_puts' instead of 'seq_printf' when possible. It is slightly more efficient. Link: https://lore.kernel.org/r/7bdedb342b9221169ab085540cf25d1992e8b97a.1620148539.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-05PCI: tegra: Fix OF node reference leakChristophe JAILLET
Commit 9e38e690ace3 ("PCI: tegra: Fix OF node reference leak") has fixed some node reference leaks in this function but missed some of them. In fact, having 'port' referenced in the 'rp' structure is not enough to prevent the leak, until 'rp' is actually added in the 'pcie->ports' list. Add the missing 'goto err_node_put' accordingly. Link: https://lore.kernel.org/r/55b11e9a7fa2987fbc0869d68ae59888954d65e2.1620148539.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-05PCI: aardvark: Fix reporting CRS valuePali Rohár
Set CRSVIS flag in emulated root PCI bridge to indicate support for Completion Retry Status. Add check for CRSSVE flag from root PCI brige when issuing Configuration Read Request via PIO to correctly returns fabricated CRS value as it is required by PCIe spec. Link: https://lore.kernel.org/r/20210722144041.12661-5-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org # e0d9d30b7354 ("PCI: pci-bridge-emul: Fix big-endian support")
2021-08-05PCI: pci-bridge-emul: Add PCIe Root Capabilities RegisterPali Rohár
The 16-bit Root Capabilities register is at offset 0x1e in the PCIe Capability. Rename current 'rsvd' struct member to 'rootcap'. Link: https://lore.kernel.org/r/20210722144041.12661-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org>
2021-08-05PCI: aardvark: Increase polling delay to 1.5s while waiting for PIO responsePali Rohár
Measurements in different conditions showed that aardvark hardware PIO response can take up to 1.44s. Increase wait timeout from 1ms to 1.5s to ensure that we do not miss responses from hardware. After 1.44s hardware returns errors (e.g. Completer abort). The previous two patches fixed checking for PIO status, so now we can use it to also catch errors which are reported by hardware after 1.44s. After applying this patch, kernel can detect and print PIO errors to dmesg: [ 6.879999] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100004 [ 6.896436] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 [ 6.913049] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100010 [ 6.929663] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100010 [ 6.953558] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100014 [ 6.970170] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100014 [ 6.994328] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 Without this patch kernel prints only a generic error to dmesg: [ 5.246847] advk-pcie d0070000.pcie: config read/write timed out Link: https://lore.kernel.org/r/20210722144041.12661-3-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock")
2021-08-05PCI: aardvark: Fix checking for PIO statusEvan Wang
There is an issue that when PCIe switch is connected to an Armada 3700 board, there will be lots of warnings about PIO errors when reading the config space. According to Aardvark PIO read and write sequence in HW specification, the current way to check PIO status has the following issues: 1) For PIO read operation, it reports the error message, which should be avoided according to HW specification. 2) For PIO read and write operations, it only checks PIO operation complete status, which is not enough, and error status should also be checked. This patch aligns the code with Aardvark PIO read and write sequence in HW specification on PIO status check and fix the warnings when reading config space. [pali: Fix CRS handling when CRSSVE is not enabled] Link: https://lore.kernel.org/r/20210722144041.12661-2-pali@kernel.org Tested-by: Victor Gu <xigu@marvell.com> Signed-off-by: Evan Wang <xswang@marvell.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Victor Gu <xigu@marvell.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org # b1bd5714472c ("PCI: aardvark: Indicate error in 'val' when config read fails")
2021-08-04PCI: tegra194: Cleanup unused codeOm Prakash Singh
Remove unused code from function tegra_pcie_config_ep. Link: https://lore.kernel.org/r/20210623100525.19944-6-omp@nvidia.com Signed-off-by: Om Prakash Singh <omp@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-04PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP modeOm Prakash Singh
When Tegra PCIe is in endpoint mode it should be available for root port. PCIe link up by root port fails if it is in suspend state. So, don't allow Tegra to suspend when endpoint mode is enabled. Link: https://lore.kernel.org/r/20210623100525.19944-5-omp@nvidia.com Signed-off-by: Om Prakash Singh <omp@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-04PCI: tegra194: Disable interrupts before entering L2Om Prakash Singh
In suspend_noirq() call if link doesn't goto L2, PERST# is asserted to bring link to detect state. However, this is causing surprise link down AER error. Since Kernel is executing noirq suspend calls, AER interrupt is not processed. PME and AER are shared interrupts and PCIe subsystem driver enables wake capability of PME irq during suspend. So this AER will cause suspend failure due to pending AER interrupt. After PCIe link is in L2, interrupts are not expected since PCIe controller will be in reset state. Disable PCIe interrupts before going to L2 state to avoid pending AER interrupt. Link: https://lore.kernel.org/r/20210623100525.19944-4-omp@nvidia.com Signed-off-by: Om Prakash Singh <omp@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-04PCI: tegra194: Fix MSI-X programmingOm Prakash Singh
Lower order MSI-X address is programmed in MSIX_ADDR_MATCH_HIGH_OFF DBI register instead of higher order address. This patch fixes this programming mistake. Link: https://lore.kernel.org/r/20210623100525.19944-3-omp@nvidia.com Signed-off-by: Om Prakash Singh <omp@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-04PCI: tegra194: Fix handling BME_CHGED eventOm Prakash Singh
In tegra_pcie_ep_hard_irq(), APPL_INTR_STATUS_L0 is stored in val and again APPL_INTR_STATUS_L1_0_0 is also stored in val. So when execution reaches "if (val & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT)", val is not correct. Link: https://lore.kernel.org/r/20210623100525.19944-2-omp@nvidia.com Signed-off-by: Om Prakash Singh <omp@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Vidya Sagar <vidyas@nvidia.com>
2021-08-04PCI: iproc: Fix BCMA probe resource handlingRob Herring
In commit 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()"), calling devm_request_pci_bus_resources() was dropped from the common iProc probe code, but is still needed for BCMA bus probing. Without it, there will be lots of warnings like this: pci 0000:00:00.0: BAR 8: no space for [mem size 0x00c00000] pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00c00000] Add back calling devm_request_pci_bus_resources() and adding the resources to pci_host_bridge.windows for BCMA bus probe. Link: https://lore.kernel.org/r/20210803215656.3803204-2-robh@kernel.org Fixes: 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()") Reported-by: Rafał Miłecki <zajec5@gmail.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Srinath Mannam <srinath.mannam@broadcom.com> Cc: Roman Bacik <roman.bacik@broadcom.com> Cc: Bharat Gooty <bharat.gooty@broadcom.com> Cc: Abhishek Shah <abhishek.shah@broadcom.com> Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com> Cc: Ray Jui <ray.jui@broadcom.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "Krzysztof Wilczyński" <kw@linux.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
2021-08-04PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges'Rob Herring
Commit 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") made devm_pci_alloc_host_bridge() fail on any DT resource parsing errors, but Broadcom iProc uses devm_pci_alloc_host_bridge() on BCMA bus devices that don't have DT resources. In particular, there is no 'ranges' property. Fix iProc by making 'ranges' optional. If 'ranges' is required by a platform, there's going to be more errors latter on if it is missing. Link: https://lore.kernel.org/r/20210803215656.3803204-1-robh@kernel.org Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") Reported-by: Rafał Miłecki <zajec5@gmail.com> Tested-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Srinath Mannam <srinath.mannam@broadcom.com> Cc: Roman Bacik <roman.bacik@broadcom.com> Cc: Bharat Gooty <bharat.gooty@broadcom.com> Cc: Abhishek Shah <abhishek.shah@broadcom.com> Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com> Cc: Ray Jui <ray.jui@broadcom.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-03PCI: Add ACS quirks for NXP LX2xx0 and LX2xx2 platformsWasim Khan
Root Ports in NXP LX2xx0 and LX2xx2, where each Root Port is a Root Complex with unique segment numbers, do provide isolation features to disable peer transactions and validate bus numbers in requests, but do not provide an actual PCIe ACS capability. Add ACS quirks for NXP LX2xx0 A/C/E/N and LX2xx2 A/C/E/N platforms. LX2xx0A : without security features + CAN-FD LX2160A (0x8d81) - 16 cores LX2120A (0x8da1) - 12 cores LX2080A (0x8d83) - 8 cores LX2xx0C : security features + CAN-FD LX2160C (0x8d80) - 16 cores LX2120C (0x8da0) - 12 cores LX2080C (0x8d82) - 8 cores LX2xx0E : security features + CAN LX2160E (0x8d90) - 16 cores LX2120E (0x8db0) - 12 cores LX2080E (0x8d92) - 8 cores LX2xx0N : without security features + CAN LX2160N (0x8d91) - 16 cores LX2120N (0x8db1) - 12 cores LX2080N (0x8d93) - 8 cores LX2xx2A : without security features + CAN-FD LX2162A (0x8d89) - 16 cores LX2122A (0x8da9) - 12 cores LX2082A (0x8d8b) - 8 cores LX2xx2C : security features + CAN-FD LX2162C (0x8d88) - 16 cores LX2122C (0x8da8) - 12 cores LX2082C (0x8d8a) - 8 cores LX2xx2E : security features + CAN LX2162E (0x8d98) - 16 cores LX2122E (0x8db8) - 12 cores LX2082E (0x8d9a) - 8 cores LX2xx2N : without security features + CAN LX2162N (0x8d99) - 16 cores LX2122N (0x8db9) - 12 cores LX2082N (0x8d9b) - 8 cores [bhelgaas: put PCI_VENDOR_ID_NXP definition next to PCI_VENDOR_ID_FREESCALE as a clue that they share the same Device ID namespace] Link: https://lore.kernel.org/r/20210729121747.1823086-1-wasim.khan@oss.nxp.com Link: https://lore.kernel.org/r/20210803180021.3252886-1-wasim.khan@oss.nxp.com Signed-off-by: Wasim Khan <wasim.khan@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-03PCI: Return int from pciconfig_read() syscallKrzysztof Wilczyński
Change pciconfig_read() syscall "err" return value from long to int. This makes it consistent with pciconfig_write(). [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210729233755.1509616-2-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-03PCI: Return ~0 data on pciconfig_read() CAP_SYS_ADMIN failureKrzysztof Wilczyński
The pciconfig_read() syscall reads PCI configuration space using hardware-dependent config accessors. If the read fails on PCI, most accessors don't return an error; they pretend the read was successful and got ~0 data from the device, so the syscall returns success with ~0 data in the buffer. When the accessor does return an error, pciconfig_read() normally fills the user's buffer with ~0 and returns an error in errno. But after e4585da22ad0 ("pci syscall.c: Switch to refcounting API"), we don't fill the buffer with ~0 for the EPERM "user lacks CAP_SYS_ADMIN" error. Userspace may rely on the ~0 data to detect errors, but after e4585da22ad0, that would not detect CAP_SYS_ADMIN errors. Restore the original behaviour of filling the buffer with ~0 when the CAP_SYS_ADMIN check fails. [bhelgaas: commit log, fold in Nathan's fix https://lore.kernel.org/r/20210803200836.500658-1-nathan@kernel.org] Fixes: e4585da22ad0 ("pci syscall.c: Switch to refcounting API") Link: https://lore.kernel.org/r/20210729233755.1509616-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-01 21:35:04 +0000