linux/drivers/usb, branch v4.3

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2015-11-01T04:36:07Z

Pull ARM SoC fixes from Olof Johansson: "This should be our final batch of fixes for 4.3: - A patch from Sudeep Holla that fixes annotation of wakeup sources properly, old unused format seems to have spread through copying. - Two patches from Tony for OMAP. One dealing with MUSB setup problems due to runtime PM being enabled too early on the parent device. The other fixes IRQ numbering for OMAP1" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: usb: musb: omap2430: Fix regression caused by driver core change ARM: OMAP1: fix incorrect INT_DMA_LCD ARM: dts: fix gpio-keys wakeup-source property

usb: musb: omap2430: Fix regression caused by driver core change

2015-10-28T17:16:04Z

Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe") started automatically ensuring the parent device is enabled when the child gets probed. This however caused a regression for MUSB omap2430 interface as the runtime PM for the parent device needs the child initialized to access the MUSB hardware registers. Let's delay the enabling of PM runtime for the parent until the child has been properly initialized as suggested in an earlier patch by Grygorii Strashko . In addition to delaying pm_runtime_enable, we now also need to make sure the parent is enabled during omap2430_musb_init. We also want to propagate an error from omap2430_runtime_resume if struct musb is not initialized. Note that we use pm_runtime_put_noidle here for both the child and parent to prevent an extra runtime_suspend/resume cycle. Let's also add some comments to avoid confusion between the two different devices. Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe") Suggested-by: Grygorii Strashko Reviewed-by: Grygorii Strashko Acked-by: Felipe Balbi Signed-off-by: Tony Lindgren

xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

2015-10-17T07:04:18Z

We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by: Laura Abbott Cc: Takashi Iwai Cc: Oliver Neukum [Added more history to commit message -Mathias] Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: handle no ping response error properly

2015-10-17T07:04:18Z

If a host fails to wake up a isochronous SuperSpeed device from U1/U2 in time for a isoch transfer it will generate a "No ping response error" Host will then move to the next transfer descriptor. Handle this case in the same way as missed service errors, tag the current TD as skipped and handle it on the next transfer event. Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: don't finish a TD if we get a short transfer event mid TD

2015-10-17T07:04:18Z

If the difference is big enough between the bytes asked and received in a bulk transfer we can get a short transfer event pointing to a TRB in the middle of the TD. We don't want to handle the TD yet as we will anyway receive a new event for the last TRB in the TD. Hold off from finishing the TD and removing it from the list until we receive an event for the last TRB in the TD Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: Add device quirk for Logitech PTZ cameras

2015-10-04T10:01:13Z

Add a device quirk for the Logitech PTZ Pro Camera and its sibling the ConferenceCam CC3000e Camera. This fixes the failed camera enumeration on some boot, particularly on machines with fast CPU. Tested by connecting a Logitech PTZ Pro Camera to a machine with a Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles while recording the kernel logs and taking camera picture after each boot. Before the patch, more than 7% of the boots show some enumeration transfer failures and in a few of them, the kernel is giving up before actually enumerating the webcam. After the patch, the enumeration has been correct on every reboot. Signed-off-by: Vincent Palatin Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: chaoskey read offset bug

2015-10-04T10:01:13Z

Rng reads in chaoskey driver could return the same data under the certain conditions. Signed-off-by: Alexander Inyukhin Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Add reset-resume quirk for two Plantronics usb headphones.

2015-10-04T10:01:13Z

These two headphones need a reset-resume quirk to properly resume to original volume level. Signed-off-by: Yao-Wen Mao Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: Add support for R-Car H3

2015-09-30T16:21:11Z

This patch adds a compatible string to support for R-Car H3. Since the HS-USB controller of R-Car H3 is almost the same specification with R-Car Gen2 (these have 16 pipes and usb-dmac), this patch sets the "type" of renesas_usbhs_driver_param to USBHS_TYPE_RCAR_GEN2. Acked-by: Geert Uytterhoeven Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi

usb: renesas_usbhs: fix build warning if 64-bit architecture

2015-09-30T16:21:03Z

This patch fixes the following warning if 64-bit architecture environment: ./drivers/usb/renesas_usbhs/common.c:496:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dparam->type = of_id ? (u32)of_id->data : 0; Acked-by: Geert Uytterhoeven Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi