Add the device tree nodes for APM X-Gene PCIe host controller and PCIe
clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts nodes
are added.
Tanmay Inamdar [Wed, 1 Oct 2014 19:01:35 +0000 (13:01 -0600)]
PCI: xgene: Add APM X-Gene PCIe driver
Add the AppliedMicro X-Gene SOC PCIe host controller driver. The X-Gene
PCIe controller supports up to 8 lanes and GEN3 speed. The X-Gene SOC
supports up to 5 PCIe ports.
[bhelgaas: folded in MAINTAINERS and bindings updates] Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Dann Frazier <dann.frazier@canonical.com> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> (driver)
Bjorn Helgaas [Wed, 1 Oct 2014 18:31:23 +0000 (12:31 -0600)]
Merge branch 'pci/host-generic' into next
* pci/host-generic:
arm64: Add architectural support for PCI
PCI: Add pci_remap_iospace() to map bus I/O resources
of/pci: Add support for parsing PCI host bridge resources from DT
of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()
PCI: Add generic domain handling
of/pci: Fix the conversion of IO ranges into IO resources
of/pci: Move of_pci_range_to_resource() to of/address.c
ARM: Define PCI_IOBASE as the base of virtual PCI IO space
of/pci: Add pci_register_io_range() and pci_pio_to_address()
asm-generic/io.h: Fix ioport_map() for !CONFIG_GENERIC_IOMAP
Yijing Wang [Tue, 30 Sep 2014 00:35:16 +0000 (18:35 -0600)]
PCI/MSI: Use __write_msi_msg() instead of write_msi_msg()
default_restore_msi_irq() already has the struct msi_desc pointer required
by __write_msi_msg(), so call it directly instead of having write_msi_msg()
look it up from the IRQ.
No functional change.
[bhelgaas: split into separate patch] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yijing Wang [Wed, 24 Sep 2014 03:09:45 +0000 (11:09 +0800)]
MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
__read_msi_msg(), so call it directly instead of having read_msi_msg() look
it up from the IRQ.
No functional change.
[bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: linuxppc-dev@lists.ozlabs.org
Yijing Wang [Tue, 23 Sep 2014 05:27:25 +0000 (13:27 +0800)]
PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg()
Both callers of get_cached_msi_msg() start with a struct irq_data pointer,
look up the corresponding IRQ number, and pass it to get_cached_msi_msg(),
which then uses irq_get_irq_data() to look up the struct irq_data again to
call __get_cached_msi_msg().
Since we already have the struct irq_data, call __get_cached_msi_msg()
directly and skip the lookup work done by get_cached_msi_msg().
No functional change.
[bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Tony Luck <tony.luck@intel.com> CC: linux-ia64@vger.kernel.org
Yijing Wang [Tue, 23 Sep 2014 05:27:24 +0000 (13:27 +0800)]
PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints
The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
future driver requests for MSI or MSI-X. Previously, the sysfs file
existed for endpoints but did nothing.
Add "msi_bus" support for endpoints, so an administrator can prevent the
use of MSI and MSI-X for individual devices.
Note that as for bridges, these changes only affect future driver requests
for MSI or MSI-X, so drivers may need to be reloaded.
PCI/MSI: Move D0 check into pci_msi_check_device()
Both callers of pci_msi_check_device() check that the device is in D0
state, so move the check from the callers into pci_msi_check_device()
itself.
In pci_enable_msi_range(), note that pci_msi_check_device() never returns a
positive value any more, so the loop that called it until it returns zero
or negative is no longer necessary.
[bhelgaas: changelog, split to separate patch] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
No architectures implement arch_msi_check_device() or the struct msi_chip
.check_device() method, so remove them.
Remove the "type" parameter to pci_msi_check_device() because it was only
used to call arch_msi_check_device() and is no longer needed.
[bhelgaas: changelog, split to separate patch] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
This makes the code more compact and allows removing
arch_msi_check_device() from generic MSI code.
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net> CC: Thomas Gleixner <tglx@linutronix.de>
Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
This makes the code more compact and allows removing
arch_msi_check_device() from generic MSI code.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Use the generic PCI domain and OF functions to provide support for PCI
on arm64.
[bhelgaas: Change comments to use generic PCI, not just PCIe. Nothing at
this level is PCIe-specific.] Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
PCI: Add pci_remap_iospace() to map bus I/O resources
Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
address space. Architectures with special needs may provide their own
version, but most should be able to use this one.
This function is useful for PCI host bridge drivers that need to map the
PCI I/O resources into virtual memory space.
of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()
Add pci_get_new_domain_nr() to allocate a new domain number and
of_get_pci_domain_nr() to retrieve the PCI domain number of a given device
from DT. Host bridge drivers or architecture-specific code can choose to
implement their PCI domain number policy using these two functions.
Using of_get_pci_domain_nr() guarantees a stable PCI domain number on every
boot provided that all host bridge controllers are assigned a number in the
device tree using "linux,pci-domain" property. Mixing use of
pci_get_new_domain_nr() and of_get_pci_domain_nr() is not recommended as it
can lead to potentially conflicting domain numbers being assigned to root
buses behind different host bridges.
The handling of PCI domains (or PCI segments in ACPI speak) is usually a
straightforward affair but its implementation is currently left to the
architectural code, with pci_domain_nr(b) querying the value of the domain
associated with bus b.
This patch introduces CONFIG_PCI_DOMAINS_GENERIC as an option that can be
selected if an architecture wants a simple implementation where the value
of the domain associated with a bus is stored in struct pci_bus.
The architectures that select CONFIG_PCI_DOMAINS_GENERIC will then have to
implement pci_bus_assign_domain_nr() as a way of setting the domain number
associated with a root bus. All child buses except the root bus will
inherit the domain_nr value from their parent.
of/pci: Fix the conversion of IO ranges into IO resources
The ranges property for a host bridge controller in DT describes the
mapping between the PCI bus address and the CPU physical address. The
resources framework however expects that the IO resources start at a pseudo
"port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT. The
conversion from PCI ranges to resources failed to take that into account,
returning a CPU physical address instead of a port number.
Also fix all the drivers that depend on the old behaviour by fetching the
CPU physical address based on the port number where it is being needed.
Lucas Stach [Tue, 30 Sep 2014 16:36:26 +0000 (18:36 +0200)]
PCI: designware: Setup and clear exactly one MSI at a time
The setup_irq function is supposed to set up exactly one MSI IRQ. Multiple
IRQ setup is handled differently, to respect the choices made by the upper
layers.
Also only clear one MSI IRQ at a time; the PCI core will call into this
function multiple times if it has to tear down more than one MSI IRQ.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Jingoo Han <jg1.han@samsung.com>
Yinghai Lu [Sat, 23 Aug 2014 01:15:07 +0000 (18:15 -0700)]
PCI: Add missing MEM_64 mask in pci_assign_unassigned_bridge_resources()
In 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources"), we added IORESOURCE_MEM_64 to the mask in
pci_assign_unassigned_root_bus_resources(), but not to the mask in
pci_assign_unassigned_bridge_resources().
Add IORESOURCE_MEM_64 to the pci_assign_unassigned_bridge_resources() type
mask.
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+
of/pci: Move of_pci_range_to_resource() to of/address.c
We need to enhance of_pci_range_to_resources() enough that it won't make
sense for it to be inline anymore. Move it to drivers/of/address.c, under
#ifdef CONFIG_PCI.
of_address.h previously implemented of_pci_range_to_resources()
unconditionally, regardless of any config options. The implementation in
address.c is defined only when CONFIG_OF_ADDRESS=y and CONFIG_PCI=y,
so add a dummy version to avoid build errors when CONFIG_OF or
CONFIG_OF_ADDRESS is not defined.
[bhelgaas: drop extra detail from changelog, move def under CONFIG_PCI,
add dummy of_pci_range_to_resource() for build errors (from Arnd)] Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Arnd Bergmann <arnd@arndb.de> CC: Catalin Marinas <catalin.marinas@arm.com>
ARM: Define PCI_IOBASE as the base of virtual PCI IO space
This is needed for calls into OF code that parses PCI ranges. It signals
support for memory mapped PCI I/O accesses that are described by device
trees.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> CC: Russell King <linux@arm.linux.org.uk> CC: Rob Herring <robh+dt@kernel.org>
of/pci: Add pci_register_io_range() and pci_pio_to_address()
Some architectures do not have a simple view of the PCI I/O space and
instead use a range of CPU addresses that map to bus addresses. For some
architectures these ranges will be expressed by OF bindings in a device
tree file.
This patch introduces a pci_register_io_range() helper function with a
generic implementation that can be used by such architectures to keep track
of the I/O ranges described by the PCI bindings. If the PCI_IOBASE macro
is not defined, that signals lack of support for PCI and we return an
error.
In order to retrieve the CPU address associated with an I/O port, a new
helper function pci_pio_to_address() is introduced. This will search in
the list of ranges registered with pci_register_io_range() and return the
CPU address that corresponds to the given port.
[arnd: add dummy !CONFIG_OF pci_pio_to_address() to fix build errors] Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Rob Herring <robh@kernel.org> CC: Grant Likely <grant.likely@linaro.org>
asm-generic/io.h: Fix ioport_map() for !CONFIG_GENERIC_IOMAP
The !CONFIG_GENERIC_IOMAP version of ioport_map() is wrong. It returns a
mapped, i.e., virtual, address that can start from zero and completely
ignores the PCI_IOBASE and IO_SPACE_LIMIT that most architectures that use
!CONFIG_GENERIC_MAP define.
Alex Williamson [Fri, 26 Sep 2014 23:07:59 +0000 (17:07 -0600)]
PCI: Add ACS quirk for Intel 10G NICs
Intel has verified there is no peer-to-peer between functions for the below
selection of 82598, 82599, and X520 10G NICs. These NICs lack an ACS
capability, so we're not able to determine this isolation without the help
of quirks.
Generalize the Solarflare quirk and add these Intel 10G NICs.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: John Ronciak <John.ronciak@intel.com>
* pci/host-designware:
PCI: designware: Add get_msi_data() to pcie_host_ops
PCI: designware: Rename get_msi_data() to get_msi_addr()
PCI: designware: Fix IO resource end address calculation
PCI: designware: Fix configuration base address when using 'reg'
PCI: designware: Use NULL instead of false
[bhelgaas: Fixup keystone for "PCI: designware: Rename get_msi_data() to
get_msi_addr()"]
Chen, Gong [Wed, 13 Aug 2014 06:22:40 +0000 (02:22 -0400)]
PCI/AER: Rename PCI_ERR_UNC_TRAIN to PCI_ERR_UNC_UND
In PCIe r1.0, sec 5.10.2, bit 0 of the Uncorrectable Error Status, Mask,
and Severity Registers was for "Training Error." In PCIe r1.1, sec 7.10.2,
bit 0 was redefined to be "Undefined."
Rename PCI_ERR_UNC_TRAIN to PCI_ERR_UNC_UND to reflect this change.
No functional change.
[bhelgaas: changelog] Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Chen, Gong [Wed, 13 Aug 2014 06:22:37 +0000 (02:22 -0400)]
trace, RAS: Replace bare numbers with #defines for PCIe AER error strings
Replace bare numbers like "BIT(0)" with the existing #defines, e.g.,
PCI_ERR_COR_RCVR, to improve maintainability. This way grep will find more
uses of the #defines.
No functional change.
[bhelgaas: changelog] Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Merge branches 'pci/hotplug', 'pci/initdata' and 'pci/misc' into next
* pci/hotplug:
PCI: pciehp: Stop disabling notifications during init
PCI: pciehp: Add more Slot Control debug output
PCI: pciehp: Fix wait time in timeout message
* pci/initdata:
x86/PCI: Mark PCI BIOS initialization code as such
x86/PCI: Constify pci_mmcfg_probes[] array
x86/PCI: Mark constants of pci_mmcfg_nvidia_mcp55() as __initconst
x86/PCI: Move __init annotation to the correct place
x86/PCI: Mark DMI tables as initialization data
* pci/misc:
PCI: Move PCI_VENDOR_ID_VMWARE to pci_ids.h
Move PCI_VENDOR_ID_VMWARE from device-specific files to pci_ids.h.
It is useful to always have access to it, especially when accessing
subsystem_vendor_id on emulated devices.
[bhelgaas: keep pci_ids.h sorted and use lower-case hex] Signed-off-by: Francesco Ruggeri <fruggeri@arista.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add space before open parenthesis as is conventional.
No functional change.
[bhelgaas: fix a few more in ibmphp, shpchp] Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Minghuan Lian [Tue, 23 Sep 2014 14:28:56 +0000 (22:28 +0800)]
PCI: designware: Fix configuration base address when using 'reg'
The code has calculated cfg0_base and cfg1_base when parsing 'reg' or
'ranges' property of PCI DTS node, so remove duplicate calculation. When
using 'reg', resource cfg is not used, so this code computed an incorrect
configuration base.
Mathias Krause [Mon, 25 Aug 2014 21:26:39 +0000 (23:26 +0200)]
x86/PCI: Mark PCI BIOS initialization code as such
The pci_find_bios() function is only ever called from initialization code,
therefore can be marked as such, too. This, in turn, allows marking other
functions called only in this context as well.
The bios32_indirect variable can be marked as __initdata as it is only
referenced from __init functions now.
Mathias Krause [Mon, 25 Aug 2014 21:26:36 +0000 (23:26 +0200)]
x86/PCI: Move __init annotation to the correct place
According to include/linux/init.h, the __init annotation should be added
immediately before the function name. However, for quite a few functions
in mmconfig-shared.c this is not the case. It's either before the return
type or even in the middle of it. Beside gcc still getting it right, we
should change them to comply to the rules of include/linux/init.h.
For controllers with errata like Intel CF118, we previously waited for a
timeout before issuing the second hotplug command because the first command
only updates interrupt enable bits and is not a "real" hotplug command, so
the controller doesn't report Command Completed for it.
But there's no need to disable notifications in the first place. If BIOS
left them enabled, we could easily take an interrupt before disabling them,
so there's no benefit in disabling them for the tiny window before we
enable them.
Drop the unnecessary pcie_disable_notification() call.
Yinghai Lu [Tue, 23 Sep 2014 02:07:35 +0000 (20:07 -0600)]
PCI: pciehp: Fix wait time in timeout message
When we warned about a timeout on a hotplug command, we previously printed
the time between calls to pcie_write_cmd(), without accounting for any time
spent actually waiting. Consider this sequence:
pcie_write_cmd
pcie_wait_cmd
now = jiffies # T2
wait_event_timeout # we may wait here
if (timeout)
ctrl_info("Timeout on command issued %u msec ago",
jiffies_to_msecs(now - cmd_started))
We previously printed (T2 - T1), but that doesn't include the time spent in
wait_event_timeout().
Fix this by using the current jiffies value, not the one cached before
calling wait_event_timeout().
[bhelgaas: changelog, use current jiffies instead of adding timeout] Fixes: 40b960831cfa ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
of_get_address() expects pointers in the third and fourth parameters.
Pass NULL in order to fix the following sparse warnings:
drivers/pci/host/pcie-designware.c:433:51: warning: Using plain integer as NULL pointer
drivers/pci/host/pcie-designware.c:433:58: warning: Using plain integer as NULL pointer
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Jingoo Han <jg1.han@samsung.com>
Thomas Petazzoni [Wed, 17 Sep 2014 15:58:27 +0000 (17:58 +0200)]
PCI: mvebu: Fix uninitialized variable in mvebu_get_tgt_attr()
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.
Mathias Krause [Mon, 25 Aug 2014 21:26:35 +0000 (23:26 +0200)]
x86/PCI: Mark DMI tables as initialization data
The DMI tables are only used in __init code, thereby can be marked as
initialization data, too. The same is true for the callback functions
referenced from the DMI tables.
This moves ~9.6 kB of code and r/o data to the init sections, marking the
memory for release after initialization.
PCI: spear: Pass config resource through reg property
PCIe configuration space should be passed through reg property, rather than
through ranges property. This patch does the correction for SPEAr13XX
SOCs.
PCI: Generate uppercase hex for modalias interface class
Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.
The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D. Most interface types defined in the spec do not use
alpha characters, so they won't be affected. For example, 00h, 01h, 10h,
20h, etc. are unaffected.
Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.
Merge branches 'pci/host-designware', 'pci/host-imx6', 'pci/host-keystone', 'pci/host-tegra' and 'pci/host-xilinx' into next
* pci/host-designware:
PCI: designware: Fold struct pcie_port_info into struct pcie_port
* pci/host-imx6:
PCI: imx6: Delay enabling reference clock for SS until it stabilizes
* pci/host-keystone:
PCI: keystone: Set device ID based on SoC to support multiple ports
PCI: keystone: Assume controller is already in RC mode
PCI: keystone: Limit MRSS for all downstream devices
* pci/host-tegra:
PCI: tegra: Add Tegra124 support
PCI: tegra: Make sure the PCIe PLL is really reset
PCI: tegra: Fix extended configuration space mapping
PCI: tegra: Clear CLKREQ# enable on port disable
* pci/host-xilinx:
PCI: xilinx: Fix xilinx_pcie_assign_msi() return value test
Merge branches 'pci/enumeration', 'pci/misc' and 'pci/virtualization' into next
* pci/enumeration:
PCI: Enable CRS Software Visibility for root port if it is supported
PCI: Check only the Vendor ID to identify Configuration Request Retry
* pci/misc:
PCI: Parenthesize PCI_DEVID and PCI_VPD_LRDT_ID parameters
PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size
PCI/AER: Make <linux/aer.h> standalone includable
* pci/virtualization:
PCI: Use device flag helper functions
xen/pciback: Use PCI device flag helper functions
KVM: Use PCI device flag helper functions
PCI: Add device flag helper functions
PCI: Assume all Mellanox devices have broken INTx masking
PCI: Parenthesize PCI_DEVID and PCI_VPD_LRDT_ID parameters
Add parentheses around parameters in PCI_DEVID and PCI_VPD_LRDT_ID macros
to prevent possible expansion errors as described by the CERT Secure Coding
Standard: PRE01-C: Use parentheses within macros around parameter names
Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Megan Kamiya <megan.a.kamiya@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Thierry Reding [Tue, 26 Aug 2014 15:11:38 +0000 (17:11 +0200)]
PCI: tegra: Add Tegra124 support
The PCIe controller on Tegra124 has two root ports that can be used in a
x4/x1 or x2/x1 configuration and can run at PCIe 2.0 link speeds (up to
5 GT/s). The PHY programming has been moved into a separate controller, so
the driver now needs to request an external PHY referenced using the device
tree.
Eric Yuen [Tue, 26 Aug 2014 15:11:37 +0000 (17:11 +0200)]
PCI: tegra: Make sure the PCIe PLL is really reset
Depending on the prior state of the controller, the PLL reset may not be
pulsed. Clear the register bit and set it after a small delay to ensure
that the PLL is really reset.
Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Eric Yuen <eyuen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Peter Daifuku [Tue, 26 Aug 2014 15:11:36 +0000 (17:11 +0200)]
PCI: tegra: Fix extended configuration space mapping
The 16 chunks of 64 KiB that need to be stitched together to make up the
configuration space for one bus (1 MiB) are located 24 bits (== 16 MiB)
apart in physical address space. This is determined by the start of the
extended register field (bits 24-27) in the physical mapping.
Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Peter Daifuku <pdaifuku@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Douglas Lehr [Wed, 20 Aug 2014 23:26:52 +0000 (09:26 +1000)]
PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size
The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to
an erratum, setting the SR-IOV page size causes the physical function BARs
to expand to the system page size. Since ppc64 uses 64k pages, when Linux
tries to assign the smaller resource sizes to the now 64k BARs the address
will be truncated and the BARs will overlap.
Force Linux to allocate the resource as a full page, which avoids the
overlap.
[bhelgaas: print expanded resource, too] Signed-off-by: Douglas Lehr <dllehr@us.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Milton Miller <miltonm@us.ibm.com> CC: stable@vger.kernel.org
Thierry Reding [Tue, 5 Aug 2014 12:08:55 +0000 (14:08 +0200)]
PCI/AER: Make <linux/aer.h> standalone includable
The header file references u16 and u32 types, but they are not defined in
the header nor does the header pull in the necessary includes for them.
This causes build breakage when the file is included without any of the
dependencies being satisfied from somewhere else.
Fix this by including linux/types.h (for u16 and u32).
PCI: keystone: Set device ID based on SoC to support multiple ports
K2E SoC has two PCI ports. The SATA controller is connected to second PCI
port (port 1). To support multiple port handling in Keystone PCI driver,
read the PCI device ID dynamically by iomap/read/unmap during probe and
save it in driver's private data and update it in host init code. The PCI
device ID field in the RC's config space is not filled by default by the
hardware and has to be updated by the PCI driver by reading the same from
the SoC register indicated by reg index #2 in DT bindings.
PCI: keystone: Assume controller is already in RC mode
Keystone PCI hardware supports both RC and EP modes and devcfg register has
bits to boot strap the device to either of these modes. It seems proper to
add this functionality to the boot loader rather than in the driver as
device will be operating in either mode, not both any time. Currently the
driver supports only RC mode and hence register configuration in the driver
is not needed and the driver can assume the hardware is in RC mode.
PCI: keystone: Limit MRSS for all downstream devices
Keystone PCIe controller has a limitation that memory read request size
must not exceed 256 bytes. This is a hardware limitation. Add a quirk to
force this limit on all downstream devices by updating MRRS.
Andreas Noever [Tue, 16 Sep 2014 21:16:02 +0000 (15:16 -0600)]
PCI: pciehp: Prevent NULL dereference during probe
pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's
secondary bus, exists. But we do not create that bus if we run out of bus
numbers during enumeration. This leads to a NULL dereference in
init_slot() (and other places).
Change pciehp_probe() to return -ENODEV when no secondary bus is present.
Bjorn Helgaas [Fri, 15 Aug 2014 23:18:44 +0000 (17:18 -0600)]
PCI: pciehp: Reduce PCIe slot_ctrl to 16 bits
4283c70e91dc ("PCI: pciehp: Make pcie_wait_cmd() self-contained") added
a cache of the most recent command written to the Slot Control register.
This register is only 16 bits wide, but the cache ("slot_ctrl") is 32 bits.
Reduce slot_ctrl to a u16 so it matches the register size. No functional
change.
Bjorn Helgaas [Sat, 30 Aug 2014 13:23:01 +0000 (07:23 -0600)]
PCI: Configure *all* devices, not just hot-added ones
There's not really a good way to determine whether firmware has already
configured a device with _HPP/_HPX settings. On legacy systems, the BIOS
has probably configured everything, but on UEFI systems it is not required
to do so.
Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or
PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding
BARs and maybe we can assume it has configured the rest of the device. And
if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume
firmware has configured the bridge. But we can't tell much about devices
without BARs.
I think it should be safe to apply _HPP and _HPX settings anyway, even if
firmware has already configured the device, so configure everything we
find.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
PCI: Preserve MPS and MRRS when applying _HPX settings
Linux manages MPS and MRRS settings to keep them consistent across the PCIe
fabric. BIOS doesn't participate in this Linux management, so ignore that
part of any _HPX settings it supplies.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas [Sat, 30 Aug 2014 13:22:13 +0000 (07:22 -0600)]
PCI: Apply _HPP settings to all hot-added PCI devices
We currently apply _HPP settings only to:
- non-bridge devices, and
- PCI-to-PCI bridges
i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been
that way since _HPP support was added by 40abb96c51bb ("pciehp: Fix
programming hotplug parameters"), but I don't think there's any reason to
exclude these other bridges.
Apply _HPP settings to hot-added PCI devices of any type.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas [Wed, 27 Aug 2014 20:38:14 +0000 (14:38 -0600)]
PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settings
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The
spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1,
we should enable SERR in the command register. It says nothing about
*disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should
leave PERR alone unless "Enable PERR" is 1.
For hot-added devices, this probably doesn't matter because they power up
with these bits cleared. But in addition to hot-plugged devices, the spec
allows the platform to use _HPP for "configuration of PCI devices not
configured by the BIOS at system boot," and it may make a difference for
devices present at boot.
This change means that if BIOS enables SERR or PERR on a device, and it
supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will now
leave SERR or PERR reporting enabled on that device instead of disabling it
as we previously did.
See also 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), where
this code was first added.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas [Sat, 30 Aug 2014 00:10:19 +0000 (18:10 -0600)]
PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-X
The ACPI _HPP method was defined before PCIe existed, so its documentation
only mentions PCI. The _HPX Type 0 setting record is essentially identical
to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied
to PCI, PCI-X, and PCIe devices, with settings being ignored if they are
not applicable.
Some platforms with both conventional PCI and PCIe devices provide only
_HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and
apply it to PCIe devices as well as PCI and PCI-X.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas [Wed, 27 Aug 2014 20:29:47 +0000 (14:29 -0600)]
PCI: Add pci_configure_device() during enumeration
Some platforms can tell the OS how to configure PCI devices, e.g., how to
set cache line size, error reporting enables, etc. ACPI defines _HPP and
_HPX methods for this purpose.
This configuration was previously done by some of the hotplug drivers using
pci_configure_slot(). But not all hotplug drivers did this, and per the
spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not
configured by the BIOS at system boot."
Move this configuration into the PCI core by adding pci_configure_device()
and calling it from pci_device_add(), so we do this for all devices as we
enumerate them.
This is based on pci_configure_slot(), which is used by hotplug drivers.
I omitted:
- pcie_bus_configure_settings() because it configures MPS and MRRS, which
requires global knowledge of the fabric and must be done later, and
- configuration of subordinate devices; that will happen when we call
pci_device_add() for those devices.
Because pci_configure_slot() was only done by hotplug drivers, this initial
version of pci_configure_device() only configures hot-added devices,
ignoring anything added during boot.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>