devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Tanmay Inamdar <tinamdar@apm.com>, Arnd Bergmann <arnd@arndb.de>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rob Landley <rob@landley.net>, Liviu Dudau <liviu.dudau@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	patches <patches@apm.com>, Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver
Date: Mon, 22 Sep 2014 16:27:27 -0600	[thread overview]
Message-ID: <20140922222727.GC15822@obsidianresearch.com> (raw)
In-Reply-To: <CAErSpo4C_6mh7hais14254rYBeMYArvf=nETmgvBjgP290aD4Q@mail.gmail.com>

On Mon, Sep 22, 2014 at 04:09:03PM -0600, Bjorn Helgaas wrote:
> On Mon, Sep 22, 2014 at 3:33 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> 
> >>> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> >>> +{
> >>> +     int i;
> >>> +
> >>> +     /* Hide the PCI host BARs from the kernel as their content doesn't
> >>> +      * fit well in the resource management
> >>> +      */
> >>
> >> This needs a better explanation than "doesn't fit well."
> >>
> >> I *think* you're probably talking about something similar to the MVEBU
> >> devices mentioned here:
> >> http://lkml.kernel.org/r/CAErSpo56jB1Bf2JtYCGKXZBZqRF1jXFxGmeewPX_e6vSXueGyA@mail.gmail.com
> >>
> >> where the device can be configured as either an endpoint or a root port,
> >> and the endpoint BARs are still visible when configured as a root port.
> >>
> >
> > It is true that X-Gene PCIe port can be configured as EP, however the
> > the FIXUP is required not because of the BARs are still visible when
> > configured as EP in past. X-Gene PCIe port, when configured as RC,
> > uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
> > region is mapped in these BARs so that it is accessible for EP devices
> > for DMA. So if the fixup is not done during enumeration, whole
> > outbound memory resource space gets assigned to RC and nothing is left
> > EP devices.
> 
> I'm not familiar with the concept of an "inbound BAR"; at least I'm
> not aware of anything like this in the PCI specs.  I think it might
> reduce confusion if we avoided calling them "BARs".  They happen to be
> at the same addresses where real BARs would be, but they certainly
> don't behave like real BARs.

So what does the lspci look like?

If x-gene has an otherwise correct bridge config space and only the
0/1 BARs have a non-standard meaning, that I'd agree with Bjorn, hide
all access to these registers from the kernel (and tell your HW crew
to read the specs, because it is very clear what those registers are
supposed to do) .

If x-gene doesn't even have a bridge config space, then there are much
bigger problems, and these corrupt BARs are just the start.

Jason

  reply	other threads:[~2014-09-22 22:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 22:33 [PATCH v9 0/4] APM X-Gene PCIe host controller Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver Tanmay Inamdar
2014-09-19 22:32   ` Bjorn Helgaas
2014-09-22 21:33     ` Tanmay Inamdar
2014-09-22 22:09       ` Bjorn Helgaas
2014-09-22 22:27         ` Jason Gunthorpe [this message]
2014-09-22 22:59           ` Tanmay Inamdar
2014-09-22 22:40         ` Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 2/4] arm64: dts: APM X-Gene PCIe device tree nodes Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 3/4] dt-bindings: pci: xgene pcie device tree bindings Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 4/4] MAINTAINERS: entry for APM X-Gene PCIe host driver Tanmay Inamdar
2014-09-19  3:08 ` [PATCH v9 0/4] APM X-Gene PCIe host controller Ming Lei
2014-09-19 17:15   ` Tanmay Inamdar
2014-09-22  1:23     ` Ming Lei
     [not found]       ` <CACVXFVMWTeOnVMp2SCzjhPEc1M=zTLg4O8yFhv_jDPYn_6DfeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-30 16:53         ` Bjorn Helgaas
2014-09-30 17:01           ` Liviu Dudau

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=20140922222727.GC15822@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=patches@apm.com \
    --cc=rob@landley.net \
    --cc=robh+dt@kernel.org \
    --cc=tinamdar@apm.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).