1. 23 4月, 2013 6 次提交
    • A
      Merge remote-tracking branch 'kraxel/usb.81' into staging · 2cfd5cc0
      Anthony Liguori 提交于
      # By Gerd Hoffmann (3) and Hans de Goede (1)
      # Via Gerd Hoffmann
      * kraxel/usb.81:
        usb-host: raise libusbx minimum version to 1.0.13
        usb: better speed mismatch error reporting
        ehci_free_packet: Discard finished packets when the queue is halted
        xhci: remove XHCIRing->base (unused)
      
      Message-id: 1366705929-11251-1-git-send-email-kraxel@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      2cfd5cc0
    • G
      usb-host: raise libusbx minimum version to 1.0.13 · 3f5cc97e
      Gerd Hoffmann 提交于
      Allows to remove one FIXME.  Makes LIBUSB_LOG_LEVEL_WARNING build errors
      go away.  And starting with that version libusb has a LIBUSBX_API_VERSION
      define which allows to easily #ifdef version dependencies should that
      need arrive in the future.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      3f5cc97e
    • G
      usb: better speed mismatch error reporting · 3b7e759a
      Gerd Hoffmann 提交于
      Report the supported speeds for device and port in the error message.
      Also add the speeds to the tracepoint.  And while being at it drop
      the redundant error message in usb_desc_attach, usb_device_attach will
      report the error anyway.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      3b7e759a
    • H
      ehci_free_packet: Discard finished packets when the queue is halted · e449f26b
      Hans de Goede 提交于
      With pipelining it is possible to encounter a finished packet when cleaning
      the queue due to a halt. This happens when a non stall error happens while
      talking to a real device. In this case the queue on the usb-host side will
      continue processing packets, and we can have completed packets waiting in
      the queue after an error condition packet causing a halt.
      
      There are 2 reasons to discard the completed packets at this point, rather
      then trying to writing them back to the guest:
      
      1) The guest expect to be able to cancel and/or change packets after the
      packet with the error without doing an unlink, so writing them back may
      confuse the guest.
      
      2) Since the queue does not advance when halted, the writing back of these
      packets will fail anyways since p->qtdaddr != q->qtdaddr, so the
      ehci_verify_qtd call in ehci_writeback_async_complete_packet will fail.
      
      Note that 2) means that then only functional change this patch introduces
      is the printing of a warning when this scenario happens.
      
      Note that discarding these packets means that the guest driver and the device
      will get out of sync! This is unfortunate, but should not be a problem since
      with a non stall error (iow an io-error) the 2 are out of sync already anyways.
      Still this patch adds a warning to signal this happening.
      
      Note that sofar this has only been seen with a DVB-T receiver, which gives
      of a MPEG-2 stream, which allows for recovering from lost packets, see:
      https://bugzilla.redhat.com/show_bug.cgi?id=890320Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      e449f26b
    • G
      xhci: remove XHCIRing->base (unused) · 7d04c2b7
      Gerd Hoffmann 提交于
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      7d04c2b7
    • K
      block: Fix build with tracing enabled · 45673671
      Kevin Wolf 提交于
      filename was still uninitialised when it's used as a parameter to a
      tracing function, so let's move the initialisation. Also, commit c2ad1b0c
      forgot to add a NULL check, which this patch adds while we're at it.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Tested-by: NAndreas Färber <afaerber@suse.de>
      Message-id: 1366645720-11384-1-git-send-email-kwolf@redhat.com
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      45673671
  2. 22 4月, 2013 33 次提交
  3. 21 4月, 2013 1 次提交