The commit referenced below deferred waiting for command completion until
the start of the next command, allowing hardware to do the latching
asynchronously.  Unfortunately, being ready to accept a new command is the
only indication we have that the previous command is completed.  In cases
where we need that state change to be enabled, we must still wait for
completion.  For instance, pciehp_reset_slot() attempts to disable anything
that might generate a surprise hotplug on slots that support presence
detection.  If we don't wait for those settings to latch before the
secondary bus reset, we negate any value in attempting to prevent the
spurious hotplug.

Create a base function with optional wait and helper functions so that
pcie_write_cmd() turns back into the "safe" interface which waits before
and after issuing a command and add pcie_write_cmd_nowait(), which
eliminates the trailing wait for asynchronous completion.  The following
functions are returned to their previous behavior:

  pciehp_power_on_slot
  pciehp_power_off_slot
  pcie_disable_notification
  pciehp_reset_slot

The rationale is that pciehp_power_on_slot() enables the link and therefore
relies on completion of power-on.  pciehp_power_off_slot() and
pcie_disable_notification() need a wait because data structures may be
freed after these calls and continued signaling from the device would be
unexpected.  And, of course, pciehp_reset_slot() needs to wait for the
scenario outlined above.

Fixes: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily")
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.17+

If the ignore_hotplug flag is set for a PCI device without an ACPI
companion and a bus check notification is received for an ancestor bridge
that is not the device's parent, ACPIPHP will ignore that flag.

Namely, in that case acpiphp_check_bridge() is called for the target bridge
and if all of the devices immediately below the bridge are still present,
trim_stale_devices() will be called for each of them.  That function
recursively walks the hierarchy downwards and removes device objects
corresponding to devices that don't appear to be present any more.
Unfortunately, it only checks ignore_hotplug for devices having ACPI
companions, so it will remove the others (if they don't respond) regardless
of the ignore_hotplug value.

Fix the problem by making trim_stale_devices() take ignore_hotplug into
consideration regardless of whether or not an ACPI companion is present for
the device it has been called for.

[bhelgaas: This may fix bug 61891, depending on whether the bridge above a
device is removed along with the device]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The err_out_none label in pciehp_probe() only leads to a return statement,
so use return statements instead of jumps to it and drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Jarod Wilson reports that ExpressCard hotplug doesn't work on HP ZBook G2.
The problem turns out to be the ACPI-based "slot detection" code called
from pciehp_probe() which uses questionable heuristics based on what ACPI
objects are present for the PCIe port device to figure out whether to
register a hotplug slot for that port.

That code is used if there is at least one PCIe port having an ACPI device
configuration object related to hotplug (such as _EJ0 or _RMV), and the
Thunderbolt port on the ZBook has _RMV.  Of course, Thunderbolt and PCIe
native hotplug need not be mutually exclusive (as they aren't on the
ZBook), so that rule is simply incorrect.

Moreover, the ACPI-based "slot detection" check does not add any value if
pciehp_probe() is called at all and the service type of the device object
it has been called for is PCIE_PORT_SERVICE_HP, because PCIe hotplug
services are only registered if the _OSC handshake in acpi_pci_root_add()
allows the kernel to control the PCIe native hotplug feature.  No more
checks need to be carried out to decide whether or not to register a native
PCIe hotlug slot in that case.

For the above reasons, make pciehp_probe() check if it has been called for
the right service type and drop the pointless ACPI-based "slot detection"
check from it.  Also remove the entire code whose only user is that check
(the entire pciehp_acpi.c file goes away as a result) and drop function
headers related to it from the internal pciehp header file.

Link: http://lkml.kernel.org/r/1431632038-39917-1-git-send-email-jarod@redhat.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98581Reported-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJarod Wilson <jarod@redhat.com>
Tested-by: NJarod Wilson <jarod@redhat.com>

Originally, EEH core probes on device_node or pci_dev to populate
EEH devices and PEs, which conflicts with the fact: SRIOV VFs are
usually enabled and created by PF's driver and they don't have the
corresponding device_nodes. Instead, SRIOV VFs have dynamically
created pci_dn, which can be used for EEH probe.

The patch reworks EEH probe for PowerNV and pSeries platforms to
do probing based on pci_dn, instead of pci_dev or device_node any
more.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Previously, pci_scan_bus() created a root PCI bus, enumerated the devices
on it, and called pci_bus_add_devices(), which made the devices available
for drivers to claim them.

Most callers assigned resources to devices after pci_scan_bus() returns,
which may be after drivers have claimed the devices.  This is incorrect;
the PCI core should not change device resources while a driver is managing
the device.

Remove pci_bus_add_devices() from pci_scan_bus() and do it after any
resource assignment in the callers.

[bhelgaas: changelog, check for failure in mcf_pci_init()]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Guan Xuetao <gxt@mprc.pku.edu.cn>
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: Matt Turner <mattst88@gmail.com>

I don't have this hardware but it looks like we weren't adding bridge
devices as intended.  Maybe the bridge is always the last device?

Fixes: 05b12500 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYijing Wang <wangyijing@huawei.com>
CC: stable@vger.kernel.org	# v3.9+

ACPICA has implemented acpi_unload_parent_table() which can exactly replace
the acpi_get_id()/acpi_unload_table_id() implemented in Linux kernel.  The
acpi_unload_parent_table() has been unit tested in ACPICA simulation
environment.

This patch can also help to reduce the source code differences between
Linux and ACPICA.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Tested-by: NOctavian Purdila <octavian.purdila@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support
for surprise *removal*, but pciehp checked this to determine if it should
handle presence detect interrupts for device *addition*.

Allow surprise device addition even if the slot doesn't advertise support
for surprise removal.

Keith has a platform with slots for front-loading SFF devices.  The slots
do not have attention buttons and do not support surprise removal, but they
do have presence detect.  In that case, we still want to use presence
detect for device addition.

Keith's original patch handled surprise insertions only if Hot-Plug Capable
is set.  I think that test is superfluous because pciehp only claims slots
that advertise Hot-Plug Capable (see get_port_device_capability()).

Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.comBased-on-patch-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>

The pci_dev_put() function tests whether its argument is NULL and then
returns immediately.  Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Clean up code by moving IOAPIC related declarations from hw_irq.h into
io_apic.h.
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Aubrey <aubrey.li@linux.intel.com>
Cc: Ryan Desfosses <ryan@desfo.org>
Cc: Quentin Lambert <lambert.quentin@gmail.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: http://lkml.kernel.org/r/1414397531-28254-14-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

None of the callers requires irq_attr to be filled
in. IO_APIC_get_PCI_irq_vector() does not do anything useful with it
either.

Remove the parameter and fixup the call sites.

[ tglx: Massaged changelog ]
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Ryan Desfosses <ryan@desfo.org>
Cc: Quentin Lambert <lambert.quentin@gmail.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: http://lkml.kernel.org/r/1414397531-28254-4-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Simplify a trivial if-return sequence.  Possibly combine with a preceding
function call.

Generated by: scripts/coccinelle/misc/simple_return.cocci
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This reverts bceee4a9 ("PCI: pciehp: Prevent NULL dereference during
probe") because it was accidentally applied twice:

  62e4492c ("PCI: Prevent NULL dereference during pciehp probe")
  bceee4a9 ("PCI: pciehp: Prevent NULL dereference during probe")

Revert the latter to dispose of the duplicated code block.

[bhelgaas: tidy changelog, drop stable tag]
Signed-off-by: NKamal Mostafa <kamal@canonical.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Andreas Noever <andreas.noever@gmail.com>

The modifications effectively change the value of len_tmp
in the case where the first condition is not met.
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The following Coccinelle semantic patch was used to find and correct cases
of assignments in "if" conditions:

@@
expression var, expr;
statement S;
@@

+ var = expr;
  if(
- (var = expr)
+ var
  ) S
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Remove curly braces in simple "if" cases.

No functional change.
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NBjorn 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: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

During pciehp initialization, we previously wrote two hotplug commands:

  pciehp_probe
    pcie_init
      pcie_disable_notification
        pcie_write_cmd           # command 1
    pcie_init_notification
      pcie_enable_notification
        pcie_write_cmd           # command 2

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.

[bhelgaas: changelog]
Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.htmlSigned-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add more Slot Control debug output and move one print after
pcie_write_cmd() to be consistent with other debug output.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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
    write SLTCTL
    cmd_started = jiffies          # T1

  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: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pcie_poll_cmd() take msecs instead of jiffies, so convert timeout to msecs.

Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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.
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.2+

4283c70e ("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.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We now configure each PCI device as it is enumerated, in pci_device_add(),
so remove the configuration done in acpiphp.

That configuration, in pci_configure_device(), does not include the
MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep
that here.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

We now configure each PCI device as it is enumerated, in pci_device_add(),
so remove the configuration done in shpchp.

That configuration, in pci_configure_device(), does not include the
MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep
that here.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

We now configure each PCI device as it is enumerated, in pci_device_add(),
so remove the configuration done in pciehp.

That configuration, in pci_configure_device(), does not include the
MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep
that here.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Move pci_configure_slot() and related functions from
drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c.

This is to prepare for doing device configuration during the normal
enumeration process instead of just after hot-add.

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

Move pci_get_hp_params() and related functions from
drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c.

Previously, pci_get_hp_params() was used only by hotplug drivers.  But
future changes will move this into the normal device enumeration process,
so it will be used even when CONFIG_HOTPLUG_PCI is not set.

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

We configure cache line size and other settings of hot-added devices, e.g.,
based on ACPI _HPP or _HPX methods.  Previously we skipped this for display
devices, but ACPI rev 5.0, sec 6.2.7 and 6.2.8 have no requirement to skip
them.

Remove the check so we configure display devices the same way we configure
other devices.

See also ac81860e ("PCI: hotplug: pciehp: Removed check for hotplug of
display devices").
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

We print way too many messages like this:

    pci 0000:00:00.0: no hotplug settings from platform
    pci 0000:00:00.0: using default PCI settings

This usually happens when the platform doesn't supply an ACPI _HPP method,
but the method is optional, so there's no point in warning about it.

Not only are the messages useless, but we call pci_configure_slot() far too
many times, so they're repeated many times.  I'll fix the overuse of
pci_configure_slot() too, but that will wait until the next merge window.

For now, just remove both log messages.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84391Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
normally generates a hot-remove event that unbinds the driver.

Some drivers expect to remain bound to a device even while they power it
off and back on again.  This can be dangerous, because if the device is
removed or replaced while it is powered off, the driver doesn't know that
anything changed.  But some drivers accept that risk.

Add pci_ignore_hotplug() for use by drivers that know their device cannot
be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
events for the device should be ignored.

The radeon and nouveau drivers use this to switch between a low-power,
integrated GPU and a higher-power, higher-performance discrete GPU.  They
power off the unused GPU, but they want to remain bound to it.

This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
Fix VGA switcheroo problem related to hotplug") but extends it to work with
both acpiphp and pciehp.

This fixes a problem where systems with dual GPUs using the radeon drivers
become unusable, freezing every few seconds (see bugzillas below).  The
resume of the radeon device may also fail, e.g.,

This fixes problems on dual GPU systems where the radeon driver becomes
unusable because of problems while suspending the device, as in bug 79701:

    [drm] radeon: finishing device.
    radeon 0000:01:00.0: Userspace still has active objects !
    radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
    ...
    WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
    trying to unbind memory from uninitialized GART !

or while resuming it, as in bug 77261:

    radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
    radeon 0000:01:00.0: GPU lockup ...
    radeon 0000:01:00.0: GPU pci config reset
    pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
    radeon 0000:01:00.0: GPU reset succeeded, trying to resume
    *ERROR* radeon: dpm resume failed
    radeon 0000:01:00.0: Wait for MC idle timedout !

Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com>
Reported-by: NJose P. <lbdkmjdf@sharklasers.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
CC: stable@vger.kernel.org	# v3.15+

KMSG_COMPONENT has to be defined instead of COMPONENT.
Signed-off-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Fixes the following sparse warning:

drivers/pci/hotplug/acpiphp_glue.c:923:6: warning:
 symbol 'acpiphp_drop_bridge' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since all of the acpi_set_hp_context() callers pass at least one NULL
function pointer and one caller passes NULL function pointers only
to it, drop function pointer arguments from acpi_set_hp_context()
and make the callers initialize the function pointers in struct
acpi_hotplug_context by themselves before passing it to
acpi_set_hp_context().
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

Since acpiphp_dev_to_bridge() is only called by
acpiphp_check_host_bridge(), move the code from it to that function
directly which reduces the call chain depth and makes the code
slightly easier to follow.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

Fix checkpatch warning:
"WARNING: debugfs_remove(NULL) is safe this check is probably not required"
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Ryan Desfosses <ryan@desfo.org>

During PCIe hot-plug initialization - pciehp_probe() - data structures
related to slot capabilities are set up.  As part of this set up, ISRs are
put in place to handle slot events and all event bits are cleared out.

This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC)
Slot Status bit to the event bits that are cleared out during
initialization.

If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices
that it's set and interprets it as a new Link Up event, which results in
spurious messages:

  pciehp 0000:82:04.0:pcie24: slot(4): Link Up event
  pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add
  pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00

Prior to e48f1b67 ("PCI: pciehp: Use link change notifications for
hot-plug and removal"), pciehp ignored DLLSC.

Reference:
  PCI-SIG.  PCI Express Base Specification Revision 4.0 Version 0.3
  (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah).

[bhelgaas: add e48f1b67 ref and stable tag]
Fixes: e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.15+

"no_cmd_complete" is only used once, and it duplicates read-only
information we already have in the cached Slot Capabilities value.

Remove the field and use the existing macro NO_CMD_CMPL() instead.

[bhelgaas: changelog]
Signed-off-by: NRajat Jain <rajatxjain@gmail.com>
Signed-off-by: NRajat Jain <rajatjain@juniper.net>
Signed-off-by: NGuenter Roeck <groeck@juniper.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

There are a bunch of users open coding the for_each_node_by_name() by
calling of_find_node_by_name() directly instead of using the macro. This
is getting in the way of some cleanups, and the possibility of removing
of_find_node_by_name() entirely. Clean it up so that all the users are
consistent.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Takashi Iwai <tiwai@suse.de>