linux-toradex.git/drivers/pci, branch v3.12.14

PCI: Enable INTx if BIOS left them disabled

2014-03-05T16:13:47+00:00

commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream.

Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts.  Clear Interrupt Disable so we get those interrupts.

Based on the report mentioned below, if the user selects the "EHCI only"
option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
with the PCI_COMMAND_INTX_DISABLE bit set.

Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601
Reported-by: Chris Cheng 
Reported-and-tested-by: Jamie Chen 
Signed-off-by: Bjorn Helgaas 
CC: Sarah Sharp 
Signed-off-by: Jiri Slaby

PCI: mvebu: Use Device ID and revision from underlying endpoint

2014-03-05T16:13:47+00:00

commit 322a8e91844f4ae2093e0d3d8a318d0ef2596756 upstream.

Marvell SoCs place the SoC number into the PCIe endpoint device ID.  The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.

The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.

When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality.  Debian would
like to use this in order to aid installing the correct DTB file.

Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn 
Signed-off-by: Bjorn Helgaas 
Acked-by: Thomas Petazzoni 
Acked-by: Jason Cooper 
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

xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

2014-02-13T21:50:10+00:00

commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.

The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:

  xen_platform_pci=0
  (in the guest config file)

or
  xen_emul_unplug=never
  (on the Linux command line)

except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:

input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[]  [] get_free_entries+0x2e0/0x300
Call Trace:
 [] ? evdev_connect+0x1e3/0x240
 [] gnttab_grant_foreign_access+0x2e/0x70
 [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
 [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
 [] xenbus_dev_probe+0x77/0x130
 [] xenbus_frontend_dev_probe+0x47/0x50
 [] driver_probe_device+0x89/0x230
 [] __driver_attach+0x9b/0xa0
 [] ? driver_probe_device+0x230/0x230
 [] ? driver_probe_device+0x230/0x230
 [] bus_for_each_dev+0x8c/0xb0
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x1a0/0x220
 [] driver_register+0x5f/0xf0
 [] xenbus_register_driver_common+0x15/0x20
 [] xenbus_register_frontend+0x23/0x40
 [] ? 0xffffffffa0014fff
 [] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
 [] do_one_initcall+0x49/0x170

.. snip..

which is hardly nice. This patch fixes this by having each
PV driver check for:
 - if running in PV, then it is fine to execute (as that is their
   native environment).
 - if running in HVM, check if user wanted 'xen_emul_unplug=never',
   in which case bail out and don't load any PV drivers.
 - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
   does not exist, then bail out and not load PV drivers.
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
   then bail out for all PV devices _except_ the block one.
   Ditto for the network one ('nics').
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
   then load block PV driver, and also setup the legacy IDE paths.
   In (v3) make it actually load PV drivers.

Reported-by: Sander Eikelenboom 
Reported-and-Tested-by: Fabio Fantoni 
Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini 
Acked-by: Bjorn Helgaas  [for PCI parts]
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

PCI: Disable Bus Master only on kexec reboot

2013-12-20T15:48:54+00:00

commit 4fc9bbf98fd66f879e628d8537ba7c240be2b58e upstream.

Add a flag to tell the PCI subsystem that kernel is shutting down in
preparation to kexec a kernel.  Add code in PCI subsystem to use this flag
to clear Bus Master bit on PCI devices only in case of kexec reboot.

This fixes a power-off problem on Acer Aspire V5-573G and likely other
machines and avoids any other issues caused by clearing Bus Master bit on
PCI devices in normal shutdown path.  The problem was introduced by
b566a22c2332 ("PCI: disable Bus Master on PCI device shutdown").

This patch is based on discussion at
http://marc.info/?l=linux-pci&m=138425645204355&w=2

Link: https://bugzilla.kernel.org/show_bug.cgi?id=63861
Reported-by: Chang Liu 
Signed-off-by: Khalid Aziz 
Signed-off-by: Bjorn Helgaas 
Acked-by: Konstantin Khlebnikov 
Signed-off-by: Greg Kroah-Hartman

PCI: Remove duplicate pci_disable_device() from pcie_portdrv_remove()

2013-12-04T19:05:39+00:00

commit e7cc5cf74544d97d7b69e2701595037474db1f96 upstream.

The pcie_portdrv .probe() method calls pci_enable_device() once, in
pcie_port_device_register(), but the .remove() method calls
pci_disable_device() twice, in pcie_port_device_remove() and in
pcie_portdrv_remove().

That causes a "disabling already-disabled device" warning when removing a
PCIe port device.  This happens all the time when removing Thunderbolt
devices, but is also easy to reproduce with, e.g.,
"echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind"

This patch removes the disable from pcie_portdrv_remove().

[bhelgaas: changelog, tag for stable]
Reported-by: David Bulkow 
Reported-by: Mika Westerberg 
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
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