From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757185AbcBHW4s (ORCPT ); Mon, 8 Feb 2016 17:56:48 -0500 Received: from mail-bn1bon0097.outbound.protection.outlook.com ([157.56.111.97]:35616 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753872AbcBHW4q (ORCPT ); Mon, 8 Feb 2016 17:56:46 -0500 X-Greylist: delayed 896 seconds by postgrey-1.27 at vger.kernel.org; Mon, 08 Feb 2016 17:56:45 EST Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=caviumnetworks.com; Message-ID: <56B919A5.5090000@caviumnetworks.com> Date: Mon, 8 Feb 2016 14:41:41 -0800 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bjorn Helgaas CC: Rob Herring , David Daney , Bjorn Helgaas , "linux-pci@vger.kernel.org" , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , David Daney Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com> <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com> <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost> In-Reply-To: <20160208221204.GA30821@localhost> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: BN1PR07CA0037.namprd07.prod.outlook.com (10.255.193.12) To CY1PR07MB2135.namprd07.prod.outlook.com (25.164.112.13) X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;2:efFgIGzjoP+pu5+6IztQ8j32M9kvESiGma1HULaU6owic0IRcfucQ6x0E359S2xnHmq3GW9VR6Q7nQQbJSuhv1O8zHf0zQ2o63YSDWhTzRvwZQL0FJigxXiGT0pKSanPFpiCCpsKz9CdVT9Hb9Tzmg==;3:0+4a58dM02QTVIRGNKQn5V+nfh4og36H8v+0yLX/piARP3pZwSDgMo3GvtatqHSz+wiaP5j8zYVk/5IwUaN/gsPVZGfGCuGxWBRgEgDTGsUyyAIqERoltOJGveA6pDVl;25:Luhzw3jXl0bCH0K8/sep220Zki05D/fBTjH7QGxdVzsST2TPSnJtgBxNl3jgw2+14nPM5oMQwIooroQhO3Apk948K+0vk0hoDiIU2UCbMhwuJOwJTQrFRuzlQWm8mAkiGsHCHD8aD76X16r6oiv9k5YjV4CDFMwef5yxsTTZYVZpESJEyDKL9N0JPnGNl8JrfOKNlE0WqcbaBH3TPKJ9MvCMQDEFtfj7dyyIEKCB8FGAFWPP7gVQt2KTy9dFsXDs958VClr5anOVb1mvGIMOSopd7KSzkI8QGOt6WAhavmQ7eSsEJxrvZ1bZDgThsr5O X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2135; X-MS-Office365-Filtering-Correlation-Id: 9cede1a3-aa78-4ad0-099a-08d330d90722 X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;20:YMrsABBiXZRdEvyWRlJYTsDXmCbbc6KbqRTDhHucnNn+QNRnA9ACYuUbA+05e8u+vrHdtkmUmoiCE+PenXv0gkOw0B29HnVyYCDhdDn/YHVK62LtunP/Qb/M/dalhmrMGJD6gQ/umvp2QytaoDyZJdsGQw1RRBnCK9ltfbtX2YisjMVRRhSGki74fiukMJAy2CDShs5yE+f/kiSjvkc9WRRwpPlqhGcAXE6qcvQODRy7THr1zSn9Kgq6KrwF1xwxxY25/Xw0jno2VgeuglxIlKAA7Kj16yZyhTJrlwMTeTHgo+jIOvGeHROKR81w2zxs4aDSYLZsJ41lT+jo4iQr8KkFO6F0Ne3SwdOlgqFxugCDqXAE2ZO0/wIbJwpX9/KyezoEP1fRRdEicAhcZW8867POMHpMz5IFQt29v+H0ZF3+FMjYL+U/ZxIYTWhXyAWQhNspyT8R7pNbob9ysgYrYDKWkJbHgMeasceogfKnVWl2zAoww9443EVZNxSoAw26uWCgZvp/2msXdf2qEMHc7XsF5jZk7wEFA4ypm+4CkF1rUwjXtB233YSvPj1Y47JPv96QKpLQw8KL5ojojPU/LzeoAFesqHXujd/ToZvoMWQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:CY1PR07MB2135;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2135; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;4:UupwFfTYm1TgwB0MsMkf1/Ef8fZuZmWPRaun7lzQ1hzreG36notU5gy4DC/551G9Je5QqWaU5yQnrBzqHi2oLyOHrjYIUAMLu5wPqvag11+8dtKywYzN8jffd50t8lDx47FbT7qzhoJnnBy2btf/aN+8wixdrtZ4Ajm+8txbrYJ7cPY1lsocLjhBfwIV1VS69QpGWQbpZpax0LIKo9E69EB6LOAsAB15Q/Bf84uNX5xJFmkobjkce9GvsfdtUKzsVYyv2CSK/g7LkiGNr7mnwvvKa0H6VI2BrCvNpCTpDUUdu9lWqYU9EZINDnS1gyitMf1obJN5EE56mNm+mjF9x08vSc54XJmoPSjPvnG8LxbFS/sY9QRUwe5cqRUQnSGH X-Forefront-PRVS: 084674B2CF X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(377454003)(24454002)(479174004)(2906002)(230700001)(4326007)(50466002)(36756003)(77096005)(2950100001)(64126003)(23756003)(4001350100001)(5008740100001)(189998001)(3846002)(80316001)(110136002)(6116002)(19580395003)(19580405001)(5001960100002)(92566002)(1096002)(59896002)(586003)(230783001)(65956001)(87976001)(83506001)(47776003)(42186005)(93886004)(65806001)(5004730100002)(66066001)(53416004)(33656002)(54356999)(50986999)(87266999)(76176999)(65816999)(122386002)(40100003);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2135;H:dl.caveonetworks.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;CY1PR07MB2135;23:lS8AXwy+ikL2iyshhda8CM5moz8UBKQ6530kBiP?= =?iso-8859-1?Q?24sj2chzLaudWt1PwGIlfwvc8xmfhEvOsPQfAeH/UbpW2n5YWkgoMTgvLF?= =?iso-8859-1?Q?6ZPa1ZSjkLDitgcJM+vam3yuVXLq5kGQrcoYVVjXpSBOLCjOu/hlCDKJd7?= =?iso-8859-1?Q?Bu8CxzvAC4DMwGn485q+IOT09Zoa81Tws2+md1wUeDkyr8xOhXDD6zMxHm?= =?iso-8859-1?Q?2KvWWvzZRUVJF1Gig52HjZqvK46D9ce4CkFlxrViojfbDvReR8w4LgtbRA?= =?iso-8859-1?Q?oViDABxmIBTPtwcm1iuajzpVniglNV4ywio7aj+xQeW/ltNZTal2MuX/M4?= =?iso-8859-1?Q?3jQBIwZziW+qeWPyAGSCWAc22rQ3EEuoX/5Z1WTov1cFbz/z3WWjm9P2sM?= =?iso-8859-1?Q?5pR4GNeCrKZwhGxVjzwt6uhSRCFQYLwJF4G1OSAVWXUZH689Rq+aZBongr?= =?iso-8859-1?Q?pxpfuvmgmCOVOEbIjOsvNFv+0rkDXcf4+ppsZeCqBEU7b8QAQ8/oexOj59?= =?iso-8859-1?Q?KLD6ew9Na9kFAE/hc1XOIf7JzWaexBQh9ogglDaRuoUDZh6+PaM5HokJ5b?= =?iso-8859-1?Q?Aqe2VrLogA3CKnuc19Wm3rR6bKMUd5/PWQ/3Vm6D0kZ2BbmjbFb3tM2SdU?= =?iso-8859-1?Q?3GFYRWRdZ+utHuEFpvK97Ue68g0xnJeW9QT7IfytGFfIgmtGyD3io9+I7C?= =?iso-8859-1?Q?oR7+bZ5/89jOL21l0N/PXUPRSUIyo5WusNEkGFwxesDDFDEwCK8zGJIvBE?= =?iso-8859-1?Q?CNtsPK4Ww8pFqrovkpmtiTlRo0rW79I/P0I2Tylgw8SXnUJJ8FhvzooPr/?= =?iso-8859-1?Q?Fi2BUYzzwP7pzyqo9YEKDMay1+BHXneTxHyXGaMDczB7Exi2989IroYfo1?= =?iso-8859-1?Q?CXGpMAcVMEIyjheUxA9XGt2fsQdxtvO2JeaMC6ahA5A1eKX9XM0GJZ7mRx?= =?iso-8859-1?Q?2l3HdtE7RUAix3l8StZYs8K766ayJr3gGPWvZKorH8ogi9Kj8MlkUTUq1v?= =?iso-8859-1?Q?8BG8osrTqg5xyoaJvVnfg7cnEdEtz6kyvEREbXVujgcLY7ERf7kMB1Ddf9?= =?iso-8859-1?Q?L/03nasnnaFfvpFBTuOAltfEuvENtRjfZIh40MPG57cHvOOXhxePiscNFc?= =?iso-8859-1?Q?uZOYQxSKLrZGl/kneadqkjiXCDL37C64nJ5utYQm1DTd2LjJqSIDELxOas?= =?iso-8859-1?Q?UJ0ywWZUJKR1XCxaDasxKQZUuZsJrUcBa5WM2sTgBAVuWcHL02SrxrQ1Ot?= =?iso-8859-1?Q?tCS4g3g0S2J80NAXf?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;5:+qGVFwl/Ut4QtGGSzPsVY2Q3wotoEtUnLKiP7Bm0xmEhY6BlPVWW1pHiMFAaYKU5Kk1O/jOOKxhZdLWX0+WA0yHDAAY4gNQhYpkbsNMkjauYKB0r28Nb2OSuI8sLBVrWRP3SgW7pH2FHd193Rv2eKA==;24:ChdB1otLaqgURCHsscdvE4vKiHS99KFib3cQ6t5Y6IhUY7/Mv0PQFV7Te9F55htP/HJhqVZFUEvMvK+mcTkUJyzYstdCEYn14hwi4GQQnf8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2016 22:41:45.1953 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2135 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/08/2016 02:12 PM, Bjorn Helgaas wrote: > On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote: >> On 02/08/2016 01:12 PM, Rob Herring wrote: >>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney wrote: >>>> On 02/08/2016 11:56 AM, Rob Herring wrote: >>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote: >>>>>> From: David Daney >>> >>> [...] >>> >>>>>> +Properties of the host controller node that differ from >>>>>> +host-generic-pci.txt: >>>>>> + >>>>>> +- compatible : Must be "cavium,pci-host-thunder-ecam" >>>>>> + >>>>>> +Example: >>>>>> + >>>>>> + pci@84b0,00000000 { >>>>> >>>>> >>>>> Drop the comma, >>>> >>>> >>>> OK... >>>> >>>>> and the node name should be "pcie". >>>>> >>>> >>>> Why pcie? >>>> >>>> There are no PCIe devices or buses reachable from this type of root complex. >>>> There are however many PCI devices. >>> >>> I thought ECAM is a PCIe thing. If not, then nevermind. > > The "ECAM" confusion bites again :) > >> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the >> the PCI Express(R) base Specification, but it just defines a >> standard layout of address bits to memory map config space >> operations. Since the PCI config space is a sub set of the PCIe >> config space, ECAM can also be used in PCI systems. >> >> Really, it is a bit of a gray area here as we don't have any bridges >> to PCIe buses and there are multiple devices residing on each bus, >> so from that point of view it cannot be PCIe. There are, however, >> devices that implement the PCI Express Capability structure, so does >> that make it PCIe? It is not clear what the specifications demand >> here. > > The PCI core doesn't care about the node name in the device tree. But > it *does* care about some details of PCI/PCIe topology. We consider > anything with a PCIe capability to be PCIe. For example, > > - pci_cfg_space_size() thinks PCIe devices have 4K of config space > > - only_one_child() thinks a PCIe bus, i.e., a link, only has a > single device on it > > - a PCIe device should have a PCIe Root Port or PCIe Downstream Port > upstream from it (we did remove some of these restrictions with > b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but > it's possible we didn't get them all) > > I assume your system conforms to expectations like these; I'm just > pointing them out because you mentioned buses with multiple devices on > them, which is definitely something one doesn't expect in PCIe. > The topology we have is currently working with the kernel's core PCI code. I don't really want to get into discussing what the definition of PCIe is. We have multiple devices (more than 32) on a single bus, and they have PCI Express and ARI Capabilities. Is that PCIe? I don't know. For the purpose of naming the device tree node, I would like to stick with the name "pci@..." as it is somewhat accurate, a value contemplated by the device tree specifications, ignored by the kernel code, and already implemented. David Daney > Bjorn > From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices Date: Mon, 8 Feb 2016 14:41:41 -0800 Message-ID: <56B919A5.5090000@caviumnetworks.com> References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com> <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com> <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160208221204.GA30821@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Bjorn Helgaas Cc: Mark Rutland , Pawel Moll , Ian Campbell , "linux-pci@vger.kernel.org" , David Daney , Will Deacon , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , David Daney , Kumar Gala , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org On 02/08/2016 02:12 PM, Bjorn Helgaas wrote: > On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote: >> On 02/08/2016 01:12 PM, Rob Herring wrote: >>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney wrote: >>>> On 02/08/2016 11:56 AM, Rob Herring wrote: >>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote: >>>>>> From: David Daney >>> >>> [...] >>> >>>>>> +Properties of the host controller node that differ from >>>>>> +host-generic-pci.txt: >>>>>> + >>>>>> +- compatible : Must be "cavium,pci-host-thunder-ecam" >>>>>> + >>>>>> +Example: >>>>>> + >>>>>> + pci@84b0,00000000 { >>>>> >>>>> >>>>> Drop the comma, >>>> >>>> >>>> OK... >>>> >>>>> and the node name should be "pcie". >>>>> >>>> >>>> Why pcie? >>>> >>>> There are no PCIe devices or buses reachable from this type of root complex. >>>> There are however many PCI devices. >>> >>> I thought ECAM is a PCIe thing. If not, then nevermind. > > The "ECAM" confusion bites again :) > >> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the >> the PCI Express(R) base Specification, but it just defines a >> standard layout of address bits to memory map config space >> operations. Since the PCI config space is a sub set of the PCIe >> config space, ECAM can also be used in PCI systems. >> >> Really, it is a bit of a gray area here as we don't have any bridges >> to PCIe buses and there are multiple devices residing on each bus, >> so from that point of view it cannot be PCIe. There are, however, >> devices that implement the PCI Express Capability structure, so does >> that make it PCIe? It is not clear what the specifications demand >> here. > > The PCI core doesn't care about the node name in the device tree. But > it *does* care about some details of PCI/PCIe topology. We consider > anything with a PCIe capability to be PCIe. For example, > > - pci_cfg_space_size() thinks PCIe devices have 4K of config space > > - only_one_child() thinks a PCIe bus, i.e., a link, only has a > single device on it > > - a PCIe device should have a PCIe Root Port or PCIe Downstream Port > upstream from it (we did remove some of these restrictions with > b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but > it's possible we didn't get them all) > > I assume your system conforms to expectations like these; I'm just > pointing them out because you mentioned buses with multiple devices on > them, which is definitely something one doesn't expect in PCIe. > The topology we have is currently working with the kernel's core PCI code. I don't really want to get into discussing what the definition of PCIe is. We have multiple devices (more than 32) on a single bus, and they have PCI Express and ARI Capabilities. Is that PCIe? I don't know. For the purpose of naming the device tree node, I would like to stick with the name "pci@..." as it is somewhat accurate, a value contemplated by the device tree specifications, ignored by the kernel code, and already implemented. David Daney > Bjorn > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <56B919A5.5090000@caviumnetworks.com> Date: Mon, 8 Feb 2016 14:41:41 -0800 From: David Daney MIME-Version: 1.0 To: Bjorn Helgaas CC: Rob Herring , David Daney , Bjorn Helgaas , "linux-pci@vger.kernel.org" , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , David Daney Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com> <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com> <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost> In-Reply-To: <20160208221204.GA30821@localhost> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: On 02/08/2016 02:12 PM, Bjorn Helgaas wrote: > On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote: >> On 02/08/2016 01:12 PM, Rob Herring wrote: >>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney wrote: >>>> On 02/08/2016 11:56 AM, Rob Herring wrote: >>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote: >>>>>> From: David Daney >>> >>> [...] >>> >>>>>> +Properties of the host controller node that differ from >>>>>> +host-generic-pci.txt: >>>>>> + >>>>>> +- compatible : Must be "cavium,pci-host-thunder-ecam" >>>>>> + >>>>>> +Example: >>>>>> + >>>>>> + pci@84b0,00000000 { >>>>> >>>>> >>>>> Drop the comma, >>>> >>>> >>>> OK... >>>> >>>>> and the node name should be "pcie". >>>>> >>>> >>>> Why pcie? >>>> >>>> There are no PCIe devices or buses reachable from this type of root complex. >>>> There are however many PCI devices. >>> >>> I thought ECAM is a PCIe thing. If not, then nevermind. > > The "ECAM" confusion bites again :) > >> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the >> the PCI Express(R) base Specification, but it just defines a >> standard layout of address bits to memory map config space >> operations. Since the PCI config space is a sub set of the PCIe >> config space, ECAM can also be used in PCI systems. >> >> Really, it is a bit of a gray area here as we don't have any bridges >> to PCIe buses and there are multiple devices residing on each bus, >> so from that point of view it cannot be PCIe. There are, however, >> devices that implement the PCI Express Capability structure, so does >> that make it PCIe? It is not clear what the specifications demand >> here. > > The PCI core doesn't care about the node name in the device tree. But > it *does* care about some details of PCI/PCIe topology. We consider > anything with a PCIe capability to be PCIe. For example, > > - pci_cfg_space_size() thinks PCIe devices have 4K of config space > > - only_one_child() thinks a PCIe bus, i.e., a link, only has a > single device on it > > - a PCIe device should have a PCIe Root Port or PCIe Downstream Port > upstream from it (we did remove some of these restrictions with > b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but > it's possible we didn't get them all) > > I assume your system conforms to expectations like these; I'm just > pointing them out because you mentioned buses with multiple devices on > them, which is definitely something one doesn't expect in PCIe. > The topology we have is currently working with the kernel's core PCI code. I don't really want to get into discussing what the definition of PCIe is. We have multiple devices (more than 32) on a single bus, and they have PCI Express and ARI Capabilities. Is that PCIe? I don't know. For the purpose of naming the device tree node, I would like to stick with the name "pci@..." as it is somewhat accurate, a value contemplated by the device tree specifications, ignored by the kernel code, and already implemented. David Daney > Bjorn > From mboxrd@z Thu Jan 1 00:00:00 1970 From: ddaney@caviumnetworks.com (David Daney) Date: Mon, 8 Feb 2016 14:41:41 -0800 Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices In-Reply-To: <20160208221204.GA30821@localhost> References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com> <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com> <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost> Message-ID: <56B919A5.5090000@caviumnetworks.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/08/2016 02:12 PM, Bjorn Helgaas wrote: > On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote: >> On 02/08/2016 01:12 PM, Rob Herring wrote: >>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney wrote: >>>> On 02/08/2016 11:56 AM, Rob Herring wrote: >>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote: >>>>>> From: David Daney >>> >>> [...] >>> >>>>>> +Properties of the host controller node that differ from >>>>>> +host-generic-pci.txt: >>>>>> + >>>>>> +- compatible : Must be "cavium,pci-host-thunder-ecam" >>>>>> + >>>>>> +Example: >>>>>> + >>>>>> + pci at 84b0,00000000 { >>>>> >>>>> >>>>> Drop the comma, >>>> >>>> >>>> OK... >>>> >>>>> and the node name should be "pcie". >>>>> >>>> >>>> Why pcie? >>>> >>>> There are no PCIe devices or buses reachable from this type of root complex. >>>> There are however many PCI devices. >>> >>> I thought ECAM is a PCIe thing. If not, then nevermind. > > The "ECAM" confusion bites again :) > >> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the >> the PCI Express(R) base Specification, but it just defines a >> standard layout of address bits to memory map config space >> operations. Since the PCI config space is a sub set of the PCIe >> config space, ECAM can also be used in PCI systems. >> >> Really, it is a bit of a gray area here as we don't have any bridges >> to PCIe buses and there are multiple devices residing on each bus, >> so from that point of view it cannot be PCIe. There are, however, >> devices that implement the PCI Express Capability structure, so does >> that make it PCIe? It is not clear what the specifications demand >> here. > > The PCI core doesn't care about the node name in the device tree. But > it *does* care about some details of PCI/PCIe topology. We consider > anything with a PCIe capability to be PCIe. For example, > > - pci_cfg_space_size() thinks PCIe devices have 4K of config space > > - only_one_child() thinks a PCIe bus, i.e., a link, only has a > single device on it > > - a PCIe device should have a PCIe Root Port or PCIe Downstream Port > upstream from it (we did remove some of these restrictions with > b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but > it's possible we didn't get them all) > > I assume your system conforms to expectations like these; I'm just > pointing them out because you mentioned buses with multiple devices on > them, which is definitely something one doesn't expect in PCIe. > The topology we have is currently working with the kernel's core PCI code. I don't really want to get into discussing what the definition of PCIe is. We have multiple devices (more than 32) on a single bus, and they have PCI Express and ARI Capabilities. Is that PCIe? I don't know. For the purpose of naming the device tree node, I would like to stick with the name "pci at ..." as it is somewhat accurate, a value contemplated by the device tree specifications, ignored by the kernel code, and already implemented. David Daney > Bjorn >