This patch adds a check for DT passed reset-gpios property and deasserts/
asserts reset pin on probe/remove with configurable delay. Corresponding
binding documentation is also updated.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

This removes the subsys_initcall from the driver and converts it to
a normal platform_driver. Also, drvdata is set and a remove functions
is added to disable the clock and free resources. As pci driver removal
currently is not supported, set .suppress_bind_attrs to permit unbinding.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The number of ports is probed by counting the number of available child nodes.
Later on, the registration of a port can fail and cause a mismatch between
the ->nports counter and registered ports. This patch modifies the counting
strategy, to make ->nports represent the number of registered ports instead
of the number of available childs.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The clock passed to PCI controller found on MVEBU SoCs may come from a
clock gate. This requires the clock to be enabled before any registers
are accessed. Therefore, move the clock enable before register iomap to
ensure it is enabled.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

This commit adds support for Message Signaled Interrupts in the
Marvell PCIe host controller. The work is very simple: it simply gets
a reference to the msi_chip associated to the PCIe controller thanks
to the msi-parent DT property, and stores this reference in the
pci_bus structure. This is enough to let the Linux PCI core use the
functions of msi_chip to setup and teardown MSIs.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NThierry Reding <thierry.reding@gmail.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

After the last architecture switched to generic hard irqs the config
options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
for !CONFIG_GENERIC_HARDIRQS can be removed.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

In the current ACPIPHP notify handler we always go directly for a
rescan of the parent bus if we get a device check notification for
a device that is not a bridge.  However, this obviously is
overzealous if nothing really changes, because this way we may rescan
the whole PCI hierarchy pretty much in vain.

That happens on Alex Williamson's machine whose ACPI tables contain
device objects that are supposed to coresspond to PCIe root ports,
but those ports aren't physically present (or at least they aren't
visible in the PCI config space to us).  The BIOS generates multiple
device check notifies for those objects during boot and for each of
them we go straight for the parent bus rescan, but the parent bus is
the root bus in this particular case.  In consequence, we rescan the
whole PCI bus from the top several times in a row, which is
completely unnecessary, increases boot time by 50% (after previous
fixes) and generates excess dmesg output from the PCI subsystem.

Fix the problem by checking if we can find anything new in the
slot corresponding to the device we've got a device check notify
for and doing nothig if that's not the case.

The spec (ACPI 5.0, Section 5.6.6) appears to mandate this behavior,
as it says:

  Device Check. Used to notify OSPM that the device either appeared
  or disappeared. If the device has appeared, OSPM will re-enumerate
  from the parent. If the device has disappeared, OSPM will
  invalidate the state of the device. OSPM may optimize out
  re-enumeration.

Therefore, according to the spec, we are free to do nothing if
nothing changes.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60865Reported-and-tested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The spec suggests that we should use _OST to notify the platform
about the status of notifications it sends us, for example so that
it doesn't repeate a notification that has been handled already.

This turns out to help reduce the amount of diagnostic output from
the ACPIPHP subsystem and speed up boot on at least one system that
generates multiple device check notifies for PCIe devices on the root
bus during boot.
Reported-and-tested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Sometimes we may get a spurious device check or bus check notify for
a hotplug device and in those cases we should avoid doing all of the
configuration work needed when something actually changes.  To that
end, check the return value of pci_scan_slot() in enable_slot() and
bail out early if it is 0.

This turns out to help reduce the amount of diagnostic output from
the ACPIPHP subsystem and speed up boot on at least one system that
generates multiple device check notifies for PCIe devices on the root
bus during boot.
Reported-and-tested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In acpiphp_bus_add() we first remove device objects corresponding to
the given handle and the ACPI namespace branch below it, which are
then re-created by acpi_bus_scan().  This used to be done to clean
up after surprise removals, but now we do the cleanup through
trim_stale_devices() which checks if the devices in question are
actually gone before removing them, so the device hierarchy trimming
in acpiphp_bus_add() is not necessary any more and, moreover, it may
lead to problems if it removes device objects corresponding to
devices that are actually present.

For this reason, remove the leftover acpiphp_bus_trim() from
acpiphp_bus_add().
Reported-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add an arch specific attribute to recover a pci function from an
error state or config space blockage.
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Convert s390' pci hotplug to be builtin only, with no module option.
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Use devm_ioremap_resource instead of devm_request_and_ioremap.

This was done using the semantic patch
scripts/coccinelle/api/devm_ioremap_resource.cocci

Error-handling code was manually removed from the associated calls to
platform_get_resource.

Adjust the comment at the third platform_get_resource_byname to make clear
why ioremap is not done at this point.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This patch adds wrappers for MMIO access to ELBI, PHY, and other
registers.  No functional change.

[bhelgaas: changelog]
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>

The "dbi_addr" argument to dw_pcie_readl_rc() and dw_pcie_writel_rc()
is redundant and misleading because we always have the "struct pcie_port"
and we always want to use the address from there.

This patch removes the argument and changes the callers to match.
No functional change.

[bhelgaas: changelog]
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>

pcie_cap_has_devctl() does nothing, so remove it.  Simplicity over
consistency in this case.  No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-By: NJiang Liu <jiang.liu@huawei.com>

Previously we allowed callers to access Slot Capabilities, Status, and
Control for Root Ports even if the Root Port did not implement a slot.
This seems dubious because the spec only requires these registers if a
slot is implemented.

It's true that even Root Ports without slots must have *space* for these
slot registers, because the Root Capabilities, Status, and Control
registers are after the slot registers in the capability.  However,
for a v1 PCIe Capability, the *semantics* of the slot registers are
undefined unless a slot is implemented.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-By: NJiang Liu <jiang.liu@huawei.com>

Previously we relied on the PCIe r3.0, sec 7.8, spec language that says
"For Functions that do not implement the [Link, Slot, Root] registers,
these spaces must be hardwired to 0b," which means that for v2 PCIe
capabilities, we don't need to check the device type at all.

But it's simpler if we don't need to check the capability version at all,
and I think the spec is explicit enough about which registers are required
for which types that we can remove the version checks.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-By: NJiang Liu <jiang.liu@huawei.com>

Every PCIe device has a link, except Root Complex Integrated Endpoints
and Root Complex Event Collectors.  Previously we didn't give access
to PCIe capability link-related registers for Upstream Ports, Downstream
Ports, and Bridges, so attempts to read PCI_EXP_LNKCTL incorrectly
returned zero.  See PCIe spec r3.0, sec 7.8 and 1.3.2.3.

Reference: http://lkml.kernel.org/r/979A8436335E3744ADCD3A9F2A2B68A52AD136BE@SJEXCHMB10.corp.ad.broadcom.comReported-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-By: NJiang Liu <jiang.liu@huawei.com>

All other PCIe capability register fields include "PCI_EXP" + <reg-name> +
<field-name>.  This renames PCI_EXP_OBFF_MASK, PCI_EXP_IDO_REQ_EN,
PCI_EXP_LTR_EN, and related fields using the same convention.
No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>	# for MFD driver

If a BIOS configures MPS incorrectly, devices may not work normally.
For example, if a bridge has MPS set larger than an endpoint below it,
the endpoint may discard packets.

To help diagnose this issue, print a warning if we find an endpoint
MPS setting different than that of the upstream bridge.

[bhelgaas: changelog, "bridge" temporary, warning text]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60799Reported-by: NJoe Jin <joe.jin@oracle.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Jon Mason <jdmason@kudzu.us>

Correct minor wording issue in MPS peer-to-peer comment.  Noticed by Don
Dutile.
Signed-off-by: NJon Mason <jdmason@kudzu.us>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We disable BARs while sizing them so we don't cause conflicts with other
devices (see 253d2e54 and bbffe435).  But if device decoding is already
disabled before we size the BAR, we don't need to disable it again.

[bhelgaas: changelog, add PCI_COMMAND_DECODING_ENABLE for readability]
Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Per f5f2b131 ("msi: sanely support hardware level msi disabling"), we
want pci_msi_off() to work even if MSI support is not compiled into the
kernel, and there are existing callers that use it when CONFIG_PCI_MSI=n.
This adds a comment to that effect.

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

Platforms may want to provide architecture-specific functionality when
a PCI device is doing a hibernate transition.  Add a weak symbol
pcibios_pm_ops that architectures can override to do so.

[bhelgaas: fold in return value checks from v2 patch]
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When booting with "pci=pcie_bus_safe", we previously limited the
fabric MPS to 128 when we found:

  (1) A hotplug-capable Downstream Port ("dev->is_hotplug_bridge &&
      pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT"), or

  (2) A hotplug-capable Root Port with a slot that was either empty or
      contained a multi-function device ("dev->is_hotplug_bridge &&
      !list_is_singular(&dev->bus->devices)")

Part (1) is valid, but part (2) is not.

After a hot-add in the slot below a Root Port, we can reconfigure all
MPS values in the fabric below the Root Port because the new device is
the only thing below the Root Port and there are no active drivers.
Therefore, there's no reason to limit the MPS for Root Ports, no
matter what's in the slot.

Test info:

    -+-[0000:40]-+-07.0-[0000:46]--+-00.0  Intel 82576 NIC
                                   \-00.1  Intel 82576 NIC

    0000:40:07.0 Root Port bridge to [bus 46] (MPS supported=256)
    0000:46:00.0 Endpoint                     (MPS supported=512)
    0000:46:00.1 Endpoint                     (MPS supported=512)

    # echo 0 > /sys/bus/pci/slots/7/power
    # echo 1 > /sys/bus/pci/slots/7/power
    pcieport 0000:40:07.0: PCI-E Max Payload Size set to 256/ 256 (was 256)
    pci 0000:46:00.0:      PCI-E Max Payload Size set to 256/ 512 (was 128)
    pci 0000:46:00.1:      PCI-E Max Payload Size set to 256/ 512 (was 128)

Before this change, we set MPS to 128 for the Root Port and both NICs
because the slot contained a multi-function device and

    dev->is_hotplug_bridge && !list_is_singular(&dev->bus->devices)

was true.  After this change, we set it to 256.

[bhelgaas: changelog, comments, split out upstream bridge check]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Jon Mason <jdmason@kudzu.us>

PCIe hotplug bridges are always either Root Ports or Downstream Ports.  No
other device type can have a PCIe link leading downstream to a slot.

Root Ports don't have an upstream bridge, so "dev->is_hotplug_bridge &&
dev->bus->self" is true if and only if "dev" is a Downstream Port.  That
means we can simplify this by looking at the type of "dev" itself, without
looking upstream at all.

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

After 59875ae4 ("PCI/core: Use PCI Express Capability accessors"),
pcie_get_mps() never returns an error, so don't bother to check for it.

No functional change.

[bhelgaas: changelog, fix pcie_get_mps() doc]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Based on a patch by Jon Mason (see URL below).

All users of pcie_bus_configure_settings() pass arguments of the form
"bus, bus->self->pcie_mpss".  The "mpss" argument is redundant since we
can easily look it up internally.  In addition, all callers check
"bus->self" for NULL, which we can also do internally.

This patch simplifies the interface and the callers.  No functional change.

Reference: http://lkml.kernel.org/r/1317048850-30728-2-git-send-email-mason@myri.comSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>

The conventional spelling is "PCIe", but I think even that is superfluous,
so remove the whole thing.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

After commit bbd34fcd (ACPI / hotplug / PCI: Register all devices
under the given bridge) register_slot() is called for all PCI
devices under a given bridge that have corresponding objects in
the ACPI namespace, but it calls acpiphp_register_hotplug_slot()
only for devices satisfying specific criteria.  Still,
cleanup_bridge() calls acpiphp_unregister_hotplug_slot() for all
objects created by register_slot(), although it should only call it
for the ones that acpiphp_register_hotplug_slot() has been called
for (successfully).  This causes a NULL pointer to be dereferenced
by the acpiphp_unregister_hotplug_slot() executed by cleanup_bridge()
if the object it is called for has not been passed to
acpiphp_register_hotplug_slot().

To fix this problem, check if the 'slot' field of the object passed
to acpiphp_unregister_hotplug_slot() in cleanup_bridge() is not NULL,
which only is the case if acpiphp_register_hotplug_slot() has been
executed for that object.  In addition to that, make register_slot()
reset the 'slot' field to NULL if acpiphp_register_hotplug_slot() has
failed for the given object to prevent stale pointers from being
used by acpiphp_unregister_hotplug_slot().
Reported-and-tested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Users of pci_reset_bus() and pci_reset_slot() need a way to probe
whether the bus or slot supports reset.  Add trivial helper functions
and export them as vfio-pci will make use of these.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

One PCI bus reset function to rule them all.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst).  We should be able to assume
stable power for a Hot Reset, but we add another millisecond as
a fudge factor to make sure the reset is seen on the bus for at least
a full 1ms.

After reset is de-asserted we must wait for devices to complete
initialization.  The specs refer to this as "recovery time" (Trhfa).
For PCI this is 2^25 clock cycles or 2^26 for PCI-X.  For minimum
bus speeds, both of those come to 1s.  PCIe "softens" this
requirement with the Configuration Request Retry Status (CRS)
completion status.  Theoretically we could use CRS to shorten the
wait time.  We don't make use of that here, using a fixed 1s delay
to allow devices to re-initialize.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Devices come out of reset in D0.  Restoring a device to a different
post-reset state takes more smarts than our simple config space
restore, which can leave devices in an inconsistent state.  For
example, if a device is reset in D3, but the restore doesn't
successfully return the device to D3, then the actual state of the
device and dev->current_state are contradictory.  Put everything
in D0 going into the reset, then we don't need to do anything
special on the way out.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Sometimes pci_reset_function() is not sufficient.  We have cases where
devices do not support any kind of reset, but there might be multiple
functions on the bus preventing pci_reset_function() from doing a
secondary bus reset.  We also have cases where a device will advertise
that it supports a PM reset, but really does nothing on D3hot->D0
(graphics cards are notorious for this).  These devices often also
have more than one function, so even blacklisting PM reset for them
wouldn't allow a secondary bus reset through pci_reset_function().

If a driver supports multiple devices it should have the ability to
induce a bus reset when it needs to.  This patch provides that ability
through pci_reset_slot() and pci_reset_bus().  It's the caller's
responsibility when using these interfaces to understand that all of
the devices in or below the slot (or on or below the bus) will be
reset and therefore should be under control of the caller.  PCI state
of all the affected devices is saved and restored around these resets,
but internal state of all of the affected devices is reset (which
should be the intention).
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Only cosmetic code changes to existing paths.  Expand the comment in
the new pci_dev_save_and_disable() function since there's a lot
hidden in that Command register write.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If the hotplug controller provides a way to reset a slot, use that
before a direct parent bus reset.  Like the bus reset option, this is
only available when a single pci_dev occupies the slot.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCIe hotplug has a bus per slot, so we can just use a normal
secondary bus reset.  However, if a slot supports surprise removal,
a bus reset can be seen as a presence detection change triggering
a hot-remove followed by a hot-add.  Disable presence detection from
triggering an interrupt or being polled around the bus reset.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Tegra20 HW appears to have a bug such that PCIe device interrupts,
whether they are legacy IRQs or MSI, are lost when LP2 is enabled. To
work around this, simply disable LP2 if any PCIe devices with interrupts
are present. Detect this via the IRQ domain map operation. This is
slightly over-conservative; if a device with an interrupt is present but
the driver does not actually use them, LP2 will still be disabled.
However, this is a reasonable trade-off which enables a simpler
workaround.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>