Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
domain during system suspend) modified the ACPI PM domain's system
suspend callbacks to allow devices attached to it to be left in the
runtime-suspended state during system suspend so as to optimize
the suspend process.

This was based on the general mechanism introduced by commit
aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
devices unnecessarily).

Extend that approach to PCI devices by modifying the PCI bus type's
->prepare callback to return 1 for devices that are runtime-suspended
when it is being executed and that are in a suitable power state and
need not be resumed going forward.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PCI core code.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The variable "retval" in pci_add_dynid() is only used to store the return
value of driver_attach() and is then directly returned.  Remove the
variable and directly pass on driver_attach()'s return value.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add pci_fixup_suspend_late as a new pci_fixup_pass. The pass is called
from suspend_noirq and poweroff_noirq. Using the same pass for suspend
and hibernate is consistent with resume_early which is called by
resume_noirq and restore_noirq.

The new quirk pass is required for Thunderbolt support on Apple
hardware.
Signed-off-by: NAndreas Noever <andreas.noever@gmail.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Move EXPORT_SYMBOL so it immediately follows the function or variable.

No functional change.

[bhelgaas: squash similar changes, fix hotplug, probe, rom, search, too]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device.  This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.

First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled.  This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci.  Using driver_override we can do this
deterministically using:

  echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device.  Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.

To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:

  echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding.  For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO.  However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci.  With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Previously, pci_is_bridge() returned true only when a subordinate bus
existed.  Rename pci_is_bridge() to pci_has_subordinate() to better
indicate what we're checking.

No functional change.

[bhelgaas: changelog]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

"pdev" can never be NULL here, so remove the test.

Found by Coverity (CID 744313).
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

While using the sysfs new_id interface, the user can unintentionally feed
incorrect values if the driver static table has a matching entry.  This is
possible since only the device and vendor fields are mandatory and the rest
are optional.  As a result, store_new_id() will fill in default values that
are then passed on to the driver and can have unintended consequences.

As an example, consider the ixgbe driver and the 82599EB network card:

  echo "8086 10fb" > /sys/bus/pci/drivers/ixgbe/new_id

This will pass a pci_device_id with driver_data = 0 to ixgbe_probe(), which
uses that zero to index a table of card operations.  The zeroth entry of
the table does *not* correspond to the 82599 operations.

This change returns an error if the user attempts to add a dynid for a
vendor/device combination for which a static entry already exists.
However, if the user intentionally wants a different set of values, she
must provide all the 7 fields and that will be accepted.

[bhelgaas: drop KVM text since the problem isn't KVM-specific]
Signed-off-by: NBandan Das <bsd@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

Runtime-suspended devices are resumed during system suspend by
pci_pm_prepare() for two reasons: First, because they may need
to be reprogrammed in order to change their wakeup settings and,
second, because they may need to be operatonal for their children
to be successfully suspended.  That is a problem, though, if there
are many runtime-suspended devices that need to be resumed this
way during system suspend, because the .prepare() PM callbacks of
devices are executed sequentially and the times taken by them
accumulate, which may increase the total system suspend time quite
a bit.

For this reason, move the resume of runtime-suspended devices up
to the next phase of device suspend (during system suspend), except
for the ones that have power.ignore_children set.  The exception is
made, because the devices with power.ignore_children set may still
be necessary for their children to be successfully suspended (during
system suspend) and they won't be resumed automatically as a result
of the runtime resume of their children.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

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
b566a22c ("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=63861Reported-by: NChang Liu <cl91tp@gmail.com>
Signed-off-by: NKhalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKonstantin Khlebnikov <koct9i@gmail.com>
Cc: stable@vger.kernel.org	# v3.5+

If we are already on a CPU local to the device, call the driver .probe()
method directly without using work_on_cpu().

This is a workaround for a lockdep warning in the following scenario:

  pci_call_probe
    work_on_cpu(cpu, local_pci_probe, ...)
      driver .probe
        pci_enable_sriov
          ...
            pci_bus_add_device
              ...
                pci_call_probe
                  work_on_cpu(cpu, local_pci_probe, ...)

It would be better to fix PCI so we don't call VF driver .probe() methods
from inside a PF driver .probe() method, but that's a bigger project.

[bhelgaas: open bugzilla, rework comments & changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=65071
Link: http://lkml.kernel.org/r/CAE9FiQXYQEAZ=0sG6+2OdffBqfLS9MpoN1xviRR9aDbxPxcKxQ@mail.gmail.com
Link: http://lkml.kernel.org/r/20130624195942.40795.27292.stgit@ahduyck-cp1.jf.intel.comTested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Fix whitespace, capitalization, and spelling errors.  No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Ages ago, drivers could return values greater than zero from their probe
function and this would be regarded as success.

But after f3ec4f87 ("PCI: change device runtime PM settings for probe
and remove") and 967577b0 ("PCI/PM: Keep runtime PM enabled for unbound
PCI devices"), we set dev->driver to NULL if the driver's probe function
returns a value greater than zero.

__pci_device_probe() treats this as success, and drivers can still mostly
work even with dev->driver == NULL, but PCI power management doesn't work,
and we don't call the driver's remove function on rmmod.

To help catch these driver problems, issue a warning in this case.

[bhelgaas: changelog]
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

88d26136 ("PM: Prevent runtime suspend during system resume") removed the
pm_runtime_put_sync() from pci_pm_complete() to PM core code
device_complete().

Here the pci_pm_complete() is doing the same work which can be done in
device_complete(), so we can remove it directly.
Signed-off-by: NLiu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

pci_dev_pm_ops is local to pci-driver.c.  Make it static.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0.  If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.

Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.

To reduce overall code bloat, make the changes described above.
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

This is a fix for commit 7897e602 ("PCI: Disable Bus Master
unconditionally in pci_device_shutdown()").  Vivek reported that
with this commit, kexec failed because none of his SATA disks
came up.

A ->shutdown() callback might put the device in D3cold, which means config
space is no longer available.

[bhelgaas: changelog]
Link: https://lkml.org/lkml/2013/3/12/529Reported-and-Tested-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch clears pci_dev->state_saved at the beginning of suspending.
PCI config state may be saved long before that.  Some drivers call
pci_save_state() from the ->probe() callback to get snapshot of sane
configuration space to use in the ->slot_reset() callback.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> # add comment
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit b566a22c ("PCI: disable Bus Master on PCI device shutdown")
used pci_disable_device(), but that doesn't disable Bus Mastering
unconditionally; we allow nested enable/disable calls, and only the
last disable call actually does anything.

This uses pci_clear_master() to unconditionally clear the Bus Master
bit.

Matthew Garrett and Alan Cox said (see LKML link below) that clearing Bus
Master for all PCI devices may lead to unpredictable consequences: some
devices ignores this bit and continue DMA, some of them hang after that or
crash the whole system.  But we're already trying to clear Bus Master in
general because of b566a22c; this merely deals with the cases where
drivers haven't shut down the device correctly.

[bhelgaas: changelog]
Link: https://lkml.org/lkml/2012/6/6/278Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We want to add PCI devices to the device tree as early as possible but
delay attaching drivers.

device_add() adds a device to the device hierarchy and (via
device_attach()) attaches a matching driver and calls its .probe() method.
We want to separate adding the device to the hierarchy from attaching the
driver.

This patch does that by adding "match_driver" in struct pci_dev.  When
false, we return failure from pci_bus_match(), which makes device_attach()
believe there's no matching driver.

Later, we set "match_driver = true" and call device_attach() again, which
now attaches the driver and calls its .probe() method.

[bhelgaas: changelog, explicitly init dev->match_driver,
fold device_attach() call into pci_bus_add_device()]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

For unbound PCI devices, what we need is:

 - Always in D0 state, because some devices do not work again after
   being put into D3 by the PCI bus.

 - In SUSPENDED state if allowed, so that the parent devices can still
   be put into low power state.

To satisfy these requirements, the runtime PM for the unbound PCI
devices are disabled and set to SUSPENDED state.  One issue of this
solution is that the PCI devices will be put into SUSPENDED state even
if the SUSPENDED state is forbidden via the sysfs interface
(.../power/control) of the device.  This is not an issue for most
devices, because most PCI devices are not used at all if unbound.
But there are exceptions.  For example, unbound VGA card can be used
for display, but suspending its parents makes it stop working.

To fix the issue, we keep the runtime PM enabled when the PCI devices
are unbound.  But the runtime PM callbacks will do nothing if the PCI
devices are unbound.  This way, we can put the PCI devices into
SUSPENDED state without putting the PCI devices into D3 state.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org          # v3.6+

With the demise of CONFIG_HOTPLUG as an option, the pci_uevent
function located in hotplug.c will now always be used and doesn't need
special treatment in the Makefile.  Move pci_uevent into pci-driver.c
and remove hotplug.c
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove conditional code based on CONFIG_HOTPLUG being false.  It's
always on now in preparation of it going away as an option.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the driver takes care of state saving, don't touch any registers on it.

Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
unfortunately enter it on normal D3 transitions via the ACPI callback.

So when we use runtime PM to transition to D3, the card disappears off
the PCI bus, however we then try to access registers on it in the
runtime suspend finish, which really doesn't work.

This patch checks whether the pci state is saved and doesn't attempt to hit
any registers after that point if it is.

(Looks okay to Rafael)
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so resume device before shutdown.

Without this patch, a device may not be enumerated after a kexec
because the corresponding bridge is not in D0, so that
configuration space of the device is not accessible.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org		# v3.6+

This patch (as1591) moves the pm_runtime_get_noresume() and
pm_runtime_put_sync() calls from __device_suspend() and
device_resume() to device_prepare() and device_complete() in the PM
core.

The reason for doing this is to make sure that parent devices remain
at full power (i.e., don't go into runtime suspend) while their
children are being resumed from a system sleep.

The PCI core already contained equivalent code to serve the same
purpose.  The patch removes the duplicated code, since it is no longer
needed.  One of the comments from the PCI core gets moved into the PM
core, and a second comment is added to explain whe the _get_noresume
and _put_sync calls are present.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch removes hardcoded sysfs attributes manipulation and
converts them into generic pci_bus->drv_attrs. This saves several bytes.
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch fixes the following bug:

http://marc.info/?l=linux-pci&m=134329923124234&w=2

The root cause of the bug is as follow.

If a device is not bound with the corresponding driver, the device
runtime PM will be disabled and the device will be put into suspended
state.  So that, the bridge/PCIe port connected to it may be put into
suspended and low power state.  When do probing for the device later,
because the bridge/PCIe port connected to it is in low power state,
the IO access to device may fail.

To solve the issue, the bridge/PCIe port connected to the device is
put into active state before probing.
Reported-by: NBjorn Mork <bjorn@mork.no>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>

Commit dbf0e4c7 (PCI: EHCI: fix crash during suspend on ASUS
computers) added a workaround for an ASUS suspend issue related to
USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut
down the EHCI controller during system suspend if its PCI command
register doesn't contain 0 at that time.

It turns out that the same workaround is necessary in the analogous
hibernation code path, so add it.

References: https://bugzilla.kernel.org/show_bug.cgi?id=45811Reported-and-tested-by: NOleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org

Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend.  It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b6128 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.

It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working.  Consequently
commit c2fb8a3f (USB: add
NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.

Now we know the actual cause of the problem.  Thanks to AceLan Kao for
tracking it down.

According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows.  When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state.  If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so.  This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3.  The end result is
a system hang or memory corruption.

Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend.  This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.

In theory we could do this for every PCI device.  However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.

Finally the affected systems can suspend with USB wakeup working
properly.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDâniel Fraga <fragabr@gmail.com>
Tested-by: NJavier Marcet <jmarcet@gmail.com>
Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
Tested-by: NOleksij Rempel <bug-track@fisher-privat.net>
Tested-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit cc2893b6 (PCI: Ensure we re-enable devices on resume)
addressed the problem with USB not being powered after resume on
recent Lenovo machines, but it did that in a suboptimal way.
Namely, it should have changed the relevant code paths only,
which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed
to restore the device's power and standard configuration registers
after system resume from suspend or hibernation.  Instead, however,
it modified pci_set_power_state() which is executed in several
other situations too.  That resulted in some undesirable effects,
like attempting to change a device's power state in the same way
multiple times in a row (up to as many as 4 times in a row in the
snd_hda_intel driver).

Fix the bug addressed by commit cc2893b6 in an alternative way,
by forcibly powering up all devices in pci_pm_default_resume_early(),
which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq()
to restore the device's power and standard configuration registers,
and modifying pci_pm_runtime_resume() to avoid the forcible power-up
if not necessary.  Then, revert the changes made by commit cc2893b6
to make the confusion introduced by it go away.
Acked-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>