Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp47989iob; Tue, 3 May 2022 11:20:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlLJlhGSCFjLDEyOqwlARKwc93yQVL2gdudjFJcvEoX2AvZ3927K+wstNqfhFxqQsEh4lG X-Received: by 2002:a17:90a:de87:b0:1d9:8264:baef with SMTP id n7-20020a17090ade8700b001d98264baefmr6090973pjv.227.1651602056834; Tue, 03 May 2022 11:20:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651602056; cv=none; d=google.com; s=arc-20160816; b=Q+N1SLeP63FBd6TP4rf9g11z0Ee+2sK0QKsnYq/y75kCZ4Z2cALR1O0UOjZXwyyWPG 6wK4iZGrtqeNDEeq4xeriGSaN7UGu2cxEdBk0lliqPwPp1qFRfxmoUGjQb733H7JpNc/ ilDKCLXvX9OqtgpSMz9cidb6K3oHt+vOGU1O2qoPO2yAmfhtCCRXFrfJFxyG1rO+MBQj uc7Y+gYyiVH/9Lq2jLBxnAT5PNJzA0N0Pvf9PCtSfMhQOmhcqDyR1dGc31xdgC4cIqaU 0ANusodbqKPpPi8ZOn5g293F92TLm60O7A08zBXECITK/G8ZCRqB7Ens5xL+qYsAi2sD cRwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+YF29TZi131w+V+niyw8f+5BrVYB2TL4PkQPvgOxC1c=; b=0w4MVg4hK3jwFmjxhJdKRNUoyv8W+3CF7OIJGwy/HqLmTbDNjkjXnJtVOUPojP2ifL dd4ZuD98HfFDI0WrFqPAkLe6zNCikIG255U218EFhqk59l2T8W3ptnaM9z9/GG9/kK9x FKa23bZOJOiYSxMo8ymUWTCciZRR/BscbeWd07O4Ebq27JhWjj/LGUYR1amK21xGM6da GsYT7DUP35gz/+csMYVNwgPxqcr6chfl9ov6+HdDv1CVhmpy6Gdfy2D1obprqBs4EOp9 F+qGuuJctrS+9+CQ0rMPiTAXzASy3Qm8Kxc/7KLXnTq2TygWO5+ZlVquuoIK17deDiCJ +Q4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q20-20020a656854000000b0039d67613687si17273139pgt.701.2022.05.03.11.20.38; Tue, 03 May 2022 11:20:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236747AbiECOPm (ORCPT + 99 others); Tue, 3 May 2022 10:15:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236013AbiECOPl (ORCPT ); Tue, 3 May 2022 10:15:41 -0400 Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90A451581B; Tue, 3 May 2022 07:12:08 -0700 (PDT) Received: by mail-oo1-f50.google.com with SMTP id y27-20020a4a9c1b000000b0032129651bb0so3113840ooj.2; Tue, 03 May 2022 07:12:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+YF29TZi131w+V+niyw8f+5BrVYB2TL4PkQPvgOxC1c=; b=kyjmNVAk+5Plm1ZZ7PK1tWgvYl3lczYhmf44lu0dWmNQN8CK1R08C5aJmn7JyX53vX gF+vZrFRPRMsdQkO9PRtqQAqjTdezF7eHbkti2w1N+AxyU0XsKuuPlKRhU/N/dm41ZOC srFlJ1Ioqqo/vZ8TiQbdjGh2ks+2vPxfZvboffrEqPLQiy6GPynM1Y/daTjK6EsUg4fw lyYpOx8UPbQNJDZ5ywKkEb48Bxg184+aKl70tbqRzYCkqj9vjTKua8XK4XFW6+aW+aoY NuFpNQyRHiS8yhkzzOQR87/ezEtn5k1L7nxTnjTF3IInx8St3Rwnd1ivf430WC6edHWQ j7/Q== X-Gm-Message-State: AOAM531UnVipyNF/ECr1Z8wzBZmUE8fHXH3vv7yI3/6KGkO67QyuGp6W PHB9ewQpnBlWuYmn8LjD6w== X-Received: by 2002:a4a:e8cc:0:b0:35f:6c5:a41a with SMTP id h12-20020a4ae8cc000000b0035f06c5a41amr2262794ooe.74.1651587127814; Tue, 03 May 2022 07:12:07 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id f9-20020a0568301c2900b0060603221247sm3981516ote.23.2022.05.03.07.12.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 May 2022 07:12:07 -0700 (PDT) Received: (nullmailer pid 3564454 invoked by uid 1000); Tue, 03 May 2022 14:12:06 -0000 Date: Tue, 3 May 2022 09:12:06 -0500 From: Rob Herring To: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= Cc: Frank Rowand , Pantelis Antoniou , Bjorn Helgaas , Allan Nielsen , Horatiu Vultur , Steen Hegelund , Thomas Petazzoni , Alexandre Belloni , Mark Brown , Andy Shevchenko , Jakub Kicinski , Hans de Goede , Andrew Lunn , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 2/3] PCI: of: create DT nodes for PCI devices if they do not exists Message-ID: References: <20220427094502.456111-1-clement.leger@bootlin.com> <20220427094502.456111-3-clement.leger@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220427094502.456111-3-clement.leger@bootlin.com> X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2022 at 11:45:01AM +0200, Cl?ment L?ger wrote: > In order to apply overlays to PCI device nodes, the nodes must first > exist. This commit add support to populate a skeleton tree for PCI bus > and devices. These nodes can then be used by drivers to apply overlays. > While I implemented this creating the nodes as the PCI devices are created, I think probably we're going to want to create the device node and any needed parent nodes on demand. Otherwise, just turning on CONFIG_OF could break platforms. One potential issue is that fwnode assumes there is either a DT node or ACPI node. With this, we have the potential for both. I'm not sure how much that's going to be an issue. > Co-developed-by: Rob Herring > Signed-off-by: Rob Herring > Signed-off-by: Cl?ment L?ger > --- > drivers/pci/of.c | 184 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 184 insertions(+) > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index cb2e8351c2cc..f2325708726e 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -16,12 +16,194 @@ > #include "pci.h" > > #ifdef CONFIG_PCI > +static int of_pci_add_property(struct of_changeset *ocs, struct device_node *np, > + const char *name, const void *value, int length) Nothing really PCI specific about this function. The kernel support for creating nodes and properties is pretty poor. We should improve it with functions like this (in drivers/of/). Maybe the changeset part should be separate though. We have some cases of creating properties or nodes already, and whatever new APIs we make those cases should be able to use them. And if they are converted, then it can be merged sooner rather than when all the PCI parts are ready. > +{ > + struct property *prop; > + int ret = -ENOMEM; > + > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > + if (!prop) > + return -ENOMEM; > + > + prop->name = kstrdup(name, GFP_KERNEL); > + if (!prop->name) > + goto out_err; > + > + if (value) { > + prop->value = kmemdup(value, length, GFP_KERNEL); > + if (!prop->value) > + goto out_err; > + } else { > + /* > + * Even if the property has no value, it must be set to a > + * non-null value since of_get_property() is used to check > + * some values that might or not have a values (ranges for > + * instance). Moreover, when the node is released, prop->value > + * is kfreed so the memory must come from kmalloc. > + */ > + prop->value = kmalloc(1, GFP_KERNEL); > + if (!prop->value) > + goto out_err; > + } > + > + of_property_set_flag(prop, OF_DYNAMIC); > + > + prop->length = length; > + > + ret = of_changeset_add_property(ocs, np, prop); > + if (!ret) > + return 0; > + > +out_err: > + kfree(prop->value); > + kfree(prop->name); > + kfree(prop); > + > + return ret; > +} > + > +static struct device_node *of_pci_make_node(void) > +{ This isn't PCI specific either. > + struct device_node *node; > + > + node = kzalloc(sizeof(*node), GFP_KERNEL); > + if (!node) > + return NULL; > + > + of_node_set_flag(node, OF_DYNAMIC); > + of_node_set_flag(node, OF_DETACHED); > + of_node_init(node); > + > + return node; > +} > + > +static int of_pci_add_cells_props(struct device_node *node, > + struct of_changeset *cs, int n_addr_cells, > + int n_size_cells) > +{ > + __be32 val; > + int ret; > + > + ret = of_pci_add_property(cs, node, "ranges", NULL, 0); The host bridge node is going to need to fill in 'ranges'. Empty ranges is not valid when there's a change in number of cells. The root node also will need "#address-cells" and "#size-cells". > + if (ret) > + return ret; > + > + val = __cpu_to_be32(n_addr_cells); > + ret = of_pci_add_property(cs, node, "#address-cells", &val, > + sizeof(__be32)); > + if (ret) > + return ret; > + > + val = __cpu_to_be32(n_size_cells); > + return of_pci_add_property(cs, node, "#size-cells", &val, > + sizeof(__be32)); > +} > + > +static int of_pci_add_pci_bus_props(struct device_node *node, > + struct of_changeset *cs) > +{ > + int ret; > + > + ret = of_pci_add_property(cs, node, "device_type", "pci", > + strlen("pci") + 1); > + if (ret) > + return ret; > + > + return of_pci_add_cells_props(node, cs, 3, 2); > +} > + > +static void of_pci_make_dev_node(struct pci_dev *dev) > +{ > + static struct of_changeset cs; > + const char *pci_type = "dev"; > + struct device_node *node; > + __be32 val[5] = {0}; > + int ret; > + > + node = of_pci_make_node(); > + if (!node) > + return; > + > + node->parent = dev->bus->dev.of_node; > + of_changeset_init(&cs); > + > + if (pci_is_bridge(dev)) { > + ret = of_pci_add_pci_bus_props(node, &cs); > + if (ret) > + goto changeset_destroy; > + pci_type = "pci"; > + } > + > + node->full_name = kasprintf(GFP_KERNEL, "%s@%x,%x", pci_type, > + PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn)); > + > + val[0] = __cpu_to_be32(dev->devfn << 8); > + val[4] = __cpu_to_be32(SZ_4K); > + ret = of_pci_add_property(&cs, node, "reg", val, 5 * sizeof(__be32)); > + if (ret) > + goto changeset_destroy; > + > + ret = of_changeset_attach_node(&cs, node); > + if (ret) > + goto changeset_destroy; > + > + ret = of_changeset_apply(&cs); > + if (ret) > + goto changeset_destroy; > + > + dev->dev.of_node = node; > + > + return; > + > +changeset_destroy: > + of_changeset_destroy(&cs); > + kfree(node); > +} > + > +static struct device_node *of_pci_create_root_bus_node(struct pci_bus *bus) > +{ > + static struct of_changeset cs; > + struct device_node *node; > + int ret; > + > + node = of_pci_make_node(); > + if (!node) > + return NULL; > + > + node->full_name = "pci"; > + node->parent = of_root; > + > + of_changeset_init(&cs); > + ret = of_pci_add_pci_bus_props(node, &cs); > + if (ret) > + goto changeset_destroy; > + > + ret = of_changeset_attach_node(&cs, node); > + if (ret) > + goto changeset_destroy; > + > + ret = of_changeset_apply(&cs); > + if (ret) > + goto changeset_destroy; > + > + return node; > + > +changeset_destroy: > + of_changeset_destroy(&cs); > + kfree(node); > + > + return NULL; > +} > + > void pci_set_of_node(struct pci_dev *dev) > { > if (!dev->bus->dev.of_node) > return; > dev->dev.of_node = of_pci_find_child_device(dev->bus->dev.of_node, > dev->devfn); > + if (!dev->dev.of_node) > + of_pci_make_dev_node(dev); > if (dev->dev.of_node) > dev->dev.fwnode = &dev->dev.of_node->fwnode; > } > @@ -39,6 +221,8 @@ void pci_set_bus_of_node(struct pci_bus *bus) > > if (bus->self == NULL) { > node = pcibios_get_phb_of_node(bus); > + if (!node) > + node = of_pci_create_root_bus_node(bus); > } else { > node = of_node_get(bus->self->dev.of_node); > if (node && of_property_read_bool(node, "external-facing")) > -- > 2.34.1 > >