#
f6997740 |
|
29-Sep-2023 |
Lizhi Hou <lizhi.hou@amd.com> |
PCI: of: Destroy changeset when adding PCI device node fails Previously of_pci_make_dev_node() leaked a cset if it failed to create a device node for the PCI device with of_changeset_create_node(). Destroy the cset if of_changeset_create_node() fails. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/1696007417-42059-1-git-send-email-lizhi.hou@amd.com Reported-by: Herve Codina <herve.codina@bootlin.com> Closes: https://lore.kernel.org/all/20230911171319.495bb837@bootlin.com/ Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com>
|
#
407d1a51 |
|
15-Aug-2023 |
Lizhi Hou <lizhi.hou@amd.com> |
PCI: Create device tree node for bridge The PCI endpoint device such as Xilinx Alveo PCI card maps the register spaces from multiple hardware peripherals to its PCI BAR. Normally, the PCI core discovers devices and BARs using the PCI enumeration process. There is no infrastructure to discover the hardware peripherals that are present in a PCI device, and which can be accessed through the PCI BARs. Apparently, the device tree framework requires a device tree node for the PCI device. Thus, it can generate the device tree nodes for hardware peripherals underneath. Because PCI is self discoverable bus, there might not be a device tree node created for PCI devices. Furthermore, if the PCI device is hot pluggable, when it is plugged in, the device tree nodes for its parent bridges are required. Add support to generate device tree node for PCI bridges. Add an of_pci_make_dev_node() interface that can be used to create device tree node for PCI devices. Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on, the kernel will generate device tree nodes for PCI bridges unconditionally. Initially, add the basic properties for the dynamically generated device tree nodes which include #address-cells, #size-cells, device_type, compatible, ranges, reg. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/1692120000-46900-3-git-send-email-lizhi.hou@amd.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
1a8c251c |
|
03-Aug-2023 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
PCI: move OF status = "disabled" detection to dev->match_driver The blamed commit has broken probing on arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi when &enetc_port0 (PCI function 0) has status = "disabled". Background: pci_scan_slot() has logic to say that if the function 0 of a device is absent, the entire device is absent and we can skip the other functions entirely. Traditionally, this has meant that pci_bus_read_dev_vendor_id() returns an error code for that function. However, since the blamed commit, there is an extra confounding condition: function 0 of the device exists and has a valid vendor id, but it is disabled in the device tree. In that case, pci_scan_slot() would incorrectly skip the entire device instead of just that function. In the case of NXP LS1028A, status = "disabled" does not mean that the PCI function's config space is not available for reading. It is, but the Ethernet port is just not functionally useful with a particular SerDes protocol configuration (0x9999) due to pinmuxing constraints of the Soc. So, pci_scan_slot() skips all other functions on the ENETC ECAM (enetc_port1, enetc_port2, enetc_mdio_pf3 etc) when just enetc_port0 had to not be probed. There is an additional regression introduced by the change, caused by its fundamental premise. The enetc driver needs to run code for all PCI functions, regardless of whether they're enabled or not in the device tree. That is no longer possible if the driver's probe function is no longer called. But Rob recommends that we move the of_device_is_available() detection to dev->match_driver, and this makes the PCI fixups still run on all functions, while just probing drivers for those functions that are enabled. So, a separate change in the enetc driver will have to move the workarounds to a PCI fixup. Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/netdev/CAL_JsqLsVYiPLx2kcHkDQ4t=hQVCR7NHziDwi9cCFUFhx48Qow@mail.gmail.com/ Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c6f54cf4 |
|
21-Apr-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PCI: of: Propagate firmware node by calling device_set_node() Insulate pci_set_of_node() and pci_set_bus_of_node() from possible changes to fwnode_handle implementation by using device_set_node() instead of open-coding dev->dev.fwnode assignments. Link: https://lore.kernel.org/r/20230421100939.68225-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9195ee1a |
|
10-Mar-2023 |
Rob Herring <robh@kernel.org> |
PCI: Use of_property_present() for testing DT property presence It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property()/of_find_property() functions for reading properties. As part of this, convert of_get_property()/of_find_property() calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Link: https://lore.kernel.org/r/20230310144719.1544443-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> # pcie-mediatek
|
#
0d21e71a |
|
19-Apr-2023 |
Rob Herring <robh@kernel.org> |
PCI: Restrict device disabled status check to DT Commit 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") checked the firmware device status for both DT and ACPI devices. That caused a regression in some ACPI systems. The exact reason isn't clear. It's possibly a firmware bug. For now, at least, refactor the check to be for DT based systems only. Note that the original implementation leaked a refcount which is now correctly handled. [bhelgaas: Per ACPI r6.5, sec 6.3.7, for devices on an enumerable bus, _STA must return with bit[0] ("device is present") set] Link: https://lore.kernel.org/all/m2fs9lgndw.fsf@gmail.com/ Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/r/20230419193513.708818-1-robh@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217317 Reported-by: Donald Hunter <donald.hunter@gmail.com> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Donald Hunter <donald.hunter@gmail.com> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Binbin Zhou <zhoubinbin@loongson.cn> Cc: Liu Peibao <liupeibao@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn>
|
#
b8397a8f |
|
09-May-2022 |
Robin Murphy <robin.murphy@arm.com> |
iommu/dma: Explicitly sort PCI DMA windows Originally, creating the dma_ranges resource list in pre-sorted fashion was the simplest and most efficient way to enforce the order required by iova_reserve_pci_windows(). However since then at least one PCI host driver is now re-sorting the list for its own probe-time processing, which doesn't seem entirely unreasonable, so that basic assumption no longer holds. Make iommu-dma robust and get the sort order it needs by explicitly sorting, which means we can also save the effort at creation time and just build the list in whatever natural order the DT had. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/35661036a7e4160850895f9b37f35408b6a29f2f.1652091160.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
35662423 |
|
12-Apr-2022 |
Pali Rohár <pali@kernel.org> |
PCI: Add function for parsing 'slot-power-limit-milliwatt' DT property Add function of_pci_get_slot_power_limit(), which parses the 'slot-power-limit-milliwatt' DT property, returning the value in milliwatts and in format ready for the PCIe Slot Capabilities Register. Link: https://lore.kernel.org/r/20220412094946.27069-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ccd36795 |
|
07-Jan-2022 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Correct misspelled words Fix a number of misspelled words, and while at it, correct two phrases used to indicate a status of an operation where words used have been cleverly truncated and thus always trigger a spellchecking error while performing a static code analysis over the PCI tree. [bhelgaas: reverse sense of quirk ternary] Link: https://lore.kernel.org/r/20220107225942.121484-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
978fd005 |
|
29-Sep-2021 |
Marc Zyngier <maz@kernel.org> |
PCI: of: Allow matching of an interrupt-map local to a PCI device Just as we now allow an interrupt map to be parsed when part of an interrupt controller, there is no reason to ignore an interrupt map that would be part of a pci device node such as a root port since we already allow interrupt specifiers. Allow the matching of such property when local to the node of a PCI device, which allows the device itself to use the interrupt map for for its own purpose. Link: https://lore.kernel.org/r/20210929163847.2807812-4-maz@kernel.org Tested-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
|
#
d277f6e8 |
|
03-Aug-2021 |
Rob Herring <robh@kernel.org> |
PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges' 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>
|
#
3bd6b827 |
|
14-Jun-2021 |
Punit Agrawal <punitagrawal@gmail.com> |
PCI: of: Clear 64-bit flag for non-prefetchable memory below 4GB Alexandru and Qu reported this resource allocation failure on ROCKPro64 v2 and ROCK Pi 4B, both based on the RK3399: pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff 64bit] pci 0000:00:00.0: PCI bridge to [bus 01] pci 0000:00:00.0: BAR 14: no space for [mem size 0x00100000] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] "BAR 14" is the PCI bridge's 32-bit non-prefetchable window, and our PCI allocation code isn't smart enough to allocate it in a host bridge window marked as 64-bit, even though this should work fine. A DT host bridge description includes the windows from the CPU address space to the PCI bus space. On a few architectures (microblaze, powerpc, sparc), the DT may also describe PCI devices themselves, including their BARs. Before 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses"), of_bus_pci_get_flags() ignored the fact that some DT addresses described 64-bit windows and BARs. That was a problem because the virtio virtual NIC has a 32-bit BAR and a 64-bit BAR, and the driver couldn't distinguish them. 9d57e61bf723 set IORESOURCE_MEM_64 for those 64-bit DT ranges, which fixed the virtio driver. But it also set IORESOURCE_MEM_64 for host bridge windows, which exposed the fact that the PCI allocator isn't smart enough to put 32-bit resources in those 64-bit windows. Clear IORESOURCE_MEM_64 from host bridge windows since we don't need that information. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Fixes: 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses") Link: https://lore.kernel.org/r/20210614230457.752811-1-punitagrawal@gmail.com Reported-at: https://lore.kernel.org/lkml/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com/ Reported-at: https://lore.kernel.org/lkml/YMyTUv7Jsd89PGci@m4/T/#u Reported-by: Alexandru Elisei <alexandru.elisei@arm.com> Reported-by: Qu Wenruo <wqu@suse.com> Tested-by: Alexandru Elisei <alexandru.elisei@arm.com> Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> Signed-off-by: Punit Agrawal <punitagrawal@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
#
85aabbd7 |
|
10-May-2021 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
PCI/MSI: Fix MSIs for generic hosts that use device-tree's "msi-map" Since commit 9ec37efb8783 ("PCI/MSI: Make pci_host_common_probe() declare its reliance on MSI domains"), platforms that rely on the "msi-map" device-tree property don't get MSIs anymore. On the Arm Fast Model for example [1], the host bridge doesn't have a "msi-parent" property since it doesn't itself generate MSIs, and so doesn't get a MSI domain. It has an "msi-map" property instead to describe MSI controllers of child devices. As a result, due to the new msi_domain check in pci_register_host_bridge(), the whole bus gets PCI_BUS_FLAGS_NO_MSI. Check whether the root complex has an "msi-map" property before giving up on MSIs. [1] arch/arm64/boot/dts/arm/fvp-base-revc.dts Fixes: 9ec37efb8783 ("PCI/MSI: Make pci_host_common_probe() declare its reliance on MSI domains") Link: https://lore.kernel.org/r/20210510173129.750496-1-jean-philippe@linaro.org Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Marc Zyngier <maz@kernel.org>
|
#
43395d9e |
|
10-Mar-2021 |
Krzysztof Wilczyński <kw@linux.com> |
PCI: Fix kernel-doc errors Fix kernel-doc formatting errors, function names that don't match the doc, and some missing parameter documentation. These are reported by: make W=1 drivers/pci/ No functional change intended. [bhelgaas: squashed into one patch since this only changes comments] Link: https://lore.kernel.org/r/20210311001724.423356-1-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-2-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-3-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-4-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-5-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-6-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-7-kw@linux.com Link: https://lore.kernel.org/r/20210311001724.423356-8-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fede8526 |
|
18-Nov-2020 |
Vidya Sagar <vidyas@nvidia.com> |
PCI: of: Warn if non-prefetchable memory aperture size is > 32-bit As per PCIe spec r5.0, sec 7.5.1.3.8 only 32-bit BAR registers are defined for non-prefetchable memory and hence a warning should be reported when the size of them go beyond 32-bits. Link: https://lore.kernel.org/r/20201118144626.32189-2-vidyas@nvidia.com Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
|
#
9b41d19a |
|
29-Jul-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
PCI: Fix kerneldoc warnings Fix kerneldoc warnings, e.g., $ make W=1 drivers/pci/ drivers/pci/ats.c:196: warning: Function parameter or member 'pdev' not described in 'pci_enable_pri' drivers/pci/ats.c:196: warning: Function parameter or member 'reqs' not described in 'pci_enable_pri' ... Link: https://lore.kernel.org/r/20200729201224.26799-2-krzk@kernel.org Link: https://lore.kernel.org/r/20200729201224.26799-3-krzk@kernel.org Link: https://lore.kernel.org/r/20200729201224.26799-4-krzk@kernel.org Link: https://lore.kernel.org/r/20200729201224.26799-5-krzk@kernel.org Link: https://lore.kernel.org/r/20200729201224.26799-6-krzk@kernel.org Link: https://lore.kernel.org/r/20200729201224.26799-7-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b64aa11e |
|
21-Jul-2020 |
Rob Herring <robh@kernel.org> |
PCI: Set bridge map_irq and swizzle_irq to default functions The majority of DT based host drivers use the default .map_irq() and .swizzle_irq() functions, so let's initialize the function pointers to the default and drop setting them in the host drivers. Drivers like iProc which don't support legacy interrupts need to set .map_irq() back to NULL. Link: https://lore.kernel.org/r/20200722022514.1283916-20-robh@kernel.org 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
|
#
669cbc70 |
|
21-Jul-2020 |
Rob Herring <robh@kernel.org> |
PCI: Move DT resource setup into devm_pci_alloc_host_bridge() Now that pci_parse_request_of_pci_ranges() callers just setup pci_host_bridge.windows and dma_ranges directly and don't need the bus range returned, we can just initialize them when allocating the pci_host_bridge struct. With this, pci_parse_request_of_pci_ranges() becomes a static function. Link: https://lore.kernel.org/r/20200722022514.1283916-19-robh@kernel.org 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
|
#
4cb18d13 |
|
21-Jul-2020 |
Rob Herring <robh@kernel.org> |
PCI: of: Reduce missing non-prefetchable memory region to a warning The pci-rcar-gen2 controller requires only a prefetchable memory region, and the error prevents using pci_parse_request_of_pci_ranges() for it. Let's reduce this to just a warning message so this function can be used for pci-rcar-gen2. Link: https://lore.kernel.org/r/20200722022514.1283916-17-robh@kernel.org 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: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
99b50be9 |
|
07-Jul-2020 |
Rajat Jain <rajatja@google.com> |
PCI: Treat "external-facing" devices themselves as internal "External-facing" devices are internal devices that expose PCIe hierarchies such as Thunderbolt outside the platform [1]. Previously these internal devices were marked as "untrusted" the same as devices downstream from them. Use the ACPI or DT information to identify external-facing devices, but only mark the devices *downstream* from them as "untrusted" [2]. The external-facing device itself is no longer marked as untrusted. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports [2] https://lore.kernel.org/linux-pci/20200610230906.GA1528594@bjorn-Precision-5520/ Link: https://lore.kernel.org/r/20200707224604.3737893-3-rajatja@google.com Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2dd9072e |
|
30-Apr-2020 |
Pali Rohár <pali@kernel.org> |
PCI: of: Zero max-link-speed value is invalid Interpret zero value of max-link-speed property as invalid, as the device tree bindings documentation specifies. Link: https://lore.kernel.org/r/20200430080625.26070-4-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
|
#
3b55809c |
|
28-Oct-2019 |
Rob Herring <robh@kernel.org> |
PCI: Make devm_of_pci_get_host_bridge_resources() static Now that all the PCI host drivers are using pci_parse_request_of_pci_ranges(), make devm_of_pci_get_host_bridge_resources() static. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
|
#
331f6345 |
|
30-Oct-2019 |
Rob Herring <robh@kernel.org> |
PCI: of: Add inbound resource parsing to helpers Extend devm_of_pci_get_host_bridge_resources() and pci_parse_request_of_pci_ranges() helpers to also parse the inbound addresses from DT 'dma-ranges' and populate a resource list with the translated addresses. This will help ensure 'dma-ranges' is always parsed in a consistent way. Tested-by: Srinath Mannam <srinath.mannam@broadcom.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> # for AArdvark Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Will Deacon <will@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Toan Le <toan@os.amperecomputing.com> Cc: Ley Foon Tan <lftan@altera.com> Cc: Tom Joseph <tjoseph@cadence.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in> Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Cc: Simon Horman <horms@verge.net.au> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Michal Simek <michal.simek@xilinx.com> Cc: rfi@lists.rocketboards.org Cc: linux-mediatek@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org
|
#
65991f43 |
|
28-Oct-2019 |
Rob Herring <robh@kernel.org> |
PCI: Export pci_parse_request_of_pci_ranges() pci_parse_request_of_pci_ranges() is missing a module export, so add it. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>
|
#
b071c1fd |
|
07-Aug-2019 |
Lubomir Rintel <lkundrak@v3.sk> |
PCI: OF: Correct of_irq_parse_pci() documentation 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>
|
#
59b099a6 |
|
14-Jan-2019 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
PCI: OF: Initialize dev->fwnode appropriately For PCI devices that have an OF node, set the fwnode as well. This way drivers that rely on fwnode don't need the special case described by commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately"). Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
#
40e5d614 |
|
25-Mar-2019 |
Kishon Vijay Abraham I <kishon@ti.com> |
PCI: OF: Allow of_pci_get_max_link_speed() to be used by PCI Endpoint drivers of_pci_get_max_link_speed() is built only if CONFIG_PCI is enabled. Make of_pci_get_max_link_speed() to be also used by PCI Endpoint controllers with just CONFIG_PCI_ENDPOINT enabled. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9cb30a71 |
|
11-Apr-2019 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
PCI: OF: Support "external-facing" property Set the "untrusted" attribute to any PCIe port that has an "external-facing" device tree property. Any device downstream of this port will inherit the attribute and have only the strictest IOMMU protection. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
83a50d3a |
|
05-Dec-2018 |
Rob Herring <robh@kernel.org> |
PCI: Use of_node_name_eq() for node name comparisons Convert string compares of DT node names to use of_node_name_eq() helper instead. This removes direct access to the node name pointer. Signed-off-by: Rob Herring <robh@kernel.org> [bhelgaas: drop similar rpaphp_core.c change to avoid merge conflict] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2a6db719 |
|
10-Sep-2018 |
Nipun Gupta <nipun.gupta@nxp.com> |
iommu/of: make of_pci_map_rid() available for other devices too iommu-map property is also used by devices with fsl-mc. This patch moves the of_pci_map_rid to generic location, so that it can be used by other busses too. 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no functional change done in the API. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
a5fb9fb0 |
|
18-Jul-2018 |
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> |
PCI: OF: Fix I/O space page leak When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY driver was left disabled, the kernel crashed with this BUG: kernel BUG at lib/ioremap.c:72! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092 Hardware name: Renesas Condor board based on r8a77980 (DT) Workqueue: events deferred_probe_work_func pstate: 80000005 (Nzcv daif -PAN -UAO) pc : ioremap_page_range+0x370/0x3c8 lr : ioremap_page_range+0x40/0x3c8 sp : ffff000008da39e0 x29: ffff000008da39e0 x28: 00e8000000000f07 x27: ffff7dfffee00000 x26: 0140000000000000 x25: ffff7dfffef00000 x24: 00000000000fe100 x23: ffff80007b906000 x22: ffff000008ab8000 x21: ffff000008bb1d58 x20: ffff7dfffef00000 x19: ffff800009c30fb8 x18: 0000000000000001 x17: 00000000000152d0 x16: 00000000014012d0 x15: 0000000000000000 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0720072007300730 x10: 00000000000000ae x9 : 0000000000000000 x8 : ffff7dffff000000 x7 : 0000000000000000 x6 : 0000000000000100 x5 : 0000000000000000 x4 : 000000007b906000 x3 : ffff80007c61a880 x2 : ffff7dfffeefffff x1 : 0000000040000000 x0 : 00e80000fe100f07 Process kworker/0:1 (pid: 39, stack limit = 0x (ptrval)) Call trace: ioremap_page_range+0x370/0x3c8 pci_remap_iospace+0x7c/0xac pci_parse_request_of_pci_ranges+0x13c/0x190 rcar_pcie_probe+0x4c/0xb04 platform_drv_probe+0x50/0xbc driver_probe_device+0x21c/0x308 __device_attach_driver+0x98/0xc8 bus_for_each_drv+0x54/0x94 __device_attach+0xc4/0x12c device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0xb0/0x150 process_one_work+0x12c/0x29c worker_thread+0x200/0x3fc kthread+0x108/0x134 ret_from_fork+0x10/0x18 Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000) It turned out that pci_remap_iospace() wasn't undone when the driver's probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER, the probe was retried, finally causing the BUG due to trying to remap already remapped pages. Introduce the devm_pci_remap_iospace() managed API and replace the pci_remap_iospace() call with it to fix the bug. Fixes: dbf9826d5797 ("PCI: generic: Convert to DT resource parsing API") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [lorenzo.pieralisi@arm.com: split commit/updated the commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
93c9a7f8 |
|
19-Jun-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources() Instead of first allocating and then freeing memory for struct resource in case we cannot parse a PCI resource from the device tree, work against a local struct and kmemdup() it when we decide to go with it. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
|
#
5bd51b35 |
|
15-May-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources() of_pci_get_host_bridge_resources() allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, convert the existing function to a managed version. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by: Joao Pinto <jpinto@synopsys.com> Acked-by: Jingoo Han <jingoohan1@gmail.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
d9c5d5ac |
|
15-May-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Use dev_printk() in of_pci_get_host_bridge_resources() Now that we have a device reference, make use of it for printing. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
|
#
055f87a2 |
|
15-May-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Pass struct device to of_pci_get_host_bridge_resources() Another step towards a managed version of of_pci_get_host_bridge_resources(): Feed in the underlying device, rather than just the OF node. This will allow us to use managed resource allocation internally later on. Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by: Jingoo Han <jingoohan1@gmail.com> CC: Joao Pinto <Joao.Pinto@synopsys.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
126b7de6 |
|
15-May-2018 |
Jan Kiszka <jan.kiszka@siemens.com> |
PCI: Rename of_pci_get_host_bridge_resources() device node parameter We will add a "struct device *dev" parameter to this function soon, so rename the existing "struct device_node *dev" parameter to "dev_node". Tested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
|
#
3a8f77e4 |
|
30-Jan-2018 |
Cyrille Pitchen <cyrille.pitchen@free-electrons.com> |
PCI: OF: Add generic function to parse and allocate PCI resources The patch moves the gen_pci_parse_request_of_pci_ranges() function from drivers/pci/host/pci-host-common.c into drivers/pci/of.c to easily share common source code between PCI host drivers. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@free-electrons.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
736759ef |
|
26-Jan-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate Add SPDX GPL-2.0+ to all PCI files that specified the GPL and allowed either GPL version 2 or any later version. Remove the boilerplate GPL version 2 or later language, relying on the assertion in b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") that the SPDX identifier may be used instead of the full boilerplate text. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7e297843 |
|
04-Jan-2018 |
Rob Herring <robh@kernel.org> |
PCI: Make of_irq_parse_pci() static Now that the DT PCI code is merged into drivers/pci, of_irq_parse_pci() can be static. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Frank Rowand <frowand.list@gmail.com>
|
#
4670d610 |
|
17-Jan-2018 |
Rob Herring <robh@kernel.org> |
PCI: Move OF-related PCI functions into PCI core Following what has been done for other subsystems, move the remaining PCI related code out of drivers/of/ and into drivers/pci/of.c With this, we can kill a few kconfig symbols. Signed-off-by: Rob Herring <robh@kernel.org> [bhelgaas: minor whitespace, comment cleanups] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Frank Rowand <frowand.list@gmail.com>
|
#
c8d17588 |
|
18-Sep-2015 |
Marc Zyngier <maz@kernel.org> |
PCI/MSI: Use of_msi_get_domain instead of open-coded "msi-parent" parsing Now that we have a function that implements the complexity of the "msi-parent" property parsing, switch to that. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
471c931c |
|
28-Jul-2015 |
Marc Zyngier <maz@kernel.org> |
PCI/MSI: Allow msi_domain lookup using the host bridge node A number of platforms do not need to use the msi-parent property, as the host bridge itself provides the MSI controller. Allow this configuration by performing an irq domain lookup based on the host bridge node if it doesn't have a valid msi-parent property. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Yijing Wang <wangyijing@huawei.com> Cc: Ma Jun <majun258@huawei.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Duc Dang <dhdang@apm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1438091186-10244-7-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
b165e2b6 |
|
28-Jul-2015 |
Marc Zyngier <maz@kernel.org> |
PCI/MSI: Add support for OF-provided msi_domain In order to populate the PCI host bridge msi_domain, use the "msi-parent" attribute to lookup a corresponding irq domain. If found, this is our MSI domain. This gets plugged into the core PCI code. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Yijing Wang <wangyijing@huawei.com> Cc: Ma Jun <majun258@huawei.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Duc Dang <dhdang@apm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1438091186-10244-6-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
69566dd8 |
|
16-Aug-2011 |
David Daney <david.daney@cavium.com> |
PCI: OF: Don't crash when bridge parent is NULL. In pcibios_get_phb_of_node(), we will crash while booting if bus->bridge->parent is NULL. Check for this case and avoid dereferencing the NULL pointer. Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
98d9f30c8 |
|
10-Apr-2011 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
pci/of: Match PCI devices to OF nodes dynamically powerpc has two different ways of matching PCI devices to their corresponding OF node (if any) for historical reasons. The ppc64 one does a scan looking for matching bus/dev/fn, while the ppc32 one does a scan looking only for matching dev/fn on each level in order to be agnostic to busses being renumbered (which Linux does on some platforms). This removes both and instead moves the matching code to the PCI core itself. It's the most logical place to do it: when a pci_dev is created, we know the parent and thus can do a single level scan for the matching device_node (if any). The benefit is that all archs now get the matching for free. There's one hook the arch might want to provide to match a PHB bus to its device node. A default weak implementation is provided that looks for the parent device device node, but it's not entirely reliable on powerpc for various reasons so powerpc provides its own. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Michal Simek <monstr@monstr.eu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|