[PATCH V13 0/5] Generate device tree node for pci devices

[PATCH V13 0/5] Generate device tree node for pci devices

[Lizhi Hou]

This patch series introduces OF overlay support for PCI devices which
primarily addresses two use cases. First, it provides a data driven method
to describe hardware peripherals that are present in a PCI endpoint and
hence can be accessed by the PCI host. Second, it allows reuse of a OF
compatible driver -- often used in SoC platforms -- in a PCI host based
system.

There are 2 series devices rely on this patch:

  1) Xilinx Alveo Accelerator cards (FPGA based device)
  2) Microchip LAN9662 Ethernet Controller

     Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/

Normally, the PCI core discovers PCI devices and their BARs using the
PCI enumeration process. However, the process does not provide a way to
discover the hardware peripherals that are present in a PCI device, and
which can be accessed through the PCI BARs. Also, the enumeration process
does not provide a way to associate MSI-X vectors of a PCI device with the
hardware peripherals that are present in the device. PCI device drivers
often use header files to describe the hardware peripherals and their
resources as there is no standard data driven way to do so. This patch
series proposes to use flattened device tree blob to describe the
peripherals in a data driven way. Based on previous discussion, using
device tree overlay is the best way to unflatten the blob and populate
platform devices. To use device tree overlay, there are three obvious
problems that need to be resolved.

First, we need to create a base tree for non-DT system such as x86_64. A
patch series has been submitted for this:
https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/

Second, a device tree node corresponding to the PCI endpoint is required
for overlaying the flattened device tree blob for that PCI endpoint.
Because PCI is a self-discoverable bus, a device tree node is usually not
created for PCI devices. This series adds support to generate a device
tree node for a PCI device which advertises itself using PCI quirks
infrastructure.

Third, we need to generate device tree nodes for PCI bridges since a child
PCI endpoint may choose to have a device tree node created.

This patch series is made up of three patches.

The first patch is adding OF interface to create or destroy OF node
dynamically.

The second patch introduces a kernel option, CONFIG_PCI_DYNAMIC_OF_NODES.
When the option is turned on, the kernel will generate device tree nodes
for all PCI bridges unconditionally. The patch also shows how to use the
PCI quirks infrastructure, DECLARE_PCI_FIXUP_FINAL to generate a device
tree node for a device. Specifically, the patch generates a device tree
node for Xilinx Alveo U50 PCIe accelerator device. The generated device
tree nodes do not have any property.

The third patch adds basic properties ('reg', 'compatible' and
'device_type') to the dynamically generated device tree nodes. More
properties can be added in the future.

Here is the example of device tree nodes generated within the ARM64 QEMU.

# lspci -t
-[0000:00]-+-00.0
           +-01.0
           +-03.0-[01-03]----00.0-[02-03]----00.0-[03]----00.0
           +-03.1-[04]--
           \-04.0-[05-06]----00.0-[06]--

Without CONFIG_PCI_DYNAMIC_OF_NODES

# tree /sys/firmware/devicetree/base/pcie@10000000/
/sys/firmware/devicetree/base/pcie@10000000/
|-- #address-cells
|-- #interrupt-cells
|-- #size-cells
|-- bus-range
|-- compatible
|-- device_type
|-- dma-coherent
|-- interrupt-map
|-- interrupt-map-mask
|-- linux,pci-domain
|-- msi-map
|-- name
|-- ranges
`-- reg

With CONFIG_PCI_DYNAMIC_OF_NODES

# tree /sys/firmware/devicetree/base/pcie@10000000/
/sys/firmware/devicetree/base/pcie@10000000/
|-- #address-cells
|-- #interrupt-cells
|-- #size-cells
|-- bus-range
|-- compatible
|-- device_type
|-- dma-coherent
|-- interrupt-map
|-- interrupt-map-mask
|-- linux,pci-domain
|-- msi-map
|-- name
|-- pci@3,0
|   |-- #address-cells
|   |-- #interrupt-cells
|   |-- #size-cells
|   |-- bus-range
|   |-- compatible
|   |-- device_type
|   |-- interrupt-map
|   |-- interrupt-map-mask
|   |-- interrupts
|   |-- pci@0,0
|   |   |-- #address-cells
|   |   |-- #interrupt-cells
|   |   |-- #size-cells
|   |   |-- bus-range
|   |   |-- compatible
|   |   |-- device_type
|   |   |-- interrupt-map
|   |   |-- interrupt-map-mask
|   |   |-- pci@0,0
|   |   |   |-- #address-cells
|   |   |   |-- #interrupt-cells
|   |   |   |-- #size-cells
|   |   |   |-- bus-range
|   |   |   |-- compatible
|   |   |   |-- dev@0,0
|   |   |   |   |-- #address-cells
|   |   |   |   |-- #size-cells
|   |   |   |   |-- compatible
|   |   |   |   |-- ranges
|   |   |   |   `-- reg
|   |   |   |-- device_type
|   |   |   |-- interrupt-map
|   |   |   |-- interrupt-map-mask
|   |   |   |-- ranges
|   |   |   `-- reg
|   |   |-- ranges
|   |   `-- reg
|   |-- ranges
|   `-- reg
|-- pci@3,1
|   |-- #address-cells
|   |-- #interrupt-cells
|   |-- #size-cells
|   |-- bus-range
|   |-- compatible
|   |-- device_type
|   |-- interrupt-map
|   |-- interrupt-map-mask
|   |-- interrupts
|   |-- ranges
|   `-- reg
|-- pci@4,0
|   |-- #address-cells
|   |-- #interrupt-cells
|   |-- #size-cells
|   |-- bus-range
|   |-- compatible
|   |-- device_type
|   |-- interrupt-map
|   |-- interrupt-map-mask
|   |-- pci@0,0
|   |   |-- #address-cells
|   |   |-- #interrupt-cells
|   |   |-- #size-cells
|   |   |-- bus-range
|   |   |-- compatible
|   |   |-- device_type
|   |   |-- interrupt-map
|   |   |-- interrupt-map-mask
|   |   |-- interrupts
|   |   |-- ranges
|   |   `-- reg
|   |-- ranges
|   `-- reg
|-- ranges
`-- reg

Changes since v12:
- Minor fix for kernel test robot warning

Changes since v11:
- Create interrupt related properties

Changes since v10:
- Remove 'dynamic' property

Changes since v9:
- Introduce 'dynamic' property to identify dynamically generated device tree
  node for PCI device
- Added 'bus-range' property to remove dtc warnings
- Minor code review fixes

Changes since v8:
- Added patches to create unit test to verifying address translation
    The test relies on QEMU PCI Test Device, please see
        https://github.com/houlz0507/xoclv2/blob/pci-dt-0329/pci-dt-patch-0329/README
    for test setup
- Minor code review fixes

Changes since v7:
- Modified dynamic node creation interfaces
- Added unittest for new added interfaces

Changes since v6:
- Removed single line wrapper functions
- Added Signed-off-by Clément Léger <clement.leger@bootlin.com>

Changes since v5:
- Fixed code review comments
- Fixed incorrect 'ranges' and 'reg' properties

Changes since RFC v4:
- Fixed code review comments

Changes since RFC v3:
- Split the Xilinx Alveo U50 PCI quirk to a separate patch
- Minor changes in commit description and code comment

Changes since RFC v2:
- Merged patch 3 with patch 2
- Added OF interfaces of_changeset_add_prop_* and use them to create
  properties.
- Added '#address-cells', '#size-cells' and 'ranges' properties.

Changes since RFC v1:
- Added one patch to create basic properties.
- To move DT related code out of PCI subsystem, replaced of_node_alloc()
  with of_create_node()/of_destroy_node()

Lizhi Hou (5):
  of: dynamic: Add interfaces for creating device node dynamically
  PCI: Create device tree node for bridge
  PCI: Add quirks to generate device tree node for Xilinx Alveo U50
  of: overlay: Extend of_overlay_fdt_apply() to specify the target node
  of: unittest: Add pci_dt_testdrv pci driver

 drivers/of/dynamic.c                          | 164 ++++++++
 drivers/of/overlay.c                          |  42 ++-
 drivers/of/unittest-data/Makefile             |   3 +-
 .../of/unittest-data/overlay_pci_node.dtso    |  22 ++
 drivers/of/unittest.c                         | 211 ++++++++++-
 drivers/pci/Kconfig                           |  12 +
 drivers/pci/Makefile                          |   1 +
 drivers/pci/bus.c                             |   2 +
 drivers/pci/of.c                              |  79 ++++
 drivers/pci/of_property.c                     | 355 ++++++++++++++++++
 drivers/pci/pci.h                             |  12 +
 drivers/pci/quirks.c                          |  12 +
 drivers/pci/remove.c                          |   1 +
 include/linux/of.h                            |  25 +-
 14 files changed, 926 insertions(+), 15 deletions(-)
 create mode 100644 drivers/of/unittest-data/overlay_pci_node.dtso
 create mode 100644 drivers/pci/of_property.c

-- 
2.34.1

[PATCH V13 1/5] of: dynamic: Add interfaces for creating device node dynamically

[Lizhi Hou]

of_changeset_create_node() creates device node dynamically and attaches
the newly created node to a changeset.

Expand of_changeset APIs to handle specific types of properties.
    of_changeset_add_prop_string()
    of_changeset_add_prop_string_array()
    of_changeset_add_prop_u32_array()

Signed-off-by: Clément Léger <clement.leger@bootlin.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
---
 drivers/of/dynamic.c  | 164 ++++++++++++++++++++++++++++++++++++++++++
 drivers/of/unittest.c |  19 ++++-
 include/linux/of.h    |  23 ++++++
 3 files changed, 205 insertions(+), 1 deletion(-)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index e311d406b170..9259cebda4d6 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -487,6 +487,38 @@ struct device_node *__of_node_dup(const struct device_node *np,
 	return NULL;
 }
 
+/**
+ * of_changeset_create_node - Dynamically create a device node and attach to
+ * a given changeset.
+ *
+ * @parent: Pointer to parent device node
+ * @full_name: Node full name
+ * @cset: Pointer to changeset
+ *
+ * Return: Pointer to the created device node or NULL in case of an error.
+ */
+struct device_node *of_changeset_create_node(struct device_node *parent,
+					     const char *full_name,
+					     struct of_changeset *cset)
+{
+	struct device_node *np;
+	int ret;
+
+	np = __of_node_dup(NULL, full_name);
+	if (!np)
+		return NULL;
+	np->parent = parent;
+
+	ret = of_changeset_attach_node(cset, np);
+	if (ret) {
+		of_node_put(np);
+		return NULL;
+	}
+
+	return np;
+}
+EXPORT_SYMBOL(of_changeset_create_node);
+
 static void __of_changeset_entry_destroy(struct of_changeset_entry *ce)
 {
 	if (ce->action == OF_RECONFIG_ATTACH_NODE &&
@@ -960,3 +992,135 @@ int of_changeset_action(struct of_changeset *ocs, unsigned long action,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_changeset_action);
+
+static int of_changeset_add_prop_helper(struct of_changeset *ocs,
+					struct device_node *np,
+					const struct property *pp)
+{
+	struct property *new_pp;
+	int ret;
+
+	new_pp = __of_prop_dup(pp, GFP_KERNEL);
+	if (!new_pp)
+		return -ENOMEM;
+
+	ret = of_changeset_add_property(ocs, np, new_pp);
+	if (ret) {
+		kfree(new_pp->name);
+		kfree(new_pp->value);
+		kfree(new_pp);
+	}
+
+	return ret;
+}
+
+/**
+ * of_changeset_add_prop_string - Add a string property to a changeset
+ *
+ * @ocs:	changeset pointer
+ * @np:		device node pointer
+ * @prop_name:	name of the property to be added
+ * @str:	pointer to null terminated string
+ *
+ * Create a string property and add it to a changeset.
+ *
+ * Return: 0 on success, a negative error value in case of an error.
+ */
+int of_changeset_add_prop_string(struct of_changeset *ocs,
+				 struct device_node *np,
+				 const char *prop_name, const char *str)
+{
+	struct property prop;
+
+	prop.name = (char *)prop_name;
+	prop.length = strlen(str) + 1;
+	prop.value = (void *)str;
+
+	return of_changeset_add_prop_helper(ocs, np, &prop);
+}
+EXPORT_SYMBOL_GPL(of_changeset_add_prop_string);
+
+/**
+ * of_changeset_add_prop_string_array - Add a string list property to
+ * a changeset
+ *
+ * @ocs:	changeset pointer
+ * @np:		device node pointer
+ * @prop_name:	name of the property to be added
+ * @str_array:	pointer to an array of null terminated strings
+ * @sz:		number of string array elements
+ *
+ * Create a string list property and add it to a changeset.
+ *
+ * Return: 0 on success, a negative error value in case of an error.
+ */
+int of_changeset_add_prop_string_array(struct of_changeset *ocs,
+				       struct device_node *np,
+				       const char *prop_name,
+				       const char **str_array, size_t sz)
+{
+	struct property prop;
+	int i, ret;
+	char *vp;
+
+	prop.name = (char *)prop_name;
+
+	prop.length = 0;
+	for (i = 0; i < sz; i++)
+		prop.length += strlen(str_array[i]) + 1;
+
+	prop.value = kmalloc(prop.length, GFP_KERNEL);
+	if (!prop.value)
+		return -ENOMEM;
+
+	vp = prop.value;
+	for (i = 0; i < sz; i++) {
+		vp += snprintf(vp, (char *)prop.value + prop.length - vp, "%s",
+			       str_array[i]) + 1;
+	}
+	ret = of_changeset_add_prop_helper(ocs, np, &prop);
+	kfree(prop.value);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_changeset_add_prop_string_array);
+
+/**
+ * of_changeset_add_prop_u32_array - Add a property of 32 bit integers
+ * property to a changeset
+ *
+ * @ocs:	changeset pointer
+ * @np:		device node pointer
+ * @prop_name:	name of the property to be added
+ * @array:	pointer to an array of 32 bit integers
+ * @sz:		number of array elements
+ *
+ * Create a property of 32 bit integers and add it to a changeset.
+ *
+ * Return: 0 on success, a negative error value in case of an error.
+ */
+int of_changeset_add_prop_u32_array(struct of_changeset *ocs,
+				    struct device_node *np,
+				    const char *prop_name,
+				    const u32 *array, size_t sz)
+{
+	struct property prop;
+	__be32 *val;
+	int i, ret;
+
+	val = kcalloc(sz, sizeof(__be32), GFP_KERNEL);
+	if (!val)
+		return -ENOMEM;
+
+	for (i = 0; i < sz; i++)
+		val[i] = cpu_to_be32(array[i]);
+	prop.name = (char *)prop_name;
+	prop.length = sizeof(u32) * sz;
+	prop.value = (void *)val;
+
+	ret = of_changeset_add_prop_helper(ocs, np, &prop);
+	kfree(val);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_changeset_add_prop_u32_array);
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index a406a12eb208..d2b286d32db0 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -802,7 +802,9 @@ static void __init of_unittest_changeset(void)
 	struct property *ppname_n21, pname_n21 = { .name = "name", .length = 3, .value = "n21" };
 	struct property *ppupdate, pupdate = { .name = "prop-update", .length = 5, .value = "abcd" };
 	struct property *ppremove;
-	struct device_node *n1, *n2, *n21, *nchangeset, *nremove, *parent, *np;
+	struct device_node *n1, *n2, *n21, *n22, *nchangeset, *nremove, *parent, *np;
+	static const char * const str_array[] = { "str1", "str2", "str3" };
+	const u32 u32_array[] = { 1, 2, 3 };
 	struct of_changeset chgset;
 
 	n1 = __of_node_dup(NULL, "n1");
@@ -857,6 +859,17 @@ static void __init of_unittest_changeset(void)
 	unittest(!of_changeset_add_property(&chgset, parent, ppadd), "fail add prop prop-add\n");
 	unittest(!of_changeset_update_property(&chgset, parent, ppupdate), "fail update prop\n");
 	unittest(!of_changeset_remove_property(&chgset, parent, ppremove), "fail remove prop\n");
+	n22 = of_changeset_create_node(n2, "n22", &chgset);
+	unittest(n22, "fail create n22\n");
+	unittest(!of_changeset_add_prop_string(&chgset, n22, "prop-str", "abcd"),
+		 "fail add prop prop-str");
+	unittest(!of_changeset_add_prop_string_array(&chgset, n22, "prop-str-array",
+						     (const char **)str_array,
+						     ARRAY_SIZE(str_array)),
+		 "fail add prop prop-str-array");
+	unittest(!of_changeset_add_prop_u32_array(&chgset, n22, "prop-u32-array",
+						  u32_array, ARRAY_SIZE(u32_array)),
+		 "fail add prop prop-u32-array");
 
 	unittest(!of_changeset_apply(&chgset), "apply failed\n");
 
@@ -866,6 +879,9 @@ static void __init of_unittest_changeset(void)
 	unittest((np = of_find_node_by_path("/testcase-data/changeset/n2/n21")),
 		 "'%pOF' not added\n", n21);
 	of_node_put(np);
+	unittest((np = of_find_node_by_path("/testcase-data/changeset/n2/n22")),
+		 "'%pOF' not added\n", n22);
+	of_node_put(np);
 
 	unittest(!of_changeset_revert(&chgset), "revert failed\n");
 
@@ -874,6 +890,7 @@ static void __init of_unittest_changeset(void)
 	of_node_put(n1);
 	of_node_put(n2);
 	of_node_put(n21);
+	of_node_put(n22);
 #endif
 }
 
diff --git a/include/linux/of.h b/include/linux/of.h
index 6ecde0515677..82d0a476ec75 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1580,6 +1580,29 @@ static inline int of_changeset_update_property(struct of_changeset *ocs,
 {
 	return of_changeset_action(ocs, OF_RECONFIG_UPDATE_PROPERTY, np, prop);
 }
+
+struct device_node *of_changeset_create_node(struct device_node *parent,
+					     const char *full_name,
+					     struct of_changeset *cset);
+int of_changeset_add_prop_string(struct of_changeset *ocs,
+				 struct device_node *np,
+				 const char *prop_name, const char *str);
+int of_changeset_add_prop_string_array(struct of_changeset *ocs,
+				       struct device_node *np,
+				       const char *prop_name,
+				       const char **str_array, size_t sz);
+int of_changeset_add_prop_u32_array(struct of_changeset *ocs,
+				    struct device_node *np,
+				    const char *prop_name,
+				    const u32 *array, size_t sz);
+static inline int of_changeset_add_prop_u32(struct of_changeset *ocs,
+					    struct device_node *np,
+					    const char *prop_name,
+					    const u32 val)
+{
+	return of_changeset_add_prop_u32_array(ocs, np, prop_name, &val, 1);
+}
+
 #else /* CONFIG_OF_DYNAMIC */
 static inline int of_reconfig_notifier_register(struct notifier_block *nb)
 {
-- 
2.34.1

[PATCH V13 2/5] PCI: Create device tree node for bridge

[Lizhi Hou]

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>
---
 drivers/pci/Kconfig       |  12 ++
 drivers/pci/Makefile      |   1 +
 drivers/pci/bus.c         |   2 +
 drivers/pci/of.c          |  79 +++++++++
 drivers/pci/of_property.c | 355 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/pci.h         |  12 ++
 drivers/pci/remove.c      |   1 +
 7 files changed, 462 insertions(+)
 create mode 100644 drivers/pci/of_property.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 3c07d8d214b3..49bd09c7dd0a 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -194,6 +194,18 @@ config PCI_HYPERV
 	  The PCI device frontend driver allows the kernel to import arbitrary
 	  PCI devices from a PCI backend to support PCI driver domains.
 
+config PCI_DYNAMIC_OF_NODES
+	bool "Create Device tree nodes for PCI devices"
+	depends on OF
+	select OF_DYNAMIC
+	help
+	  This option enables support for generating device tree nodes for some
+	  PCI devices. Thus, the driver of this kind can load and overlay
+	  flattened device tree for its downstream devices.
+
+	  Once this option is selected, the device tree nodes will be generated
+	  for all PCI bridges.
+
 choice
 	prompt "PCI Express hierarchy optimization setting"
 	default PCIE_BUS_DEFAULT
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 2680e4c92f0a..cc8b4e01e29d 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_PCI_P2PDMA)	+= p2pdma.o
 obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
 obj-$(CONFIG_VGA_ARB)		+= vgaarb.o
 obj-$(CONFIG_PCI_DOE)		+= doe.o
+obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o
 
 # Endpoint library must be initialized before its users
 obj-$(CONFIG_PCI_ENDPOINT)	+= endpoint/
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 5bc81cc0a2de..ab7d06cd0099 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -340,6 +340,8 @@ void pci_bus_add_device(struct pci_dev *dev)
 	 */
 	pcibios_bus_add_device(dev);
 	pci_fixup_device(pci_fixup_final, dev);
+	if (pci_is_bridge(dev))
+		of_pci_make_dev_node(dev);
 	pci_create_sysfs_dev_files(dev);
 	pci_proc_attach_device(dev);
 	pci_bridge_d3_update(dev);
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index e51219f9f523..ec132fbf5c69 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -611,6 +611,85 @@ int devm_of_pci_bridge_init(struct device *dev, struct pci_host_bridge *bridge)
 	return pci_parse_request_of_pci_ranges(dev, bridge);
 }
 
+#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 failed;
+	of_changeset_init(cset);
+
+	np = of_changeset_create_node(ppnode, name, cset);
+	if (!np)
+		goto failed;
+	np->data = cset;
+
+	ret = of_pci_add_properties(pdev, cset, np);
+	if (ret)
+		goto failed;
+
+	ret = of_changeset_apply(cset);
+	if (ret)
+		goto failed;
+
+	pdev->dev.of_node = np;
+	kfree(name);
+
+	return;
+
+failed:
+	if (np)
+		of_node_put(np);
+	kfree(name);
+}
+#endif
+
 #endif /* CONFIG_PCI */
 
 /**
diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c
new file mode 100644
index 000000000000..710ec35ba4a1
--- /dev/null
+++ b/drivers/pci/of_property.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022-2023, Advanced Micro Devices, Inc.
+ */
+
+#include <linux/pci.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include "pci.h"
+
+#define OF_PCI_ADDRESS_CELLS		3
+#define OF_PCI_SIZE_CELLS		2
+#define OF_PCI_MAX_INT_PIN		4
+
+struct of_pci_addr_pair {
+	u32		phys_addr[OF_PCI_ADDRESS_CELLS];
+	u32		size[OF_PCI_SIZE_CELLS];
+};
+
+/*
+ * Each entry in the ranges table is a tuple containing the child address,
+ * the parent address, and the size of the region in the child address space.
+ * Thus, for PCI, in each entry parent address is an address on the primary
+ * side and the child address is the corresponding address on the secondary
+ * side.
+ */
+struct of_pci_range {
+	u32		child_addr[OF_PCI_ADDRESS_CELLS];
+	u32		parent_addr[OF_PCI_ADDRESS_CELLS];
+	u32		size[OF_PCI_SIZE_CELLS];
+};
+
+#define OF_PCI_ADDR_SPACE_IO		0x1
+#define OF_PCI_ADDR_SPACE_MEM32		0x2
+#define OF_PCI_ADDR_SPACE_MEM64		0x3
+
+#define OF_PCI_ADDR_FIELD_NONRELOC	BIT(31)
+#define OF_PCI_ADDR_FIELD_SS		GENMASK(25, 24)
+#define OF_PCI_ADDR_FIELD_PREFETCH	BIT(30)
+#define OF_PCI_ADDR_FIELD_BUS		GENMASK(23, 16)
+#define OF_PCI_ADDR_FIELD_DEV		GENMASK(15, 11)
+#define OF_PCI_ADDR_FIELD_FUNC		GENMASK(10, 8)
+#define OF_PCI_ADDR_FIELD_REG		GENMASK(7, 0)
+
+enum of_pci_prop_compatible {
+	PROP_COMPAT_PCI_VVVV_DDDD,
+	PROP_COMPAT_PCICLASS_CCSSPP,
+	PROP_COMPAT_PCICLASS_CCSS,
+	PROP_COMPAT_NUM,
+};
+
+static void of_pci_set_address(struct pci_dev *pdev, u32 *prop, u64 addr,
+			       u32 reg_num, u32 flags, bool reloc)
+{
+	prop[0] = FIELD_PREP(OF_PCI_ADDR_FIELD_BUS, pdev->bus->number) |
+		FIELD_PREP(OF_PCI_ADDR_FIELD_DEV, PCI_SLOT(pdev->devfn)) |
+		FIELD_PREP(OF_PCI_ADDR_FIELD_FUNC, PCI_FUNC(pdev->devfn));
+	prop[0] |= flags | reg_num;
+	if (!reloc) {
+		prop[0] |= OF_PCI_ADDR_FIELD_NONRELOC;
+		prop[1] = upper_32_bits(addr);
+		prop[2] = lower_32_bits(addr);
+	}
+}
+
+static int of_pci_get_addr_flags(struct resource *res, u32 *flags)
+{
+	u32 ss;
+
+	if (res->flags & IORESOURCE_IO)
+		ss = OF_PCI_ADDR_SPACE_IO;
+	else if (res->flags & IORESOURCE_MEM_64)
+		ss = OF_PCI_ADDR_SPACE_MEM64;
+	else if (res->flags & IORESOURCE_MEM)
+		ss = OF_PCI_ADDR_SPACE_MEM32;
+	else
+		return -EINVAL;
+
+	*flags = 0;
+	if (res->flags & IORESOURCE_PREFETCH)
+		*flags |= OF_PCI_ADDR_FIELD_PREFETCH;
+
+	*flags |= FIELD_PREP(OF_PCI_ADDR_FIELD_SS, ss);
+
+	return 0;
+}
+
+static int of_pci_prop_bus_range(struct pci_dev *pdev,
+				 struct of_changeset *ocs,
+				 struct device_node *np)
+{
+	u32 bus_range[] = { pdev->subordinate->busn_res.start,
+			    pdev->subordinate->busn_res.end };
+
+	return of_changeset_add_prop_u32_array(ocs, np, "bus-range", bus_range,
+					       ARRAY_SIZE(bus_range));
+}
+
+static int of_pci_prop_ranges(struct pci_dev *pdev, struct of_changeset *ocs,
+			      struct device_node *np)
+{
+	struct of_pci_range *rp;
+	struct resource *res;
+	int i, j, ret;
+	u32 flags, num;
+	u64 val64;
+
+	if (pci_is_bridge(pdev)) {
+		num = PCI_BRIDGE_RESOURCE_NUM;
+		res = &pdev->resource[PCI_BRIDGE_RESOURCES];
+	} else {
+		num = PCI_STD_NUM_BARS;
+		res = &pdev->resource[PCI_STD_RESOURCES];
+	}
+
+	rp = kcalloc(num, sizeof(*rp), GFP_KERNEL);
+	if (!rp)
+		return -ENOMEM;
+
+	for (i = 0, j = 0; j < num; j++) {
+		if (!resource_size(&res[j]))
+			continue;
+
+		if (of_pci_get_addr_flags(&res[j], &flags))
+			continue;
+
+		val64 = res[j].start;
+		of_pci_set_address(pdev, rp[i].parent_addr, val64, 0, flags,
+				   false);
+		if (pci_is_bridge(pdev)) {
+			memcpy(rp[i].child_addr, rp[i].parent_addr,
+			       sizeof(rp[i].child_addr));
+		} else {
+			/*
+			 * For endpoint device, the lower 64-bits of child
+			 * address is always zero.
+			 */
+			rp[i].child_addr[0] = j;
+		}
+
+		val64 = resource_size(&res[j]);
+		rp[i].size[0] = upper_32_bits(val64);
+		rp[i].size[1] = lower_32_bits(val64);
+
+		i++;
+	}
+
+	ret = of_changeset_add_prop_u32_array(ocs, np, "ranges", (u32 *)rp,
+					      i * sizeof(*rp) / sizeof(u32));
+	kfree(rp);
+
+	return ret;
+}
+
+static int of_pci_prop_reg(struct pci_dev *pdev, struct of_changeset *ocs,
+			   struct device_node *np)
+{
+	struct of_pci_addr_pair reg = { 0 };
+
+	/* configuration space */
+	of_pci_set_address(pdev, reg.phys_addr, 0, 0, 0, true);
+
+	return of_changeset_add_prop_u32_array(ocs, np, "reg", (u32 *)&reg,
+					       sizeof(reg) / sizeof(u32));
+}
+
+static int of_pci_prop_interrupts(struct pci_dev *pdev,
+				  struct of_changeset *ocs,
+				  struct device_node *np)
+{
+	int ret;
+	u8 pin;
+
+	ret = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
+	if (ret != 0)
+		return ret;
+
+	if (!pin)
+		return 0;
+
+	return of_changeset_add_prop_u32(ocs, np, "interrupts", (u32)pin);
+}
+
+static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
+				struct device_node *np)
+{
+	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
+	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
+	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
+	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
+	struct device_node *pnode;
+	struct pci_dev *child;
+	u32 *int_map, *mapp;
+	int ret;
+	u8 pin;
+
+	pnode = pci_device_to_OF_node(pdev->bus->self);
+	if (!pnode)
+		pnode = pci_bus_to_OF_node(pdev->bus);
+
+	if (!pnode) {
+		pci_err(pdev, "failed to get parent device node");
+		return -EINVAL;
+	}
+
+	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
+	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
+		i = pin - 1;
+		out_irq[i].np = pnode;
+		out_irq[i].args_count = 1;
+		out_irq[i].args[0] = pin;
+		ret = of_irq_parse_raw(laddr, &out_irq[i]);
+		if (ret) {
+			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
+			continue;
+		}
+		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
+					   &addr_sz[i]);
+		if (ret)
+			addr_sz[i] = 0;
+	}
+
+	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
+		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
+			i = pci_swizzle_interrupt_pin(child, pin) - 1;
+			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;
+		}
+	}
+
+	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
+	mapp = int_map;
+
+	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
+		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
+			*mapp = (child->bus->number << 16) |
+				(child->devfn << 8);
+			mapp += OF_PCI_ADDRESS_CELLS;
+			*mapp = pin;
+			mapp++;
+			i = pci_swizzle_interrupt_pin(child, pin) - 1;
+			*mapp = out_irq[i].np->phandle;
+			mapp++;
+			if (addr_sz[i]) {
+				ret = of_property_read_u32_array(out_irq[i].np,
+								 "reg", mapp,
+								 addr_sz[i]);
+				if (ret)
+					goto failed;
+			}
+			mapp += addr_sz[i];
+			memcpy(mapp, out_irq[i].args,
+			       out_irq[i].args_count * sizeof(u32));
+			mapp += out_irq[i].args_count;
+		}
+	}
+
+	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map", int_map,
+					      map_sz);
+	if (ret)
+		goto failed;
+
+	ret = of_changeset_add_prop_u32(ocs, np, "#interrupt-cells", 1);
+	if (ret)
+		goto failed;
+
+	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map-mask",
+					      int_map_mask,
+					      ARRAY_SIZE(int_map_mask));
+	if (ret)
+		goto failed;
+
+	kfree(int_map);
+	return 0;
+
+failed:
+	kfree(int_map);
+	return ret;
+}
+
+static int of_pci_prop_compatible(struct pci_dev *pdev,
+				  struct of_changeset *ocs,
+				  struct device_node *np)
+{
+	const char *compat_strs[PROP_COMPAT_NUM] = { 0 };
+	int i, ret;
+
+	compat_strs[PROP_COMPAT_PCI_VVVV_DDDD] =
+		kasprintf(GFP_KERNEL, "pci%x,%x", pdev->vendor, pdev->device);
+	compat_strs[PROP_COMPAT_PCICLASS_CCSSPP] =
+		kasprintf(GFP_KERNEL, "pciclass,%06x", pdev->class);
+	compat_strs[PROP_COMPAT_PCICLASS_CCSS] =
+		kasprintf(GFP_KERNEL, "pciclass,%04x", pdev->class >> 8);
+
+	ret = of_changeset_add_prop_string_array(ocs, np, "compatible",
+						 compat_strs, PROP_COMPAT_NUM);
+	for (i = 0; i < PROP_COMPAT_NUM; i++)
+		kfree(compat_strs[i]);
+
+	return ret;
+}
+
+int of_pci_add_properties(struct pci_dev *pdev, struct of_changeset *ocs,
+			  struct device_node *np)
+{
+	int ret;
+
+	/*
+	 * The added properties will be released when the
+	 * changeset is destroyed.
+	 */
+	if (pci_is_bridge(pdev)) {
+		ret = of_changeset_add_prop_string(ocs, np, "device_type",
+						   "pci");
+		if (ret)
+			return ret;
+
+		ret = of_pci_prop_bus_range(pdev, ocs, np);
+		if (ret)
+			return ret;
+
+		ret = of_pci_prop_intr_map(pdev, ocs, np);
+		if (ret)
+			return ret;
+	}
+
+	ret = of_pci_prop_ranges(pdev, ocs, np);
+	if (ret)
+		return ret;
+
+	ret = of_changeset_add_prop_u32(ocs, np, "#address-cells",
+					OF_PCI_ADDRESS_CELLS);
+	if (ret)
+		return ret;
+
+	ret = of_changeset_add_prop_u32(ocs, np, "#size-cells",
+					OF_PCI_SIZE_CELLS);
+	if (ret)
+		return ret;
+
+	ret = of_pci_prop_reg(pdev, ocs, np);
+	if (ret)
+		return ret;
+
+	ret = of_pci_prop_compatible(pdev, ocs, np);
+	if (ret)
+		return ret;
+
+	ret = of_pci_prop_interrupts(pdev, ocs, np);
+	if (ret)
+		return ret;
+
+	return 0;
+}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index a4c397434057..ba717bdd700d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -679,6 +679,18 @@ static inline int devm_of_pci_bridge_init(struct device *dev, struct pci_host_br
 
 #endif /* CONFIG_OF */
 
+struct of_changeset;
+
+#ifdef CONFIG_PCI_DYNAMIC_OF_NODES
+void of_pci_make_dev_node(struct pci_dev *pdev);
+void of_pci_remove_node(struct pci_dev *pdev);
+int of_pci_add_properties(struct pci_dev *pdev, struct of_changeset *ocs,
+			  struct device_node *np);
+#else
+static inline void of_pci_make_dev_node(struct pci_dev *pdev) { }
+static inline void of_pci_remove_node(struct pci_dev *pdev) { }
+#endif
+
 #ifdef CONFIG_PCIEAER
 void pci_no_aer(void);
 void pci_aer_init(struct pci_dev *dev);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index d68aee29386b..d749ea8250d6 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -22,6 +22,7 @@ static void pci_stop_dev(struct pci_dev *dev)
 		device_release_driver(&dev->dev);
 		pci_proc_detach_device(dev);
 		pci_remove_sysfs_dev_files(dev);
+		of_pci_remove_node(dev);
 
 		pci_dev_assign_added(dev, false);
 	}
-- 
2.34.1

[PATCH V13 3/5] PCI: Add quirks to generate device tree node for Xilinx Alveo U50

[Lizhi Hou]

The Xilinx Alveo U50 PCI card exposes multiple hardware peripherals on
its PCI BAR. The card firmware provides a flattened device tree to
describe the hardware peripherals on its BARs. This allows U50 driver to
load the flattened device tree and generate the device tree node for
hardware peripherals underneath.

To generate device tree node for U50 card, add PCI quirks to call
of_pci_make_dev_node() for U50.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
---
 drivers/pci/quirks.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 321156ca273d..6c0e7b6bbdd1 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6138,3 +6138,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a2d, dpc_log_size);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a2f, dpc_log_size);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a31, dpc_log_size);
 #endif
+
+/*
+ * For a PCI device with multiple downstream devices, its driver may use
+ * a flattened device tree to describe the downstream devices.
+ * To overlay the flattened device tree, the PCI device and all its ancestor
+ * devices need to have device tree nodes on system base device tree. Thus,
+ * before driver probing, it might need to add a device tree node as the final
+ * fixup.
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
-- 
2.34.1

[PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Lizhi Hou]

Currently, in an overlay fdt fragment, it needs to specify the exact
location in base DT. In another word, when the fdt fragment is generated,
the base DT location for the fragment is already known.

There is new use case that the base DT location is unknown when fdt
fragment is generated. For example, the add-on device provide a fdt
overlay with its firmware to describe its downstream devices. Because it
is add-on device which can be plugged to different systems, its firmware
will not be able to know the overlay location in base DT. Instead, the
device driver will load the overlay fdt and apply it to base DT at runtime.
In this case, of_overlay_fdt_apply() needs to be extended to specify
the target node for device driver to apply overlay fdt.
    int overlay_fdt_apply(..., struct device_node *base);

Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
---
 drivers/of/overlay.c  | 42 +++++++++++++++++++++++++++++++-----------
 drivers/of/unittest.c |  3 ++-
 include/linux/of.h    |  2 +-
 3 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 7feb643f1370..6f3ae30c878d 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -682,9 +682,11 @@ static int build_changeset(struct overlay_changeset *ovcs)
  * 1) "target" property containing the phandle of the target
  * 2) "target-path" property containing the path of the target
  */
-static struct device_node *find_target(struct device_node *info_node)
+static struct device_node *find_target(struct device_node *info_node,
+				       struct device_node *target_base)
 {
 	struct device_node *node;
+	char *target_path;
 	const char *path;
 	u32 val;
 	int ret;
@@ -700,10 +702,23 @@ static struct device_node *find_target(struct device_node *info_node)
 
 	ret = of_property_read_string(info_node, "target-path", &path);
 	if (!ret) {
-		node =  of_find_node_by_path(path);
-		if (!node)
-			pr_err("find target, node: %pOF, path '%s' not found\n",
-			       info_node, path);
+		if (target_base) {
+			target_path = kasprintf(GFP_KERNEL, "%pOF%s", target_base, path);
+			if (!target_path)
+				return NULL;
+			node = of_find_node_by_path(target_path);
+			if (!node) {
+				pr_err("find target, node: %pOF, path '%s' not found\n",
+				       info_node, target_path);
+			}
+			kfree(target_path);
+		} else {
+			node =  of_find_node_by_path(path);
+			if (!node) {
+				pr_err("find target, node: %pOF, path '%s' not found\n",
+				       info_node, path);
+			}
+		}
 		return node;
 	}
 
@@ -715,6 +730,7 @@ static struct device_node *find_target(struct device_node *info_node)
 /**
  * init_overlay_changeset() - initialize overlay changeset from overlay tree
  * @ovcs:		Overlay changeset to build
+ * @target_base:	Point to the target node to apply overlay
  *
  * Initialize @ovcs.  Populate @ovcs->fragments with node information from
  * the top level of @overlay_root.  The relevant top level nodes are the
@@ -725,7 +741,8 @@ static struct device_node *find_target(struct device_node *info_node)
  * detected in @overlay_root.  On error return, the caller of
  * init_overlay_changeset() must call free_overlay_changeset().
  */
-static int init_overlay_changeset(struct overlay_changeset *ovcs)
+static int init_overlay_changeset(struct overlay_changeset *ovcs,
+				  struct device_node *target_base)
 {
 	struct device_node *node, *overlay_node;
 	struct fragment *fragment;
@@ -786,7 +803,7 @@ static int init_overlay_changeset(struct overlay_changeset *ovcs)
 
 		fragment = &fragments[cnt];
 		fragment->overlay = overlay_node;
-		fragment->target = find_target(node);
+		fragment->target = find_target(node, target_base);
 		if (!fragment->target) {
 			of_node_put(fragment->overlay);
 			ret = -EINVAL;
@@ -877,6 +894,7 @@ static void free_overlay_changeset(struct overlay_changeset *ovcs)
  *
  * of_overlay_apply() - Create and apply an overlay changeset
  * @ovcs:	overlay changeset
+ * @base:	point to the target node to apply overlay
  *
  * Creates and applies an overlay changeset.
  *
@@ -900,7 +918,8 @@ static void free_overlay_changeset(struct overlay_changeset *ovcs)
  * the caller of of_overlay_apply() must call free_overlay_changeset().
  */
 
-static int of_overlay_apply(struct overlay_changeset *ovcs)
+static int of_overlay_apply(struct overlay_changeset *ovcs,
+			    struct device_node *base)
 {
 	int ret = 0, ret_revert, ret_tmp;
 
@@ -908,7 +927,7 @@ static int of_overlay_apply(struct overlay_changeset *ovcs)
 	if (ret)
 		goto out;
 
-	ret = init_overlay_changeset(ovcs);
+	ret = init_overlay_changeset(ovcs, base);
 	if (ret)
 		goto out;
 
@@ -952,6 +971,7 @@ static int of_overlay_apply(struct overlay_changeset *ovcs)
  * @overlay_fdt:	pointer to overlay FDT
  * @overlay_fdt_size:	number of bytes in @overlay_fdt
  * @ret_ovcs_id:	pointer for returning created changeset id
+ * @base:		pointer for the target node to apply overlay
  *
  * Creates and applies an overlay changeset.
  *
@@ -967,7 +987,7 @@ static int of_overlay_apply(struct overlay_changeset *ovcs)
  */
 
 int of_overlay_fdt_apply(const void *overlay_fdt, u32 overlay_fdt_size,
-			 int *ret_ovcs_id)
+			 int *ret_ovcs_id, struct device_node *base)
 {
 	void *new_fdt;
 	void *new_fdt_align;
@@ -1037,7 +1057,7 @@ int of_overlay_fdt_apply(const void *overlay_fdt, u32 overlay_fdt_size,
 	}
 	ovcs->overlay_mem = overlay_mem;
 
-	ret = of_overlay_apply(ovcs);
+	ret = of_overlay_apply(ovcs, base);
 	/*
 	 * If of_overlay_apply() error, calling free_overlay_changeset() may
 	 * result in a memory leak if the apply partly succeeded, so do NOT
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index d2b286d32db0..7bff6c4cb653 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3478,7 +3478,8 @@ static int __init overlay_data_apply(const char *overlay_name, int *ovcs_id)
 	if (!size)
 		pr_err("no overlay data for %s\n", overlay_name);
 
-	ret = of_overlay_fdt_apply(info->dtbo_begin, size, &info->ovcs_id);
+	ret = of_overlay_fdt_apply(info->dtbo_begin, size, &info->ovcs_id,
+				   NULL);
 	if (ovcs_id)
 		*ovcs_id = info->ovcs_id;
 	if (ret < 0)
diff --git a/include/linux/of.h b/include/linux/of.h
index 82d0a476ec75..5fe5257a7ab7 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1668,7 +1668,7 @@ struct of_overlay_notify_data {
 #ifdef CONFIG_OF_OVERLAY
 
 int of_overlay_fdt_apply(const void *overlay_fdt, u32 overlay_fdt_size,
-			 int *ovcs_id);
+			 int *ovcs_id, struct device_node *target_base);
 int of_overlay_remove(int *ovcs_id);
 int of_overlay_remove_all(void);
 
-- 
2.34.1

[PATCH V13 5/5] of: unittest: Add pci_dt_testdrv pci driver

[Lizhi Hou]

pci_dt_testdrv is bound to QEMU PCI Test Device. It reads
overlay_pci_node fdt fragment and apply it to Test Device. Then it
calls of_platform_default_populate() to populate the platform
devices.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
---
 drivers/of/unittest-data/Makefile             |   3 +-
 .../of/unittest-data/overlay_pci_node.dtso    |  22 ++
 drivers/of/unittest.c                         | 189 ++++++++++++++++++
 drivers/pci/quirks.c                          |   1 +
 4 files changed, 214 insertions(+), 1 deletion(-)
 create mode 100644 drivers/of/unittest-data/overlay_pci_node.dtso

diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
index ea5f4da68e23..1aa875088159 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -32,7 +32,8 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.dtbo.o \
 			    overlay_gpio_02b.dtbo.o \
 			    overlay_gpio_03.dtbo.o \
 			    overlay_gpio_04a.dtbo.o \
-			    overlay_gpio_04b.dtbo.o
+			    overlay_gpio_04b.dtbo.o \
+			    overlay_pci_node.dtbo.o
 
 # enable creation of __symbols__ node
 DTC_FLAGS_overlay += -@
diff --git a/drivers/of/unittest-data/overlay_pci_node.dtso b/drivers/of/unittest-data/overlay_pci_node.dtso
new file mode 100644
index 000000000000..c05e52e9e44a
--- /dev/null
+++ b/drivers/of/unittest-data/overlay_pci_node.dtso
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+/ {
+	fragment@0 {
+		target-path="";
+		__overlay__ {
+			#address-cells = <3>;
+			#size-cells = <2>;
+			pci-ep-bus@0 {
+				compatible = "simple-bus";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x0 0x0 0x0 0x1000>;
+				reg = <0 0 0 0 0>;
+				unittest-pci@100 {
+					compatible = "unittest-pci";
+					reg = <0x100 0x200>;
+				};
+			};
+		};
+	};
+};
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 7bff6c4cb653..fef46a9a5e81 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 #include <linux/device.h>
 #include <linux/platform_device.h>
+#include <linux/pci.h>
 #include <linux/kernel.h>
 
 #include <linux/i2c.h>
@@ -3324,6 +3325,7 @@ OVERLAY_INFO_EXTERN(overlay_gpio_02b);
 OVERLAY_INFO_EXTERN(overlay_gpio_03);
 OVERLAY_INFO_EXTERN(overlay_gpio_04a);
 OVERLAY_INFO_EXTERN(overlay_gpio_04b);
+OVERLAY_INFO_EXTERN(overlay_pci_node);
 OVERLAY_INFO_EXTERN(overlay_bad_add_dup_node);
 OVERLAY_INFO_EXTERN(overlay_bad_add_dup_prop);
 OVERLAY_INFO_EXTERN(overlay_bad_phandle);
@@ -3359,6 +3361,7 @@ static struct overlay_info overlays[] = {
 	OVERLAY_INFO(overlay_gpio_03, 0),
 	OVERLAY_INFO(overlay_gpio_04a, 0),
 	OVERLAY_INFO(overlay_gpio_04b, 0),
+	OVERLAY_INFO(overlay_pci_node, 0),
 	OVERLAY_INFO(overlay_bad_add_dup_node, -EINVAL),
 	OVERLAY_INFO(overlay_bad_add_dup_prop, -EINVAL),
 	OVERLAY_INFO(overlay_bad_phandle, -EINVAL),
@@ -3729,6 +3732,191 @@ static inline __init void of_unittest_overlay_high_level(void) {}
 
 #endif
 
+#ifdef CONFIG_PCI_DYNAMIC_OF_NODES
+
+static int of_unittest_pci_dev_num;
+static int of_unittest_pci_child_num;
+
+/*
+ * PCI device tree node test driver
+ */
+static const struct pci_device_id testdrv_pci_ids[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_REDHAT, 0x5), }, /* PCI_VENDOR_ID_REDHAT */
+	{ 0, }
+};
+
+static int testdrv_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+	struct overlay_info *info;
+	struct device_node *dn;
+	int ret, ovcs_id;
+	u32 size;
+
+	dn = pdev->dev.of_node;
+	if (!dn) {
+		dev_err(&pdev->dev, "does not find bus endpoint");
+		return -EINVAL;
+	}
+
+	for (info = overlays; info && info->name; info++) {
+		if (!strcmp(info->name, "overlay_pci_node"))
+			break;
+	}
+	if (!info || !info->name) {
+		dev_err(&pdev->dev, "no overlay data for overlay_pci_node");
+		return -ENODEV;
+	}
+
+	size = info->dtbo_end - info->dtbo_begin;
+	ret = of_overlay_fdt_apply(info->dtbo_begin, size, &ovcs_id, dn);
+	of_node_put(dn);
+	if (ret)
+		return ret;
+
+	of_platform_default_populate(dn, NULL, &pdev->dev);
+	pci_set_drvdata(pdev, (void *)(uintptr_t)ovcs_id);
+
+	return 0;
+}
+
+static void testdrv_remove(struct pci_dev *pdev)
+{
+	int ovcs_id = (int)(uintptr_t)pci_get_drvdata(pdev);
+
+	of_platform_depopulate(&pdev->dev);
+	of_overlay_remove(&ovcs_id);
+}
+
+static struct pci_driver testdrv_driver = {
+	.name = "pci_dt_testdrv",
+	.id_table = testdrv_pci_ids,
+	.probe = testdrv_probe,
+	.remove = testdrv_remove,
+};
+
+static int unittest_pci_probe(struct platform_device *pdev)
+{
+	struct resource *res;
+	struct device *dev;
+	u64 exp_addr;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	dev = &pdev->dev;
+	while (dev && !dev_is_pci(dev))
+		dev = dev->parent;
+	if (!dev) {
+		pr_err("unable to find parent device\n");
+		return -ENODEV;
+	}
+
+	exp_addr = pci_resource_start(to_pci_dev(dev), 0) + 0x100;
+	unittest(res->start == exp_addr, "Incorrect translated address %llx, expected %llx\n",
+		 (u64)res->start, exp_addr);
+
+	of_unittest_pci_child_num++;
+
+	return 0;
+}
+
+static const struct of_device_id unittest_pci_of_match[] = {
+	{ .compatible = "unittest-pci" },
+	{ }
+};
+
+static struct platform_driver unittest_pci_driver = {
+	.probe = unittest_pci_probe,
+	.driver = {
+		.name = "unittest-pci",
+		.of_match_table = unittest_pci_of_match,
+	},
+};
+
+static int of_unittest_pci_node_verify(struct pci_dev *pdev, bool add)
+{
+	struct device_node *pnp, *np = NULL;
+	struct device *child_dev;
+	char *path = NULL;
+	const __be32 *reg;
+	int rc = 0;
+
+	pnp = pdev->dev.of_node;
+	unittest(pnp, "Failed creating PCI dt node\n");
+	if (!pnp)
+		return -ENODEV;
+
+	if (add) {
+		path = kasprintf(GFP_KERNEL, "%pOF/pci-ep-bus@0/unittest-pci@100", pnp);
+		np = of_find_node_by_path(path);
+		unittest(np, "Failed to get unittest-pci node under PCI node\n");
+		if (!np) {
+			rc = -ENODEV;
+			goto failed;
+		}
+
+		reg = of_get_property(np, "reg", NULL);
+		unittest(reg, "Failed to get reg property\n");
+		if (!reg)
+			rc = -ENODEV;
+	} else {
+		path = kasprintf(GFP_KERNEL, "%pOF/pci-ep-bus@0", pnp);
+		np = of_find_node_by_path(path);
+		unittest(!np, "Child device tree node is not removed\n");
+		child_dev = device_find_any_child(&pdev->dev);
+		unittest(!child_dev, "Child device is not removed\n");
+	}
+
+failed:
+	kfree(path);
+	if (np)
+		of_node_put(np);
+
+	return rc;
+}
+
+static void __init of_unittest_pci_node(void)
+{
+	struct pci_dev *pdev = NULL;
+	int rc;
+
+	rc = pci_register_driver(&testdrv_driver);
+	unittest(!rc, "Failed to register pci test driver; rc = %d\n", rc);
+	if (rc)
+		return;
+
+	rc = platform_driver_register(&unittest_pci_driver);
+	if (unittest(!rc, "Failed to register unittest pci driver\n")) {
+		pci_unregister_driver(&testdrv_driver);
+		return;
+	}
+
+	while ((pdev = pci_get_device(PCI_VENDOR_ID_REDHAT, 0x5, pdev)) != NULL) {
+		of_unittest_pci_node_verify(pdev, true);
+		of_unittest_pci_dev_num++;
+	}
+	if (pdev)
+		pci_dev_put(pdev);
+
+	unittest(of_unittest_pci_dev_num,
+		 "No test PCI device been found. Please run QEMU with '-device pci-testdev'\n");
+	unittest(of_unittest_pci_dev_num == of_unittest_pci_child_num,
+		 "Child device number %d is not expected %d", of_unittest_pci_child_num,
+		 of_unittest_pci_dev_num);
+
+	platform_driver_unregister(&unittest_pci_driver);
+	pci_unregister_driver(&testdrv_driver);
+
+	while ((pdev = pci_get_device(PCI_VENDOR_ID_REDHAT, 0x5, pdev)) != NULL)
+		of_unittest_pci_node_verify(pdev, false);
+	if (pdev)
+		pci_dev_put(pdev);
+}
+#else
+static void __init of_unittest_pci_node(void) { }
+#endif
+
 static int __init of_unittest(void)
 {
 	struct device_node *np;
@@ -3779,6 +3967,7 @@ static int __init of_unittest(void)
 	of_unittest_platform_populate();
 	of_unittest_overlay();
 	of_unittest_lifecycle();
+	of_unittest_pci_node();
 
 	/* Double check linkage after removing testcase data */
 	of_unittest_check_tree_linkage();
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6c0e7b6bbdd1..a8223ff52939 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6149,3 +6149,4 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a31, dpc_log_size);
  */
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT, 0x0005, of_pci_make_dev_node);
-- 
2.34.1

Re: [PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Geert Uytterhoeven]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

 	Hi Lizhi,

On Tue, 15 Aug 2023, Lizhi Hou wrote:
> Currently, in an overlay fdt fragment, it needs to specify the exact
> location in base DT. In another word, when the fdt fragment is generated,
> the base DT location for the fragment is already known.
>
> There is new use case that the base DT location is unknown when fdt
> fragment is generated. For example, the add-on device provide a fdt
> overlay with its firmware to describe its downstream devices. Because it
> is add-on device which can be plugged to different systems, its firmware
> will not be able to know the overlay location in base DT. Instead, the
> device driver will load the overlay fdt and apply it to base DT at runtime.
> In this case, of_overlay_fdt_apply() needs to be extended to specify
> the target node for device driver to apply overlay fdt.
>    int overlay_fdt_apply(..., struct device_node *base);
>
> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>

Thanks for your patch, which is now commit 47284862bfc7fd56 ("of:
overlay: Extend of_overlay_fdt_apply() in dt-rh/for-next.

> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -715,6 +730,7 @@ static struct device_node *find_target(struct device_node *info_node)
> /**
>  * init_overlay_changeset() - initialize overlay changeset from overlay tree
>  * @ovcs:		Overlay changeset to build
> + * @target_base:	Point to the target node to apply overlay
>  *
>  * Initialize @ovcs.  Populate @ovcs->fragments with node information from
>  * the top level of @overlay_root.  The relevant top level nodes are the

As an overlay can contain one or more fragments, this means the
base (when specified) will be applied to all fragments, and will thus
override the target-path properties in all fragments.

However, for the use case of an overlay that you can plug into
a random location (and of which there can be multiple instances),
there can really be only a single fragment.  Even nodes that typically
live at the root level (e.g. gpio-leds or gpio-keys) must be inserted
below the specified location, to avoid conflicts.

Hence:
   1. Should init_overlay_changeset() return -EINVAL if target_base is
      specified, and there is more than one fragment?

   2. Should there be a convention about the target-path property's
      contents in the original overlay?
      drivers/of/unittest-data/overlay_pci_node.dtso in "[PATCH V13 5/5]
      of: unittest: Add pci_dt_testdrv pci driver" uses

          target-path="";

      which cannot be represented when using sugar syntax.
      "/" should work fine, though.

Thanks!

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds

Re: [PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Lizhi Hou]

Hi Geert,

Thanks for reviewing the patch. I add my comment in-line.

On 8/24/23 01:31, Geert Uytterhoeven wrote:
>     Hi Lizhi,
>
> On Tue, 15 Aug 2023, Lizhi Hou wrote:
>> Currently, in an overlay fdt fragment, it needs to specify the exact
>> location in base DT. In another word, when the fdt fragment is 
>> generated,
>> the base DT location for the fragment is already known.
>>
>> There is new use case that the base DT location is unknown when fdt
>> fragment is generated. For example, the add-on device provide a fdt
>> overlay with its firmware to describe its downstream devices. Because it
>> is add-on device which can be plugged to different systems, its firmware
>> will not be able to know the overlay location in base DT. Instead, the
>> device driver will load the overlay fdt and apply it to base DT at 
>> runtime.
>> In this case, of_overlay_fdt_apply() needs to be extended to specify
>> the target node for device driver to apply overlay fdt.
>>    int overlay_fdt_apply(..., struct device_node *base);
>>
>> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
>
> Thanks for your patch, which is now commit 47284862bfc7fd56 ("of:
> overlay: Extend of_overlay_fdt_apply() in dt-rh/for-next.
>
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -715,6 +730,7 @@ static struct device_node *find_target(struct 
>> device_node *info_node)
>> /**
>>  * init_overlay_changeset() - initialize overlay changeset from 
>> overlay tree
>>  * @ovcs:        Overlay changeset to build
>> + * @target_base:    Point to the target node to apply overlay
>>  *
>>  * Initialize @ovcs.  Populate @ovcs->fragments with node information 
>> from
>>  * the top level of @overlay_root.  The relevant top level nodes are the
>
> As an overlay can contain one or more fragments, this means the
> base (when specified) will be applied to all fragments, and will thus
> override the target-path properties in all fragments.
>
> However, for the use case of an overlay that you can plug into
> a random location (and of which there can be multiple instances),
> there can really be only a single fragment.  Even nodes that typically
> live at the root level (e.g. gpio-leds or gpio-keys) must be inserted
> below the specified location, to avoid conflicts.
>
> Hence:
>   1. Should init_overlay_changeset() return -EINVAL if target_base is
>      specified, and there is more than one fragment?

Maybe allowing more than one fragment make the interface more generic?  
For example, it could support the use case that multiple fragments share 
the same base node.

Currently, the fragment overlay path is "base node path" + "fragment 
target path". Thus, for the structure:

/a/b/c/fragment0

/a/b/d/fagment1

It can be two fragments in one fdt by using

   base node path = /a/b

   fragment0 target path = /c

   fragment1 target path = /d

I am not sure if there will be this kind of use case or not. And I think 
it would not be hurt to allow that.

>
>   2. Should there be a convention about the target-path property's
>      contents in the original overlay?
>      drivers/of/unittest-data/overlay_pci_node.dtso in "[PATCH V13 5/5]
>      of: unittest: Add pci_dt_testdrv pci driver" uses
>
>          target-path="";
>
>      which cannot be represented when using sugar syntax.
>      "/" should work fine, though.

Because the fragment overlay path is "base node path" + "fragment target 
path", I may add code to check if "fragment target patch is '/' and 
ignore it. I think that would support sugar syntax with only '/' specified.


Thanks,

Lizhi

>
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a 
> hacker. But
> when I'm talking to journalists I just say "programmer" or something 
> like that.
>                                 -- Linus Torvalds

Re: [PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Rob Herring]

On Thu, Aug 24, 2023 at 1:40 PM Lizhi Hou <lizhi.hou@amd.com> wrote:
>
> Hi Geert,
>
> Thanks for reviewing the patch. I add my comment in-line.
>
> On 8/24/23 01:31, Geert Uytterhoeven wrote:
> >     Hi Lizhi,
> >
> > On Tue, 15 Aug 2023, Lizhi Hou wrote:
> >> Currently, in an overlay fdt fragment, it needs to specify the exact
> >> location in base DT. In another word, when the fdt fragment is
> >> generated,
> >> the base DT location for the fragment is already known.
> >>
> >> There is new use case that the base DT location is unknown when fdt
> >> fragment is generated. For example, the add-on device provide a fdt
> >> overlay with its firmware to describe its downstream devices. Because it
> >> is add-on device which can be plugged to different systems, its firmware
> >> will not be able to know the overlay location in base DT. Instead, the
> >> device driver will load the overlay fdt and apply it to base DT at
> >> runtime.
> >> In this case, of_overlay_fdt_apply() needs to be extended to specify
> >> the target node for device driver to apply overlay fdt.
> >>    int overlay_fdt_apply(..., struct device_node *base);
> >>
> >> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
> >
> > Thanks for your patch, which is now commit 47284862bfc7fd56 ("of:
> > overlay: Extend of_overlay_fdt_apply() in dt-rh/for-next.
> >
> >> --- a/drivers/of/overlay.c
> >> +++ b/drivers/of/overlay.c
> >> @@ -715,6 +730,7 @@ static struct device_node *find_target(struct
> >> device_node *info_node)
> >> /**
> >>  * init_overlay_changeset() - initialize overlay changeset from
> >> overlay tree
> >>  * @ovcs:        Overlay changeset to build
> >> + * @target_base:    Point to the target node to apply overlay
> >>  *
> >>  * Initialize @ovcs.  Populate @ovcs->fragments with node information
> >> from
> >>  * the top level of @overlay_root.  The relevant top level nodes are the
> >
> > As an overlay can contain one or more fragments, this means the
> > base (when specified) will be applied to all fragments, and will thus
> > override the target-path properties in all fragments.
> >
> > However, for the use case of an overlay that you can plug into
> > a random location (and of which there can be multiple instances),
> > there can really be only a single fragment.  Even nodes that typically
> > live at the root level (e.g. gpio-leds or gpio-keys) must be inserted
> > below the specified location, to avoid conflicts.

It's not a random location, but a location where the full path and/or
unit-address are not known. What we should know is the node's base
name and compatible.

I think we can assume for this kind of usecase, that adding nodes only
under a defined base node is allowed. This is also just the
restriction I've asked for every time more general support of applying
overlays by the kernel is requested. The add-on card, hat, cape, etc.
usecases should all be applied downstream of some node.

> >
> > Hence:
> >   1. Should init_overlay_changeset() return -EINVAL if target_base is
> >      specified, and there is more than one fragment?
>
> Maybe allowing more than one fragment make the interface more generic?
> For example, it could support the use case that multiple fragments share
> the same base node.
>
> Currently, the fragment overlay path is "base node path" + "fragment
> target path". Thus, for the structure:
>
> /a/b/c/fragment0
>
> /a/b/d/fagment1
>
> It can be two fragments in one fdt by using
>
>    base node path = /a/b
>
>    fragment0 target path = /c
>
>    fragment1 target path = /d
>
> I am not sure if there will be this kind of use case or not. And I think
> it would not be hurt to allow that.
>
> >
> >   2. Should there be a convention about the target-path property's
> >      contents in the original overlay?
> >      drivers/of/unittest-data/overlay_pci_node.dtso in "[PATCH V13 5/5]
> >      of: unittest: Add pci_dt_testdrv pci driver" uses
> >
> >          target-path="";
> >
> >      which cannot be represented when using sugar syntax.
> >      "/" should work fine, though.
>
> Because the fragment overlay path is "base node path" + "fragment target
> path", I may add code to check if "fragment target patch is '/' and
> ignore it. I think that would support sugar syntax with only '/' specified.

Note that "/" is also a valid target path. I think it would be better
to have a form that's obviously not a fixed path. I think what's
needed is to be able to specify just the nodename with or without the
unit-address. I don't know if dtc will accept that.

As labels are part of the ABI with overlays, a target label could also
work. Though the kernel would have to learn to add new labels or get a
label path from another source as a label doesn't exist on a generated
node.

Rob

Re: [PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Geert Uytterhoeven]

Hi Lizhi,

On Thu, Aug 24, 2023 at 8:40 PM Lizhi Hou <lizhi.hou@amd.com> wrote:
> On 8/24/23 01:31, Geert Uytterhoeven wrote:
> > On Tue, 15 Aug 2023, Lizhi Hou wrote:
> >> Currently, in an overlay fdt fragment, it needs to specify the exact
> >> location in base DT. In another word, when the fdt fragment is
> >> generated,
> >> the base DT location for the fragment is already known.
> >>
> >> There is new use case that the base DT location is unknown when fdt
> >> fragment is generated. For example, the add-on device provide a fdt
> >> overlay with its firmware to describe its downstream devices. Because it
> >> is add-on device which can be plugged to different systems, its firmware
> >> will not be able to know the overlay location in base DT. Instead, the
> >> device driver will load the overlay fdt and apply it to base DT at
> >> runtime.
> >> In this case, of_overlay_fdt_apply() needs to be extended to specify
> >> the target node for device driver to apply overlay fdt.
> >>    int overlay_fdt_apply(..., struct device_node *base);
> >>
> >> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
> >
> > Thanks for your patch, which is now commit 47284862bfc7fd56 ("of:
> > overlay: Extend of_overlay_fdt_apply() in dt-rh/for-next.
> >
> >> --- a/drivers/of/overlay.c
> >> +++ b/drivers/of/overlay.c
> >> @@ -715,6 +730,7 @@ static struct device_node *find_target(struct
> >> device_node *info_node)
> >> /**
> >>  * init_overlay_changeset() - initialize overlay changeset from
> >> overlay tree
> >>  * @ovcs:        Overlay changeset to build
> >> + * @target_base:    Point to the target node to apply overlay
> >>  *
> >>  * Initialize @ovcs.  Populate @ovcs->fragments with node information
> >> from
> >>  * the top level of @overlay_root.  The relevant top level nodes are the
> >
> > As an overlay can contain one or more fragments, this means the
> > base (when specified) will be applied to all fragments, and will thus
> > override the target-path properties in all fragments.
> >
> > However, for the use case of an overlay that you can plug into
> > a random location (and of which there can be multiple instances),
> > there can really be only a single fragment.  Even nodes that typically
> > live at the root level (e.g. gpio-leds or gpio-keys) must be inserted
> > below the specified location, to avoid conflicts.
> >
> > Hence:
> >   1. Should init_overlay_changeset() return -EINVAL if target_base is
> >      specified, and there is more than one fragment?
>
> Maybe allowing more than one fragment make the interface more generic?
> For example, it could support the use case that multiple fragments share
> the same base node.
>
> Currently, the fragment overlay path is "base node path" + "fragment
> target path". Thus, for the structure:

Oh, I had missed that the "fragment target path" is appended,
and thought it was just overridden.

> /a/b/c/fragment0
>
> /a/b/d/fagment1
>
> It can be two fragments in one fdt by using
>
>    base node path = /a/b
>
>    fragment0 target path = /c
>
>    fragment1 target path = /d
>
> I am not sure if there will be this kind of use case or not. And I think
> it would not be hurt to allow that.

Is there a need for that? Both c and d can be handled as subnodes
in a single fragment if the target path is empty (and see below).

> >   2. Should there be a convention about the target-path property's
> >      contents in the original overlay?
> >      drivers/of/unittest-data/overlay_pci_node.dtso in "[PATCH V13 5/5]
> >      of: unittest: Add pci_dt_testdrv pci driver" uses
> >
> >          target-path="";
> >
> >      which cannot be represented when using sugar syntax.
> >      "/" should work fine, though.
>
> Because the fragment overlay path is "base node path" + "fragment target
> path", I may add code to check if "fragment target patch is '/' and
> ignore it. I think that would support sugar syntax with only '/' specified.

That makes sense.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH V13 4/5] of: overlay: Extend of_overlay_fdt_apply() to specify the target node

[Lizhi Hou]

On 8/25/23 00:25, Geert Uytterhoeven wrote:
> Hi Lizhi,
>
> On Thu, Aug 24, 2023 at 8:40 PM Lizhi Hou <lizhi.hou@amd.com> wrote:
>> On 8/24/23 01:31, Geert Uytterhoeven wrote:
>>> On Tue, 15 Aug 2023, Lizhi Hou wrote:
>>>> Currently, in an overlay fdt fragment, it needs to specify the exact
>>>> location in base DT. In another word, when the fdt fragment is
>>>> generated,
>>>> the base DT location for the fragment is already known.
>>>>
>>>> There is new use case that the base DT location is unknown when fdt
>>>> fragment is generated. For example, the add-on device provide a fdt
>>>> overlay with its firmware to describe its downstream devices. Because it
>>>> is add-on device which can be plugged to different systems, its firmware
>>>> will not be able to know the overlay location in base DT. Instead, the
>>>> device driver will load the overlay fdt and apply it to base DT at
>>>> runtime.
>>>> In this case, of_overlay_fdt_apply() needs to be extended to specify
>>>> the target node for device driver to apply overlay fdt.
>>>>     int overlay_fdt_apply(..., struct device_node *base);
>>>>
>>>> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
>>> Thanks for your patch, which is now commit 47284862bfc7fd56 ("of:
>>> overlay: Extend of_overlay_fdt_apply() in dt-rh/for-next.
>>>
>>>> --- a/drivers/of/overlay.c
>>>> +++ b/drivers/of/overlay.c
>>>> @@ -715,6 +730,7 @@ static struct device_node *find_target(struct
>>>> device_node *info_node)
>>>> /**
>>>>   * init_overlay_changeset() - initialize overlay changeset from
>>>> overlay tree
>>>>   * @ovcs:        Overlay changeset to build
>>>> + * @target_base:    Point to the target node to apply overlay
>>>>   *
>>>>   * Initialize @ovcs.  Populate @ovcs->fragments with node information
>>>> from
>>>>   * the top level of @overlay_root.  The relevant top level nodes are the
>>> As an overlay can contain one or more fragments, this means the
>>> base (when specified) will be applied to all fragments, and will thus
>>> override the target-path properties in all fragments.
>>>
>>> However, for the use case of an overlay that you can plug into
>>> a random location (and of which there can be multiple instances),
>>> there can really be only a single fragment.  Even nodes that typically
>>> live at the root level (e.g. gpio-leds or gpio-keys) must be inserted
>>> below the specified location, to avoid conflicts.
>>>
>>> Hence:
>>>    1. Should init_overlay_changeset() return -EINVAL if target_base is
>>>       specified, and there is more than one fragment?
>> Maybe allowing more than one fragment make the interface more generic?
>> For example, it could support the use case that multiple fragments share
>> the same base node.
>>
>> Currently, the fragment overlay path is "base node path" + "fragment
>> target path". Thus, for the structure:
> Oh, I had missed that the "fragment target path" is appended,
> and thought it was just overridden.
>
>> /a/b/c/fragment0
>>
>> /a/b/d/fagment1
>>
>> It can be two fragments in one fdt by using
>>
>>     base node path = /a/b
>>
>>     fragment0 target path = /c
>>
>>     fragment1 target path = /d
>>
>> I am not sure if there will be this kind of use case or not. And I think
>> it would not be hurt to allow that.
> Is there a need for that? Both c and d can be handled as subnodes
> in a single fragment if the target path is empty (and see below).

In our use case, we do not need that.  I am just not sure if it should be

adding the restriction to limit one fragment here.

Because the fragment target path is appended to the base node path,

each fragment is still applied to a specific location as before. The only

difference is the fragment target path does not need to always start 
with "/".


Thanks,

Lizhi

>
>>>    2. Should there be a convention about the target-path property's
>>>       contents in the original overlay?
>>>       drivers/of/unittest-data/overlay_pci_node.dtso in "[PATCH V13 5/5]
>>>       of: unittest: Add pci_dt_testdrv pci driver" uses
>>>
>>>           target-path="";
>>>
>>>       which cannot be represented when using sugar syntax.
>>>       "/" should work fine, though.
>> Because the fragment overlay path is "base node path" + "fragment target
>> path", I may add code to check if "fragment target patch is '/' and
>> ignore it. I think that would support sugar syntax with only '/' specified.
> That makes sense.
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Guenter Roeck]

On Tue, Aug 15, 2023 at 10:19:57AM -0700, Lizhi Hou wrote:
> 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>

This patch results in the following build error.

Building sparc64:allmodconfig ... failed
--------------
Error log:
<stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp]
sparc64-linux-ld: drivers/pci/of_property.o: in function `of_pci_prop_intr_map':
of_property.c:(.text+0xc4): undefined reference to `of_irq_parse_raw'

Guenter

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Jonathan Cameron]

On Tue, 15 Aug 2023 10:19:57 -0700
Lizhi Hou <lizhi.hou@amd.com> wrote:

> 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>

I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
machine.

There are some missing parts that were present in Clements series, but not this
one, particularly creation of the root pci object.

Anyhow, hit an intermittent crash...


> ---
> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
> +				struct device_node *np)
> +{
> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
> +	struct device_node *pnode;
> +	struct pci_dev *child;
> +	u32 *int_map, *mapp;
> +	int ret;
> +	u8 pin;
> +
> +	pnode = pci_device_to_OF_node(pdev->bus->self);
> +	if (!pnode)
> +		pnode = pci_bus_to_OF_node(pdev->bus);
> +
> +	if (!pnode) {
> +		pci_err(pdev, "failed to get parent device node");
> +		return -EINVAL;
> +	}
> +
> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
> +		i = pin - 1;
> +		out_irq[i].np = pnode;
> +		out_irq[i].args_count = 1;
> +		out_irq[i].args[0] = pin;
> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
> +		if (ret) {
> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
> +			continue;

If all the interrupt parsing fails we continue ever time...

> +		}
> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
> +					   &addr_sz[i]);
> +		if (ret)
> +			addr_sz[i] = 0;

This never happens.

> +	}
> +
> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;

and here we end up derefencing random memory which happens in my case to cause
a massive allocation sometimes and that fails one of the assertions in the
allocator.

I'd suggest just setting addr_sz[xxx] = {}; above
to ensure it's initialized. Then the if(ret) handling should not be needed
as well as of_property_read_u32 should be side effect free I hope!

> +		}
> +	}
> +
> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
> +	mapp = int_map;

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Herve Codina]

Hi Lizhi,

On Tue, 15 Aug 2023 10:19:57 -0700
Lizhi Hou <lizhi.hou@amd.com> wrote:
...
> +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 failed;
> +	of_changeset_init(cset);
> +
> +	np = of_changeset_create_node(ppnode, name, cset);
> +	if (!np)
> +		goto failed;

The "goto failed" will leak the cset previously allocated.

np->data = cset; (next line) allows to free the cset when the node is destroyed
(of_node_put() calls). When the node cannot be created, the allocated cset should
be freed.

> +	np->data = cset;
> +
> +	ret = of_pci_add_properties(pdev, cset, np);
> +	if (ret)
> +		goto failed;
> +
> +	ret = of_changeset_apply(cset);
> +	if (ret)
> +		goto failed;
> +
> +	pdev->dev.of_node = np;
> +	kfree(name);
> +
> +	return;
> +
> +failed:
> +	if (np)
> +		of_node_put(np);
> +	kfree(name);
> +}
> +#endif
> +
>  #endif /* CONFIG_PCI */
>  
...
> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
> +				struct device_node *np)
> +{
> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
> +	struct device_node *pnode;
> +	struct pci_dev *child;
> +	u32 *int_map, *mapp;
> +	int ret;
> +	u8 pin;
> +
> +	pnode = pci_device_to_OF_node(pdev->bus->self);
> +	if (!pnode)
> +		pnode = pci_bus_to_OF_node(pdev->bus);
> +
> +	if (!pnode) {
> +		pci_err(pdev, "failed to get parent device node");
> +		return -EINVAL;
> +	}
> +
> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
> +		i = pin - 1;
> +		out_irq[i].np = pnode;
> +		out_irq[i].args_count = 1;
> +		out_irq[i].args[0] = pin;
> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
> +		if (ret) {
> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
> +			continue;
> +		}
> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
> +					   &addr_sz[i]);
> +		if (ret)
> +			addr_sz[i] = 0;
> +	}

if of_irq_parse_raw() fails, addr_sz[i] is not initialized and map_sz bellow is
computed with uninitialized values.
On the test I did, this lead to a kernel crash due to the following kcalloc()
called with incorrect values.

Are interrupt-map and interrupt-map-mask properties needed in all cases ?
I mean are they mandatory for the host pci bridge ?

> +
> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;

of_irq_parse_raw() can fail on some pins.
Is it correct to set map_sz based on information related to all pins even if
of_irq_parse_raw() previously failed on some pins ?

> +		}
> +	}
> +
> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
> +	mapp = int_map;
> +
> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
> +			*mapp = (child->bus->number << 16) |
> +				(child->devfn << 8);
> +			mapp += OF_PCI_ADDRESS_CELLS;
> +			*mapp = pin;
> +			mapp++;
> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
> +			*mapp = out_irq[i].np->phandle;
> +			mapp++;
> +			if (addr_sz[i]) {
> +				ret = of_property_read_u32_array(out_irq[i].np,
> +								 "reg", mapp,
> +								 addr_sz[i]);
> +				if (ret)
> +					goto failed;
> +			}
> +			mapp += addr_sz[i];
> +			memcpy(mapp, out_irq[i].args,
> +			       out_irq[i].args_count * sizeof(u32));
> +			mapp += out_irq[i].args_count;
> +		}
> +	}
> +
> +	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map", int_map,
> +					      map_sz);
> +	if (ret)
> +		goto failed;
> +
> +	ret = of_changeset_add_prop_u32(ocs, np, "#interrupt-cells", 1);
> +	if (ret)
> +		goto failed;
> +
> +	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map-mask",
> +					      int_map_mask,
> +					      ARRAY_SIZE(int_map_mask));
> +	if (ret)
> +		goto failed;
> +
> +	kfree(int_map);
> +	return 0;
> +
> +failed:
> +	kfree(int_map);
> +	return ret;
> +}
> +
...

Regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Herve Codina]

Hi Jonathan,

On Mon, 11 Sep 2023 15:48:56 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Tue, 15 Aug 2023 10:19:57 -0700
> Lizhi Hou <lizhi.hou@amd.com> wrote:
> 
> > 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>  
> 
> I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> machine.
> 
> There are some missing parts that were present in Clements series, but not this
> one, particularly creation of the root pci object.
> 
> Anyhow, hit an intermittent crash...

I am facing the same issues.

I use a custom PCIe board too but on x86 ACPI machine.

In order to have a working system, I need also to build a DT node for the PCI
Host bridge (previously done by Clement's patch) and I am a bit stuck with
interrupts.

On your side (ACPI machine) how do you handle this ?
I mean is your PCI host bridge provided by ACPI ? And if so, you probably need
to build a DT node for this PCI host bridge and add some interrupt-map,
interrupt-map-mask properties in the DT node.

Best regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Jonathan Cameron]

On Mon, 11 Sep 2023 17:35:03 +0200
Herve Codina <herve.codina@bootlin.com> wrote:

> Hi Jonathan,
> 
> On Mon, 11 Sep 2023 15:48:56 +0100
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> 
> > On Tue, 15 Aug 2023 10:19:57 -0700
> > Lizhi Hou <lizhi.hou@amd.com> wrote:
> >   
> > > 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>    
> > 
> > I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> > machine.
> > 
> > There are some missing parts that were present in Clements series, but not this
> > one, particularly creation of the root pci object.
> > 
> > Anyhow, hit an intermittent crash...  
> 
> I am facing the same issues.
> 
> I use a custom PCIe board too but on x86 ACPI machine.
> 
> In order to have a working system, I need also to build a DT node for the PCI
> Host bridge (previously done by Clement's patch) and I am a bit stuck with
> interrupts.
> 
> On your side (ACPI machine) how do you handle this ?

That was next on my list to look at now I've gotten the device tree stuff
to show up.

> I mean is your PCI host bridge provided by ACPI ? And if so, you probably need
> to build a DT node for this PCI host bridge and add some interrupt-map,
> interrupt-map-mask properties in the DT node.

Agreed. Potentially some other stuff, but interrupts are the thing that
showed up first as an issue.

Given the only reason I'm looking at this is to potentially solve
a long term CXL / MCTP over I2C upstreaming problem on QEMU side, I've only
limited time to throw at this (thought it was a short activity
for a Friday afternoon :)  Will see if it turns out not too be
too hard to build the rest.

I can at least boot same system with device tree and check I'm matching
what is being generated by QEMU.

Jonathan


> 
> Best regards,
> Hervé
> 

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Jonathan Cameron]

On Mon, 11 Sep 2023 16:47:41 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Mon, 11 Sep 2023 17:35:03 +0200
> Herve Codina <herve.codina@bootlin.com> wrote:
> 
> > Hi Jonathan,
> > 
> > On Mon, 11 Sep 2023 15:48:56 +0100
> > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> >   
> > > On Tue, 15 Aug 2023 10:19:57 -0700
> > > Lizhi Hou <lizhi.hou@amd.com> wrote:
> > >     
> > > > 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>      
> > > 
> > > I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> > > machine.
> > > 
> > > There are some missing parts that were present in Clements series, but not this
> > > one, particularly creation of the root pci object.
> > > 
> > > Anyhow, hit an intermittent crash...    
> > 
> > I am facing the same issues.
> > 
> > I use a custom PCIe board too but on x86 ACPI machine.
> > 
> > In order to have a working system, I need also to build a DT node for the PCI
> > Host bridge (previously done by Clement's patch) and I am a bit stuck with
> > interrupts.
> > 
> > On your side (ACPI machine) how do you handle this ?  
> 
> That was next on my list to look at now I've gotten the device tree stuff
> to show up.
> 
> > I mean is your PCI host bridge provided by ACPI ? And if so, you probably need
> > to build a DT node for this PCI host bridge and add some interrupt-map,
> > interrupt-map-mask properties in the DT node.  
> 
> Agreed. Potentially some other stuff, but interrupts are the thing that
> showed up first as an issue.
> 
> Given the only reason I'm looking at this is to potentially solve
> a long term CXL / MCTP over I2C upstreaming problem on QEMU side, I've only
> limited time to throw at this (thought it was a short activity
> for a Friday afternoon :)  Will see if it turns out not too be
> too hard to build the rest.
> 
> I can at least boot same system with device tree and check I'm matching
> what is being generated by QEMU.

So, I'm not really sure how to approach this.  It seems 'unwise'/'unworkable' to
instantiate the device tree blob for the interrupt controller we already have
ACPI for and without that I have nothing to route to.

Or can we just ignore the interrupt map stuff completely and instead
rely on instantiating an interrupt controller on the card (that under
the hood uses non DT paths to make interrupts actually happen?)

That path to me seems workable and keeps the boundary of ACPI vs DT
actually getting used within the card specific driver.

Suggestions welcome!

Jonathan

> 
> Jonathan
> 
> 
> > 
> > Best regards,
> > Hervé
> >   
> 

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Lizhi Hou]

On 9/11/23 07:48, Jonathan Cameron wrote:
> On Tue, 15 Aug 2023 10:19:57 -0700
> Lizhi Hou <lizhi.hou@amd.com> wrote:
>
>> 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>
> I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> machine.
>
> There are some missing parts that were present in Clements series, but not this
> one, particularly creation of the root pci object.
Thanks for trying this. The entire effort was separated in different 
phases. That is why this patchset does not include creating of_root.
>
> Anyhow, hit an intermittent crash...
>
>
>> ---
>> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
>> +				struct device_node *np)
>> +{
>> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
>> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
>> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
>> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
>> +	struct device_node *pnode;
>> +	struct pci_dev *child;
>> +	u32 *int_map, *mapp;
>> +	int ret;
>> +	u8 pin;
>> +
>> +	pnode = pci_device_to_OF_node(pdev->bus->self);
>> +	if (!pnode)
>> +		pnode = pci_bus_to_OF_node(pdev->bus);
>> +
>> +	if (!pnode) {
>> +		pci_err(pdev, "failed to get parent device node");
>> +		return -EINVAL;
>> +	}
>> +
>> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
>> +		i = pin - 1;
>> +		out_irq[i].np = pnode;
>> +		out_irq[i].args_count = 1;
>> +		out_irq[i].args[0] = pin;
>> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
>> +		if (ret) {
>> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
>> +			continue;
> If all the interrupt parsing fails we continue ever time...

Did you use Clement's patch to create of_root? I am just wondering if 
parsing irq could fail on a dt-based system.

And yes, the failure case should be handled without crash. I think if 
irq parsing failed,  the interrupt-map pair generation should be skipped.


Thanks,

Lizhi

>
>> +		}
>> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
>> +					   &addr_sz[i]);
>> +		if (ret)
>> +			addr_sz[i] = 0;
> This never happens.
>
>> +	}
>> +
>> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
>> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
>> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
>> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;
> and here we end up derefencing random memory which happens in my case to cause
> a massive allocation sometimes and that fails one of the assertions in the
> allocator.
>
> I'd suggest just setting addr_sz[xxx] = {}; above
> to ensure it's initialized. Then the if(ret) handling should not be needed
> as well as of_property_read_u32 should be side effect free I hope!
>
>> +		}
>> +	}
>> +
>> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
>> +	mapp = int_map;

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Lizhi Hou]

On 9/11/23 08:13, Herve Codina wrote:
> Hi Lizhi,
>
> On Tue, 15 Aug 2023 10:19:57 -0700
> Lizhi Hou <lizhi.hou@amd.com> wrote:
> ...
>> +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 failed;
>> +	of_changeset_init(cset);
>> +
>> +	np = of_changeset_create_node(ppnode, name, cset);
>> +	if (!np)
>> +		goto failed;
> The "goto failed" will leak the cset previously allocated.
>
> np->data = cset; (next line) allows to free the cset when the node is destroyed
> (of_node_put() calls). When the node cannot be created, the allocated cset should
> be freed.
Thanks for pointing this out.
>
>> +	np->data = cset;
>> +
>> +	ret = of_pci_add_properties(pdev, cset, np);
>> +	if (ret)
>> +		goto failed;
>> +
>> +	ret = of_changeset_apply(cset);
>> +	if (ret)
>> +		goto failed;
>> +
>> +	pdev->dev.of_node = np;
>> +	kfree(name);
>> +
>> +	return;
>> +
>> +failed:
>> +	if (np)
>> +		of_node_put(np);
>> +	kfree(name);
>> +}
>> +#endif
>> +
>>   #endif /* CONFIG_PCI */
>>   
> ...
>> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
>> +				struct device_node *np)
>> +{
>> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
>> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
>> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
>> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
>> +	struct device_node *pnode;
>> +	struct pci_dev *child;
>> +	u32 *int_map, *mapp;
>> +	int ret;
>> +	u8 pin;
>> +
>> +	pnode = pci_device_to_OF_node(pdev->bus->self);
>> +	if (!pnode)
>> +		pnode = pci_bus_to_OF_node(pdev->bus);
>> +
>> +	if (!pnode) {
>> +		pci_err(pdev, "failed to get parent device node");
>> +		return -EINVAL;
>> +	}
>> +
>> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
>> +		i = pin - 1;
>> +		out_irq[i].np = pnode;
>> +		out_irq[i].args_count = 1;
>> +		out_irq[i].args[0] = pin;
>> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
>> +		if (ret) {
>> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
>> +			continue;
>> +		}
>> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
>> +					   &addr_sz[i]);
>> +		if (ret)
>> +			addr_sz[i] = 0;
>> +	}
> if of_irq_parse_raw() fails, addr_sz[i] is not initialized and map_sz bellow is
> computed with uninitialized values.
> On the test I did, this lead to a kernel crash due to the following kcalloc()
> called with incorrect values.
>
> Are interrupt-map and interrupt-map-mask properties needed in all cases ?
> I mean are they mandatory for the host pci bridge ?
interrupt-map is required for bridges when a legacy interrupt device is 
underneath. Otherwise, of_irq_parse_pci() needs to be changed for legacy 
interrupt device. Please see my previous patch and comments.
>
>> +
>> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
>> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
>> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
>> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;
> of_irq_parse_raw() can fail on some pins.
> Is it correct to set map_sz based on information related to all pins even if
> of_irq_parse_raw() previously failed on some pins ?

I think the interrupt-map pair should be skipped if of_irq_parse_raw() 
is failed. Thanks.


Lizhi

>
>> +		}
>> +	}
>> +
>> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
>> +	mapp = int_map;
>> +
>> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
>> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
>> +			*mapp = (child->bus->number << 16) |
>> +				(child->devfn << 8);
>> +			mapp += OF_PCI_ADDRESS_CELLS;
>> +			*mapp = pin;
>> +			mapp++;
>> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
>> +			*mapp = out_irq[i].np->phandle;
>> +			mapp++;
>> +			if (addr_sz[i]) {
>> +				ret = of_property_read_u32_array(out_irq[i].np,
>> +								 "reg", mapp,
>> +								 addr_sz[i]);
>> +				if (ret)
>> +					goto failed;
>> +			}
>> +			mapp += addr_sz[i];
>> +			memcpy(mapp, out_irq[i].args,
>> +			       out_irq[i].args_count * sizeof(u32));
>> +			mapp += out_irq[i].args_count;
>> +		}
>> +	}
>> +
>> +	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map", int_map,
>> +					      map_sz);
>> +	if (ret)
>> +		goto failed;
>> +
>> +	ret = of_changeset_add_prop_u32(ocs, np, "#interrupt-cells", 1);
>> +	if (ret)
>> +		goto failed;
>> +
>> +	ret = of_changeset_add_prop_u32_array(ocs, np, "interrupt-map-mask",
>> +					      int_map_mask,
>> +					      ARRAY_SIZE(int_map_mask));
>> +	if (ret)
>> +		goto failed;
>> +
>> +	kfree(int_map);
>> +	return 0;
>> +
>> +failed:
>> +	kfree(int_map);
>> +	return ret;
>> +}
>> +
> ...
>
> Regards,
> Hervé
>

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Andy Shevchenko]

On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> This patch series introduces OF overlay support for PCI devices which
> primarily addresses two use cases. First, it provides a data driven method
> to describe hardware peripherals that are present in a PCI endpoint and
> hence can be accessed by the PCI host. Second, it allows reuse of a OF
> compatible driver -- often used in SoC platforms -- in a PCI host based
> system.
> 
> There are 2 series devices rely on this patch:
> 
>   1) Xilinx Alveo Accelerator cards (FPGA based device)

>   2) Microchip LAN9662 Ethernet Controller

I believe you should Cc this to Andrew Lunn for the comments.
IIRC something similar was tried to being solved for DSA (?)
devices where SFP hotpluggable hardware can be attached or
detached at run-time (sorry if I messes / mixing up things,
I wrote this from my memory, might be completely wrong).

>      Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/
> 
> Normally, the PCI core discovers PCI devices and their BARs using the
> PCI enumeration process. However, the process does not provide a way to
> discover the hardware peripherals that are present in a PCI device, and
> which can be accessed through the PCI BARs. Also, the enumeration process
> does not provide a way to associate MSI-X vectors of a PCI device with the
> hardware peripherals that are present in the device. PCI device drivers
> often use header files to describe the hardware peripherals and their
> resources as there is no standard data driven way to do so. This patch
> series proposes to use flattened device tree blob to describe the
> peripherals in a data driven way. Based on previous discussion, using
> device tree overlay is the best way to unflatten the blob and populate
> platform devices. To use device tree overlay, there are three obvious
> problems that need to be resolved.
> 
> First, we need to create a base tree for non-DT system such as x86_64. A
> patch series has been submitted for this:
> https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/

Can you point out to the ACPI excerpt(s) of the description of anything related
to the device(s) in question?

> Second, a device tree node corresponding to the PCI endpoint is required
> for overlaying the flattened device tree blob for that PCI endpoint.
> Because PCI is a self-discoverable bus, a device tree node is usually not
> created for PCI devices. This series adds support to generate a device
> tree node for a PCI device which advertises itself using PCI quirks
> infrastructure.
> 
> Third, we need to generate device tree nodes for PCI bridges since a child
> PCI endpoint may choose to have a device tree node created.
> 
> This patch series is made up of three patches.
> 
> The first patch is adding OF interface to create or destroy OF node
> dynamically.
> 
> The second patch introduces a kernel option, CONFIG_PCI_DYNAMIC_OF_NODES.
> When the option is turned on, the kernel will generate device tree nodes
> for all PCI bridges unconditionally. The patch also shows how to use the
> PCI quirks infrastructure, DECLARE_PCI_FIXUP_FINAL to generate a device
> tree node for a device. Specifically, the patch generates a device tree
> node for Xilinx Alveo U50 PCIe accelerator device. The generated device
> tree nodes do not have any property.
> 
> The third patch adds basic properties ('reg', 'compatible' and
> 'device_type') to the dynamically generated device tree nodes. More
> properties can be added in the future.
> 
> Here is the example of device tree nodes generated within the ARM64 QEMU.
> 
> # lspci -t
> -[0000:00]-+-00.0
>            +-01.0
>            +-03.0-[01-03]----00.0-[02-03]----00.0-[03]----00.0
>            +-03.1-[04]--
>            \-04.0-[05-06]----00.0-[06]--
> 
> Without CONFIG_PCI_DYNAMIC_OF_NODES
> 
> # tree /sys/firmware/devicetree/base/pcie@10000000/
> /sys/firmware/devicetree/base/pcie@10000000/
> |-- #address-cells
> |-- #interrupt-cells
> |-- #size-cells
> |-- bus-range
> |-- compatible
> |-- device_type
> |-- dma-coherent
> |-- interrupt-map
> |-- interrupt-map-mask
> |-- linux,pci-domain
> |-- msi-map
> |-- name
> |-- ranges
> `-- reg
> 
> With CONFIG_PCI_DYNAMIC_OF_NODES
> 
> # tree /sys/firmware/devicetree/base/pcie@10000000/
> /sys/firmware/devicetree/base/pcie@10000000/
> |-- #address-cells
> |-- #interrupt-cells
> |-- #size-cells
> |-- bus-range
> |-- compatible
> |-- device_type
> |-- dma-coherent
> |-- interrupt-map
> |-- interrupt-map-mask
> |-- linux,pci-domain
> |-- msi-map
> |-- name
> |-- pci@3,0
> |   |-- #address-cells
> |   |-- #interrupt-cells
> |   |-- #size-cells
> |   |-- bus-range
> |   |-- compatible
> |   |-- device_type
> |   |-- interrupt-map
> |   |-- interrupt-map-mask
> |   |-- interrupts
> |   |-- pci@0,0
> |   |   |-- #address-cells
> |   |   |-- #interrupt-cells
> |   |   |-- #size-cells
> |   |   |-- bus-range
> |   |   |-- compatible
> |   |   |-- device_type
> |   |   |-- interrupt-map
> |   |   |-- interrupt-map-mask
> |   |   |-- pci@0,0
> |   |   |   |-- #address-cells
> |   |   |   |-- #interrupt-cells
> |   |   |   |-- #size-cells
> |   |   |   |-- bus-range
> |   |   |   |-- compatible
> |   |   |   |-- dev@0,0
> |   |   |   |   |-- #address-cells
> |   |   |   |   |-- #size-cells
> |   |   |   |   |-- compatible
> |   |   |   |   |-- ranges
> |   |   |   |   `-- reg
> |   |   |   |-- device_type
> |   |   |   |-- interrupt-map
> |   |   |   |-- interrupt-map-mask
> |   |   |   |-- ranges
> |   |   |   `-- reg
> |   |   |-- ranges
> |   |   `-- reg
> |   |-- ranges
> |   `-- reg
> |-- pci@3,1
> |   |-- #address-cells
> |   |-- #interrupt-cells
> |   |-- #size-cells
> |   |-- bus-range
> |   |-- compatible
> |   |-- device_type
> |   |-- interrupt-map
> |   |-- interrupt-map-mask
> |   |-- interrupts
> |   |-- ranges
> |   `-- reg
> |-- pci@4,0
> |   |-- #address-cells
> |   |-- #interrupt-cells
> |   |-- #size-cells
> |   |-- bus-range
> |   |-- compatible
> |   |-- device_type
> |   |-- interrupt-map
> |   |-- interrupt-map-mask
> |   |-- pci@0,0
> |   |   |-- #address-cells
> |   |   |-- #interrupt-cells
> |   |   |-- #size-cells
> |   |   |-- bus-range
> |   |   |-- compatible
> |   |   |-- device_type
> |   |   |-- interrupt-map
> |   |   |-- interrupt-map-mask
> |   |   |-- interrupts
> |   |   |-- ranges
> |   |   `-- reg
> |   |-- ranges
> |   `-- reg
> |-- ranges
> `-- reg
> 
> Changes since v12:
> - Minor fix for kernel test robot warning
> 
> Changes since v11:
> - Create interrupt related properties
> 
> Changes since v10:
> - Remove 'dynamic' property
> 
> Changes since v9:
> - Introduce 'dynamic' property to identify dynamically generated device tree
>   node for PCI device
> - Added 'bus-range' property to remove dtc warnings
> - Minor code review fixes
> 
> Changes since v8:
> - Added patches to create unit test to verifying address translation
>     The test relies on QEMU PCI Test Device, please see
>         https://github.com/houlz0507/xoclv2/blob/pci-dt-0329/pci-dt-patch-0329/README
>     for test setup
> - Minor code review fixes
> 
> Changes since v7:
> - Modified dynamic node creation interfaces
> - Added unittest for new added interfaces
> 
> Changes since v6:
> - Removed single line wrapper functions
> - Added Signed-off-by Clément Léger <clement.leger@bootlin.com>
> 
> Changes since v5:
> - Fixed code review comments
> - Fixed incorrect 'ranges' and 'reg' properties
> 
> Changes since RFC v4:
> - Fixed code review comments
> 
> Changes since RFC v3:
> - Split the Xilinx Alveo U50 PCI quirk to a separate patch
> - Minor changes in commit description and code comment
> 
> Changes since RFC v2:
> - Merged patch 3 with patch 2
> - Added OF interfaces of_changeset_add_prop_* and use them to create
>   properties.
> - Added '#address-cells', '#size-cells' and 'ranges' properties.
> 
> Changes since RFC v1:
> - Added one patch to create basic properties.
> - To move DT related code out of PCI subsystem, replaced of_node_alloc()
>   with of_create_node()/of_destroy_node()
> 
> Lizhi Hou (5):
>   of: dynamic: Add interfaces for creating device node dynamically
>   PCI: Create device tree node for bridge
>   PCI: Add quirks to generate device tree node for Xilinx Alveo U50
>   of: overlay: Extend of_overlay_fdt_apply() to specify the target node
>   of: unittest: Add pci_dt_testdrv pci driver
> 
>  drivers/of/dynamic.c                          | 164 ++++++++
>  drivers/of/overlay.c                          |  42 ++-
>  drivers/of/unittest-data/Makefile             |   3 +-
>  .../of/unittest-data/overlay_pci_node.dtso    |  22 ++
>  drivers/of/unittest.c                         | 211 ++++++++++-
>  drivers/pci/Kconfig                           |  12 +
>  drivers/pci/Makefile                          |   1 +
>  drivers/pci/bus.c                             |   2 +
>  drivers/pci/of.c                              |  79 ++++
>  drivers/pci/of_property.c                     | 355 ++++++++++++++++++
>  drivers/pci/pci.h                             |  12 +
>  drivers/pci/quirks.c                          |  12 +
>  drivers/pci/remove.c                          |   1 +
>  include/linux/of.h                            |  25 +-
>  14 files changed, 926 insertions(+), 15 deletions(-)
>  create mode 100644 drivers/of/unittest-data/overlay_pci_node.dtso
>  create mode 100644 drivers/pci/of_property.c
> 
> -- 
> 2.34.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 1/5] of: dynamic: Add interfaces for creating device node dynamically

[Andy Shevchenko]

On Tue, Aug 15, 2023 at 10:19:56AM -0700, Lizhi Hou wrote:
> of_changeset_create_node() creates device node dynamically and attaches
> the newly created node to a changeset.
> 
> Expand of_changeset APIs to handle specific types of properties.
>     of_changeset_add_prop_string()
>     of_changeset_add_prop_string_array()
>     of_changeset_add_prop_u32_array()

...

> +/**
> + * of_changeset_add_prop_string - Add a string property to a changeset
> + *
> + * @ocs:	changeset pointer
> + * @np:		device node pointer
> + * @prop_name:	name of the property to be added
> + * @str:	pointer to null terminated string
> + *
> + * Create a string property and add it to a changeset.
> + *
> + * Return: 0 on success, a negative error value in case of an error.
> + */
> +int of_changeset_add_prop_string(struct of_changeset *ocs,
> +				 struct device_node *np,
> +				 const char *prop_name, const char *str)
> +{
> +	struct property prop;
> +
> +	prop.name = (char *)prop_name;

This looks not nice. You dropped const qualifier, which is a bit worrying.
Can  you fix underneath APIs/data types so we can avoid this?

> +	prop.length = strlen(str) + 1;

> +	prop.value = (void *)str;

Do you need this casting?

Okay, seems also related to the const qualifier. I would accept this in a form
of const void *, but it will probably look a bit weird. What about to have a value
to be a union?

> +	return of_changeset_add_prop_helper(ocs, np, &prop);
> +}

...

> +	prop.name = (char *)prop_name;

Same comment as per above.

...

> +	prop.length = 0;
> +	for (i = 0; i < sz; i++)
> +		prop.length += strlen(str_array[i]) + 1;
> +
> +	prop.value = kmalloc(prop.length, GFP_KERNEL);
> +	if (!prop.value)
> +		return -ENOMEM;
> +
> +	vp = prop.value;
> +	for (i = 0; i < sz; i++) {
> +		vp += snprintf(vp, (char *)prop.value + prop.length - vp, "%s",
> +			       str_array[i]) + 1;
> +	}

Is all this kinda of reinventing kasprintf()? Perhaps you can somehow utilize
kasprintf_strarray()? It might require to get a common denominator that takes
a formatting string as a parameter.

> +	ret = of_changeset_add_prop_helper(ocs, np, &prop);
> +	kfree(prop.value);

...

> +	for (i = 0; i < sz; i++)
> +		val[i] = cpu_to_be32(array[i]);

NIH cpu_to_be32_array()

...

> +	prop.name = (char *)prop_name;
> +	prop.length = sizeof(u32) * sz;
> +	prop.value = (void *)val;

Do you need this casting?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Andy Shevchenko]

On Tue, Aug 15, 2023 at 10:19:57AM -0700, Lizhi Hou wrote:
> 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.

...

> @@ -32,6 +32,7 @@ obj-$(CONFIG_PCI_P2PDMA)	+= p2pdma.o
>  obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
>  obj-$(CONFIG_VGA_ARB)		+= vgaarb.o
>  obj-$(CONFIG_PCI_DOE)		+= doe.o

> +obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o

Maybe a bit ordered?

...

> +void of_pci_remove_node(struct pci_dev *pdev)
> +{
> +	struct device_node *np;
> +
> +	np = pci_device_to_OF_node(pdev);

CamelCase out of a sudden?!

> +	if (!np || !of_node_check_flag(np, OF_DYNAMIC))

Do you need a first check? Shouldn't the second return false for you in such a
case?

> +		return;

> +	pdev->dev.of_node = NULL;

This will mess up with fwnode, isn't it?


> +	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)

While not positive conditional?

> +		ppnode = pdev->bus->dev.of_node;
> +	else
> +		ppnode = pdev->bus->self->dev.of_node;

What about firmware nodes?

> +	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 failed;
> +	of_changeset_init(cset);
> +
> +	np = of_changeset_create_node(ppnode, name, cset);
> +	if (!np)
> +		goto failed;
> +	np->data = cset;
> +
> +	ret = of_pci_add_properties(pdev, cset, np);
> +	if (ret)
> +		goto failed;
> +
> +	ret = of_changeset_apply(cset);
> +	if (ret)
> +		goto failed;
> +
> +	pdev->dev.of_node = np;

Firmware node?

> +	kfree(name);
> +
> +	return;
> +
> +failed:

> +	if (np)

Dup check.

> +		of_node_put(np);
> +	kfree(name);
> +}

...

> +#include <linux/pci.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>

Can it be ordered?

...

> +struct of_pci_addr_pair {
> +	u32		phys_addr[OF_PCI_ADDRESS_CELLS];
> +	u32		size[OF_PCI_SIZE_CELLS];
> +};

Why not

struct foo {
	u32 phys_addr; // why not 64-bit?
	u32 size; // same Q, btw
};

struct _pairs {
	strict foo pairs[...];
}

?

...

> +struct of_pci_range {
> +	u32		child_addr[OF_PCI_ADDRESS_CELLS];
> +	u32		parent_addr[OF_PCI_ADDRESS_CELLS];
> +	u32		size[OF_PCI_SIZE_CELLS];
> +};

In the similar way?

...

> +enum of_pci_prop_compatible {
> +	PROP_COMPAT_PCI_VVVV_DDDD,
> +	PROP_COMPAT_PCICLASS_CCSSPP,
> +	PROP_COMPAT_PCICLASS_CCSS,
> +	PROP_COMPAT_NUM,

No comma for the terminator entry (as far as I got it).

> +};

...

> +static void of_pci_set_address(struct pci_dev *pdev, u32 *prop, u64 addr,
> +			       u32 reg_num, u32 flags, bool reloc)
> +{
> +	prop[0] = FIELD_PREP(OF_PCI_ADDR_FIELD_BUS, pdev->bus->number) |
> +		FIELD_PREP(OF_PCI_ADDR_FIELD_DEV, PCI_SLOT(pdev->devfn)) |
> +		FIELD_PREP(OF_PCI_ADDR_FIELD_FUNC, PCI_FUNC(pdev->devfn));
> +	prop[0] |= flags | reg_num;

No checks? No masks? flags or reg_num may easily / mistakenly rewrite the above.

> +	if (!reloc) {

	if (reloc)
		return;

?

> +		prop[0] |= OF_PCI_ADDR_FIELD_NONRELOC;
> +		prop[1] = upper_32_bits(addr);
> +		prop[2] = lower_32_bits(addr);
> +	}
> +}

...

> +static int of_pci_get_addr_flags(struct resource *res, u32 *flags)
> +{
> +	u32 ss;

> +	if (res->flags & IORESOURCE_IO)
> +		ss = OF_PCI_ADDR_SPACE_IO;
> +	else if (res->flags & IORESOURCE_MEM_64)
> +		ss = OF_PCI_ADDR_SPACE_MEM64;
> +	else if (res->flags & IORESOURCE_MEM)
> +		ss = OF_PCI_ADDR_SPACE_MEM32;
> +	else
> +		return -EINVAL;

We have ioport.h and respective helpers, can you use them?
resource_type(), for example.

> +	*flags = 0;
> +	if (res->flags & IORESOURCE_PREFETCH)
> +		*flags |= OF_PCI_ADDR_FIELD_PREFETCH;
> +
> +	*flags |= FIELD_PREP(OF_PCI_ADDR_FIELD_SS, ss);
> +
> +	return 0;
> +}

...

> +static int of_pci_prop_bus_range(struct pci_dev *pdev,
> +				 struct of_changeset *ocs,
> +				 struct device_node *np)
> +{
> +	u32 bus_range[] = { pdev->subordinate->busn_res.start,
> +			    pdev->subordinate->busn_res.end };

Wrong. It won't work on 64-bit resources.

> +	return of_changeset_add_prop_u32_array(ocs, np, "bus-range", bus_range,
> +					       ARRAY_SIZE(bus_range));
> +}

...

> +	if (pci_is_bridge(pdev)) {
> +		num = PCI_BRIDGE_RESOURCE_NUM;
> +		res = &pdev->resource[PCI_BRIDGE_RESOURCES];
> +	} else {
> +		num = PCI_STD_NUM_BARS;
> +		res = &pdev->resource[PCI_STD_RESOURCES];
> +	}

Don't we have pci_resource() macro?

...

> +	for (i = 0, j = 0; j < num; j++) {
> +		if (!resource_size(&res[j]))
> +			continue;
> +
> +		if (of_pci_get_addr_flags(&res[j], &flags))
> +			continue;
> +
> +		val64 = res[j].start;
> +		of_pci_set_address(pdev, rp[i].parent_addr, val64, 0, flags,
> +				   false);
> +		if (pci_is_bridge(pdev)) {

> +			memcpy(rp[i].child_addr, rp[i].parent_addr,
> +			       sizeof(rp[i].child_addr));

Why simple assignment is not good enough here?

> +		} else {
> +			/*
> +			 * For endpoint device, the lower 64-bits of child
> +			 * address is always zero.
> +			 */
> +			rp[i].child_addr[0] = j;
> +		}

> +		val64 = resource_size(&res[j]);

Dup. You already called this at the top of the loop, why to repeat?

> +		rp[i].size[0] = upper_32_bits(val64);
> +		rp[i].size[1] = lower_32_bits(val64);
> +
> +		i++;
> +	}

...

> +static int of_pci_prop_reg(struct pci_dev *pdev, struct of_changeset *ocs,
> +			   struct device_node *np)
> +{
> +	struct of_pci_addr_pair reg = { 0 };

0 is redundant.

> +
> +	/* configuration space */
> +	of_pci_set_address(pdev, reg.phys_addr, 0, 0, 0, true);
> +
> +	return of_changeset_add_prop_u32_array(ocs, np, "reg", (u32 *)&reg,
> +					       sizeof(reg) / sizeof(u32));
> +}

...

> +	ret = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> +	if (ret != 0)

Why this pattern?

> +		return ret;

Are you aware that above can return positive codes, aren't you?
You probably want to translate them to the Linux error codes
Same applies to all generic PCI config space accessors used in
the code.

> +	if (!pin)
> +		return 0;
> +
> +	return of_changeset_add_prop_u32(ocs, np, "interrupts", (u32)pin);

Why casting?

> +}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Andy Shevchenko]

On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> This patch series introduces OF overlay support for PCI devices which
> primarily addresses two use cases. First, it provides a data driven method
> to describe hardware peripherals that are present in a PCI endpoint and
> hence can be accessed by the PCI host. Second, it allows reuse of a OF
> compatible driver -- often used in SoC platforms -- in a PCI host based
> system.
> 
> There are 2 series devices rely on this patch:
> 
>   1) Xilinx Alveo Accelerator cards (FPGA based device)
>   2) Microchip LAN9662 Ethernet Controller
> 
>      Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/
> 
> Normally, the PCI core discovers PCI devices and their BARs using the
> PCI enumeration process. However, the process does not provide a way to
> discover the hardware peripherals that are present in a PCI device, and
> which can be accessed through the PCI BARs. Also, the enumeration process
> does not provide a way to associate MSI-X vectors of a PCI device with the
> hardware peripherals that are present in the device. PCI device drivers
> often use header files to describe the hardware peripherals and their
> resources as there is no standard data driven way to do so. This patch
> series proposes to use flattened device tree blob to describe the
> peripherals in a data driven way. Based on previous discussion, using
> device tree overlay is the best way to unflatten the blob and populate
> platform devices. To use device tree overlay, there are three obvious
> problems that need to be resolved.
> 
> First, we need to create a base tree for non-DT system such as x86_64. A
> patch series has been submitted for this:
> https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/
> 
> Second, a device tree node corresponding to the PCI endpoint is required
> for overlaying the flattened device tree blob for that PCI endpoint.
> Because PCI is a self-discoverable bus, a device tree node is usually not
> created for PCI devices. This series adds support to generate a device
> tree node for a PCI device which advertises itself using PCI quirks
> infrastructure.
> 
> Third, we need to generate device tree nodes for PCI bridges since a child
> PCI endpoint may choose to have a device tree node created.
> 
> This patch series is made up of three patches.
> 
> The first patch is adding OF interface to create or destroy OF node
> dynamically.
> 
> The second patch introduces a kernel option, CONFIG_PCI_DYNAMIC_OF_NODES.
> When the option is turned on, the kernel will generate device tree nodes
> for all PCI bridges unconditionally. The patch also shows how to use the
> PCI quirks infrastructure, DECLARE_PCI_FIXUP_FINAL to generate a device
> tree node for a device. Specifically, the patch generates a device tree
> node for Xilinx Alveo U50 PCIe accelerator device. The generated device
> tree nodes do not have any property.
> 
> The third patch adds basic properties ('reg', 'compatible' and
> 'device_type') to the dynamically generated device tree nodes. More
> properties can be added in the future.

In my opinion this series needs much more work (esp. cleaning up one)
to not look like a NIH here and there.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Andy Shevchenko]

On Mon, Sep 11, 2023 at 05:22:56PM +0100, Jonathan Cameron wrote:
> On Mon, 11 Sep 2023 16:47:41 +0100
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> > On Mon, 11 Sep 2023 17:35:03 +0200
> > Herve Codina <herve.codina@bootlin.com> wrote:
> > > On Mon, 11 Sep 2023 15:48:56 +0100
> > > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> > > > On Tue, 15 Aug 2023 10:19:57 -0700
> > > > Lizhi Hou <lizhi.hou@amd.com> wrote:

> > > > > 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>      
> > > > 
> > > > I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> > > > machine.
> > > > 
> > > > There are some missing parts that were present in Clements series, but not this
> > > > one, particularly creation of the root pci object.
> > > > 
> > > > Anyhow, hit an intermittent crash...    
> > > 
> > > I am facing the same issues.
> > > 
> > > I use a custom PCIe board too but on x86 ACPI machine.
> > > 
> > > In order to have a working system, I need also to build a DT node for the PCI
> > > Host bridge (previously done by Clement's patch) and I am a bit stuck with
> > > interrupts.
> > > 
> > > On your side (ACPI machine) how do you handle this ?  
> > 
> > That was next on my list to look at now I've gotten the device tree stuff
> > to show up.
> > 
> > > I mean is your PCI host bridge provided by ACPI ? And if so, you probably need
> > > to build a DT node for this PCI host bridge and add some interrupt-map,
> > > interrupt-map-mask properties in the DT node.  
> > 
> > Agreed. Potentially some other stuff, but interrupts are the thing that
> > showed up first as an issue.
> > 
> > Given the only reason I'm looking at this is to potentially solve
> > a long term CXL / MCTP over I2C upstreaming problem on QEMU side, I've only
> > limited time to throw at this (thought it was a short activity
> > for a Friday afternoon :)  Will see if it turns out not too be
> > too hard to build the rest.
> > 
> > I can at least boot same system with device tree and check I'm matching
> > what is being generated by QEMU.
> 
> So, I'm not really sure how to approach this.  It seems 'unwise'/'unworkable' to
> instantiate the device tree blob for the interrupt controller we already have
> ACPI for and without that I have nothing to route to.
> 
> Or can we just ignore the interrupt map stuff completely and instead
> rely on instantiating an interrupt controller on the card (that under
> the hood uses non DT paths to make interrupts actually happen?)
> 
> That path to me seems workable and keeps the boundary of ACPI vs DT
> actually getting used within the card specific driver.
> 
> Suggestions welcome!

Interestingly I haven't got your message in the thread via `b4`.
Anyways, I think that was has been discussed at some point and
DT appears just to be handy blob format to be supplied along with
the device as "description of its configuration". Whatever format
is chosen it should be available for ACPI/DT/etc platforms and
be uniform. ACPI also supports overlays (as a debug feature, though)
but would it make sense to have AML (compiled ASL) for ACPI and DTB
for DT platforms and etc for etc platforms with duplicative data
inside with all limitations of the each of those formats and their
respective parsers/interpreters?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Jonathan Cameron]

On Mon, 11 Sep 2023 09:58:04 -0700
Lizhi Hou <lizhi.hou@amd.com> wrote:

> On 9/11/23 07:48, Jonathan Cameron wrote:
> > On Tue, 15 Aug 2023 10:19:57 -0700
> > Lizhi Hou <lizhi.hou@amd.com> wrote:
> >  
> >> 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>  
> > I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> > machine.
> >
> > There are some missing parts that were present in Clements series, but not this
> > one, particularly creation of the root pci object.  
> Thanks for trying this. The entire effort was separated in different 
> phases. That is why this patchset does not include creating of_root.
> >
> > Anyhow, hit an intermittent crash...
> >
> >  
> >> ---
> >> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
> >> +				struct device_node *np)
> >> +{
> >> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
> >> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
> >> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
> >> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
> >> +	struct device_node *pnode;
> >> +	struct pci_dev *child;
> >> +	u32 *int_map, *mapp;
> >> +	int ret;
> >> +	u8 pin;
> >> +
> >> +	pnode = pci_device_to_OF_node(pdev->bus->self);
> >> +	if (!pnode)
> >> +		pnode = pci_bus_to_OF_node(pdev->bus);
> >> +
> >> +	if (!pnode) {
> >> +		pci_err(pdev, "failed to get parent device node");
> >> +		return -EINVAL;
> >> +	}
> >> +
> >> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
> >> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
> >> +		i = pin - 1;
> >> +		out_irq[i].np = pnode;
> >> +		out_irq[i].args_count = 1;
> >> +		out_irq[i].args[0] = pin;
> >> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
> >> +		if (ret) {
> >> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
> >> +			continue;  
> > If all the interrupt parsing fails we continue ever time...  
> 
> Did you use Clement's patch to create of_root? I am just wondering if 
> parsing irq could fail on a dt-based system.

For qemu already have of_root as there is still a device tree, it's just
used to pass some stuff to EDK2 I think. I was carrying the Frank's
series adding a bare device tree, it's just not doing anything on these
systems

I used Clements patch to add the pci root (cleaned up a bit to
match the style of your series more closely).

However, my interest is in ACPI based systems, not DT based ones.

Jonathan


> 
> And yes, the failure case should be handled without crash. I think if 
> irq parsing failed,  the interrupt-map pair generation should be skipped.
> 
> 
> Thanks,
> 
> Lizhi
> 
> >  
> >> +		}
> >> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
> >> +					   &addr_sz[i]);
> >> +		if (ret)
> >> +			addr_sz[i] = 0;  
> > This never happens.
> >  
> >> +	}
> >> +
> >> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
> >> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
> >> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
> >> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;  
> > and here we end up derefencing random memory which happens in my case to cause
> > a massive allocation sometimes and that fails one of the assertions in the
> > allocator.
> >
> > I'd suggest just setting addr_sz[xxx] = {}; above
> > to ensure it's initialized. Then the if(ret) handling should not be needed
> > as well as of_property_read_u32 should be side effect free I hope!
> >  
> >> +		}
> >> +	}
> >> +
> >> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
> >> +	mapp = int_map;  

Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Lizhi Hou]

On 9/12/23 03:10, Jonathan Cameron wrote:
> On Mon, 11 Sep 2023 09:58:04 -0700
> Lizhi Hou <lizhi.hou@amd.com> wrote:
>
>> On 9/11/23 07:48, Jonathan Cameron wrote:
>>> On Tue, 15 Aug 2023 10:19:57 -0700
>>> Lizhi Hou <lizhi.hou@amd.com> wrote:
>>>   
>>>> 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>
>>> I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
>>> machine.
>>>
>>> There are some missing parts that were present in Clements series, but not this
>>> one, particularly creation of the root pci object.
>> Thanks for trying this. The entire effort was separated in different
>> phases. That is why this patchset does not include creating of_root.
>>> Anyhow, hit an intermittent crash...
>>>
>>>   
>>>> ---
>>>> +static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
>>>> +				struct device_node *np)
>>>> +{
>>>> +	struct of_phandle_args out_irq[OF_PCI_MAX_INT_PIN];
>>>> +	u32 i, addr_sz[OF_PCI_MAX_INT_PIN], map_sz = 0;
>>>> +	__be32 laddr[OF_PCI_ADDRESS_CELLS] = { 0 };
>>>> +	u32 int_map_mask[] = { 0xffff00, 0, 0, 7 };
>>>> +	struct device_node *pnode;
>>>> +	struct pci_dev *child;
>>>> +	u32 *int_map, *mapp;
>>>> +	int ret;
>>>> +	u8 pin;
>>>> +
>>>> +	pnode = pci_device_to_OF_node(pdev->bus->self);
>>>> +	if (!pnode)
>>>> +		pnode = pci_bus_to_OF_node(pdev->bus);
>>>> +
>>>> +	if (!pnode) {
>>>> +		pci_err(pdev, "failed to get parent device node");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>>>> +	for (pin = 1; pin <= OF_PCI_MAX_INT_PIN;  pin++) {
>>>> +		i = pin - 1;
>>>> +		out_irq[i].np = pnode;
>>>> +		out_irq[i].args_count = 1;
>>>> +		out_irq[i].args[0] = pin;
>>>> +		ret = of_irq_parse_raw(laddr, &out_irq[i]);
>>>> +		if (ret) {
>>>> +			pci_err(pdev, "parse irq %d failed, ret %d", pin, ret);
>>>> +			continue;
>>> If all the interrupt parsing fails we continue ever time...
>> Did you use Clement's patch to create of_root? I am just wondering if
>> parsing irq could fail on a dt-based system.
> For qemu already have of_root as there is still a device tree, it's just
> used to pass some stuff to EDK2 I think. I was carrying the Frank's
> series adding a bare device tree, it's just not doing anything on these
> systems
>
> I used Clements patch to add the pci root (cleaned up a bit to
> match the style of your series more closely).
>
> However, my interest is in ACPI based systems, not DT based ones.

Thanks for your clarification. I am also more interested in ACPI based 
system. After discussing with Rob, creating PCI nodes on DT based system 
is the first step to achieve this.


Lizhi

>
> Jonathan
>
>
>> And yes, the failure case should be handled without crash. I think if
>> irq parsing failed,  the interrupt-map pair generation should be skipped.
>>
>>
>> Thanks,
>>
>> Lizhi
>>
>>>   
>>>> +		}
>>>> +		ret = of_property_read_u32(out_irq[i].np, "#address-cells",
>>>> +					   &addr_sz[i]);
>>>> +		if (ret)
>>>> +			addr_sz[i] = 0;
>>> This never happens.
>>>   
>>>> +	}
>>>> +
>>>> +	list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {
>>>> +		for (pin = 1; pin <= OF_PCI_MAX_INT_PIN; pin++) {
>>>> +			i = pci_swizzle_interrupt_pin(child, pin) - 1;
>>>> +			map_sz += 5 + addr_sz[i] + out_irq[i].args_count;
>>> and here we end up derefencing random memory which happens in my case to cause
>>> a massive allocation sometimes and that fails one of the assertions in the
>>> allocator.
>>>
>>> I'd suggest just setting addr_sz[xxx] = {}; above
>>> to ensure it's initialized. Then the if(ret) handling should not be needed
>>> as well as of_property_read_u32 should be side effect free I hope!
>>>   
>>>> +		}
>>>> +	}
>>>> +
>>>> +	int_map = kcalloc(map_sz, sizeof(u32), GFP_KERNEL);
>>>> +	mapp = int_map;

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Rob Herring]

On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> > This patch series introduces OF overlay support for PCI devices which
> > primarily addresses two use cases. First, it provides a data driven method
> > to describe hardware peripherals that are present in a PCI endpoint and
> > hence can be accessed by the PCI host. Second, it allows reuse of a OF
> > compatible driver -- often used in SoC platforms -- in a PCI host based
> > system.
> >
> > There are 2 series devices rely on this patch:
> >
> >   1) Xilinx Alveo Accelerator cards (FPGA based device)
>
> >   2) Microchip LAN9662 Ethernet Controller
>
> I believe you should Cc this to Andrew Lunn for the comments.
> IIRC something similar was tried to being solved for DSA (?)
> devices where SFP hotpluggable hardware can be attached or
> detached at run-time (sorry if I messes / mixing up things,
> I wrote this from my memory, might be completely wrong).

Could be similar in the sense that this problem exists on any
discoverable bus with non-discoverable devices downstream.

The LAN9662 case is that it's an SoC that can run Linux. Standard
stuff there. You have a DT and a bunch of drivers and SoC support in
the kernel. Now take that same SoC with the CPU cores disabled and
expose the whole (or part of) SoC via PCIe to Linux running on another
host. How to reuse all the drivers? Yes, you could define swnode
stuff, but then the PCI driver becomes a board file (or multiple). In
fact that's what they started doing at one point. It doesn't scale.

> >      Please see: https://lore.kernel.org/lkml/20220427094502.456111-1-clement.leger@bootlin.com/
> >
> > Normally, the PCI core discovers PCI devices and their BARs using the
> > PCI enumeration process. However, the process does not provide a way to
> > discover the hardware peripherals that are present in a PCI device, and
> > which can be accessed through the PCI BARs. Also, the enumeration process
> > does not provide a way to associate MSI-X vectors of a PCI device with the
> > hardware peripherals that are present in the device. PCI device drivers
> > often use header files to describe the hardware peripherals and their
> > resources as there is no standard data driven way to do so. This patch
> > series proposes to use flattened device tree blob to describe the
> > peripherals in a data driven way. Based on previous discussion, using
> > device tree overlay is the best way to unflatten the blob and populate
> > platform devices. To use device tree overlay, there are three obvious
> > problems that need to be resolved.
> >
> > First, we need to create a base tree for non-DT system such as x86_64. A
> > patch series has been submitted for this:
> > https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> > https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/
>
> Can you point out to the ACPI excerpt(s) of the description of anything related
> to the device(s) in question?

I don't understand what you are asking for.

Rob

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Andy Shevchenko]

On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:

...

> > Can you point out to the ACPI excerpt(s) of the description of anything related
> > to the device(s) in question?
> 
> I don't understand what you are asking for.

Through the email thread it was mentioned that this series was tested on the
ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
DT for the something that ACPI already describes. That's why I'm trying to
understand if it's the case. and if so, how can we improve the approach.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Herve Codina]

Hi Andy,

On Wed, 13 Sep 2023 14:17:30 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:  
> > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:  
> 
> ...
> 
> > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > to the device(s) in question?  
> > 
> > I don't understand what you are asking for.  
> 
> Through the email thread it was mentioned that this series was tested on the
> ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> DT for the something that ACPI already describes. That's why I'm trying to
> understand if it's the case. and if so, how can we improve the approach.
> 

Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
was not provided by the firmware, bootloader, etc that run the kernel.

[1]: https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/

Current Lizhi's series creates nodes from the PCI host node during the PCI
enumeration. It creates PCI-PCI bridge and PCI device nodes.

I use these series on an ACPI system.

I need one more missing component: the node related to the PCI host bridge
This was the purpose of Clement's work. This work was not sent upstream yet and I
am working on it in order to have a full tree from the of_root to the PCI device
ie:
 of_root                  <-- Frank Rowand series 
   + of_host_pci_bridge   <-- Clement's work
       + pci_bridge       <-- Current Lizhi series
           + pci_bridge   <-- Current Lizhi series
            ...
             + pci_dev    <-- Current Lizhi series

Hope that this status helped.

Regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Andy Shevchenko]

On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> On Wed, 13 Sep 2023 14:17:30 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > <andriy.shevchenko@intel.com> wrote:  
> > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:  

...

> > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > to the device(s) in question?  
> > > 
> > > I don't understand what you are asking for.  
> > 
> > Through the email thread it was mentioned that this series was tested on the
> > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > DT for the something that ACPI already describes. That's why I'm trying to
> > understand if it's the case. and if so, how can we improve the approach.
> 
> Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> was not provided by the firmware, bootloader, etc that run the kernel.
> 
> [1]: https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> 
> Current Lizhi's series creates nodes from the PCI host node during the PCI
> enumeration. It creates PCI-PCI bridge and PCI device nodes.
> 
> I use these series on an ACPI system.
> 
> I need one more missing component: the node related to the PCI host bridge
> This was the purpose of Clement's work. This work was not sent upstream yet and I
> am working on it in order to have a full tree from the of_root to the PCI device
> ie:
>  of_root                  <-- Frank Rowand series 
>    + of_host_pci_bridge   <-- Clement's work
>        + pci_bridge       <-- Current Lizhi series
>            + pci_bridge   <-- Current Lizhi series
>             ...
>              + pci_dev    <-- Current Lizhi series
> 
> Hope that this status helped.

Thanks for the explanation! I suppose it's better to have three series combined
into one and being sent with a better cover letter to explain all this. Also it
might make sense (in my opinion) to Cc Jonathan (I did it here). Sorry, Jonathan,
if you are not wanting this.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Jonathan Cameron]

On Mon, 18 Sep 2023 10:17:26 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> > On Wed, 13 Sep 2023 14:17:30 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:  
> > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:  
> > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > <andriy.shevchenko@intel.com> wrote:    
> > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:    
> 
> ...
> 
> > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > to the device(s) in question?    
> > > > 
> > > > I don't understand what you are asking for.    
> > > 
> > > Through the email thread it was mentioned that this series was tested on the
> > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > DT for the something that ACPI already describes. That's why I'm trying to
> > > understand if it's the case. and if so, how can we improve the approach.  
> > 
> > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > was not provided by the firmware, bootloader, etc that run the kernel.
> > 
> > [1]: https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> > 
> > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> > 
> > I use these series on an ACPI system.
> > 
> > I need one more missing component: the node related to the PCI host bridge
> > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > am working on it in order to have a full tree from the of_root to the PCI device
> > ie:
> >  of_root                  <-- Frank Rowand series 
> >    + of_host_pci_bridge   <-- Clement's work
> >        + pci_bridge       <-- Current Lizhi series
> >            + pci_bridge   <-- Current Lizhi series
> >             ...
> >              + pci_dev    <-- Current Lizhi series
> > 
> > Hope that this status helped.  
> 
> Thanks for the explanation! I suppose it's better to have three series combined
> into one and being sent with a better cover letter to explain all this. Also it
> might make sense (in my opinion) to Cc Jonathan (I did it here). Sorry, Jonathan,
> if you are not wanting this.
> 
I'm lurking anyway via linux-pci :)

Indeed very interested in this.  I'm carrying a local copy of Clement's series but
more than happy if Herve gets that bit ready for upstream.

I think we are still some way from this all working for a non trivial PCI card
on an ACPI system though.  Maybe I'm wrong and the rest will turn out to be easy!

Jonathan

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Rob Herring]

On Mon, Sep 18, 2023 at 2:17 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> > On Wed, 13 Sep 2023 14:17:30 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > <andriy.shevchenko@intel.com> wrote:
> > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
>
> ...
>
> > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > to the device(s) in question?
> > > >
> > > > I don't understand what you are asking for.
> > >
> > > Through the email thread it was mentioned that this series was tested on the
> > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > DT for the something that ACPI already describes. That's why I'm trying to
> > > understand if it's the case. and if so, how can we improve the approach.
> >
> > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > was not provided by the firmware, bootloader, etc that run the kernel.
> >
> > [1]: https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> >
> > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> >
> > I use these series on an ACPI system.
> >
> > I need one more missing component: the node related to the PCI host bridge
> > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > am working on it in order to have a full tree from the of_root to the PCI device
> > ie:
> >  of_root                  <-- Frank Rowand series
> >    + of_host_pci_bridge   <-- Clement's work
> >        + pci_bridge       <-- Current Lizhi series
> >            + pci_bridge   <-- Current Lizhi series
> >             ...
> >              + pci_dev    <-- Current Lizhi series
> >
> > Hope that this status helped.
>
> Thanks for the explanation! I suppose it's better to have three series combined
> into one and being sent with a better cover letter to explain all this.

You can go back (years now) and see that. I asked for this to be split
up into manageable chunks and not solve multiple problems at once. No
point in trying to do DT on top of ACPI if DT on top of DT doesn't
work first.

Rob

Re: [PATCH V13 0/5] Generate device tree node for pci devices

[Herve Codina]

On Thu, 21 Sep 2023 07:20:46 -0500
Rob Herring <robh@kernel.org> wrote:

> On Mon, Sep 18, 2023 at 2:17 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:  
> > > On Wed, 13 Sep 2023 14:17:30 +0300
> > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:  
> > > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:  
> > > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > > <andriy.shevchenko@intel.com> wrote:  
> > > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:  
> >
> > ...
> >  
> > > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > > to the device(s) in question?  
> > > > >
> > > > > I don't understand what you are asking for.  
> > > >
> > > > Through the email thread it was mentioned that this series was tested on the
> > > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > > DT for the something that ACPI already describes. That's why I'm trying to
> > > > understand if it's the case. and if so, how can we improve the approach.  
> > >
> > > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > > was not provided by the firmware, bootloader, etc that run the kernel.
> > >
> > > [1]: https://lore.kernel.org/lkml/20220624034327.2542112-1-frowand.list@gmail.com/
> > >
> > > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> > >
> > > I use these series on an ACPI system.
> > >
> > > I need one more missing component: the node related to the PCI host bridge
> > > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > > am working on it in order to have a full tree from the of_root to the PCI device
> > > ie:
> > >  of_root                  <-- Frank Rowand series
> > >    + of_host_pci_bridge   <-- Clement's work
> > >        + pci_bridge       <-- Current Lizhi series
> > >            + pci_bridge   <-- Current Lizhi series
> > >             ...
> > >              + pci_dev    <-- Current Lizhi series
> > >
> > > Hope that this status helped.  
> >
> > Thanks for the explanation! I suppose it's better to have three series combined
> > into one and being sent with a better cover letter to explain all this.  
> 
> You can go back (years now) and see that. I asked for this to be split
> up into manageable chunks and not solve multiple problems at once. No
> point in trying to do DT on top of ACPI if DT on top of DT doesn't
> work first.

I agree.

Hervé

> 
> Rob



-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com