Centos-kernel-stream-9/drivers/pci/of.c

823 lines
22 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0+
/*
* PCI <-> OF mapping helpers
*
* Copyright 2011 IBM Corp.
*/
#define pr_fmt(fmt) "PCI: OF: " fmt
#include <linux/irqdomain.h>
#include <linux/kernel.h>
#include <linux/pci.h>
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
#include "pci.h"
#ifdef CONFIG_PCI
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
/**
* pci_set_of_node - Find and set device's DT device_node
* @dev: the PCI device structure to fill
*
* Returns 0 on success with of_node set or when no device is described in the
* DT. Returns -ENODEV if the device is present, but disabled in the DT.
*/
int pci_set_of_node(struct pci_dev *dev)
{
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
struct device_node *node;
if (!dev->bus->dev.of_node)
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
return 0;
node = of_pci_find_child_device(dev->bus->dev.of_node, dev->devfn);
if (!node)
return 0;
device_set_node(&dev->dev, of_fwnode_handle(node));
PCI: Restrict device disabled status check to DT Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184745 Upstream Status: 0d21e71a91debc87e88437a2cf9c6f34f8bf012f commit 0d21e71a91debc87e88437a2cf9c6f34f8bf012f Author: Rob Herring <robh@kernel.org> Date: Wed Apr 19 14:35:13 2023 -0500 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2023-04-20 22:48:17 +00:00
return 0;
}
void pci_release_of_node(struct pci_dev *dev)
{
of_node_put(dev->dev.of_node);
device_set_node(&dev->dev, NULL);
}
void pci_set_bus_of_node(struct pci_bus *bus)
{
struct device_node *node;
if (bus->self == NULL) {
node = pcibios_get_phb_of_node(bus);
} else {
node = of_node_get(bus->self->dev.of_node);
if (node && of_property_read_bool(node, "external-facing"))
bus->self->external_facing = true;
}
device_set_node(&bus->dev, of_fwnode_handle(node));
}
void pci_release_bus_of_node(struct pci_bus *bus)
{
of_node_put(bus->dev.of_node);
device_set_node(&bus->dev, NULL);
}
struct device_node * __weak pcibios_get_phb_of_node(struct pci_bus *bus)
{
/* This should only be called for PHBs */
if (WARN_ON(bus->self || bus->parent))
return NULL;
/*
* Look for a node pointer in either the intermediary device we
* create above the root bus or its own parent. Normally only
* the later is populated.
*/
if (bus->bridge->of_node)
return of_node_get(bus->bridge->of_node);
if (bus->bridge->parent && bus->bridge->parent->of_node)
return of_node_get(bus->bridge->parent->of_node);
return NULL;
}
struct irq_domain *pci_host_bridge_of_msi_domain(struct pci_bus *bus)
{
#ifdef CONFIG_IRQ_DOMAIN
struct irq_domain *d;
if (!bus->dev.of_node)
return NULL;
/* Start looking for a phandle to an MSI controller. */
d = of_msi_get_domain(&bus->dev, bus->dev.of_node, DOMAIN_BUS_PCI_MSI);
if (d)
return d;
/*
* If we don't have an msi-parent property, look for a domain
* directly attached to the host bridge.
*/
d = irq_find_matching_host(bus->dev.of_node, DOMAIN_BUS_PCI_MSI);
if (d)
return d;
return irq_find_host(bus->dev.of_node);
#else
return NULL;
#endif
}
bool pci_host_of_has_msi_map(struct device *dev)
{
if (dev && dev->of_node)
return of_get_property(dev->of_node, "msi-map", NULL);
return false;
}
static inline int __of_pci_pci_compare(struct device_node *node,
unsigned int data)
{
int devfn;
devfn = of_pci_get_devfn(node);
if (devfn < 0)
return 0;
return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn)
{
struct device_node *node, *node2;
for_each_child_of_node(parent, node) {
if (__of_pci_pci_compare(node, devfn))
return node;
/*
* Some OFs create a parent node "multifunc-device" as
* a fake root for all functions of a multi-function
* device we go down them as well.
*/
if (of_node_name_eq(node, "multifunc-device")) {
for_each_child_of_node(node, node2) {
if (__of_pci_pci_compare(node2, devfn)) {
of_node_put(node);
return node2;
}
}
}
}
return NULL;
}
EXPORT_SYMBOL_GPL(of_pci_find_child_device);
/**
* of_pci_get_devfn() - Get device and function numbers for a device node
* @np: device node
*
* Parses a standard 5-cell PCI resource and returns an 8-bit value that can
* be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
* and function numbers respectively. On error a negative error code is
* returned.
*/
int of_pci_get_devfn(struct device_node *np)
{
u32 reg[5];
int error;
error = of_property_read_u32_array(np, "reg", reg, ARRAY_SIZE(reg));
if (error)
return error;
return (reg[0] >> 8) & 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
/**
* of_pci_parse_bus_range() - parse the bus-range property of a PCI device
* @node: device node
* @res: address to a struct resource to return the bus-range
*
* Returns 0 on success or a negative error-code on failure.
*/
int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
{
u32 bus_range[2];
int error;
error = of_property_read_u32_array(node, "bus-range", bus_range,
ARRAY_SIZE(bus_range));
if (error)
return error;
res->name = node->name;
res->start = bus_range[0];
res->end = bus_range[1];
res->flags = IORESOURCE_BUS;
return 0;
}
EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
/**
* of_get_pci_domain_nr - Find the host bridge domain number
* of the given device node.
* @node: Device tree node with the domain information.
*
* This function will try to obtain the host bridge domain number by finding
* a property called "linux,pci-domain" of the given device node.
*
* Return:
* * > 0 - On success, an associated domain number.
* * -EINVAL - The property "linux,pci-domain" does not exist.
* * -ENODATA - The linux,pci-domain" property does not have value.
* * -EOVERFLOW - Invalid "linux,pci-domain" property value.
*
* Returns the associated domain number from DT in the range [0-0xffff], or
* a negative value if the required property is not found.
*/
int of_get_pci_domain_nr(struct device_node *node)
{
u32 domain;
int error;
error = of_property_read_u32(node, "linux,pci-domain", &domain);
if (error)
return error;
return (u16)domain;
}
EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
/**
* of_pci_preserve_config - Return true if the boot configuration needs to
* be preserved
* @node: Device tree node.
*
* Look for "linux,pci-probe-only" property for a given PCI controller's
* node and return true if found. Also look in the chosen node if the
* property is not found in the given controller's node. Having this
* property ensures that the kernel doesn't reconfigure the BARs and bridge
* windows that are already done by the platform firmware.
*
* Return: true if the property exists; false otherwise.
*/
bool of_pci_preserve_config(struct device_node *node)
{
u32 val = 0;
int ret;
if (!node) {
pr_warn("device node is NULL, trying with of_chosen\n");
node = of_chosen;
}
retry:
ret = of_property_read_u32(node, "linux,pci-probe-only", &val);
if (ret) {
if (ret == -ENODATA || ret == -EOVERFLOW) {
pr_warn("Incorrect value for linux,pci-probe-only in %pOF, ignoring\n",
node);
return false;
}
if (ret == -EINVAL) {
if (node == of_chosen)
return false;
node = of_chosen;
goto retry;
}
}
if (val)
return true;
else
return false;
}
/**
* of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
* is present and valid
*/
void of_pci_check_probe_only(void)
{
if (of_pci_preserve_config(of_chosen))
pci_add_flags(PCI_PROBE_ONLY);
else
pci_clear_flags(PCI_PROBE_ONLY);
}
EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
/**
* devm_of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI
* host bridge resources from DT
* @dev: host bridge device
* @busno: bus number associated with the bridge root bus
* @bus_max: maximum number of buses for this bridge
* @resources: list where the range of resources will be added after DT parsing
* @ib_resources: list where the range of inbound resources (with addresses
* from 'dma-ranges') will be added after DT parsing
* @io_base: pointer to a variable that will contain on return the physical
* address for the start of the I/O range. Can be NULL if the caller doesn't
* expect I/O ranges to be present in the device tree.
*
* This function will parse the "ranges" property of a PCI host bridge device
* node and setup the resource mapping based on its content. It is expected
* that the property conforms with the Power ePAPR document.
*
* It returns zero if the range parsing has been successful or a standard error
* value if it failed.
*/
static int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
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
2019-10-30 22:30:57 +00:00
struct list_head *resources,
struct list_head *ib_resources,
resource_size_t *io_base)
{
struct device_node *dev_node = dev->of_node;
struct resource *res, tmp_res;
struct resource *bus_range;
struct of_pci_range range;
struct of_pci_range_parser parser;
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
2019-10-30 22:30:57 +00:00
const char *range_type;
int err;
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
bus_range = devm_kzalloc(dev, sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
dev_info(dev, " No bus range found for %pOF, using %pR\n",
dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
}
pci_add_resource(resources, bus_range);
/* Check for ranges property */
err = of_pci_range_parser_init(&parser, dev_node);
if (err)
PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges' Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045254 Upstream Status: d277f6e88c88729b1d57d40bbfb00d0bfc961972 commit d277f6e88c88729b1d57d40bbfb00d0bfc961972 Author: Rob Herring <robh@kernel.org> Date: Tue Aug 3 15:56:55 2021 -0600 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2022-01-26 20:07:56 +00:00
return 0;
dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
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
2019-10-30 22:30:57 +00:00
range_type = "IO";
else if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_MEM)
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
2019-10-30 22:30:57 +00:00
range_type = "MEM";
else
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
2019-10-30 22:30:57 +00:00
range_type = "err";
dev_info(dev, " %6s %#012llx..%#012llx -> %#012llx\n",
range_type, range.cpu_addr,
range.cpu_addr + range.size - 1, range.pci_addr);
/*
* If we failed translation or got a zero-sized region
* then skip this range
*/
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
if (err)
continue;
res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto failed;
}
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
dev_err(dev, "I/O range found for %pOF. Please provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
dev_warn(dev, "More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",
dev_node);
*io_base = range.cpu_addr;
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>
2021-06-14 23:04:57 +00:00
} else if (resource_type(res) == IORESOURCE_MEM) {
res->flags &= ~IORESOURCE_MEM_64;
}
pci_add_resource_offset(resources, res, res->start - range.pci_addr);
}
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
2019-10-30 22:30:57 +00:00
/* Check for dma-ranges property */
if (!ib_resources)
return 0;
err = of_pci_dma_range_parser_init(&parser, dev_node);
if (err)
return 0;
dev_dbg(dev, "Parsing dma-ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/*
* If we failed translation or got a zero-sized region
* then skip this range
*/
if (((range.flags & IORESOURCE_TYPE_BITS) != IORESOURCE_MEM) ||
range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
dev_info(dev, " %6s %#012llx..%#012llx -> %#012llx\n",
"IB MEM", range.cpu_addr,
range.cpu_addr + range.size - 1, range.pci_addr);
err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
if (err)
continue;
res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto failed;
}
pci_add_resource_offset(ib_resources, res,
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
2019-10-30 22:30:57 +00:00
res->start - range.pci_addr);
}
return 0;
failed:
pci_free_resource_list(resources);
return err;
}
#if IS_ENABLED(CONFIG_OF_IRQ)
/**
* of_irq_parse_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
* @out_irq: structure of_phandle_args filled by this function
*
* This function resolves the PCI interrupt for a given PCI device. If a
* device-node exists for a given pci_dev, it will use normal OF tree
* walking. If not, it will implement standard swizzling and walk up the
* PCI tree until an device-node is found, at which point it will finish
* resolving using the OF tree walking.
*/
static int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
{
struct device_node *dn, *ppnode = NULL;
struct pci_dev *ppdev;
__be32 laddr[3];
u8 pin;
int rc;
/*
* Check if we have a device node, if yes, fallback to standard
* device tree parsing
*/
dn = pci_device_to_OF_node(pdev);
if (dn) {
rc = of_irq_parse_one(dn, 0, out_irq);
if (!rc)
return rc;
}
/*
* Ok, we don't, time to have fun. Let's start by building up an
* interrupt spec. we assume #interrupt-cells is 1, which is standard
* for PCI. If you do different, then don't use that routine.
*/
rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
if (rc != 0)
goto err;
/* No pin, exit with no error message. */
if (pin == 0)
return -ENODEV;
/* Local interrupt-map in the device node? Use it! */
if (of_property_present(dn, "interrupt-map")) {
pin = pci_swizzle_interrupt_pin(pdev, pin);
ppnode = dn;
}
/* Now we walk up the PCI tree */
while (!ppnode) {
/* Get the pci_dev of our parent */
ppdev = pdev->bus->self;
/* Ouch, it's a host bridge... */
if (ppdev == NULL) {
ppnode = pci_bus_to_OF_node(pdev->bus);
/* No node for host bridge ? give up */
if (ppnode == NULL) {
rc = -EINVAL;
goto err;
}
} else {
/* We found a P2P bridge, check if it has a node */
ppnode = pci_device_to_OF_node(ppdev);
}
/*
* Ok, we have found a parent with a device-node, hand over to
* the OF parsing code.
* We build a unit address from the linux device to be used for
* resolution. Note that we use the linux bus number which may
* not match your firmware bus numbering.
* Fortunately, in most cases, interrupt-map-mask doesn't
* include the bus number as part of the matching.
* You should still be careful about that though if you intend
* to rely on this function (you ship a firmware that doesn't
* create device nodes for all PCI devices).
*/
if (ppnode)
break;
/*
* We can only get here if we hit a P2P bridge with no node;
* let's do standard swizzling and try again
*/
pin = pci_swizzle_interrupt_pin(pdev, pin);
pdev = ppdev;
}
out_irq->np = ppnode;
out_irq->args_count = 1;
out_irq->args[0] = pin;
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);
rc = of_irq_parse_raw(laddr, out_irq);
if (rc)
goto err;
return 0;
err:
if (rc == -ENOENT) {
dev_warn(&pdev->dev,
"%s: no interrupt-map found, INTx interrupts not available\n",
__func__);
pr_warn_once("%s: possibly some PCI slots don't have level triggered interrupts capability\n",
__func__);
} else {
dev_err(&pdev->dev, "%s: failed with rc=%d\n", __func__, rc);
}
return rc;
}
/**
* of_irq_parse_and_map_pci() - Decode a PCI IRQ from the device tree and map to a VIRQ
* @dev: The PCI device needing an IRQ
* @slot: PCI slot number; passed when used as map_irq callback. Unused
* @pin: PCI IRQ pin number; passed when used as map_irq callback. Unused
*
* @slot and @pin are unused, but included in the function so that this
* function can be used directly as the map_irq callback to
* pci_assign_irq() and struct pci_host_bridge.map_irq pointer
*/
int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct of_phandle_args oirq;
int ret;
ret = of_irq_parse_pci(dev, &oirq);
if (ret)
return 0; /* Proper return code 0 == NO_IRQ */
return irq_create_of_mapping(&oirq);
}
EXPORT_SYMBOL_GPL(of_irq_parse_and_map_pci);
#endif /* CONFIG_OF_IRQ */
static int pci_parse_request_of_pci_ranges(struct device *dev,
struct pci_host_bridge *bridge)
{
int err, res_valid = 0;
resource_size_t iobase;
struct resource_entry *win, *tmp;
INIT_LIST_HEAD(&bridge->windows);
INIT_LIST_HEAD(&bridge->dma_ranges);
err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &bridge->windows,
&bridge->dma_ranges, &iobase);
if (err)
return err;
err = devm_request_pci_bus_resources(dev, &bridge->windows);
if (err)
return err;
resource_list_for_each_entry_safe(win, tmp, &bridge->windows) {
struct resource *res = win->res;
switch (resource_type(res)) {
case IORESOURCE_IO:
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>
2018-07-18 20:40:26 +00:00
err = devm_pci_remap_iospace(dev, res, iobase);
if (err) {
dev_warn(dev, "error %d: failed to map resource %pR\n",
err, res);
resource_list_destroy_entry(win);
}
break;
case IORESOURCE_MEM:
res_valid |= !(res->flags & IORESOURCE_PREFETCH);
if (!(res->flags & IORESOURCE_PREFETCH))
if (upper_32_bits(resource_size(res)))
dev_warn(dev, "Memory resource size exceeds max for 32 bits\n");
break;
}
}
if (!res_valid)
dev_warn(dev, "non-prefetchable memory resource required\n");
return 0;
}
int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge *bridge)
{
if (!dev->of_node)
return 0;
bridge->swizzle_irq = pci_common_swizzle;
bridge->map_irq = of_irq_parse_and_map_pci;
return pci_parse_request_of_pci_ranges(dev, bridge);
}
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
#ifdef CONFIG_PCI_DYNAMIC_OF_NODES
void of_pci_remove_node(struct pci_dev *pdev)
{
struct device_node *np;
np = pci_device_to_OF_node(pdev);
if (!np || !of_node_check_flag(np, OF_DYNAMIC))
return;
pdev->dev.of_node = NULL;
of_changeset_revert(np->data);
of_changeset_destroy(np->data);
of_node_put(np);
}
void of_pci_make_dev_node(struct pci_dev *pdev)
{
struct device_node *ppnode, *np = NULL;
const char *pci_type;
struct of_changeset *cset;
const char *name;
int ret;
/*
* If there is already a device tree node linked to this device,
* return immediately.
*/
if (pci_device_to_OF_node(pdev))
return;
/* Check if there is device tree node for parent device */
if (!pdev->bus->self)
ppnode = pdev->bus->dev.of_node;
else
ppnode = pdev->bus->self->dev.of_node;
if (!ppnode)
return;
if (pci_is_bridge(pdev))
pci_type = "pci";
else
pci_type = "dev";
name = kasprintf(GFP_KERNEL, "%s@%x,%x", pci_type,
PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
if (!name)
return;
cset = kmalloc(sizeof(*cset), GFP_KERNEL);
if (!cset)
goto out_free_name;
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
of_changeset_init(cset);
np = of_changeset_create_node(cset, ppnode, name);
if (!np)
goto out_destroy_cset;
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
ret = of_pci_add_properties(pdev, cset, np);
if (ret)
goto out_free_node;
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
ret = of_changeset_apply(cset);
if (ret)
goto out_free_node;
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
np->data = cset;
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
pdev->dev.of_node = np;
kfree(name);
return;
out_free_node:
of_node_put(np);
out_destroy_cset:
of_changeset_destroy(cset);
kfree(cset);
out_free_name:
PCI: Create device tree node for bridge JIRA: https://issues.redhat.com/browse/RHEL-50255 Upstream Status: 407d1a51921e9f28c1bcec647c2205925bd1fdab Conflict(s): Files: drivers/pci/Kconfig, drivers/pci/Makefile Not intending to enable new functionality, thus why the hunks pertaining to the above files were skipped, but keeping up with code changes to help general re-base dependency efforts. Iff PCI_DYNAMIC_OF_NODES is needed in the future, it can be handled when such occurs. commit 407d1a51921e9f28c1bcec647c2205925bd1fdab Author: Lizhi Hou <lizhi.hou@amd.com> Date: Tue Aug 15 10:19:57 2023 -0700 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> Signed-off-by: Myron Stowe <mstowe@redhat.com>
2024-08-15 01:30:53 +00:00
kfree(name);
}
#endif
#endif /* CONFIG_PCI */
/**
* of_pci_get_max_link_speed - Find the maximum link speed of the given device node.
* @node: Device tree node with the maximum link speed information.
*
* This function will try to find the limitation of link speed by finding
* a property called "max-link-speed" of the given device node.
*
* Return:
* * > 0 - On success, a maximum link speed.
* * -EINVAL - Invalid "max-link-speed" property value, or failure to access
* the property of the device tree node.
*
* Returns the associated max link speed from DT, or a negative value if the
* required property is not found or is invalid.
*/
int of_pci_get_max_link_speed(struct device_node *node)
{
u32 max_link_speed;
if (of_property_read_u32(node, "max-link-speed", &max_link_speed) ||
max_link_speed == 0 || max_link_speed > 4)
return -EINVAL;
return max_link_speed;
}
EXPORT_SYMBOL_GPL(of_pci_get_max_link_speed);
/**
* of_pci_get_slot_power_limit - Parses the "slot-power-limit-milliwatt"
* property.
*
* @node: device tree node with the slot power limit information
* @slot_power_limit_value: pointer where the value should be stored in PCIe
* Slot Capabilities Register format
* @slot_power_limit_scale: pointer where the scale should be stored in PCIe
* Slot Capabilities Register format
*
* Returns the slot power limit in milliwatts and if @slot_power_limit_value
* and @slot_power_limit_scale pointers are non-NULL, fills in the value and
* scale in format used by PCIe Slot Capabilities Register.
*
* If the property is not found or is invalid, returns 0.
*/
u32 of_pci_get_slot_power_limit(struct device_node *node,
u8 *slot_power_limit_value,
u8 *slot_power_limit_scale)
{
u32 slot_power_limit_mw;
u8 value, scale;
if (of_property_read_u32(node, "slot-power-limit-milliwatt",
&slot_power_limit_mw))
slot_power_limit_mw = 0;
/* Calculate Slot Power Limit Value and Slot Power Limit Scale */
if (slot_power_limit_mw == 0) {
value = 0x00;
scale = 0;
} else if (slot_power_limit_mw <= 255) {
value = slot_power_limit_mw;
scale = 3;
} else if (slot_power_limit_mw <= 255*10) {
value = slot_power_limit_mw / 10;
scale = 2;
slot_power_limit_mw = slot_power_limit_mw / 10 * 10;
} else if (slot_power_limit_mw <= 255*100) {
value = slot_power_limit_mw / 100;
scale = 1;
slot_power_limit_mw = slot_power_limit_mw / 100 * 100;
} else if (slot_power_limit_mw <= 239*1000) {
value = slot_power_limit_mw / 1000;
scale = 0;
slot_power_limit_mw = slot_power_limit_mw / 1000 * 1000;
} else if (slot_power_limit_mw < 250*1000) {
value = 0xEF;
scale = 0;
slot_power_limit_mw = 239*1000;
} else if (slot_power_limit_mw <= 600*1000) {
value = 0xF0 + (slot_power_limit_mw / 1000 - 250) / 25;
scale = 0;
slot_power_limit_mw = slot_power_limit_mw / (1000*25) * (1000*25);
} else {
value = 0xFE;
scale = 0;
slot_power_limit_mw = 600*1000;
}
if (slot_power_limit_value)
*slot_power_limit_value = value;
if (slot_power_limit_scale)
*slot_power_limit_scale = scale;
return slot_power_limit_mw;
}
EXPORT_SYMBOL_GPL(of_pci_get_slot_power_limit);