Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 6月, 2012 17 次提交
  3. 21 5月, 2012 1 次提交
  5. 18 5月, 2012 1 次提交
    • R
      ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold · 5c7dd710
      由 Rafael J. Wysocki 提交于 
      Commit 1cc0c998 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.

First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.

Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power().  Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.

Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3.  However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare.  This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now.  In particular, some unused graphics adapters are not turned
off as a result.

To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.

This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.

References: https://bugzilla.kernel.org/show_bug.cgi?id=43228Reported-by: Nrocko <rockorequin@hotmail.com>
Reported-by: NCristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: NPeter <lekensteyn@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c7dd710
  7. 07 5月, 2012 1 次提交
  9. 05 5月, 2012 2 次提交
    • L
      ACPI: Fix D3hot v D3cold confusion · 1cc0c998
      由 Lin Ming 提交于 
      Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
in some places, but D3cold in other places.

After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
and all references to D3hot use ACPI_STATE_D3_HOT.

ACPI's _PR3 method is used to enter both D3hot and D3cold states.
What distinguishes D3hot from D3cold is the presence _PR3
(Power Resources for D3hot)  If these resources are all ON,
then the state is D3hot.  If _PR3 is not present,
or all _PR0 resources for the devices are OFF,
then the state is D3cold.

This patch applies after Linux-3.4-rc1.
A future syntax cleanup may remove ACPI_STATE_D3
to emphasize that it always means ACPI_STATE_D3_COLD.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NAaron Lu <aaron.lu@amd.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      1cc0c998
    • K
      PCI: disable Bus Master on PCI device shutdown · b566a22c
      由 Khalid Aziz 提交于 
      Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI
devices do not continue to DMA data after shutdown.  This can cause memory
corruption in case of a kexec where the current kernel shuts down and
transfers control to a new kernel while a PCI device continues to DMA to
memory that does not belong to it any more in the new kernel.

I have tested this code on two laptops, two workstations and a 16-socket
server.  kexec worked correctly on all of them.
Signed-off-by: NKhalid Aziz <khalid.aziz@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      b566a22c
  11. 03 5月, 2012 1 次提交
  13. 01 5月, 2012 7 次提交
  15. 27 4月, 2012 1 次提交
  17. 24 4月, 2012 1 次提交
  19. 17 4月, 2012 1 次提交
    • R
      PCI: Retry BARs restoration for Type 0 headers only · a6cb9ee7
      由 Rafael J. Wysocki 提交于 
      Some shortcomings introduced into pci_restore_state() by commit
26f41062 ("PCI: check for pci bar restore completion and retry")
have been fixed by recent commit ebfc5b80 ("PCI: Fix regression in
pci_restore_state(), v3"), but that commit treats all PCI devices as
those with Type 0 configuration headers.

That is not entirely correct, because Type 1 and Type 2 headers have
different layouts.  In particular, the area occupied by BARs in Type 0
config headers contains the secondary status register in Type 1 ones and
it doesn't make sense to retry the restoration of that register even if
the value read back from it after a write is not the same as the written
one (it very well may be different).

For this reason, make pci_restore_state() only retry the restoration
of BARs for Type 0 config headers.  This effectively makes it behave
as before commit 26f41062 for all header types except for Type 0.
Tested-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6cb9ee7
  21. 16 4月, 2012 1 次提交
    • R
      PCI: Fix regression in pci_restore_state(), v3 · ebfc5b80
      由 Rafael J. Wysocki 提交于 
      Commit 26f41062 ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.

First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one).  Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt.  Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.

All of this actually caused resume failures for some devices on Mikko's
system.

To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value.  Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ebfc5b80
  23. 07 4月, 2012 1 次提交
  25. 01 4月, 2012 1 次提交
    • M
      ASPM: Fix pcie devices with non-pcie children · c9651e70
      由 Matthew Garrett 提交于 
      Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
Some other systems using the pata_jmicron driver fail to boot because no
disks are detected.  Passing pcie_aspm=force on the kernel command line
works around it.

The cause: commit 4949be16 ("PCI: ignore pre-1.1 ASPM quirking when
ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
always return 0 if aspm is disabled, in order to avoid cases where we
changed ASPM state on pre-PCIe 1.1 devices.

This skipped the secondary function of pcie_aspm_sanity_check which was
to avoid us enabling ASPM on devices that had non-PCIe children, causing
trouble later on.  Move the aspm_disabled check so we continue to honour
that scenario.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
          http://bugs.debian.org/665420

Reported-by: Romain Francoise <romain@orebokech.com> # kernel panic
Reported-by: Chris Holland <bandidoirlandes@gmail.com> # disk detection trouble
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Tested-by: Hatem Masmoudi <hatem.masmoudi@gmail.com> # Dell Latitude E5520
Tested-by: janek <jan0x6c@gmail.com> # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c9651e70
  27. 30 3月, 2012 1 次提交
  29. 21 3月, 2012 1 次提交
  31. 08 3月, 2012 1 次提交
  33. 05 3月, 2012 1 次提交