Use devm_request_pci_bus_resources() to request host bridge window
resources instead of doing it by hand in the driver.

No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use the SET_NOIRQ_SYSTEM_SLEEP_PM_OPS helper macro for mvebu_pcie_pm_ops.
The macro also sets up freeze_noirq, thaw_noirq and poweroff_noirq,
restore_noirq accordingly.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The mvebu_pcie_pm_ops structure is never modified, so declare it as const.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Now that we advertise a PCIe capability, the Linux PCI layer will not scan
the bus for devices other than in slot 0.  This makes the work-around to
trap accesses to devices other than slot 0 unnecessary.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Add a PCI Express root complex capability block so the PCI layer identifies
the bridge as a PCI Express device.

We expose this as a version 1 PCIe capability block, with slot support.  We
disable the clock power management capability as this depends on boards
wiring the CLKREQ# signal.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Add an implementation to handle clock and reset handling that is compliant
with the PCIe specification.  The clock should be running and stable for
100us prior to reset being released, and we should re-assert reset prior to
stopping the clock.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Use a gpio_desc to carry around the gpio, so we can then make use of the
GPIOF_ACTIVE_LOW property rather than carrying that around as well.  This
also avoids needing to use gpio_is_valid() to check whether we have a GPIO;
checking for a non-NULL descriptor is simpler.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Rather than using devm_kzalloc() and multiplying the element and number,
use the provided devm_kcalloc() helper for this.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

We are in a context where we can sleep, and the PCIe reset gpio may be on
an I2C expander.  Use the cansleep() variant when setting the GPIO value.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Split the PCIe port DT parsing and resource claiming from setting up the
actual ports.  This allows us to gather all the resources first, before
touching the hardware.  This is important as some of these resources (such
as the GPIO for the PCIe reset) may defer probing.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The mvebu PCI port parsing is weak due to:

1) allocations via kasprintf() were not cleaned up when we encounter an
   error or decide to skip the port.
2) kasprintf() wasn't checked for failure.
3) of_get_named_gpio_flags() returns EPROBE_DEFER if the GPIO is not
   present, not devm_gpio_request_one().
4) the of_node was not being put when terminating the loop.

Fix these oversights.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Move the PCIe port parsing and resource claiming to a separate function in
preparation to add proper cleanup of claimed resources.

Tested-by: Willy Tarreau <w@1wt.eu> (Iomega iConnect Kirkwood, MiraBox Armada 370)
Tested-by: Andrew Lunn <andrew@lunn.ch> (D-Link DIR664 Kirkwood)
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Use the port->name string which we previously formatted when referring to
the name of a port, rather than manually creating the port name each time.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

If we have a missing required property, report the full node name rather
than a vague "PCIe DT node" statement.  This allows the exact node in error
to be identified immediately.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Rather than using for_each_child_of_node() and testing each child's
availability, use the for_each_available_child_of_node() helper instead.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Rather than open-coding of_get_available_child_count(), use the provided
helper instead.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The idea that you can arbitarily read 32-bits from PCI configuration space,
modify a sub-field (like the command register) and write it back without
consequence is deeply flawed.

Status registers (such as the status register, PCIe device status register,
etc) contain status bits which are read, write-one-to-clear.

What this means is that reading 32-bits from the command register,
modifying the command register, and then writing it back has the effect of
clearing any status bits that were indicating at that time.  Same for the
PCIe device control register clearing bits in the PCIe device status
register.

Since the Armada chips support byte, 16-bit and 32-bit accesses to the
registers (unless otherwise stated) and the PCI configuration data register
does not specify otherwise, it seems logical that the chip can indeed
generate the proper configuration access cycles down to byte level.

Testing with an ASM1062 PCIe to SATA mini-PCIe card on Armada 388.  PCIe
capability at 0x80, DevCtl at 0x88, DevSta at 0x8a.

Before:
  /# setpci -s 1:0.0 0x88.l		- DevSta: CorrErr+
  00012810
  /# setpci -s 1:0.0 0x88.w=0x2810	- Write DevCtl only
  /# setpci -s 1:0.0 0x88.l		- CorrErr cleared - FAIL
  00002810

After:
  /# setpci -s 1:0.0 0x88.l		- DevSta: CorrErr+
  00012810
  /# setpci -s 1:0.0 0x88.w=0x2810	- check DevCtl only write
  /# setpci -s 1:0.0 0x88.l		- CorErr remains set
  00012810
  /# setpci -s 1:0.0 0x88.w=0x281f	- check DevCtl write works
  /# setpci -s 1:0.0 0x88.l		- devctl field updated
  0001281f
  /# setpci -s 1:0.0 0x8a.w=0xffff	- clear DevSta
  /# setpci -s 1:0.0 0x88.l		- CorrErr now cleared
  0000281f
  /# setpci -s 1:0.0 0x88.w=0x2810	- restore DevCtl
  /# setpci -s 1:0.0 0x88.l		- check
  00002810

[bhelgaas: changelog]
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

PCI requires reads to reserved or unimplemented configuration space to
return zero and complete normally (see PCI r3.0, sec 6.1).  However, the
root port software implementation was returning 0xfffffff and
PCIBIOS_BAD_REGISTER_NUMBER.

Return zero when reading reserved or unimplemented config space.

[bhelgaas: changelog]
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (Armada XP GP)
Tested-by: Andrew Lunn <andrew@lunn.ch> (Kirkwood DIR665)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

of_parse_phandle() returns a device_node pointer with the refcount
incremented.  We should dispose of this reference when we're finished.

Drop the reference acquired by of_parse_phandle().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

After b97ea289 ("PCI: Assign resources before drivers claim devices
(pci_scan_root_bus())"), pci_scan_root_bus() no longer adds the devices, so
it is equivalent to mvebu_pcie_scan_bus().

Remove mvebu_pcie_scan_bus() (the hw.scan method), so we use the generic
pci_scan_root_bus() path.  We also need to use pci_common_init_dev()
instead of pci_common_init() so we can supply the host bridge device
pointer.

[bhelgaas: changelog]
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Jason Cooper <jason@lakedaemon.net>

Add suspend/resume support for the mvebu PCIe host driver.  Without this
commit, the system will panic at resume time when PCIe devices are
connected.

Note that we have to use the ->suspend_noirq() and ->resume_noirq() hooks,
because at resume time, the PCI fixups are done at ->resume_noirq() time,
so the PCIe controller has to be ready at this point.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

Most if not all ARM PCI host controller device drivers either ignore the
domain field in the pci_sys_data structure or just increment it every time
a host controller is probed, using it as a domain counter.

Therefore, instead of relying on pci_sys_data to stash the domain number in
a standard location, ARM pcibios code can be moved to the newly introduced
generic PCI domains code, implemented in commits:

  41e5c0f8 ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()")
  670ba0c8 ("PCI: Add generic domain handling")

ARM code is made to select PCI_DOMAINS_GENERIC by default, which builds
core PCI code that assigns the domain number through the generic function:

  void pci_bus_assign_domain_nr(...)

that relies on a DT property to define the domain number or falls back to a
counter according to a predefined logic; its usage replaces the current
domain assignment code in PCI host controllers present in the kernel.
Tested-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NYijing Wang <wangyijing@huawei.com>
Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> # mvebu
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NPhil Edworthy <phil.edworthy@renesas.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
CC: Mohit Kumar <mohit.kumar@st.com>

Save MSI controller in pci_sys_data instead of assigning MSI controller
pointer to every PCI bus in .add_bus().
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch fixes the following checkpatch warning:

  WARNING: Missing a blank line after declarations

[bhelgaas: drop mvebu_pcie_add_bus() change because it's going away anyway]
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

"msi_chip" isn't very descriptive, so rename it to "msi_controller".  That
tells a little more about what it does and is already used in device tree
bindings.

No functional change.

[bhelgaas: changelog, change *only* the struct name so it's reviewable]
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Geert Uytterhoeven reported a warning when building pci-mvebu:

  drivers/pci/host/pci-mvebu.c: In function 'mvebu_get_tgt_attr':
  drivers/pci/host/pci-mvebu.c:887:39: warning: 'rtype' may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (slot == PCI_SLOT(devfn) && type == rtype) {
					 ^

And indeed, the code of mvebu_get_tgt_attr() may lead to the usage of rtype
when being uninitialized, even though it would only happen if we had
entries other than I/O space and 32 bits memory space.

This commit fixes that by simply skipping the current DT range being
considered, if it doesn't match the resource type we're looking for.
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.12+

Per license_is_gpl_compatible(), the MODULE_LICENSE() string for GPL v2 is
"GPL v2", not "GPLv2".  Use "GPL v2" so this module doesn't taint the
kernel.

[bhelgaas: changelog]
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix the following build warning that happens when building
multi_v7_defconfig with CONFIG_ARM_LPAE=y:

  drivers/pci/host/pci-mvebu.c:334:5: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'phys_addr_t' [-Wformat=]

Fix the warning by using '%pa' to printing 'phys_addr_t' type.  While at
it, also use the more standard notation [mem 0x-0x] for memory region.

[bhelgaas: make end address inclusive, remove extra spaces]
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>

Serialization of configuration accesses is provided by 'pci_lock' in
drivers/pci/access.c thus making the driver's 'conf_lock' superfluous.
Signed-off-by: NAndrew Murray <amurray@embedded-bits.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

MBus windows are used on Marvell platforms to map certain peripherals
in the physical address space. In the PCIe context, MBus windows are
needed to map PCIe I/O and memory regions in the physical address.

However, those MBus windows can only have power of two sizes, while
PCIe BAR do not necessarily guarantee this. For this reason, the
current pci-mvebu breaks on platforms where PCIe devices have BARs
that don't sum up to a power of two size at the emulated bridge level.

This commit fixes this by allowing the pci-mvebu driver to create
multiple contiguous MBus windows (each having a power of two size) to
cover a given PCIe BAR.

To achieve this, two functions are added: mvebu_pcie_add_windows() and
mvebu_pcie_del_windows() to respectively add and remove all the MBus
windows that are needed to map the provided PCIe region base and
size. The emulated PCI bridge code now calls those functions, instead
of directly calling the mvebu-mbus driver functions.

Fixes: 45361a4f ('pci: PCIe driver for Marvell Armada 370/XP systems')
Cc: <stable@vger.kernel.org> # v3.11+
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.comTested-by: NNeil Greatorex <neil@fatboyfat.co.uk>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

mvebu_pcie_handle_membase_change() and
mvebu_pcie_handle_iobase_change() do not correctly compute the window
size. PCI uses an inclusive start/end address pair, which requires a
+1 when converting to size.

This only worked because a bug in the mbus driver allowed it to
silently accept and round up bogus sizes.

Fix this by adding one to the computed size.

Fixes: 45361a4f ('PCIe driver for Marvell Armada 370/XP systems')
Cc: <stable@vger.kernel.org> # v3.11+
Signed-off-by: NWilly Tarreau <w@1wt.eu>
Reviewed-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.comTested-by: NNeil Greatorex <neil@fatboyfat.co.uk>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

It is typical for host drivers to request a resource for the aperture; once
this is done the PCI core will properly populate resources for all BARs in
the system.

With this patch cat /proc/iomem will now show:

  e0000000-efffffff : PCI MEM 0000
    e0000000-e00fffff : PCI Bus 0000:01
      e0000000-e001ffff : 0000:01:00.0

Tested on Kirkwood.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

The second parameter of of_read_number() is not the index, but a size.  As
it happens, in this case it may work just fine because of the conversion to
u32 and the favorable endianness on this architecture.

Fixes: 11be6547 ("PCI: mvebu: Adapt to the new device tree layout")
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@traphandler.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org	# v3.12+

Marvell SoCs place the SoC number into the PCIe endpoint device ID.  The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.

The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.

When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality.  Debian would
like to use this in order to aid installing the correct DTB file.

Fixes: 45361a4f ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org	# v3.11+

Marvell SoCs place the SoC number into the PCIe endpoint device ID.  The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.

The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.

When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality.  Debian would
like to use this in order to aid installing the correct DTB file.

Fixes: 45361a4f ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org	# v3.11+

Use max_t() instead of max(resource_size_t,) in order to fix
the following checkpatch warning.

  WARNING: max() should probably be max_t(resource_size_t, SZ_64K, size)
  WARNING: max() should probably be max_t(resource_size_t, SZ_1M, size)
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>

The mvebu PCI host controller driver uses an emulated PCI-to-PCI bridge to
leverage the core PCI kernel enumeration logic to dynamically create and
remove the MBus windows needed to access the memory and I/O regions of each
PCI interface.

In the context of this PCI-to-PCI bridge emulation, the driver emulates
all reads and writes to the PCI bridge registers.  Upon a write to the
registers configuring the I/O base and limit, the driver was creating the
MBus window and calling pci_ioremap_io() to setup the mapping.

However, it turns out that accesses to these registers are made in an IRQ
disabled context, while pci_ioremap_io() is a potentially sleeping
function.  Not only this is wrong, but it is causing fairly loud warnings
at boot time when the appropriate kernel hacking options are enabled.

This patch solves this by moving the pci_ioremap_io() call to the startup
of the driver.  At this point, we don't know how many PCI interfaces will
be enabled, so we are simply remapping the entire PCI I/O space to virtual
addresses.  This is reasonable since this I/O space is limited to 1 MB in
size, and also because the MBus windows continue to be created in a dynamic
fashion only when devices need them.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

mvebu_pcie_of_match_table is always compiled in.  Hence of_match_ptr is not
required.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>