Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp922481pxb; Wed, 27 Oct 2021 15:16:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpQml/N+Gf3WweZgFEJw9tYIv3o01HZIApcspJgWEdJfqQe6C9jUXTQSv6K9nDVKOM8qR3 X-Received: by 2002:a63:7219:: with SMTP id n25mr321717pgc.253.1635373019679; Wed, 27 Oct 2021 15:16:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635373019; cv=none; d=google.com; s=arc-20160816; b=A+L9wZL3cmlwItveFW6tGilRbtCHL3a4XAZRMXo0AFy92A7JVuGRqd1OCiXlmChuea AsxDysDzc+GqFSNyF7tIIeCrsbJ/pNErZityg4jI/X/KzdCl4DCqsgUnR6B69FmT7LLc Of/vjWyKDWXW/OLNHX0bMaZ+W35nqrMpIgwSJZs0NiimddA5cpoF+vkkdVx5bDOTPLhg ctiiQhtKP/m7WTr0fySFegm4J7mOMsTgILdPa630iBuPsY6SoIg1N2nFs0ECre47waqe jR8MvwCRdL8yIAhKTE4sc7WAE8LcA7kpxdErLS3t+3IgvvVMS+GE3x+sKwkFsYpMZHn0 9E2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=D4Mhjd5SK9cIfjKibwbF4FuCWgAGy9+y27fhN/eSzIE=; b=FT2hrYgUufPkijLrbsjaz7iQEOypJIiAQP3xgl2Y3ttk8FSf0q+9xPU1nTC3VXrCPm /jofdhBxfxrzDFcx5eIOIsQYJyxs4CdxYCKeN9hEQgE+jGTXtJJHvjfmC5tq6usMenzi 25kjvuMGOYHTy0caMxvvbgcCB02yl8qJHvpae0zf6bvvMSIzG7yYzmuXtdux7UP3hGq3 r0xSOuhP5Ca3wpku4pMZl42nkNe+UMr5OO+9DhiMVoyZmbeO+wGUktmcmsr2vj5TpJIc WZg8tSoDnfw3gwlx5vD0DEN7DEqDZqxZlwPqCbF0VT/0NbBk45XxV9C36Rxy5iNqtwlA bPHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=SS9ik34d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p2si1713610plf.212.2021.10.27.15.16.47; Wed, 27 Oct 2021 15:16:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=SS9ik34d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230418AbhJ0VeT (ORCPT + 99 others); Wed, 27 Oct 2021 17:34:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235021AbhJ0Vdl (ORCPT ); Wed, 27 Oct 2021 17:33:41 -0400 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D12EDC061767 for ; Wed, 27 Oct 2021 14:31:13 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id d3so6426056wrh.8 for ; Wed, 27 Oct 2021 14:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D4Mhjd5SK9cIfjKibwbF4FuCWgAGy9+y27fhN/eSzIE=; b=SS9ik34dzGOmlT5pJQ6n/A0gLlqH6axzhvPLj1asy5cXMi/Pztt8zYq3QIwGh3z6v8 FIOoeDlTNaZEkCLnc0Rq5rDItgCA414QF1a4QrclIrISKwqur2SpZktfkrVSuCK3BtfI w0mk1uFX5tOYpTKs05FpMMqydPRfQGVjUtCnw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D4Mhjd5SK9cIfjKibwbF4FuCWgAGy9+y27fhN/eSzIE=; b=5w8Zjc8GFK8etl0Wem0RO6BlxT81HURcyAUy89lib4nu2L9qwNZFrGy4vVH9W8j2mh OQbgpnAIM6hI4s/3Rp78XPhQqO8Hdswy5RXdtMZ0fQqkl+iKAAA7zAqgclMaKRlqB7rU X1EqbpYsxIUz6yhHNp+McD1ekIjjNlWAq2pGQOI5GGAHMevCAYRa5PD5MQEa9wZpxnsD QPjE1C/rFfYKdE+KuSKgG1HUE7EiP7QAl2GzG/X5Qzg15yXD716q9A45g5llv5cy4Ttc DgMdMjV3jTfi2+0q4p74+02PUxlbsIZeAEtJ2zqbQAMSnp4QI7f4dEatxIQK5HtEdtay yJmA== X-Gm-Message-State: AOAM531BVntSG+EnFnqJ9TWiJjpsCDPFWy5njjXZXgE6OOXH14qshAzn PhrBJzIyWp0iTrEdYq3rMffr99eFClCKlRD0r+vMIg== X-Received: by 2002:a05:6000:1449:: with SMTP id v9mr157022wrx.433.1635370272200; Wed, 27 Oct 2021 14:31:12 -0700 (PDT) MIME-Version: 1.0 References: <20211022140714.28767-1-jim2101024@gmail.com> <20211022140714.28767-2-jim2101024@gmail.com> In-Reply-To: From: Jim Quinlan Date: Wed, 27 Oct 2021 17:31:01 -0400 Message-ID: Subject: Re: [PATCH v5 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators To: Rob Herring Cc: Jim Quinlan , "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" , Nicolas Saenz Julienne , Mark Brown , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Florian Fainelli , Bjorn Helgaas , Saenz Julienne , "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 4:54 PM Rob Herring wrote: > > On Tue, Oct 26, 2021 at 4:27 PM Jim Quinlan wrote: > > > > On Mon, Oct 25, 2021 at 6:24 PM Rob Herring wrote: > > > > > > On Fri, Oct 22, 2021 at 10:06:54AM -0400, Jim Quinlan wrote: > > > > Similar to the regulator bindings found in "rockchip-pcie-host.txt", this > > > > allows optional regulators to be attached and controlled by the PCIe RC > > > > driver. That being said, this driver searches in the DT subnode (the EP > > > > node, eg pci@0,0) for the regulator property. > > > > > > > > The use of a regulator property in the pcie EP subnode such as > > > > "vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml > > > > file at > > > > > > > > https://github.com/devicetree-org/dt-schema/pull/54 > > > > > > > > Signed-off-by: Jim Quinlan > > > > --- > > > > .../bindings/pci/brcm,stb-pcie.yaml | 23 +++++++++++++++++++ > > > > 1 file changed, 23 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml > > > > index b9589a0daa5c..fec13e4f6eda 100644 > > > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml > > > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml > > > > @@ -154,5 +154,28 @@ examples: > > > > <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>; > > > > brcm,enable-ssc; > > > > brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>; > > > > + > > > > + /* PCIe bridge */ > > > > > > More specifically, the root port. > > > > > > > + pci@0,0 { > > > > + #address-cells = <3>; > > > > + #size-cells = <2>; > > > > + reg = <0x0 0x0 0x0 0x0 0x0>; > > > > + device_type = "pci"; > > > > + ranges; > > > > + > > > > + /* PCIe endpoint */ > > > > + pci@0,0 { > > > > + device_type = "pci"; > > > > > > This means this device is a PCI bridge which wouldn't typically be the > > > endpoint. Is that intended? > > Hi Rob, > > > > I'm not sure I understand what you are saying -- do you want the > > innermost node to be named something like ep-pci@0,0, and its > > containing node pci-bridge@0,0? Or, more likely, I'm missing the > > point. If my DT subtree is this > > I'm confused as to how a bridge is the endpoint. If it is a bridge > (which 'device_type = "pci"' means it is), then there should be > another PCI device under it. That may or may not have a DT node. I did not know that device_type="pci" implies that it must be a bridge; [1] says "device_type" is deprecated for PCI and [2] defers to Open Firmware EEE 1275, which is not free AFAICT. Do you have better URLs that describe this? At any rate, I will remove the device_type="pci" from the innermost DT node, and resubmit. > > > pcie@8b10000 { > > compatible = "brcm,bcm7278-pcie"; > > .... > > pci-bridge@0,0 { > > reg = <0x0 0x0 0x0 0x0 0x0>; /* bus 0 */ > > ..... > > pci-ep@0,0,0 { > > reg = <0x10000 0x0 0x0 0x0 0x0>; /* bus 1 */ > > vpcie3v3-supply = <&vreg8>; > > ... > > } > > } > > } > > > > then the of_nodes appear to align correctly with the devices: > > > > $ cd /sys/devices/platform/ > > $ cat 8b10000.pcie/of_node/name > > pcie > > $ cat 8b10000.pcie/pci0000:00/0000:00:00.0/of_node > > pci-bridge > > $ cat 8b10000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/of_node/name > > pci-ep > > What does 'lspci -tv' show? $ lspci -tv -+-[0000:01]---00.0 Intel Corporation Wireless 7260 \-[0000:00]---00.0 Broadcom Inc. and subsidiaries Device 7278 > > > > > and the EP device works of course. I've even printed out the > > device_node structure in the EP driver's probe and it is as expected. > > I've noticed that examples such as > > "arch/arm64/boot/dts/nvidia/tegra186.dtsi" have the EP node (eg > > pci@1,0) directly under the > > host bridge DT node (pcie@10003000). I did try doing that, but the EP > > device's probe is given a NUL device_node pointer. > > If you want a complex example I know that's right, then see hikey970. Thanks, will look. Jim [1] https://buildmedia.readthedocs.org/media/pdf/devicetree-specification/latest/devicetree-specification.pdf [2] https://www.openfirmware.info/data/docs/bus.pci.pdf > > Rob