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
next prev parent 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).