1. 11 8月, 2012 6 次提交
  2. 10 8月, 2012 1 次提交
    • S
      xhci: Switch PPT ports to EHCI on shutdown. · e95829f4
      Sarah Sharp 提交于
      The Intel desktop boards DH77EB and DH77DF have a hardware issue that
      can be worked around by BIOS.  If the USB ports are switched to xHCI on
      shutdown, the xHCI host will send a spurious interrupt, which will wake
      the system.  Some BIOS will work around this, but not all.
      
      The bug can be avoided if the USB ports are switched back to EHCI on
      shutdown.  The Intel Windows driver switches the ports back to EHCI, so
      change the Linux xHCI driver to do the same.
      
      Unfortunately, we can't tell the two effected boards apart from other
      working motherboards, because the vendors will change the DMI strings
      for the DH77EB and DH77DF boards to their own custom names.  One example
      is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
      Panther Point xHCI host PCI vendor and device ID, and switch the ports
      over for all PPT xHCI hosts.
      
      The only impact this will have on non-effected boards is to add a couple
      hundred milliseconds delay on boot when the BIOS has to switch the ports
      over from EHCI to xHCI.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 69e848c2 "Intel xhci: Support
      EHCI/xHCI port switching."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDenis Turischev <denis@compulab.co.il>
      Tested-by: NDenis Turischev <denis@compulab.co.il>
      Cc: stable@vger.kernel.org
      e95829f4
  3. 09 8月, 2012 1 次提交
    • S
      xhci: Fix bug after deq ptr set to link TRB. · 50d0206f
      Sarah Sharp 提交于
      This patch fixes a particularly nasty bug that was revealed by the ring
      expansion patches.  The bug has been present since the very beginning of
      the xHCI driver history, and could have caused general protection faults
      from bad memory accesses.
      
      The first thing to note is that a Set TR Dequeue Pointer command can
      move the dequeue pointer to a link TRB, if the canceled or stalled
      transfer TD ended just before a link TRB.  The function to increment the
      dequeue pointer, inc_deq, was written before cancellation and stall
      support was added.  It assumed that the dequeue pointer could never
      point to a link TRB.  It would unconditionally increment the dequeue
      pointer at the start of the function, check if the pointer was now on a
      link TRB, and move it to the top of the next segment if so.
      
      This means that if a Set TR Dequeue Point command moved the dequeue
      pointer to a link TRB, a subsequent call to inc_deq() would move the
      pointer off the segment and into la-la-land.  It would then read from
      that memory to determine if it was a link TRB.  Other functions would
      often call inc_deq() until the dequeue pointer matched some other
      pointer, which means this function would quite happily read all of
      system memory before wrapping around to the right pointer value.
      
      Often, there would be another endpoint segment from a different ring
      allocated from the same DMA pool, which would be contiguous to the
      segment inc_deq just stepped off of.  inc_deq would eventually find the
      link TRB in that segment, and blindly move the dequeue pointer back to
      the top of the correct ring segment.
      
      The only reason the original code worked at all is because there was
      only one ring segment.  With the ring expansion patches, the dequeue
      pointer would eventually wrap into place, but the dequeue segment would
      be out-of-sync.  On the second TD after the dequeue pointer was moved to
      a link TRB, trb_in_td() would fail (because the dequeue pointer and
      dequeue segment were out-of-sync), and this message would appear:
      
      ERROR Transfer event TRB DMA ptr not part of current TD
      
      This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
      port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
      I/O to offline device"),
      
      	https://bugzilla.kernel.org/show_bug.cgi?id=43333
      
      and possibly other general protection fault bugs as well.
      
      This patch should be backported to kernels as old as 2.6.31.  A separate
      patch will be created for kernels older than 3.4, since inc_deq was
      modified in 3.4 and this patch will not apply.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NJames Ettle <theholyettlz@googlemail.com>
      Tested-by: NMatthew Hall <mhall@mhcomputing.net>
      Cc: stable@vger.kernel.org
      50d0206f
  4. 08 8月, 2012 3 次提交
  5. 03 8月, 2012 3 次提交
  6. 02 8月, 2012 4 次提交
  7. 01 8月, 2012 21 次提交
  8. 31 7月, 2012 1 次提交
    • A
      vfio: Add PCI device driver · 89e1f7d4
      Alex Williamson 提交于
      Add PCI device support for VFIO.  PCI devices expose regions
      for accessing config space, I/O port space, and MMIO areas
      of the device.  PCI config access is virtualized in the kernel,
      allowing us to ensure the integrity of the system, by preventing
      various accesses while reducing duplicate support across various
      userspace drivers.  I/O port supports read/write access while
      MMIO also supports mmap of sufficiently sized regions.  Support
      for INTx, MSI, and MSI-X interrupts are provided using eventfds to
      userspace.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      89e1f7d4