Skip to content

L
linux
Switch branch/tag
  1. 17 May, 2011 4 commits
    • Mark Brown's avatar
      USB: OTG: msm: Allow the widest possible range for VDDCX when removing · 7b521fcb
      Mark Brown authored 
      When not active the hardware should be able to tolerate voltages within
the normal operating range so when removing set the maximum voltage we
can use to the maximum rather than minimum of the operating range. This
will improve interoperability in case we end up sharing the supply in
some design.
Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7b521fcb
    • Marcin Gałczyński's avatar
      USB: option: add support for Huawei E353 device · 610ba42f
      Marcin Gałczyński authored 
      I am sharing patch to the devices/usb/serial/option.c. This allows
operation of Huawei E353 broadband modem using the “option” driver. The
patch simply adds new constant with proper product ID and an entry to
usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.

Looking at the type of change, i doubt it has potential to introduce
problems in other parts of kernel or the driver itself.
Signed-off-by: default avatarMarcin Galczynski <marcin@galczynski.pl>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      610ba42f
    • Sarah Sharp's avatar
      xhci: Fix memory leak bug when dropping endpoints · 834cb0fc
      Sarah Sharp authored 
      When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule.  After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.

Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints.  The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed.  This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:

[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled

Fix this issue and free endpoint rings when their endpoints are
successfully dropped.

This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      834cb0fc
    • Sarah Sharp's avatar
      xhci: Fix memory leak in ring cache deallocation. · 30f89ca0
      Sarah Sharp authored 
      When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full.  If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented.  The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.

Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0.  This was caused by the second assignment to rings_cached:

	rings_cached = virt_dev->num_rings_cached;
	if (rings_cached < XHCI_MAX_RINGS_CACHED) {
		virt_dev->num_rings_cached++;
		rings_cached = virt_dev->num_rings_cached;
		virt_dev->ring_cache[rings_cached] =
			virt_dev->eps[ep_index].ring;

This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed.  When the driver was unloaded, this caused interesting messages
like:

xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy

This should be queued to stable kernels back to 2.6.33.
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      30f89ca0
  3. 13 May, 2011 16 commits
  5. 12 May, 2011 4 commits
  7. 11 May, 2011 4 commits
    • Sarah Sharp's avatar
      xhci: Fix bug in control transfer cancellation. · 3abeca99
      Sarah Sharp authored 
      When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing.  The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs).  The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.

Unfortunately, there is a long-standing bug in the control transfer
completion code.  It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed.  So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.

When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel.  It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs.  Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.

It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior.  Fix this
behavior.

This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
      3abeca99
    • Kuninori Morimoto's avatar
      usb: renesas_usbhs: fixup error processing on probe/remove · 97f93227
      Kuninori Morimoto authored 
      The error processing order was wrong.
This patch modify it.
Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      97f93227
    • Kuninori Morimoto's avatar
      usb: renesas_usbhs: fixup fifo disable · c786e09c
      Kuninori Morimoto authored 
      It was necessary to check pipe condition after disable fifo.
Current driver checked it in a wrong place.
Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c786e09c
    • Erik Slagter's avatar
      USB: cdc_acm: Fix oops when Droids MuIn LCD is connected · fd5054c1
      Erik Slagter authored 
      The Droids MuIn LCD operates like a serial remote terminal.
Data received are displayed directly on the LCD. This patch
fixes the kernel null pointer oops when it is plugged in.

Add NO_DATA_INTERFACE quirk to tell the driver that "control"
and "data" interfaces are not separated for this device, which
prevents dereferencing a null pointer in the device probe code.
Signed-off-by: default avatarErik Slagter <erik@slagter.name>
Signed-off-by: default avatarMaxin B. John <maxin.john@gmail.com>
Tested-by: default avatarErik Slagter <erik@slagter.name>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fd5054c1
  9. 10 May, 2011 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7