1. 30 3月, 2013 17 次提交
  2. 29 3月, 2013 13 次提交
  3. 28 3月, 2013 1 次提交
  4. 27 3月, 2013 3 次提交
    • R
      usb: Fix compile error by selecting USB_OTG_UTILS · c8fa48d3
      Roland Stigge 提交于
      The current lpc32xx_defconfig breaks like this, caused by recent phy
      restructuring:
      
        LD      init/built-in.o
      drivers/built-in.o: In function `usb_hcd_nxp_probe':
      drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
      drivers/built-in.o: In function `lpc32xx_udc_probe':
      drivers/usb/gadget/lpc32xx_udc.c:3104: undefined reference to
      `isp1301_get_client' distcc[27867] ERROR: compile (null) on localhost failed
      make: *** [vmlinux] Error 1
      
      Caused by 1c208881 (usb: Makefile: fix
      drivers/usb/phy/ Makefile entry)
      
      This patch fixes this by selecting USB_OTG_UTILS in Kconfig which
      causes the phy driver to be built again.
      Signed-off-by: NRoland Stigge <stigge@antcom.de>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8fa48d3
    • G
      Merge tag 'for-usb-linus-2013-03-26' of... · d78658d4
      Greg Kroah-Hartman 提交于
      Merge tag 'for-usb-linus-2013-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
      
      Misc xHCI fixes for 3.9
      
      Hi Greg,
      
      Here's a couple of fixes for the xHCI driver.  Three patches are nothing
      major: build warning fix, macro field width fix, and removing some
      unnecessary log spam.
      
      The only interesting thing here is Tianyu's two patches to fix the USB
      port connection type discovery, for the USB port power off mechanism.
      This adds new USB host API, but as discussed, it's necessary to avoid
      powering off the wrong USB port.  It's not marked for backport to stable
      kernels, since the sysfs mechanism to manually power off a port didn't
      go in until 3.9.
      
      I've smoke tested these, including system suspend, USB device suspend,
      and rocking out in my cube with a pair of USB headphones.  They look
      fine to me.
      
      Hibernate is currently broken on my system, due to some nouveau MMIO
      read faults.  I'll report that separately.
      
      Sarah Sharp
      d78658d4
    • M
      USB: serial: fix hang when opening port · eba0e3c3
      Ming Lei 提交于
      Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces
      one bug which can cause kernel hang when opening port.
      
      This patch initialized the 'port->delta_msr_wait' waitqueue head
      to fix the bug which is introduced in 3.9-rc4.
      
      [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Acked-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eba0e3c3
  5. 26 3月, 2013 6 次提交
    • S
      USB: EHCI: fix bug in iTD/siTD DMA pool allocation · 85ecd032
      Soeren Moch 提交于
      [Description written by Alan Stern]
      
      Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
      management of iTD and siTD structures.  Some background: ehci-hcd
      gives each isochronous endpoint its own set of active and free itd's
      (or sitd's for full-speed devices).  When a new itd is needed, it is
      taken from the head of the free list, if possible.  However, itd's
      must not be used twice in a single frame because the hardware
      continues to access the data structure for the entire duration of a
      frame.  Therefore if the itd at the head of the free list has its
      "frame" member equal to the current value of ehci->now_frame, it
      cannot be reused and instead a new itd is allocated from the DMA pool.
      The entries on the free list are not released back to the pool until
      the endpoint is no longer in use.
      
      The bug arises from the fact that sometimes an itd can be moved back
      onto the free list before itd->frame has been set properly.  In
      Soeren's case, this happened because ehci-hcd can allocate one more
      itd than it actually needs for an URB; the extra itd may or may not be
      required depending on how the transfer aligns with a frame boundary.
      For example, an URB with 8 isochronous packets will cause two itd's to
      be allocated.  If the URB is scheduled to start in microframe 3 of
      frame N then it will require both itds: one for microframes 3 - 7 of
      frame N and one for microframes 0 - 2 of frame N+1.  But if the URB
      had been scheduled to start in microframe 0 then it would require only
      the first itd, which could cover microframes 0 - 7 of frame N.  The
      second itd would be returned to the end of the free list.
      
      The itd allocation routine initializes the entire structure to 0, so
      the extra itd ends up on the free list with itd->frame set to 0
      instead of a meaningful value.  After a while the itd reaches the head
      of the list, and occasionally this happens when ehci->now_frame is
      equal to 0.  Then, even though it would be okay to reuse this itd, the
      driver thinks it must get another itd from the DMA pool.
      
      For as long as the isochronous endpoint remains in use, this flaw in
      the mechanism causes more and more itd's to be taken slowly from the
      DMA pool.  Since none are released back, the pool eventually becomes
      exhausted.
      
      This reuslts in memory allocation failures, which typically show up
      during a long-running audio stream.  Video might suffer the same
      effect.
      
      The fix is very simple.  To prevent allocations from the pool when
      they aren't needed, make sure that itd's sent back to the free list
      prematurely have itd->frame set to an invalid value which can never be
      equal to ehci->now_frame.
      
      This should be applied to -stable kernels going back to 3.6.
      Signed-off-by: NSoeren Moch <smoch@web.de>
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85ecd032
    • J
      USB: serial: update copyright information · 659597b7
      Johan Hovold 提交于
      Update copyright information.
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      659597b7
    • J
      USB: iuu_phoenix: remove bogus disconnect test in close · 8976f1df
      Johan Hovold 提交于
      Remove bogus disconnect test for serial device being NULL in close. This
      can never happen as close is guaranteed to be called before the last tty
      reference is dropped (and port->serial is cleared).
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8976f1df
    • J
      USB: garmin_gps: remove bogus disconnect test in bulk callback · 5dbabace
      Johan Hovold 提交于
      Remove bogus disconnect test for serial device being NULL in read bulk
      callback. This can never happen as the port read urb is killed (and
      poisoned) at close, which in turn is guaranteed to be called before the
      last tty reference is dropped (and port->serial is cleared).
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dbabace
    • J
      USB: garmin_gps: remove bogus disconnect test in close · 91972724
      Johan Hovold 提交于
      Remove bogus disconnect test for serial device being NULL in close. This
      can never happen as close is guaranteed to be called before the last tty
      reference is dropped (and port->serial is cleared).
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91972724
    • J
      USB: visor: always disable uart on close · 7620c33a
      Johan Hovold 提交于
      Always try to disable the uart on close.
      
      Since the switch to tty ports, close will be called as part of shutdown
      before disconnect returns. Hence there is no need to check the
      disconnected flag, and we can put devices in disabled states also on
      driver unbind.
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7620c33a