linux-stable.git/drivers/pci/hotplug, branch v3.12.9

ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug

2014-01-09T20:25:16+00:00

commit f244d8b623dae7a7bc695b0336f67729b95a9736 upstream.

The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian 
Reported-and-tested-by: 
Reported-and-tested-by: Joaquín Aramendía 
Cc: Alex Deucher 
Cc: Dave Airlie 
Cc: Takashi Iwai 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / PCI / hotplug: Avoid warning when _ADR not present

2014-01-09T20:25:13+00:00

commit f26ca1d699e8b54a50d9faf82327d3c2072aaedd upstream.

acpiphp_enumerate_slots() walks ACPI namenamespace under
a PCI host bridge with callback register_slot().
register_slot() evaluates _ADR for all the device objects
and emits a warning message for any error.  Some platforms
have _HID device objects (such as HPET and IPMI), which
trigger unnecessary warning messages.

This patch avoids emitting a warning message when a target
device object does not have _ADR.

Signed-off-by: Toshi Kani 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"

2013-10-30T14:28:52+00:00

Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for
spurious notifies) changed the enable_slot() to check return value of
pci_scan_slot() and if it is zero return early from the function. It
means that there were no new devices in this particular slot.

However, if a device appeared deeper in the hierarchy the code now
ignores it causing things like Thunderbolt chaining fail to recognize
new devices.

The problem with Alex Williamson's machine was solved with commit
a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious
device checks) and hence we should be able to restore the original
functionality that we always rescan on bus check notification.

On a device check notification we still check what acpiphp_rescan_slot()
returns and on zero bail out early.

Fixes: 2dc41281b1d1 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies)
Signed-off-by: Mika Westerberg 
Tested-by: Alex Williamson 
Signed-off-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Drop WARN_ON() from acpiphp_enumerate_slots()

2013-10-11T23:49:48+00:00

The WARN_ON() in acpiphp_enumerate_slots() triggers unnecessarily for
devices whose bridges are going to be handled by native PCIe hotplug
(pciehp) and the simplest way to prevent that from happening is to
drop the WARN_ON().

References: https://bugzilla.kernel.org/show_bug.cgi?id=62831
Reported-by: Steven Rostedt 
Signed-off-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Fix error code path in acpiphp_enumerate_slots()

2013-10-11T23:47:43+00:00

One of the error code paths in acpiphp_enumerate_slots() is missing
a pci_dev_put(bridge->pci_dev) call, so add it.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Bjorn Helgaas

Merge branch 'acpi-pci-hotplug'

2013-09-10T21:15:02+00:00

* acpi-pci-hotplug:
  ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks
  ACPI / hotplug / PCI: Use _OST to notify firmware about notify status
  ACPI / hotplug / PCI: Avoid doing too much for spurious notifies
  ACPI / hotplug / PCI: Don't trim devices before scanning the namespace

ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks

2013-09-09T19:41:07+00:00

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=60865
Reported-and-tested-by: Alex Williamson 
Signed-off-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Use _OST to notify firmware about notify status

2013-09-07T01:43:58+00:00

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: Alex Williamson 
Signed-off-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Avoid doing too much for spurious notifies

2013-09-07T01:43:35+00:00

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: Alex Williamson 
Signed-off-by: Rafael J. Wysocki

ACPI / hotplug / PCI: Don't trim devices before scanning the namespace

2013-09-05T21:39:20+00:00

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: Alex Williamson 
Signed-off-by: Rafael J. Wysocki