Skip to content

L
linux
Switch branch/tag
  1. 19 May, 2011 7 commits
  3. 18 May, 2011 5 commits
  5. 17 May, 2011 9 commits
    • Alan Stern's avatar
      usb-storage: fix up the unusual_realtek device list · a8e62dd6
      Alan Stern authored 
      This patch (as1461) fixes the unusual_devs entries for the Realtek USB
card reader.  They should be ordered by PID, and they should not
override the Subclass and Protocol values provided by the device.
Otherwise a notification about unnecessary entries gets printed in the
kernel log during probing.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Tested-By: default avatarTony Vroon <tony@linx.net>
CC: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a8e62dd6
    • Martin Jackson's avatar
      USB: gadget: f_audio: Fix invalid dereference of initdata · e6251a92
      Martin Jackson authored 
      as_out_ep_desc contines to be used during gadget enumeration and thus
should not be marked as __initdata
Signed-off-by: default avatarMartin Jackson <mjackson220.list@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e6251a92
    • Alan Stern's avatar
      EHCI: don't rescan interrupt QHs needlessly · 1e12c910
      Alan Stern authored 
      This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low.  On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.

The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame.  If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it.  Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1e12c910
    • Alan Stern's avatar
      OHCI: fix regression caused by nVidia shutdown workaround · 2b7aaf50
      Alan Stern authored 
      This patch (as1463) fixes a regression caused by commit
3df7169e (OHCI: work around for nVidia
shutdown problem).

The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down.  For
example, the LED on an optical mouse would remain on, draining a
laptop's battery.  The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown.  The workaround was to put the
controllers into the Suspend state instead.

It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately.  Thus, working around the original bug
on some machines exposes other bugs on other machines.

The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID.  I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess.  So far it was worked out okay for all the people who have
tested it.

This fixes Bugzilla #35032.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Tested-by: default avatarAndre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: default avatarYury Siamashka <yurand2@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2b7aaf50
    • Mark Brown's avatar
      USB: OTG: msm: Free VCCCX regulator even if we can't set the voltage · e99c4309
      Mark Brown authored 
      If for some reason we fail to set the voltage range for the VDDCX regulator
when removing it's better to still disable and free the regulator as that
avoids leaking a reference to it and is likely to ensure that it's turned
off completely.
Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e99c4309
    • 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
  7. 13 May, 2011 16 commits
  9. 12 May, 2011 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7