1. 15 10月, 2011 9 次提交
    • 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
    • J
      x86: constify PCI raw ops structures · 72da0b07
      Jan Beulich 提交于
      As with any other such change, the goal is to prevent inadvertent
      writes to these structures (assuming DEBUG_RODATA is enabled), and to
      separate data (possibly frequently) written to from such never getting
      modified.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      72da0b07
    • 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
  2. 14 10月, 2011 7 次提交
  3. 13 10月, 2011 4 次提交
  4. 12 10月, 2011 3 次提交
  5. 11 10月, 2011 7 次提交
  6. 10 10月, 2011 6 次提交
  7. 09 10月, 2011 1 次提交
  8. 08 10月, 2011 1 次提交
  9. 07 10月, 2011 2 次提交