From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964840AbcBIQcV (ORCPT ); Tue, 9 Feb 2016 11:32:21 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:61856 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932685AbcBIQcT (ORCPT ); Tue, 9 Feb 2016 11:32:19 -0500 From: Arnd Bergmann To: Bjorn Helgaas Cc: linux-arm-kernel@lists.infradead.org, David Daney , 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 Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices Date: Tue, 09 Feb 2016 17:31:26 +0100 Message-ID: <4260938.2z2RNjENMM@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160209162628.GA20171@localhost> References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <12842339.z2KnaZPlyO@wuerfel> <20160209162628.GA20171@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Y/A1EBrQyobrJ7QZwXfGM8Kz08aRy5DoF4dYH+sD8SjFKlA6/zB 1u4mBbfe9mjBfIHUXEStHRSDP/ICH6iVX7zlouF2NiIPq9K3YxYBcR0zknAVtQYgcXV/c3Z NTgcG0x+T9pWLbsoPkpYG1aRLUyYvds0mDKgnsoBULTxNCWS8YN2CxX/4BuO23ULjXdrQcy ruBCpWANNTM4vJD9PvCPg== X-UI-Out-Filterresults: notjunk:1;V01:K0:D36bN0uoDDI=:hjdoZpxzD2L1ZsgXLHyu6A 8KhEDFB/yqvYr1grHslaE6eNh/T1zrsNdhUpJT3wmLOJbknQ7HlzX9g7wSQyWzatSdsxtT1nk gHnc6YZKxysZpbmt6NlImXSYrGox39WVevP2+8F0z/e+HDc5fbAFnlQtFo6FTU/+cFdYt+jgr d9AabMj2eJbA44AOJG0Q5PFZbP9xZW07dTu1rFR3u4zrs62alTY8J694F7ZswQFUjirQC79jH iZM4aFep+NHPd93kmL5ym8xGMkqBrLXr8GGKNeoeEKwBy3XxxsBpuFcdG+RVRYawjMQlY+PrC pG6DbL8FJJrrcdFU1CehQQra68aAfyXcgWRe9KmiZMM5LlRQmS6L0Py2Pvdw6J04MrEgRAlEY UkuTNuyyBv0XLLL7YKn6JmnL2tx4lDkXSseBXB3e92V11+GfYWFe9ANnP4zxcbA/U+4J3RJX7 C0Xe6QVRYHcNj2el4p73uwezuS5TFVfIzT+IzCPW8kIG9tZ5A5Opac8dWmnk98uozwOMwQiem Hb/eSZvv6rlEJQ/dPkxmWrLzc8O6YR/oHJxj5G6iGwnd65l03miz5oy/EzkJQxBf40w/VdjDJ 2SRI3lvBsG65pB8btn6SRURIrXB62qCsnKdpKIEnP1ArXWDL1g7PMpeXkKUQ2QllPgTvNYcKR tBpm+IfYoj51J3pwiCdcEHEZbpqzQXqIVG9j5zDsKSPluBFonNRBStt/SChIL6Rx/NjCsslCO VwDZOi0dPf5Tynkn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 09 February 2016 10:26:28 Bjorn Helgaas wrote: > On Tue, Feb 09, 2016 at 10:25:33AM +0100, Arnd Bergmann wrote: > > On Monday 08 February 2016 17:24:30 Bjorn Helgaas wrote: > > > > > > > > > >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. > > > > > > I don't need to know the details of your topology. As long as it > > > conforms to the PCIe spec, it should be fine. If it *doesn't* conform > > > to the spec, but things currently seem to work, that's less fine, > > > because a future Linux change is liable to break something for you. > > > > > > I was a little concerned about your statement that "there are multiple > > > devices residing on each bus, so from that point of view it cannot be > > > PCIe." That made it sound like you're doing something outside the > > > spec. If you're just using regular multi-function devices or ARI, > > > then I don't see any issue (or any reason to say it can't be PCIe). > > > > It doesn't conform to the PCIe port spec, because there are no external > > ports but just integrated devices in the host bridge. > > Is there a spec section you have in mind? Based on sec 1.3.1, I don't > think there's a requirement to have PCI Express Ports (is that what > you mean by "external ports"?) No, I was just assuming that ports are specified in their own document, which would not be followed here if there are none. There is nothing in here that leads me to believe that the hardware is actually noncompliant with any relevant standard. > Root Complex Integrated Endpoints (sec 1.3.2.3) are clearly supported > and they would not be behind a Root Port. If you're using those, I > hope they're correctly identified via the PCIe capability Device/Port > Type (sec 7.8.2) because we rely on that type to figure out whether > the link-related registers are implemented. > > The spec does include rules related to peer-to-peer transactions, MPS, > ASPM, error reporting, etc., and Linux relies on those, so I think it > would be important to get those right. David can probably explain more if the registers are compliant with those parts of the spec. Arnd