linux-kernel - Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4985267.LnsktRmabM@wuerfel>
Date:	Mon, 03 Feb 2014 21:12:32 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Tanmay Inamdar <tinamdar@....com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Rob Landley <rob@...dley.net>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches <patches@....com>,
	Jon Masters <jcm@...hat.com>, Liviu Dudau <Liviu.Dudau@....com>
Subject: Re: [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver

On Monday 03 February 2014 11:42:22 Tanmay Inamdar wrote:
> On Thu, Jan 30, 2014 at 6:16 AM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Friday 24 January 2014, Tanmay Inamdar 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
> >> +      */
> >> +     for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> >> +             dev->resource[i].start = dev->resource[i].end = 0;
> >> +             dev->resource[i].flags = 0;
> >> +     }
> >> +     dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
> >> +              pci_name(dev));
> >> +}
> >> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
> >> +                      xgene_pcie_fixup_bridge);
> >
> > Shouldn't this be gone now that the host bridge is correctly shown
> > at the domain root?
> 
> In inbound region configuration, whole DDR space is mapped into the
> BAR of RC. When Linux PCI mid-layer starts enumerating, it reads the
> size of BAR of RC and tries to fit it into the memory resource. First
> thing is that the outbound memory is not enough to map the inbound BAR
> space. This creates problem with the resource management logic and
> second thing is that, it is not required to map inbound BAR space RC
> bar as no one will be accessing it further.
> 
> As Jason suggested, Bridge BAR's should be 0 size unless the bridge
> itself has registers. However this is not the case with XGene PCIe
> controller. It may have been inherited from the legacy design.
> 'arch/powerpc/sysdev/ppc4xx_pci.c' has similar fixup function.

Are you sure that is true for the root bridge as well? I don't
remember the details, but I though that for the host bridge,
we don't actually look at the BARs at all.

> > If you want to try out the I/O space, I'd suggest using an Intel
> > e1000 network card, which has both memory and i/o space. There
> > is a patch at http://www.spinics.net/lists/linux-pci/msg27684.html
> > that lets you check the I/O registers on it, or you can go
> > through /dev/port from user space.
> >
> > I also haven't seen your patch that adds pci_ioremap_io() for
> > arm64. It would be helpful to keep it in the same patch
> > series, since it won't build without this patch.
> 
> I will post the arm64 pci patch along with next revision of this
> driver. That will cover the 'pci_ioremap_io' as well.

Please note that today, Liviu Dudau has also posted patches for this,
so you should coordinate a bit.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/