1. 20 4月, 2011 1 次提交
  2. 19 4月, 2011 2 次提交
  3. 18 4月, 2011 8 次提交
  4. 17 4月, 2011 2 次提交
  5. 15 4月, 2011 6 次提交
  6. 14 4月, 2011 21 次提交
    • A
      xHCI: Implement AMD PLL quirk · c41136b0
      Andiry Xu 提交于
      This patch disable the optional PM feature inside the Hudson3 platform under
      the following conditions:
      
      1. If an isochronous device is connected to xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      The PM feature needs to be disabled to eliminate PLL startup delays when the
      link comes out of low power state. The performance of DMA data transfer could
      be impacted if system delay were encountered and in addition to the PLL start
      up delays. Disabling the PM would leave room for unpredictable system delays
      in order to guarantee uninterrupted data transfer to isochronous audio or
      video stream devices that require time sensitive information. If data in an
      audio/video stream was interrupted then erratic audio or video performance
      may be encountered.
      
      AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
      quirk code to pci-quirks.c and export them, xHCI driver can call it directly
      without having the quirk implementation in itself.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c41136b0
    • S
      xhci: Tell USB core both roothubs lost power. · fedd383e
      Sarah Sharp 提交于
      On a resume, when the power is lost during hibernate, the USB core will
      call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
      3.0 roothub:
      
      [  164.748310] usb usb1: root hub lost power or was reset
      [  164.748353] usb usb2: root hub lost power or was reset
      [  164.748487] usb usb3: root hub lost power or was reset
      [  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
      ...
      [  164.870039] hub 4-0:1.0: hub_resume
      ...
      [  164.870054] hub 3-0:1.0: hub_reset_resume
      
      This causes issues later, because the USB core assumes the USB 3.0 hub
      attached to the USB 3.0 roothub is still active.  It attempts to queue a
      control URB for the external hub, which fails because all the device
      slot contexts were released when the USB 3.0 roothub lost power:
      
      [  164.980044] hub 4-1:1.0: hub_resume
      [  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
      [  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
      [  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
      [  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
      [  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
      [  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
      [  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
      [  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980094] hub 4-1:1.0: activate --> -22
      [  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980123] hub 4-1:1.0: can't resume port 4, status -22
      [  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
      [  164.980129] usb 4-1.4: can't resume, status -22
      [  164.980131] hub 4-1:1.0: logical disconnect on port 4
      
      This causes issues when a USB 3.0 hard drive is attached to the external
      USB 3.0 hub when the system is hibernated:
      
      [ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
      [ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
      [ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
      [ 6249.849671] end_request: I/O error, dev sdb, sector 10760
      
      Make sure to inform the USB core that *both* xHCI roothubs lost power.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      fedd383e
    • A
      usbcore: Bug fix: system can't suspend with USB3.0 device connected to USB3.0 hub · a8f08d86
      Andiry Xu 提交于
      This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
      external hub, so the system can suspend and resume.
      
      Note USB3.0 device may not work after system resume and this is a temporary
      workaround. The correct fix will be in future patches.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      a8f08d86
    • M
      USB: Fix unplug of device with active streams · b214f191
      Matthew Wilcox 提交于
      If I unplug a device while the UAS driver is loaded, I get an oops
      in usb_free_streams().  This is because usb_unbind_interface() calls
      usb_disable_interface() which calls usb_disable_endpoint() which sets
      ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
      which returns a NULL pointer and passes an array of NULL pointers to
      usb_free_streams().
      
      I think the correct fix for this is to check for the NULL pointer
      in usb_free_streams() rather than making the driver check for this
      situation.  My original patch for this checked for dev->state ==
      USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
      conditional, so not all drivers would want this check.
      
      Note from Sarah Sharp: This patch does avoid a potential dereference,
      but the real fix (which will be implemented later) is to set the
      .soft_unbind flag in the usb_driver structure for the UAS driver, and
      all drivers that allocate streams.  The driver should free any streams
      when it is unbound from the interface.  This avoids leaking stream rings
      in the xHCI driver when usb_disable_interface() is called.
      
      This should be queued for stable trees back to 2.6.35.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      b214f191
    • D
      USB: xhci - also free streams when resetting devices · 2dea75d9
      Dmitry Torokhov 提交于
      Currently, when resetting a device, xHCI driver disables all but one
      endpoints and frees their rings, but leaves alone any streams that
      might have been allocated. Later, when users try to free allocated
      streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
      ep->ring is NULL.
      
      Let's free not only rings but also stream data as well, so that
      calling free_streams() on a device that was reset will be safe.
      
      This should be queued for stable trees back to 2.6.35.
      Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      2dea75d9
    • S
      xhci: Fix NULL pointer deref in handle_port_status() · 386139d7
      Sarah Sharp 提交于
      When we get a port status change event, we need to figure out what type of
      port it came from: a USB 3.0 port, or a USB 2.0/1.1 port.  We can't know
      which usb_hcd to use until that point, so hcd will be NULL for part of the
      function.  Unfortunately, if any of the sanity checks fail, we'll jump to
      the cleanup label before hcd is set to a valid pointer, and then we'll
      attempt to tell the USB core to kick the hcd, which is NULL.
      
      Skip kicking the roothub if the sanity checks fail.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      386139d7
    • D
      USB: xhci - fix math in xhci_get_endpoint_interval() · dfa49c4a
      Dmitry Torokhov 提交于
      When parsing exponent-expressed intervals we subtract 1 from the
      value and then expect it to match with original + 1, which is
      highly unlikely, and we end with frequent spew:
      
      	usb 3-4: ep 0x83 - rounding interval to 512 microframes
      
      Also, parsing interval for fullspeed isochronous endpoints was
      incorrect - according to USB spec they use exponent-based
      intervals (but xHCI spec claims frame-based intervals). I trust
      USB spec more, especially since USB core agrees with it.
      
      This should be queued for stable kernels back to 2.6.31.
      Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      dfa49c4a
    • D
      USB: xhci: simplify logic of skipping missed isoc TDs · 926008c9
      Dmitry Torokhov 提交于
      The logic of the handling Missed Service Error Events was pretty
      confusing as we were checking the same condition several times.
      In addition, it caused compiler warning since the compiler could
      not figure out that event_trb is actually unused in case we are
      skipping current TD.
      
      Fix that by rearranging "skip" condition checks, and factor out
      skip_isoc_td() so that it is called explicitly.
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      926008c9
    • D
      USB: xhci - remove excessive 'inline' markings · 575688e1
      Dmitry Torokhov 提交于
      Remove 'inline' markings from file-local functions and let compiler
      do its job and inline what makes sense for given architecture.
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      575688e1
    • D
      USB: xhci: unsigned char never equals -1 · 22e04870
      Dan Carpenter 提交于
      There were some places that compared port_speed == -1 where port_speed
      is a u8.  This doesn't work unless we cast the -1 to u8.  Some places
      did it correctly.
      
      Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
      which does the cast and is more descriptive as well.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      22e04870
    • D
      USB: xhci - fix unsafe macro definitions · 5a6c2f3f
      Dmitry Torokhov 提交于
      Macro arguments used in expressions need to be enclosed in parenthesis
      to avoid unpleasant surprises.
      
      This should be queued for kernels back to 2.6.31
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      5a6c2f3f
    • D
      USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices · 2868a2b1
      Dmitry Torokhov 提交于
      Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
      for decoding bInterval values as HighSpeed ones so adjust the code
      accordingly.
      
      Also bandwidth reservation for SuperSpeed matches highspeed, not
      low/full speed.
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2868a2b1
    • R
      USB: isp1760-hcd: move imask clear after pending work is done · 58085446
      Richard Retanubun 提交于
      This patch moves the HcInterrupt register write to clear the
      pending interrupt to after the isr work is done, doing this removes
      glitches in the irq line.
      Signed-off-by: NRichard Retanubun <richardretanubun@ruggedcom.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      58085446
    • V
      USB: fsl_qe_udc: send ZLP when zero flag and length % maxpacket == 0 · d834508e
      Valentin Longchamp 提交于
      The driver did not take the zero flag in the USB request. If the
      request length is the same as the endpoint's maxpacket, an additional
      ZLP with no data has to be transmitted.
      
      The method used here is inspired to what is done in fsl_udc_core.c
      (and pxa27x_udc.c and at91_udc.c) where this is supported.
      
      There already was a discussion about this topic with people from
      Keymile, and I propose here a better implementation:
      
      http://thread.gmane.org/gmane.linux.usb.general/38951Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
      Acked-by: NLi Yang <leoli@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d834508e
    • S
      usb: qcserial add missing errorpath kfrees · cb62d65f
      Steven Hardy 提交于
      There are two -ENODEV error paths in qcprobe where the allocated private
      data is not freed, this patch adds the two missing kfrees to avoid
      leaking memory on the error path
      Signed-off-by: NSteven Hardy <shardy@redhat.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cb62d65f
    • S
      usb: qcserial avoid pointing to freed memory · 99ab3f9e
      Steven Hardy 提交于
      Rework the qcprobe logic such that serial->private is not set when
      qcprobe exits with -ENODEV, otherwise serial->private will point to freed
      memory on -ENODEV
      Signed-off-by: NSteven Hardy <shardy@redhat.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      99ab3f9e
    • S
      usb: Fix qcserial memory leak on rmmod · 10c9ab15
      Steven Hardy 提交于
      qcprobe function allocates serial->private but this is never freed, this
      patch adds a new function qc_release() which frees serial->private, after
      calling usb_wwan_release
      Signed-off-by: NSteven Hardy <shardy@redhat.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      10c9ab15
    • P
      USB: ftdi_sio: add ids for Hameg HO720 and HO730 · c53c2fab
      Paul Friedrich 提交于
      usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
      and HO730
      
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c53c2fab
    • M
      USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem. · 80f9df3e
      Marius B. Kotsbak 提交于
      Bind only modem AT command endpoint to option.
      Signed-off-by: NMarius B. Kotsbak <marius@kotsbak.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      80f9df3e
    • D
      usb: pch_udc: unlock on allocation failure · 48570711
      Dan Carpenter 提交于
      There was an unlock missing on the error path.
      
      Also I did a small cleanup by changing ep->dev->lock for just dev->lock.
      They're the same lock, but dev->lock is shorter and that's how it is
      used for the spin_unlock_irqrestore() call.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      48570711
    • J
      USB host: Fix lockdep warning in AMD PLL quirk · 9ab7927b
      Joerg Roedel 提交于
      Booting latest kernel on my test machine produces a lockdep
      warning from the usb_amd_find_chipset_info() function:
      
       WARNING: at /data/lemmy/linux.trees.git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x95/0xc2()
       Hardware name: Snook
       Modules linked in:
       Pid: 959, comm: work_for_cpu Not tainted 2.6.39-rc2+ #22
       Call Trace:
        [<ffffffff8103c0d4>] warn_slowpath_common+0x80/0x98
        [<ffffffff812387e6>] ? T.492+0x24/0x26
        [<ffffffff8103c101>] warn_slowpath_null+0x15/0x17
        [<ffffffff81068667>] lockdep_trace_alloc+0x95/0xc2
        [<ffffffff810ed9ac>] slab_pre_alloc_hook+0x18/0x3b
        [<ffffffff810ef227>] kmem_cache_alloc_trace+0x25/0xba
        [<ffffffff812387e6>] T.492+0x24/0x26
        [<ffffffff81238816>] pci_get_subsys+0x2e/0x73
        [<ffffffff8123886c>] pci_get_device+0x11/0x13
        [<ffffffff814082a9>] usb_amd_find_chipset_info+0x3f/0x18a
      ...
      
      It turns out that this function calls pci_get_device under a spin_lock
      with irqs disabled, but the pci_get_device function is only allowed in
      preemptible context.
      
      This patch fixes the warning by making all data-structure
      modifications on temporal storage and commiting this back
      into the visible structure at the end. While at it, this
      patch also moves the pci_dev_put calls out of the spinlocks
      because this function might sleep too.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9ab7927b
新手
引导
客服 返回
顶部