From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932293AbcBIJ0b (ORCPT ); Tue, 9 Feb 2016 04:26:31 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:53017 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753375AbcBIJ01 (ORCPT ); Tue, 9 Feb 2016 04:26:27 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Bjorn Helgaas , 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 10:25:33 +0100 Message-ID: <12842339.z2KnaZPlyO@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160208232430.GA1353@localhost> References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com> <56B919A5.5090000@caviumnetworks.com> <20160208232430.GA1353@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Bw7g+F/P1VmoeKbF7wCrPDWZXf/KYTdNYzD7P0XEJ4X82y/Aa5i 4g79CRvN5qdDmcXhd2hVydslT3G99t1sHmy69YgUn+bc2NmDG39tdJuy5BjKILRlBZo+Kse joIpYeMATzpPH5/EAdy4mPnw2yIeFzZBv0ePi6Sw3z0yhwISBWg0gQOiZQJYW3i5T8n+MPF 4fmK3rzmc5ak2yCpIQQNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1T/oma9RtiE=:HzXegH3EFKHayn3rr6nLGq BqUVZlruFWniyl8F2vRZjoiOLvmDufX88BtX2HeGWDmP4GrBqzM1neSrEhqh19Pi5KKYcQBy7 XBH021qs9s/9jpLRN4U/csNje80qzWI7R33TSDajYijFfxtdZwAbzFiF/7/y6GbgDxDTLNoSX CrPm1RfmbFqVST5bmrDAiOLrLuKBTWvxXwNZf+wOyJkbcvyoNHUtfdHEsAccWNWqWDQkZLbho n1K2Z+mFzY0kxbzfEFOF4L1lfB1saFq76+eyrSmhDdec6888w7ZkV2zkpqqZr+SXgLeWBHhZm lPUhf+0y0cEcc8khoaJW1EcaXOVIX16p+DeGIYp8uE9RHXNEEtf6dt+9YfIdmC7CMEEkkuiIQ v6G1jxCqmVXnxlTN02HYzZ6/HSk576X7MkdPQaXnqQHew2RI5FFqMJCgZZEIPNMFxk6lU2vDZ cECWirn14J43bQhejRWZ/lrMVNAbl3UWwux+iphwIJd3LWIbrBu8TbddSrtDLTAZ7MxQS+sC9 HEpR2/8FYZN+KYOeWyDQdFSNFXVKLQE4Ki4bvkcAWMe7hpmq/MEKlAWFbo75Z8LZWYv54CjGx eKUYIPVdxXaToxqY0YPPjfPWourTKDC8fFXXE/4nFfiq3YHJacS1pUlfUbvvlZuLrcdCHJkO1 BPTKM2CaLta/lxp/oE3NjSAQqJrxMFOUoiz1DOLagnpjGBnll/viMhdpDegFF/LnW+Tuy74pZ N1kaCmkWmm/FnHCH Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. For this special case, I don't think it matters at all from the point of view of the DT binding whether we call the node name "pci" or "pcie". IIRC, even on real Open Firmware, the three companies that shipped PCIe (or Hypertransport, which doesn't even have a formal binding) based machines (Sun, IBM, Apple) were using slightly different bindings in practice, so I wouldn't read to much into it. Any OS that wants to run on real OF already has to support it either way. Arnd