BACKPORT 3.10.13: USB: cdc-wdm: fix race between interrupt handler and tasklet

commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.

Both could want to submit the same URB. Some checks of the flag
intended to prevent that were missing.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[benzh: This is needed for 14029eaee1205672fec6cfe4762ddd4ae4f1e0e4]
Signed-off-by: Ben Zhang <benzh@chromium.org>
UPSTREAM: USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications

Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
when sending a message over multiple fragments or when there are unsolicited
messages available.

Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications received
and decrement the count and submit the urb for the next response each time userspace
completes a read the response.

Signed-off-by: Greg Suarez <gsuarez@smithmicro.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 73e06865ead1bec8d1c179e1c647dc77adde9116)

BUG=chromium:326559
TEST=Tested the following:
1. `USE='kernel-3_10 -kernel-next' emerge-peppy chromeos-kernel-3_10`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I182d9e830c45f1b5948922e1faf27ac50241ea91
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186754
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: usb: cdc-wdm: ignore speed change notifications

The only notification supported by the Device Management class is
Response Available. But this driver is also used as a subdriver of
other CDC classes, allowing notifications like Speed Change and
Network Connection. This results in log messages which are only
confusing to an end user:

 [66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 len 8

These drivers use cdc-wdm as a subdriver to allow access to an
embedded management protocol, and all management is expected to
use this protocol. There is therefore no need to handle any of
these optional CDC notifications. Instead we can let the cdc-wdm
driver recognize them and log a debug level message instead of an
error.

Reported-by: Rob Gardner <robmatic@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9983d6dc4e8a8a1ce599cb426c0ec9384219b476)

BUG=chromium:326559
TEST=Tested the following:
1. `USE='kernel-3_10 -kernel-next' emerge-peppy chromeos-kernel-3_10`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I63c8f496de53bd475186674245872e1542dbecc1
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186755
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: usb: cdc-wdm: manage_power should always set needs_remote_wakeup

Cc: stable <stable@vger.kernel.org>
Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4144bc861ed7934d56f16d2acd808d44af0fcc90)

BUG=chromium:326559
TEST=Tested the following:
1. `USE='kernel-3_10 -kernel-next' emerge-peppy chromeos-kernel-3_10`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I107a2cb9d84ee76bdc89a7dce5ea1dd52296c4ee
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186756
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: usb: cdc-wdm: avoid hanging on zero length reads

commit 73e06865ead1 ("USB: cdc-wdm: support back-to-back
USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications") implemented
queued response handling. This added a new requirement: The read
urb must be resubmitted every time we clear the WDM_READ flag if
the response counter indicates that the device is waiting for a
read.

Fix by factoring out the code handling the WMD_READ clearing and
possible urb submission, calling it everywhere we clear the flag.

Without this fix, the driver ends up in a state where the read urb
is inactive, but the response counter is positive after a zero
length read.  This prevents the read urb from ever being submitted
again and the driver appears to be hanging.

Fixes: 73e06865ead1 ("USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications")
Cc: Greg Suarez <gsuarez@smithmicro.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org> # 3.13
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8dd5cd5395b90070d98149d0a94e5981a74cd2ec)

BUG=chromium:326559
TEST=Tested the following:
1. `USE='kernel-3_10 -kernel-next' emerge-peppy chromeos-kernel-3_10`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: Ib283934ac36e5bf56df8746772802e00615dc71a
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186757
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: usb: cdc-wdm: resp_count can be 0 even if WDM_READ is set

Do not decrement resp_count if it's already 0.

We set resp_count to 0 when the device is closed.  The next open and
read will try to clear the WDM_READ flag if there was leftover data
in the read buffer. This fix is necessary to prevent resubmitting
the read URB in a tight loop because resp_count becomes negative.

The bug can easily be triggered from userspace by not reading all
data in the read buffer, and then closing and reopening the chardev.

Fixes: 8dd5cd5395b9 ("usb: cdc-wdm: avoid hanging on zero length reads")
Cc: <stable@vger.kernel.org> # 3.13
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f563926fed982f26b391ca42493f55f2447f1b0a)

BUG=chromium:326559
TEST=Tested the following:
1. `USE='kernel-3_10 -kernel-next' emerge-peppy chromeos-kernel-3_10`
2. Manually test cellular support on a DUT with a MBIM modem.
3. Run network_3GIdentifiers, network_3GModemPresent and
   network_3GSmokeTest.

Change-Id: I394d695330ea99ebbeb24b1f95a4744643c6dc3e
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186758
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: USB: cdc-acm: remove unneeded spin_lock_irqsave/restore on write path

When writing data we were:
	lock
	do some work
	unlock
	call function
		lock
		do some work
		unlock
		return
	return

It turns out, that "function" was only ever called in the one place, so
instead of locking/unlocking for no good reason, just inline the
function and only grab the lock once.

This has sped up the pathological case of sending 1 byte packets to a
loop-back cdc-acm device from 49600 bytes per second to 50100 bytes a
second on my workstation.  A tiny increase yes, but noticable, and now
the spinlock isn't the hottest thing on the perf graph anymore.  Yes, we
are still waiting for the hardware for the most part, but getting rid of
a spinlock_irq_save() call for every packet is still a good thing.

And we end up deleting lines of code, always a win overall.

This was found by using a Teensy 3.0 device and the test program and
firmware located at:
	http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

Reported-by: Paul Stoffregen <paul@pjrc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:345086
TEST=Tested the following:
     - USE="-kernel_next kernel-3_10" ./build_packages
     - Manually tested cellular support on a DUT with alt3100 and y3300 modems
     - On the same devices, ran network_3GIdentifiers, network_3GModemPresent,
       network_3GSmokeTest

(cherry picked from commit 71c2fb03fc5800f24b66b730cbb9fddc22df40d3)
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Change-Id: I9f7f607594af5ddc93390905d0e4f608b9efd108
Reviewed-on: https://chromium-review.googlesource.com/187330
Reviewed-by: Ben Chan <benchan@chromium.org>
UPSTREAM: cdc-acm: add TIOCMIWAIT

This implements TIOCMIWAIT for TIOCM_DSR, TIOCM_RI and TIOCM_CD
Disconnect is handled as TIOCM_CD or an error.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:345086
TEST=Tested the following:
     - USE="-kernel_next kernel-3_10" ./build_packages
     - Manually tested cellular support on a DUT with alt3100 and y3300 modems
     - On the same devices, ran network_3GIdentifiers, network_3GModemPresent,
       network_3GSmokeTest

(cherry picked from commit 5a6a62bdb9257aa74ab0ad2b2c8a33b0f9b17ce4)
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Change-Id: I7f42cff0741feddd875d942f6bde6ca6b04f73fc
Reviewed-on: https://chromium-review.googlesource.com/187332
Reviewed-by: Ben Chan <benchan@chromium.org>
UPSTREAM: cdc-acm: add TIOCGICOUNT

Simple straightforward implementation. Just returning the statistics
gathered for TIOCMIWAIT

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:345086
TEST=Tested the following:
     - USE="-kernel_next kernel-3_10" ./build_packages
     - Manually tested cellular support on a DUT with alt3100 and y3300 modems
     - On the same devices, ran network_3GIdentifiers, network_3GModemPresent,
       network_3GSmokeTest

(cherry picked from commit 797ef13716ce05d26c5be12893ca75b2b003f25f)
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Change-Id: I549a9f3b6ecfef976fed0f9fc510d3d58fa15617
Reviewed-on: https://chromium-review.googlesource.com/187333
Reviewed-by: Ben Chan <benchan@chromium.org>
UPSTREAM: cdc-acm: fix power management in ioctl

An ioctl that does depends on communication with a device should
prevent suspension of teh device.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:345086
TEST=Tested the following:
     - USE="-kernel_next kernel-3_10" ./build_packages
     - Manually tested cellular support on a DUT with alt3100 and y3300 modems
     - On the same devices, ran network_3GIdentifiers, network_3GModemPresent,
       network_3GSmokeTest

(cherry picked from commit 8fdbeb26b5105282e55559b54a660fe7b6eed331)
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Change-Id: If298cf4600e27785d655b62cfd32e06652ceb617
Reviewed-on: https://chromium-review.googlesource.com/187334
Reviewed-by: Ben Chan <benchan@chromium.org>
BACKPORT 3.10.15: xhci: Fix race between ep halt and URB cancellation

commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.

The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699

Signed-off-by: Florian Wolter <wolly84@web.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[benzh: Cherry-picked to usb-xhci topic branch because
cba17ddd504448452bd44c3071f6e0d91e521b03 depends on it]
Signed-off-by: Ben Zhang <benzh@chromium.org>

Change-Id: I1bdeda3c6807c927849079d53c63eade641240ef
CHROMIUM: usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb

We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.

The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.

This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.

This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."

BUG=chrome-os-partner:25595
TEST=Make sure USB 3.0 ports still work in all the ways they should.

Patch was sent upstream and signed off by the maintainer on Feb 28, but
not yet picked up in any branch I can find.

Change-Id: I20aa7be196b41d45ddf2f1010ce4e198b6c4a400
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188791
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
UPSTREAM: usb: class: cdc-acm: be careful with bInterval

bInterval must be on the range 1 - 16, if we
want to pass the maximum allowed, we should
be passing 16

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:345086
TEST=Tested the following:
     - USE="-kernel_next kernel-3_10" ./build_packages
     - Manually tested cellular support on a DUT with alt3100 and y3300 modems
     - On the same devices, ran network_3GIdentifiers, network_3GModemPresent,
       network_3GSmokeTest

(cherry picked from commit d102e78f7035f2d6896ced598122b878afd1c352)
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187331
Reviewed-by: Ben Chan <benchan@chromium.org>
Change-Id: Iae431cdb6026b2a19e4ad61f7a2a6d4327ac57b0
Reviewed-on: https://chromium-review.googlesource.com/190402
CHROMIUM: xhci: plat: enable runtime PM

Enable runtime PM for the xhci-plat device so that the parent device
may implement runtime PM.

BUG=None
TEST=Runtime PM works with Tegra-XHCI driver.

Change-Id: I597a49a8a2b0e85756dc750678056c65c963ccd0
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190411
Reviewed-by: Julius Werner <jwerner@chromium.org>
CHROMIUM: HACK: xhci: plat: Wait for ports to enter U3 before suspend

Sleep briefly before xhci_suspend to ensure the ports have had enough
time to enter U3.

BUG=None
TEST=Suspend/resume with XHCI enabled.

Change-Id: I4d848f2f1e10a01714025ae8377389d16141dc0c
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190412
CHROMIUM: usb: host: Add Tegra XHCI host-controller driver

Add support for the XHCI host controller driver present on Tegra114
and Tegra124 SoCs.  The driver currently only supports host mode and
must be used with the Tegra XUSB PHY driver.

BUG=None
TEST=USB 2.0/3.0 work on Nyan.  Test runtime and LP0 suspend.

Change-Id: I580beb57507cf175a2d3311e7b5b4575a67004e1
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190413
CHROMIUM: usb: phy: Add Tegra XUSB PHY driver

Add support for the Tegra XUSB PHY present on Tegra114 and Tegra124 SoCs.
This provides all PHY functionality for the Tegra XHCI host-controller
driver and supports UTMI, HSIC, and SuperSpeed interfaces.

Note: this implements much of the functionality required to support
LP0 suspend/resume in the current Tegra USB2.0 PHY driver.  Eventually
that code should be split out into a common Tegra USB PHY driver.

BUG=None
TEST=USB 2.0/3.0 work on Nyan.  Test runtime and LP0 suspend.

Change-Id: Iac3a4834050ff3d9f70f68bdfaabe664de856f6d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190414
Reviewed-by: Julius Werner <jwerner@chromium.org>
CHROMIUM: usb: xhci: tegra: powergate XUSBB when no device-mode

Powergate XUSBB partition, right now device mode is not supported.

BUG=None
TEST=In remote console, run "cat /sys/kernel/debug/powergate",
then xusbb is not powered.

Change-Id: I0f9b68cad2aa93989343555f3124c762cbfba0cd
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/191196
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: xhci: tegra: clean up runtime PM handling

Instead of doing pm_runtime_get() from the VBUS notifier, just
use pm_request_resume() to force a runtime resume if the device
is in runtime suspend.  This allows us to drop the usage-counter
balancing and autosuspend logic.

BUG=None
TEST=Test runtime suspend/resume by inserting and removing both
USB2.0 and USB3.0 devices.

Change-Id: Ifc0d3fc183a4eb364bf563ec5bef0893dba6fd62
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191166
Reviewed-by: Julius Werner <jwerner@chromium.org>
CHROMIUM: xhci: tegra: Don't map the XHCI host registers

The child xhci-plat device already does this for us and there's
no need to wait for STS_CNR in load_firmware() as that is handled
by xhci_reset().

BUG=None
TEST=Test runtime and LP0 suspend/resume.

Change-Id: I06b7dd94ad2edc9825b2834efe55464963f18f7b
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191167
Reviewed-by: Julius Werner <jwerner@chromium.org>