Skip to content

L
linux
Switch branch/tag
  1. 19 May, 2011 1 commit
    • Alan Stern's avatar
      USB: remove remaining usages of hcd->state from usbcore and fix regression · 69fff59d
      Alan Stern authored 
      This patch (as1467) removes the last usages of hcd->state from
usbcore.  We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().

This fixes a regression introduced by commit
9b37596a (USB: move usbcore away from
hcd->state).  It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped.  The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped.  The solution is to ignore HC_STATE_HALT
following the handler's return.

As a consequence of this change, several of the host controller
drivers need to be modified.  They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.

The patch also changes a few of the interrupt handlers.  They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive.  Early returns were added to avoid any
confusion.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Tested-by: default avatarManuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      69fff59d
  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 4 commits
  11. 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
  13. 10 May, 2011 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7