linux-toradex.git/drivers/usb, branch v4.9.97

usb: musb: Fix external abort in musb_remove on omap2430

2018-04-29T09:31:56+00:00

commit 94e46a4f2d5eb14059e42f313c098d4854847376 upstream.

This fixes an oops on unbind / module unload (on the musb omap2430
platform).

musb_remove function now calls musb_platform_exit before disabling
runtime pm.

Signed-off-by: Merlijn Wajer 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

2018-04-29T09:31:56+00:00

commit df6b074dbe248d8c43a82131e8fd429e401841a5 upstream.

Without pm_runtime_{get,put}_sync calls in place, reading
vbus status via /sys causes the following error:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060
pgd = b333e822
[fa0ab060] *pgd=48011452(bad)

[] (musb_default_readb) from [] (musb_vbus_show+0x58/0xe4)
[] (musb_vbus_show) from [] (dev_attr_show+0x20/0x44)
[] (dev_attr_show) from [] (sysfs_kf_seq_show+0x80/0xdc)
[] (sysfs_kf_seq_show) from [] (seq_read+0x250/0x448)
[] (seq_read) from [] (__vfs_read+0x1c/0x118)
[] (__vfs_read) from [] (vfs_read+0x90/0x144)
[] (vfs_read) from [] (SyS_read+0x3c/0x74)
[] (SyS_read) from [] (ret_fast_syscall+0x0/0x54)

Solution was suggested by Tony Lindgren .

Signed-off-by: Merlijn Wajer 
Acked-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: musb: fix enumeration after resume

2018-04-29T09:31:56+00:00

commit 17539f2f4f0b7fa906b508765c8ada07a1e45f52 upstream.

On dm3730 there are enumeration problems after resume.
Investigation led to the cause that the MUSB_POWER_SOFTCONN
bit is not set. If it was set before suspend (because it
was enabled via musb_pullup()), it is set in
musb_restore_context() so the pullup is enabled. But then
musb_start() is called which overwrites MUSB_POWER and
therefore disables MUSB_POWER_SOFTCONN, so no pullup is
enabled and the device is not enumerated.

So let's do a subset of what musb_start() does
in the same way as musb_suspend() does it. Platform-specific
stuff it still called as there might be some phy-related stuff
which needs to be enabled.
Also interrupts are enabled, as it was the original idea
of calling musb_start() in musb_resume() according to
Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
enable them on resume")

Signed-off-by: Andreas Kemnade 
Tested-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: pci: Properly cleanup resource

2018-04-24T07:34:11+00:00

commit cabdf83dadfb3d83eec31e0f0638a92dbd716435 upstream.

Platform device is allocated before adding resources. Make sure to
properly cleanup on error case.

Cc: 
Fixes: f1c7e7108109 ("usb: dwc3: convert to pcim_enable_device()")
Signed-off-by: Thinh Nguyen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw

2018-04-24T07:34:11+00:00

commit 64627388b50158fd24d6ad88132525b95a5ef573 upstream.

USB3 hubs don't support global suspend.

USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective
suspend and resume, they do not support global suspend/resume where the
hub downstream facing ports states are not affected.

When system enters hibernation it first enters freeze process where only
the root hub enters suspend, usb_port_suspend() is not called for other
devices, and suspend status flags are not set for them. Other devices are
expected to suspend globally. Some external USB3 hubs will suspend the
downstream facing port at global suspend. These devices won't be resumed
at thaw as the suspend status flag is not set.

A USB3 removable hard disk connected through a USB3 hub that won't resume
at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71”
error, and needs a 60 seconds timeout which causing system hang for 60s
before the USB host reset the port for the USB3 removable hard disk to
recover.

Fix this by always calling usb_port_suspend() during freeze for USB3
devices.

Signed-off-by: Zhengjun Xing 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: gadget: f_midi: fixing a possible double-free in f_midi

2018-04-24T07:34:10+00:00

commit 7fafcfdf6377b18b2a726ea554d6e593ba44349f upstream.

It looks like there is a possibility of a double-free vulnerability on an
error path of the f_midi_set_alt function in the f_midi driver. If the
path is feasible then free_ep_req gets called twice:

         req->complete = f_midi_complete;
         err = usb_ep_queue(midi->out_ep, req, GFP_ATOMIC);
            => ...
             usb_gadget_giveback_request
               =>
                 f_midi_complete (CALLBACK)
                   (inside f_midi_complete, for various cases of status)
                   free_ep_req(ep, req); // first kfree
         if (err) {
                 ERROR(midi, "%s: couldn't enqueue request: %d\n",
                             midi->out_ep->name, err);
                 free_ep_req(midi->out_ep, req); // second kfree
                 return err;
         }

The double-free possibility was introduced with commit ad0d1a058eac
("usb: gadget: f_midi: fix leak on failed to enqueue out requests").

Found by MOXCAFE tool.

Signed-off-by: Tuba Yavuz 
Fixes: ad0d1a058eac ("usb: gadget: f_midi: fix leak on failed to enqueue out requests")
Acked-by: Felipe Balbi 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: core: update usb_ep_queue() documentation

2018-04-24T07:34:09+00:00

commit eaa358c7790338d83bb6a31258bdc077de120414 upstream.

Mention that ->complete() should never be called from within
usb_ep_queue().

Signed-off-by: Felipe Balbi 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: musb: gadget: misplaced out of bounds check

2018-04-24T07:34:09+00:00

commit af6f8529098aeb0e56a68671b450cf74e7a64fcd upstream.

musb->endpoints[] has array size MUSB_C_NUM_EPS.
We must check array bounds before accessing the array and not afterwards.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: Bin Liu 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci: plat: Register shutdown for xhci_plat"

2018-04-13T17:48:37+00:00

Pixel 2 field testers reported that when they tried to reboot their
phones with some USB devices plugged in, the reboot would get wedged and
eventually trigger watchdog reset.  Once the Pixel kernel team found a
reliable repro case, they narrowed it down to this commit's 4.4.y
backport.  Reverting the change made the issue go away.

This reverts commit b07c12517f2aed0add8ce18146bb426b14099392.

Signed-off-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

USB: ene_usb6250: fix SCSI residue overwriting

2018-04-13T17:48:00+00:00

[ Upstream commit aa18c4b6e0e39bfb00af48734ec24bc189ac9909 ]

In the ene_usb6250 sub-driver for usb-storage, the SCSI residue is not
reported correctly.  The residue is initialized to 0, but this value
is overwritten whenever the driver sends firmware to the card reader
before performing the current command.  As a result, a valid READ or
WRITE operation appears to have failed, causing the SCSI core to retry
the command multiple times and eventually fail.

This patch fixes the problem by resetting the SCSI residue to 0 after
sending firmware to the device.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Andreas Hartmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman