linux.git/drivers/usb, branch v4.4-rc5

USB: add quirk for devices with broken LPM

2015-12-11T23:40:51+00:00

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.

Signed-off-by: Alan Stern 
Reported-by: Steinar H. Gunderson 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

xhci: fix usb2 resume timing and races.

2015-12-11T23:40:51+00:00

According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.

On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.

There are a few issues with this approach

1. A host initiated resume will also generate a resume event. The event
   handler will find the port in resume state, believe it's a device
   initiated resume, and act accordingly.

2. A port status request might cut the resume signalling short if a
   get_port_status request is handled during the host resume signalling.
   The port will be found in resume state. The timestamp is not set leading
   to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
   get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happens to the port during device
   initiated resume signalling it will leave all the device resume
   parameters hanging uncleared, preventing further suspend, returning
   -EBUSY, and cause the pm thread to busyloop trying to enter suspend.

Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state

This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS

Cc: stable 
Reported-by: Daniel J Blueman 
Tested-by: Daniel J Blueman 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'fixes-for-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

2015-12-09T18:15:30+00:00

Felipe writes:

usb: fixes for-v4.4-rc5

Hopefully final set of fixes for v4.4 release cycle.

There's a fix for a regression on dwc3 caused by recent changes to how
transfers are started. We're not pre-starting interrupt endpoints
anymore.

A NULL pointer dereference fix for the MSM phy driver.

The UVC gadget got a minor fix for permissions to its configfs
attributes and, finally, two fixes for MUSB. A fix for PM runtime when
MUSB returns EPROBE_DEFER and a fix to actually return an error in case
we can't initialize a DMA engine.

Signed-off-by: Felipe Balbi

usb: musb: fail with error when no DMA controller set

2015-12-09T15:36:03+00:00

Fail with error when no DMA controller is set.

Signed-off-by: Aaro Koskinen 
Signed-off-by: Felipe Balbi

usb: gadget: uvc: fix permissions of configfs attributes

2015-12-08T14:53:43+00:00

76e0da3 "usb-gadget/uvc: use per-attribute show and store methods"
removed write permission for writeable attributes. Correct attribute
permissions.

Fixes: 76e0da3 "usb-gadget/uvc: use per-attribute show and store methods"
Reviewed-by: Christoph Hellwig 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Mian Yousaf Kaukab 
Signed-off-by: Felipe Balbi

usb: musb: core: Fix pm runtime for deferred probe

2015-12-08T14:41:09+00:00

If musb_init_controller fails at musb_platform_init, we have already
called pm_runtime_irq_safe for musb and that causes the pm runtime count
to be enabled for parent before the parent has completed initialization.
This causes pm to stop working as on unload nothing gets idled.

This issue can be reproduced at least with:

# modprobe omap2430
HS USB OTG: no transceiver configured
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
# modprobe phy-twl4030-usb
# rmmod omap2430

And after the steps above omap2430 will block deeper idle states on
omap3.

To fix this, let's not enable pm runtime until we need to and the
parent has been initialized. Note that this does not fix the issue of
PM being broken for musb during runtime.

Signed-off-by: Tony Lindgren 
Signed-off-by: Felipe Balbi

usb: phy: msm: fix a possible NULL dereference

2015-12-08T14:13:28+00:00

of_match_device could return NULL, and so cause a NULL pointer
dereference later.
Even if the probability of this case is very low, fixing it made
static analyzers happy.
Solving this with of_device_get_match_data made also code simplier.

Reported-by: coverity (CID 1324133)
Signed-off-by: LABBE Corentin 
Signed-off-by: Felipe Balbi

USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq

2015-12-04T16:19:55+00:00

The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
after registration. At that time, pdev->dev.platform_data is not yet set,
leading to a NULL pointer dereference.

Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe)
Reported-by: Peter Rosin 
Tested-by: Peter Rosin 
Signed-off-by: Alexandre Belloni 
Cc: stable@vger.kernel.org # 4.3+
Acked-by: Nicolas Ferre 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: Quiet down false peer failure messages

2015-12-04T16:19:55+00:00

My recent Intel box is spewing these messages:

xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: 0000:00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) (usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) (usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) (usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) (usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)

Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).

Further the unused ports have location data initialized to 0x80000000.

Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.

These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.

The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.

Tested on my Intel box.

Signed-off-by: Don Zickus 
Acked-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix config fail of FS hub behind a HS hub with MTT

2015-12-04T16:19:55+00:00

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun 
Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman