linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	David Daney <ddaney@caviumnetworks.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	David Daney <david.daney@cavium.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	David Daney <ddaney.cavm@gmail.com>,
	Kumar Gala <galak@codeaurora.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
Date: Tue, 9 Feb 2016 10:26:28 -0600	[thread overview]
Message-ID: <20160209162628.GA20171@localhost> (raw)
In-Reply-To: <12842339.z2KnaZPlyO@wuerfel>

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"?)

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.

> 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".

And the PCI core doesn't even know the node name, it doesn't matter
there either.

Bjorn

  reply	other threads:[~2016-02-09 16:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 23:41 [PATCH v5 0/3] Add host controller drivers for Cavium ThunderX PCI David Daney
2016-02-05 23:41 ` [PATCH v5 1/3] PCI: generic: Refactor code to enable reuse by other drivers David Daney
2016-02-05 23:41 ` [PATCH v5 2/3] pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors David Daney
2016-02-06 16:01   ` Bjorn Helgaas
2016-02-05 23:41 ` [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices David Daney
2016-02-08 19:56   ` Rob Herring
2016-02-08 20:47     ` David Daney
2016-02-08 21:12       ` Rob Herring
2016-02-08 21:39         ` David Daney
2016-02-08 22:12           ` Bjorn Helgaas
2016-02-08 22:41             ` David Daney
2016-02-08 23:24               ` Bjorn Helgaas
2016-02-08 23:31                 ` David Daney
2016-02-09  9:25                 ` Arnd Bergmann
2016-02-09 16:26                   ` Bjorn Helgaas [this message]
2016-02-09 16:31                     ` Arnd Bergmann
2016-02-09 16:58                       ` David Daney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160209162628.GA20171@localhost \
    --to=helgaas@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=david.daney@cavium.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).