linux-toradex.git/drivers/pci/hotplug, branch v3.12.43

PCI: rphahp: Fix endianess issues

2014-08-26T12:12:22+00:00

commit 761ce53330a4f02c58768631027d1c1dd0d538f7 upstream.

Numerical values stored in the device tree are encoded in Big Endian and
should be byte swapped when running in Little Endian.

The RPA hotplug module should convert those values as well.

Note that in rpaphp_get_drc_props(), the comparison between indexes[i+1]
and *index is done using the BE values (whatever is the current endianess).
This doesn't matter since we are checking for equality here.  This way only
the returned value is byte swapped.

RPA also made RTAS calls which implies BE values to be used.  According to
the patch done in RTAS (http://patchwork.ozlabs.org/patch/336865), no
additional conversion is required in RPA.

Signed-off-by: Laurent Dufour 
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Jiri Slaby

PCI: shpchp: Check bridge's secondary (not primary) bus speed

2014-06-09T13:53:43+00:00

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus
speed.

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: Marcel Apfelbaum 
Signed-off-by: Bjorn Helgaas 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Jiri Slaby

ACPI / hotplug / PCI: Relax the checking of _STA return values

2014-02-22T21:32:29+00:00

commit 7282059489868e0ed1b0d79765730c6b233a8399 upstream.

The ACPI specification (ACPI 5.0A, Section 6.3.7) says:

 _STA may return bit 0 clear (not present) with bit 3 set (device is
 functional). This case is used to indicate a valid device for which
 no device driver should be loaded (for example, a bridge device.)
 Children of this device may be present and valid. OSPM should
 continue enumeration below a device whose _STA returns this bit
 combination.

Evidently, some BIOSes follow that and return 0x0A from _STA, which
causes problems to happen when they trigger bus check or device check
notifications for those devices too.  Namely, ACPIPHP thinks that they
are gone and may drop them, for example, if such a notification is
triggered during a resume from system suspend.

To fix that, modify ACPICA to regard devies as present and
functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED
and ACPI_STA_DEVICE_FUNCTIONING bits set for them.

Reported-and-tested-by: Peter Wu 
[rjw: Subject and changelog, minor code modifications]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

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