Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 10月, 2011 10 次提交
    • J
      PCI: Add implementation for PRI capability · c320b976
      由 Joerg Roedel 提交于 
      Implement the necessary functions to handle PRI capabilities
on PCIe devices. With PRI devices behind an IOMMU can signal
page fault conditions to software and recover from such
faults.
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c320b976
    • J
      PCI: Export ATS functions to modules · d4c0636c
      由 Joerg Roedel 提交于 
      This patch makes the ATS functions usable for modules.
They will be used by a module implementing some advanced
AMD IOMMU features.
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d4c0636c
    • J
      PCI: Move ATS implementation into own file · db3c33c6
      由 Joerg Roedel 提交于 
      ATS does not depend on IOV support, so move the code into
its own file. This file will also include support for the
PRI and PASID capabilities later.
Also give ATS its own Kconfig variable to allow selecting it
without IOV support.
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      db3c33c6
    • R
      PCI / PM: Remove unnecessary error variable from acpi_dev_run_wake() · 78d090b0
      由 Rafael J. Wysocki 提交于 
      The result returned by acpi_dev_run_wake() is always either -EINVAL
or -ENODEV, while obviously it should return 0 on success.  The
problem is that the leftover error variable, that's not really used
in the function, is initialized with -ENODEV and then returned
without modification.

To fix this issue remove the error variable from acpi_dev_run_wake()
and make the function return 0 on success as appropriate.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      78d090b0
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      由 Prarit Bhargava 提交于 
      I originally submitted a patch to workaround this by pushing all Ejection
Requests and Device Checks onto the kacpi_hotplug queue.

http://marc.info/?l=linux-acpi&m=131678270930105&w=2

The patch is still insufficient in that Bus Checks also need to be added.

Rather than add all events, including non-PCI-hotplug events, to the
hotplug queue, mjg suggested that a better approach would be to modify
the acpiphp driver so only acpiphp events would be added to the
kacpi_hotplug queue.

It's a longer patch, but at least we maintain the benefit of having separate
queues in ACPI.  This, of course, is still only a workaround the problem.
As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
the right thing but at this point it is a better to have this code working.

The acpi core places all events on the kacpi_notify queue.  When the acpiphp
driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
following call sequence occurs:

cleanup_p2p_bridge()
	    -> cleanup_bridge()
		    -> acpi_remove_notify_handler()
			    -> acpi_os_wait_events_complete()
				    -> flush_workqueue(kacpi_notify_wq)

which is the queue we are currently executing on and the process will hang.

Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
push the rest of the work onto the kacpi_hotplug queue and then avoid the
deadlock.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Cc: mjg@redhat.com
Cc: bhelgaas@google.com
Cc: linux-acpi@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
    • R
      PCI / PM: Extend PME polling to all PCI devices · 379021d5
      由 Rafael J. Wysocki 提交于 
      The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices.  There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#.  There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are).  There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below.  There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup.  Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods.  In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever.  Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.

This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel.  Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones.  Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      379021d5
    • J
      PCI quirk: mmc: Always check for lower base frequency quirk for Ricoh 1180:e823 · 3e309cdf
      由 Josh Boyer 提交于 
      Commit 15bed0f2 added a quirk for the e823 Ricoh card reader to lower the
base frequency.  However, the quirk first checks to see if the proprietary
MMC controller is disabled, and returns if so.  On some devices, such as the
Lenovo X220, the MMC controller is already disabled by firmware it seems,
but the frequency change is still needed so sdhci-pci can talk to the cards.
Since the MMC controller is disabled, the frequency fixup was never being run
on these machines.

This moves the e823 check above the MMC controller check so that it always
gets run.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      3e309cdf
    • B
      PCI: Make pci_setup_bridge() non-static for use by arch code · e2444273
      由 Benjamin Herrenschmidt 提交于 
      The "powernv" platform of the powerpc architecture needs to assign PCI
resources using a specific algorithm to fit some HW constraints of
the IBM "IODA" architecture (related to the ability to create error
handling domains that encompass specific segments of MMIO space).

For doing so, it wants to call pci_setup_bridge() from architecture
specific resource management in order to configure bridges after all
resources have been assigned. So make it non-static.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e2444273
    • B
      PCI: Add quirk for known incorrect MPSS · a94d072b
      由 Ben Hutchings 提交于 
      Using legacy interrupts and TLPs > 256 bytes on the SFC4000 (all
revisions) may cause interrupt messages to be replayed.  In some
systems this results in a non-recoverable MCE.  Early boards using the
SFC4000 set the maximum payload size supported (MPSS) to 1024 bytes
and we should override that.

There are probably other devices with similar issues, so give this
quirk a generic name.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a94d072b
    • B
      PCI: Add Solarflare vendor ID and SFC4000 device IDs · 937383a5
      由 Ben Hutchings 提交于 
      These will be shared between the sfc driver and a PCI quirk.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      937383a5
  3. 14 10月, 2011 2 次提交
  5. 13 10月, 2011 1 次提交
  7. 11 10月, 2011 3 次提交
  9. 06 10月, 2011 1 次提交
  11. 05 10月, 2011 11 次提交
  13. 04 10月, 2011 12 次提交