gmane.linux.usb.general

Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.

Shawn Nematbakhsh — 2013-05-25T16:59:46

Hi Sarah and Alan,

Thanks for the comments. I will make the following revisions:

1. Call pm_runtime_get_noresume only when the first device is
connected, and call pm_runtime_put when the last device is
disconnected.
2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST.
3. Make sure that all pm_runtime_get_noresume calls have a
corresponding pm_runtime_put somewhere (originally the intent was to
disable runtime suspend "forever", but no longer).

In principle, would the patch be acceptable with these revisions?

On Sat, May 25, 2013 at 7:11 AM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz< at >public.gmane.org> wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.

Alan Stern — 2013-05-25T14:11:44


This is a complicated issue.  It depends on the runtime PM settings for 
both the device and the host controller.

As just one aspect, consider the fact that if it wants to, userspace
can already prevent the controller from going into runtime suspend.  
Always preventing this at the kernel level, even when no devices are 
plugged in, does seem too heavy-handed.


That's not so easy, because the kernel changes over time.  Userspace 
has no general way to tell which drivers have reset-resume support.


Not just that; the patch is incorrect on the face of it...


It adds a pm_runtime_get call with no corresponding pm_runtime_put.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci_hcd nonfunctional in 3.9.0,3.9.3

Bjørn Mork — 2013-05-25T10:57:52


The PCI EHCI driver was split out in a separate ehci_pci module in
v3.8.   That's where you'll find the module aliases.  If it doesn't
autoload then maybe you don't build it?  You may also have to update
your initramfs building process to make sure the ehci_pci module is
included there (so it can be loaded before the ohci_hcd).


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb-audio regression 3.8.5->3.9.2

Tobias Diedrich — 2013-05-25T10:28:08

I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an
issue with usb-audio:
With two different usb-headsets, pulseaudio is now regularily losing the
microphone audio stream (which just gets 'stuck', i.e. the level
indicator bar in pavucontrol doesn't move anymore, but is not at 0).

Every time this happens I get kernel messages like these:
May 25 11:05:01 nukunuku kernel: [43611.510661] delay: estimated 221, actual 0
May 25 11:06:02 nukunuku kernel: [43672.086015] delay: estimated 222, actual 1
May 25 11:06:02 nukunuku kernel: [43672.102018] delay: estimated 133, actual 0
May 25 11:07:03 nukunuku kernel: [43733.814401] delay: estimated 133, actual 0
May 25 11:08:02 nukunuku kernel: [43792.636147] delay: estimated 89, actual 0
May 25 11:10:03 nukunuku kernel: [43913.539550] cannot submit urb (err = -18)
May 25 11:10:03 nukunuku kernel: [43913.539610] cannot submit urb (err = -18)
May 25 11:10:03 nukunuku kernel: [43913.539622] cannot submit urb (err = -18)
May 25 11:10:03 nukunuku kernel: [4391

Re: dwc2: Transaction errors with device connected at boot

Matthijs Kooijman — 2013-05-25T09:35:04

Hi Paul,

I tried it quickly with that patch and got one succesful boot and one
failed boot, so it seems the patch doesn't help for my problem.

I'll have a look next week, thanks.

Gr.

Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: dwc2: fix value of dma_mask

Matthijs Kooijman — 2013-05-25T06:47:02

Hi Paul,

On Fri, May 24, 2013 at 04:27:56PM -0700, Paul Zimmerman wrote:
Isn't 32 the default value usually? Not sure a about PCI devices,
though. It also made sense to set it to 31, since the comment talks
about a workaround for > 2GB ram (and 2GB ~~ 31 bits).

Or, is the workaround really only needed in the coherent mask and is
that the reason why you didn't change the coherent dma mask to 32?

If this is so, wouldn't it make sense to only set the coherent dma mask
and leave the dma mask at whatever default (just guessing here...).

Gr.

Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: xhci: Use non-interruptible sleep for XHCI commands

Julius Werner — 2013-05-25T01:39:37

The XHCI stack usually uses wait_for_completion_interruptible_timeout()
to wait for the completion of an XHCI command, and treats both timeouts
and interruptions as errors. This is a bad idea, since these commands
are often essential for the correct operation of the USB stack, and
their failure can leave devices in a misconfigured and/or unusable
state. While a timeout probably means a real problem that needs to be
dealt with, a random signal to the controlling user-space process should
not cause such harsh consequences.

This patch changes that behavior to use uninterruptible waits instead.
It fixes an easy to reproduce bug that occurs when you kill -9 a
process that reads from a UVC camera. The UVC driver's release code
tries to set the camera's alternate setting back to 0, but the lingering
SIGKILL instantly aborts any Stop Endpoint or Configure Endpoint command
sent to the xHC. The code dies halfway through the bandwidth allocation
process, leaving the device in an active configuration and preventing
fut

[PATCH] usb: xhci: Fix Command Ring Stopped Event handling

Julius Werner — 2013-05-25T01:33:50

The current XHCI code treats a command completion event with the
COMP_CMD_STOP code as a slightly different version of COMP_CMD_ABORT. In
particular, it puts the pointed-to command TRB through the normal
command completion handlers. This is not how this event works.

As XHCI spec 4.6.1.1 describes, unlike other command completion events
Command Ring Stopped sets the Command TRB Pointer to the *current*
Command Ring Dequeue Pointer. This is the command TRB that the XHCI will
execute next, and not a command that has already been executed. The
driver's internal command ring dequeue pointer should not be increased
after this event, since it does not really mark a command completion...
it's just a hint for the driver that execution is stopped now and where
it will be picked up again if the ring gets restarted.

This patch gets rid of the handle_stopped_command_ring() function and
splits its behavior into two distinct parts for COMP_CMD_STOP and
COMP_CMD_ABORT events. It ensures that the former no longer messes wi

[RFC 2/6] xhci: Remove BUG_ON in xhci_get_input_control_ctx.

Sarah Sharp — 2013-05-25T00:42:56

Fail gracefully, instead of causing the kernel to panic, if the input
control context doesn't have the right type (XHCI_CTX_TYPE_INPUT).  Push
finding the pointer to the input control context up into functions that
can fail.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-dbg.c  |    5 ++
 drivers/usb/host/xhci-mem.c  |    4 +-
 drivers/usb/host/xhci-ring.c |    4 +
 drivers/usb/host/xhci.c      |  148 ++++++++++++++++++++++++++++++++----------
 4 files changed, 126 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c7..8e0be37 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
< at >< at >

[RFC 3/6] xhci: Remove BUG in xhci_setup_addressable_virt_dev

Sarah Sharp — 2013-05-25T00:42:59

From: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>

We may have more speed types in the future, so fail gracefully, rather
than causing the kernel to panic.

BUG() was called if the device speed was unknown when setting max packet
size.  Set the max packet size at the same time as the slot speed and
get rid of one switch statement with BUG() option completely.

[Note: Sarah merged a patch that she wrote that touched the
xhci_setup_addressable_virt_dev function with this patch from Mathias
for clarity.]

This patch should be backported to kernels as old as 2.6.31, that
contain the commit 3ffbba9511b4148cbe1f6b6238686adaeaca8feb "USB: xhci:
Allocate and address USB devices"

Signed-off-by: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-mem.c |   35 ++++++++++-------------------------
 1 files changed, 10

[RFC 5/6] xhci: check for failed dma pool allocation

Sarah Sharp — 2013-05-25T00:43:03

From: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>

Fail and free the container context in case dma_pool_alloc() can't allocate
the raw context data part of it

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-mem.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 94412ec..82d4677 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
< at >< at > -373,6 +373,10 < at >< at > static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci
 ctx->size +=

[RFC 6/6] usb: check usb_hub_to_struct_hub() return value

Sarah Sharp — 2013-05-25T00:43:05

From: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>

usb_hub_to_struct_hub() can return NULL in the unlikely cases a hub
without active configuration, or a hub without ports is found.

Even if unlikely we need to handle those cases properly.

[Note from Sarah: I'm not sure which stable kernels need parts of this
patch applied.  I think parts of it will need to be backported to
kernels as old as 2.6.32.

Commit 25118084ef03f4fc314ab33ef6a9d9271d0e616a "USB: check for hub
driver not bound to root hub device" (which was merged in 2.6.32)
changed hdev_to_hub() to return NULL if the driver wasn't bound to the
roothub.  Any commits after that commit that don't check for the NULL
pointer need to be fixed.

This is further complicated by the fact that commit
ad493e5e580546e6c3024b76a41535476da1546a "usb: add usb port auto power
off mechanism" renamed hdev_to_hub() to usb_hub_to_struct_hub(), and
thus this patch will not apply to kernels older than 3.9.

Also, commit 84ebc10294a3d7be4c66f51070

[RFC 1/6] xhci: Remove BUG_ON() in xhci_alloc_container_ctx.

Sarah Sharp — 2013-05-25T00:42:54

It's horrible coding style to panic the kernel when someone passes you
an argument value you didn't expect.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-mem.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index fbf75e5..1a2052d 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
< at >< at > -358,11 +358,15 < at >< at > int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring,
 static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
     int type, gfp_t flags)
 {
-struct xhci_container_ctx *ctx = kzalloc(sizeof(*ctx), flags)

[RFC 4/6] xhci: remove BUG() in xhci_get_endpoint_type()

Sarah Sharp — 2013-05-25T00:43:01

From: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>

If the endpoint type is unknown, set it to 0 and fail gracefully
instead of causing a kernel panic.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit f94e0186312b0fc39f41eed4e21836ed74b7efe1 "USB: xhci:
Bandwidth allocation support"

Signed-off-by: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-mem.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 9f06aa8..94412ec 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
< at >< at > -1329,7 +1329,7 < at >< at > static u32 xhci_get_endpoint_type(struct usb_device *udev,
 else
 type = EP_TYPE(INT_OUT_EP);
 } else {
-BUG();
+type = 0;
 }
 return type;
 }
< at >< at > -1

[RFC 0/6] xHCI and USB security bug fixes

Sarah Sharp — 2013-05-25T00:42:52

This patchset address some (but not all) of the security issues found
with the Klockwork static analysis tool.  I have not reviewed these in
detail to see if these could be used by attackers, so someone with more
security experience may want to look these over.

Sarah Sharp

The following changes since commit c3897aa5386faba77e5bbdf94902a1658d3a5b11:

  xhci: Disable D3cold for buggy TI redrivers. (2013-05-24 15:23:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git ful-klockwork

for you to fetch changes up to c3a0a3ea1c2ece9596b6e3ae3fcb4540fc9b6e31:

  usb: check usb_hub_to_struct_hub() return value (2013-05-24 17:26:48 -0700)

----------------------------------------------------------------
Mathias Nyman (4):
      xhci: Remove BUG in xhci_setup_addressable_virt_dev
      xhci: remove BUG() in xhci_get_endpoint_type()
      xhci: check for failed dma pool allocation
      usb: check usb_hub_to_struct_hub() return value

Sarah Sharp (2):

Re: Mobile Broadband Interface Model (MBIM) support?

Dan Williams — 2013-05-25T00:11:52

As Bjorn mentioned, libmbim just got a 1.0 release, and ModemManager
0.7.x (git master, basically) has support for MBIM devices via libmbim.
0.7.x will turn into an official 0.8 release Real Soon Now; it's already
built for Fedora 20, though we don't have libmbim capability in F20
quite yet.

Dan



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: dwc2: change some dev_dbg() messages to dev_vdbg()

Paul Zimmerman — 2013-05-24T23:32:12

Change some dev_dbg() messages in dwc2_hcd_hub_control() to
dev_vdbg(), to prevent massive spew to the dmesg log when a device
is disconnected.

Signed-off-by: Paul Zimmerman <paulz-HKixBCOQz3hWk0Htik3J/w< at >public.gmane.org>
---
 drivers/staging/dwc2/hcd.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 2b09199..2ed54b1 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
< at >< at > -1563,9 +1563,9 < at >< at > static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
 break;
 
 case GetPortStatus:
-dev_dbg(hsotg->dev,
-"GetPortStatus wIndex=0x%04x flags=0x%08x\n", windex,
-hsotg->flags.d32);
+dev_vdbg(hsotg->dev,
+ "GetPortStatus wIndex=0x%04x flags=0x%08x\n", windex,
+ hsotg->flags.d32);
 if (!windex || windex > 1)
 goto error;
 
< at >< at > -1598,7 +1598,7 < at >< at > static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
 }
 
 hprt0 = readl(hsotg->regs + HPRT0);
-dev_dbg(h

[PATCH] staging: dwc2: fix value of dma_mask

Paul Zimmerman — 2013-05-24T23:27:56

Passing the value DMA_BIT_MASK(31) to dma_set_mask() causes the
dwc2-pci driver to sometimes fail (cannot enumerate the connected
device). Change it to DMA_BIT_MASK(32) instead, which is a more
sensible value anyway.

Signed-off-by: Paul Zimmerman <paulz-HKixBCOQz3hWk0Htik3J/w< at >public.gmane.org>
---
This should be sent to Linus for the next -rc, since without it
the dwc2-pci driver may not work when DMA mode is enabled.

 drivers/staging/dwc2/hcd.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index 827ab78..8551cce 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
< at >< at > -2804,9 +2804,8 < at >< at > int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
 
 /* Set device flags indicating whether the HCD supports DMA */
 if (hsotg->core_params->dma_enable > 0) {
-if (dma_set_mask(hsotg->dev, DMA_BIT_MASK(31)) < 0)
-dev_warn(hsotg->dev,
- "can't enable workaround for >2GB RAM\n");
+if (dma_set_mask(hsotg->dev,

[PATCH 3/4] xhci - correct comp_mode_recovery_timer on return from hibernate

Sarah Sharp — 2013-05-24T23:07:54

From: Tony Camuso <tcamuso-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>

Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.

The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.

Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.

At this point, a call trace is emitted indicati

[PATCH 1/4] xhci-mem: init list heads at the beginning of init

Sarah Sharp — 2013-05-24T23:07:52

From: Sergio Aguirre <sergio.a.aguirre.rodriguez-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>

It is possible that we fail on xhci_mem_init, just before doing
the INIT_LIST_HEAD, and calling xhci_mem_cleanup.

Problem is that, the list_for_each_entry_safe macro, assumes
list heads are initialized (not NULL), and dereferences their 'next'
pointer, causing a kernel panic if this is not yet initialized.

Let's protect from that by moving inits to the beginning.

This patch should be backported to kernels as old as 3.2, that
contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test
USB2 software LPM".

Signed-off-by: Sergio Aguirre <sergio.a.aguirre.rodriguez-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
Acked-by: David Cohen <david.a.cohen-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA< at >public.gmane.org>
Cc: stable-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
---
 drivers/usb/host/xhci-mem.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 4/4] xhci: Disable D3cold for buggy TI redrivers.

Sarah Sharp — 2013-05-24T23:07:54

Some xHCI hosts contain a "redriver" from TI that silently drops port
status connect changes if the port slips into Compliance Mode.  If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event.  If the port slips into compliance mode
while the host is in D3, the host will not send a PME.  This includes
when the system is suspended (S3) or hibernated (S4).

If this happens when the system is in S3/S4, there is nothing software
can do.  Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost.  This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events.  A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.

Software can deal with this issue when the system is in S0.  A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continu