linux-kernel - Re: [PATCH v2 2/2] pci: host: new driver for Axis ARTPEC-6 PCIe controller

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 13 Jun 2016 08:33:57 -0500
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Niklas Cassel <niklas.cassel@...s.com>
Cc:	bhelgaas@...gle.com, jespern@...s.com, akpm@...ux-foundation.org,
	davem@...emloft.net, gregkh@...uxfoundation.org,
	mchehab@....samsung.com, linux@...ck-us.net, jslaby@...e.cz,
	robh@...nel.org, marc.zyngier@....com, rjui@...adcom.com,
	arnd@...db.de, david.daney@...ium.com, geert+renesas@...der.be,
	lftan@...era.com, bharat.kumar.gogada@...inx.com, hauke@...ke-m.de,
	thomas.petazzoni@...e-electrons.com, simon.horman@...ronome.com,
	phil.edworthy@...esas.com, svarbanov@...sol.com, dhdang@....com,
	wangzhou1@...ilicon.com, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-arm-kernel@...s.com
Subject: Re: [PATCH v2 2/2] pci: host: new driver for Axis ARTPEC-6 PCIe
 controller

On Mon, Jun 13, 2016 at 03:12:13PM +0200, Niklas Cassel wrote:
> On 06/10/2016 12:41 AM, Bjorn Helgaas wrote:
> > On Mon, May 09, 2016 at 01:49:03PM +0200, Niklas Cassel wrote:
> >> From: Niklas Cassel <niklas.cassel@...s.com>
> >>
> >> The Axis ARTPEC-6 SoC integrates a PCIe controller from Synopsys.
> >> This commit adds a new driver that provides the small glue
> >> needed to use the existing Designware driver to make it work on
> >> the Axis ARTPEC-6 SoC.
> >>
> >> Signed-off-by: Niklas Cassel <niklas.cassel@...s.com>
> > Hi Niklas,
> >
> > I'll review this soon.  In the meantime, can you send /proc/iomem and
> > /proc/ioport contents?  I'm looking to avoid problems like this:
> > http://lkml.kernel.org/r/20160606230537.20936.2892.stgit@bhelgaas-glaptop2.roam.corp.google.com
> >
> > It looks like this is based on DesignWare, so it probably has the
> > problem, and will probably be fixed by these:
> >
> > http://lkml.kernel.org/r/20160606230452.20936.28937.stgit@bhelgaas-glaptop2.roam.corp.google.com
> > http://lkml.kernel.org/r/20160606230501.20936.71818.stgit@bhelgaas-glaptop2.roam.corp.google.com
> > http://lkml.kernel.org/r/20160606230508.20936.81845.stgit@bhelgaas-glaptop2.roam.corp.google.com
> >
> > If you wanted to apply those and then send /proc/iomem and
> > /proc/ioports, that would be even better.
> >
> > Bjorn
> >
> 
> Output with your patches applied:

Great, thanks, Niklas!  Comments below:

> [    2.107320] PCI host bridge /pcie@...50000 ranges:
> [    2.112138]   No bus range found for /pcie@...50000, using [bus 00-ff]

Your DT *should* provide a bus number range.  There is no way for the
PCI core to correctly determine the range.

> [    2.118684]    IO 0xc0010000..0xc001ffff -> 0x00010000
> [    2.123835]   MEM 0xc0020000..0xdfffffff -> 0xc0020000
> [    2.245559] artpec6-pcie f8050000.pcie: link up
> [    2.250228] artpec6-pcie f8050000.pcie: PCI host bridge to bus 0000:00
> [    2.256773] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    2.262273] pci_bus 0000:00: root bus resource [io  0x0000-0xffff] (bus address [0x10000-0x1ffff])

This looks questionable.  This says we're using I/O ports
0x10000-0x1ffff on the PCI bus.  That's legal, but unusual.

The conventional PCI spec allowed the upper 16 bits of I/O BARs
to be hard-wired to zero "for devices intended for 16-bit I/O
systems, such as PC compatibles."

I don't know whether a PCIe device with an I/O BAR with the
upper bits hard-wired to zero exists.  The conservative approach
would be to use ports 0x0000-0xffff on PCI.

> [    2.271250] pci_bus 0000:00: root bus resource [mem 0xc0020000-0xdfffffff]
> [    2.278407] PCI: bus0: Fast back to back transfers disabled
> [    2.293358] PCI: bus1: Fast back to back transfers disabled
> [    2.299018] pci 0000:00:00.0: BAR 0: assigned [mem 0xc0100000-0xc01fffff]
> [    2.305825] pci 0000:00:00.0: BAR 1: assigned [mem 0xc0200000-0xc02fffff]
> [    2.312627] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0300000-0xc07fffff]
> [    2.319430] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0400000-0xc05fffff]
> [    2.326241] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0600000-0xc07fffff]
> [    2.333052] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0300000-0xc0303fff]
> [    2.339862] pci 0000:00:00.0: PCI bridge to [bus 01]
> [    2.344838] pci 0000:00:00.0:   bridge window [mem 0xc0300000-0xc07fffff]
> 
> # cat /proc/iomem
> 00000000-0fffffff : System RAM
>   00208000-01071b2f : Kernel code
>   01300000-01465347 : Kernel data
> c0020000-dfffffff : MEM
>   c0100000-c01fffff : 0000:00:00.0
>   c0200000-c02fffff : 0000:00:00.0
>   c0300000-c07fffff : PCI Bus 0000:01
>     c0300000-c0303fff : 0000:01:00.0
>       c0301000-c0301007 : serial
>       c0301200-c0301207 : serial
>     c0400000-c05fffff : 0000:01:00.0
>     c0600000-c07fffff : 0000:01:00.0
> f8010000-f8013fff : /amba@...thernet@...10000
> f8036000-f8036fff : /amba@...erial@...36000
>   f8036000-f8036fff : /amba@...erial@...36000
> f8037000-f8037fff : /amba@...erial@...37000
>   f8037000-f8037fff : /amba@...erial@...37000
> f8038000-f8038fff : /amba@...erial@...38000
>   f8038000-f8038fff : /amba@...erial@...38000
> f8039000-f8039fff : /amba@...erial@...39000
>   f8039000-f8039fff : /amba@...erial@...39000
> f8040000-f8040fff : phy
> f8050000-f8051fff : dbi
> 
> # cat /proc/ioports
> 00000000-0000ffff : I/O
> 
> 
> Without your patches applied:
> /proc/ioports is empty.
> /proc/iomem is missing the node "c0020000-dfffffff : MEM"
> and all of its child nodes.

Good, that's exactly what I expected.  We could use better names for
the resources, so they're connected to the PCIe controller, but at
least we have the entries.

Bjorn