Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp2479167rdb; Tue, 12 Sep 2023 03:17:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGQFLpk27vUn14f7oWgaM9dqiR4OdE/tG9oQCi0j0rCNeRStAWhxKbMaN9kligmvUzs26eJ X-Received: by 2002:a05:6a21:181:b0:14e:509:1d7b with SMTP id le1-20020a056a21018100b0014e05091d7bmr13381478pzb.8.1694513833824; Tue, 12 Sep 2023 03:17:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694513833; cv=none; d=google.com; s=arc-20160816; b=Ku4xFp6hCMtr/vjEUg+ghlBnA2ZQQAxaNDAQPqLQ/f+6h+TFnYTFw5BVQce5W2umbo TRNE+nr6FDOf8nLu+Zf3k4QCsKXt+DzMakC3qbG5Vpsh66tdk59f8ITW5ImoEsQ/ooy3 ypFiwoK3wlcf+60BysvzJwO0fOxkHcU+i5DGBq5UKrlVgIK7Kb/tXnfHRTBbak62+GVC 5sF8KeUy6Qvg/LKIc1xQOvXkoMUFHlHN+phDcuAOJ3Fg9ovEhIVu0SmYd6h9zAmjU7PU oJ0zFedwYiCgqACUoBnwMuSo3emTZGsJkoacME1566z1g66T90JNcnlLsdLP4zpgD6+y /H2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=MbhsDnqGlbHuwcjRtWyhQTaXWJErP+tfbCsDpG8/Vmg=; fh=a/y2e9CdEQq0gK7HmqUGJsIoNitxXaVUkhN3kNef5fc=; b=KqPD/YORvjONjZXCXfixva8baCbLm/tOpb5c6RWvNsnFYxH7IZFeeVCmaS0N+hXUFR 6PZVfgmKo2Q1gI+hc2zjKCth73IpvY2n8dOFl7a/2+344bcBeFn6TrV5k/TR7qnJPf0K ZhrhhW3PHxIY87wPeFWvP8Q2pNwpqlXisvPDCpvK5x0+8laJSm5/jzqs7RHy+2rturO1 hsWnDpbL66mS+hrOkcM049SLa5KWdEJLcRzIgytDly8GQhnC1c5+hXT7Pzblvhjqn8bn KrOg37GTyhwaG+5X6KymA0bLx+N8LRjbbdijoKGMxEeyeRz0JHKdcGDmWNbznPcQ1z62 1ZPg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id g15-20020a17090adb0f00b00268067839c9si7629425pjv.106.2023.09.12.03.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 03:17:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 12F04801DBAB; Tue, 12 Sep 2023 03:11:18 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.8 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231574AbjILKLL convert rfc822-to-8bit (ORCPT + 99 others); Tue, 12 Sep 2023 06:11:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233688AbjILKK7 (ORCPT ); Tue, 12 Sep 2023 06:10:59 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2143172E; Tue, 12 Sep 2023 03:10:38 -0700 (PDT) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RlK6w4s01z6HJlZ; Tue, 12 Sep 2023 18:08:56 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 12 Sep 2023 11:10:35 +0100 Date: Tue, 12 Sep 2023 11:10:35 +0100 From: Jonathan Cameron To: Lizhi Hou CC: , , , , , , , =?ISO-8859-1?Q?C?= =?ISO-8859-1?Q?l=E9ment_L=E9ger?= Subject: Re: [PATCH V13 2/5] PCI: Create device tree node for bridge Message-ID: <20230912111035.00002e9b@Huawei.com> In-Reply-To: <0cc232a2-1743-aeaa-cb87-ce320cc9fc39@amd.com> References: <1692120000-46900-1-git-send-email-lizhi.hou@amd.com> <1692120000-46900-3-git-send-email-lizhi.hou@amd.com> <20230911154856.000076c3@Huawei.com> <0cc232a2-1743-aeaa-cb87-ce320cc9fc39@amd.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500006.china.huawei.com (7.191.161.198) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 12 Sep 2023 03:11:18 -0700 (PDT) X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email On Mon, 11 Sep 2023 09:58:04 -0700 Lizhi Hou wrote: > On 9/11/23 07:48, Jonathan Cameron wrote: > > On Tue, 15 Aug 2023 10:19:57 -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 > >> Signed-off-by: Lizhi Hou > > 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;