Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7145382ybp; Wed, 16 Oct 2019 04:34:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqwn39fyU4YssA/Yc3f/dZOTpet28AY0Mk2OvMVuDZ6SfO+8s835IDfQlBTcC1HiF6W8dQhD X-Received: by 2002:a05:6402:794:: with SMTP id d20mr18871903edy.240.1571225693190; Wed, 16 Oct 2019 04:34:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571225693; cv=none; d=google.com; s=arc-20160816; b=gPAY5VpoMrngzUxFv0wjuPeklgR+MPRK4OHF1XHgSRVpgubJs7faXFVh5+Z9NH2uH1 hiABZuoOXuXJugxLQXaNYGunj18prgfbbO21i39lYz7GUJdhov2OmfvdzQNRK/QvyZ2q +Q1Zg4c8R6p1y+NSUu9VsFL8Pja4FCF+IRyetBOGifBoBtilemThat7v1MtsZ52S6Lmp h6jIClKu8yVg6unNmg6zlftBaxiitucq6bMCROlJWzq/SSA3bPNekljdrfULlNYPWXsL a2Gz8At0GkhEzjxaFqMCNk/B40OESPdNAKsMYovnbQBcLxs88ozE8K4z6tpuF05hRE7z TqGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=2e1ep+jz9ThULjwuPHURE/WBfxKsgQ0iJmPcL/PVeZo=; b=Eyo2oKXRoIg5xOXQ21riXC/3OMDK8LgPawAkcYXP+mNrZabFuucY1XzjXfIPiJrbyz vBdv+si9sqkgbVWqkNk1poqlPLcRjhebv64cjL2grkbLkAIuti19F3xU9po0JgtOaM6T Cl5m8wIIPKpA2TPiVVm4tFcx0vZG+rdwM9APnh+aZ+92FzYSa6M3wMmGb1C6qhegnUsx K9gjymmhJ13DOV/OzL9LAIYrUqCNBsZ4nw51T5JdfGaabDkYndsSjokkxTtzsFi0HbNX 1ferL74ZcxuRcjzKc5dwLnudfIaPdEzK6zTJ2TGfMW2d0Im/AQCpzSPzHSpbzq9rvz9j hn8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=SfJcnijl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v2si17199798edm.80.2019.10.16.04.34.30; Wed, 16 Oct 2019 04:34:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=SfJcnijl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391169AbfJPEqM (ORCPT + 99 others); Wed, 16 Oct 2019 00:46:12 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:50834 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391117AbfJPEqM (ORCPT ); Wed, 16 Oct 2019 00:46:12 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id x9G4k1Q9130349; Tue, 15 Oct 2019 23:46:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1571201161; bh=2e1ep+jz9ThULjwuPHURE/WBfxKsgQ0iJmPcL/PVeZo=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=SfJcnijlf1XwiD6nqRxlO3e9zzuqWTguFxaNWOVio66d/ssT0/dJd4IzEZMiEqzea KRFef42cOE1obpQC6z4BX4mf0X6fh08o33i9nOX+whSfsc1OK5JIeVQqRZuvJSc7ph cP+UWXKr3skoqMbAefp3lWgOo0a1IVNdamID15UA= Received: from DLEE101.ent.ti.com (dlee101.ent.ti.com [157.170.170.31]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x9G4k1NQ001573 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Oct 2019 23:46:01 -0500 Received: from DLEE107.ent.ti.com (157.170.170.37) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 15 Oct 2019 23:45:54 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Tue, 15 Oct 2019 23:46:00 -0500 Received: from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id x9G4jqTh107770; Tue, 15 Oct 2019 23:45:54 -0500 Subject: Re: [RFC PATCH 02/21] dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Device To: Rob Herring CC: Bjorn Helgaas , Jonathan Corbet , Jon Mason , Dave Jiang , Allen Hubbe , Lorenzo Pieralisi , Mark Rutland , , , , , References: <20190926112933.8922-1-kishon@ti.com> <20190926112933.8922-3-kishon@ti.com> <20191015184243.GA10228@bogus> From: Kishon Vijay Abraham I Message-ID: Date: Wed, 16 Oct 2019 10:15:23 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191015184243.GA10228@bogus> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/10/19 12:12 AM, Rob Herring wrote: > On Thu, Sep 26, 2019 at 04:59:14PM +0530, Kishon Vijay Abraham I wrote: >> Add device tree bindings for PCI endpoint function device. The >> nodes for PCI endpoint function device should be attached to >> PCI endpoint function bus. >> >> Signed-off-by: Kishon Vijay Abraham I >> --- >> .../bindings/pci/endpoint/pci-epf.txt | 28 +++++++++++++++++++ >> 1 file changed, 28 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/pci/endpoint/pci-epf.txt > > This and the previous patch for the bus should be combined and please > convert to a schema. Sure Rob. Thanks for the review. -Kishon > >> >> diff --git a/Documentation/devicetree/bindings/pci/endpoint/pci-epf.txt b/Documentation/devicetree/bindings/pci/endpoint/pci-epf.txt >> new file mode 100644 >> index 000000000000..f006395fd526 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pci/endpoint/pci-epf.txt >> @@ -0,0 +1,28 @@ >> +PCI Endpoint Function Device >> + >> +This describes the generic bindings to be used when a device has to be >> +exposed to the remote host over PCIe. The device could be an actual >> +peripheral in the platform or a virtual device created by the software. >> + >> +epcs : phandle to the endpoint controller device >> +epc-names : the names of the endpoint controller device corresponding >> + to the EPCs present in the *epcs* phandle > > Other than the NTB case, I'd expect the parent device to be the > controller. Let's make NTB the exception... > > >> +vendor-id: used to identify device manufacturer >> +device-id: used to identify a particular device >> +baseclass-code: used to classify the type of function the device performs >> +subclass-code: used to identify more specifically the function of the device > > Are these codes standard? > > Powerpc has "class-code" already... > >> +subsys-vendor-id: used to identify vendor of the add-in card or subsystem > > Powerpc has "subsystem-vendor-id" already... > >> +subsys-id: used to specify an id that is specific to a vendor >> + >> +Example: >> +Following is an example of NTB device exposed to the remote host. >> + >> +ntb { > > This is going to need some sort of addressing (which implies 'reg')? If > not, I don't understand why you have 2 levels. > >> + compatible = "pci-epf-ntb"; >> + epcs = <&pcie0_ep>, <&pcie1_ep>; >> + epc-names = "primary", "secondary"; >> + vendor-id = /bits/ 16 <0x104c>; >> + device-id = /bits/ 16 <0xb00d>; > > These have a long history in OF and should be 32-bits (yes, we've let > some cases of 16-bit creep in). > >> + num-mws = <4>; > > Doesn't this apply to more than NTB? > > Can't you just get the length of 'mws-size'? > >> + mws-size = <0x100000>, <0x100000>, <0x100000>, <0x100000>; > > Need to support 64-bit sizes? > >> +}; >> -- >> 2.17.1 >>