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: net: cdc_mbim: change the default to send ZLPs

A number of devices in the wild have turned out to require ZLPs.
Even if this is a spec violation, our priority is to make any
device work as good as possible. Devices needing ZLPs will fail
to receive any full sized frame we send. On the other hand,
devices which do not need the ZLP will still work if we send
them.

This gives us no other option than sending ZLPs by default.

This will prevent devices conforming to the spec from making the
optimizations which are possible without ZLPs.  Adding known
such devices to a whitelist, to avoid the possible negative
impact of the new spec violating default.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c1a2e95435976cb040db1f6c0afbe4287c3d2e28)

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: I3bac3f66230925154ccb609082ad5e366ef13c8b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186813
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: net: cdc_mbim: manage_power should always set needs_remote_wakeup

Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 04d948a9fc7b352b05125bd3d81c565fb8840c56)

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: If3ced3ad384c9a41c244c626133f6ef756565c3c
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186814
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: net: cdc_mbim: no need to check for resume if suspend exists

Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c37ac9b22b6732c0c9dc17076ebe84e841d4eb16)

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: I248f29c324fd680a9ea2ee1cae8d6e19b1d2f112
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186815
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: net: cdc_mbim: fixup error return value

Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e62416e8e4e086652cfc88b88921708964aac3b5)

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: I6a06dfea4ed38cc95a136804cfd502313ba78d39
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186816
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: fix cmd and Tx data timeout issue for PCIe cards

We are sending sleep confirm done interrupt in the middle of
sleep handshake. There is a corner case when Tx done interrupt
is received from firmware during sleep handshake due to which
host and firmware power states go out of sync causing cmd and
Tx data timeout problem.

Hence sleep confirm done interrupt is sent at the end of sleep
handshake to fix the problem.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: I208d09eacf4bde8e6220179d71f91914a8126dd0
Reviewed-on: https://chromium-review.googlesource.com/186746
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
mwifiex: re-enable PCIe interrupt after awake event is received

It's found that sometimes the PCIe interrupt isn't re-enabled in
some cases where power save state is transitioning to awake state.
It will cause cmd timeout and/or Tx watchdog timeouts if interrupt
is disabled. This patch ensures that the interrupt is re-enabled.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: I1f9e5dba1db56c1eb3501c77d562d957d6b38890
Reviewed-on: https://chromium-review.googlesource.com/186747
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
mwifiex: change transmit buffer size for 8897

Currently default Tx buffer size configured to firmware is 2K
for all chipsets. This patch changes it to 4K for SD/PCIe/USB
8897 chipsets as per firmware requirements.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24397
TEST=browse to slashdot.org; open a new Ctrl-T console and run script:
while sleep 10; do ping -f -c 100 www.google.com; done

Change-Id: Id860f8b222e724d5ad8e9ad73c939ccc8eb38ece
Reviewed-on: https://chromium-review.googlesource.com/186748
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Revert "HACK: CHROMIUM: config: disable DVFS-related options on Tegra"

This reverts commit 00ad04c3984f14b0d76f7a801e75f66126bb226e.

BUG=chrome-os-partner:25578
TEST=Build and boot on Nyan; DVFS stuff works again.

Change-Id: Iafc4f85e20fc81b40ee8a4b5eb4dfd7877114e81
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186736
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
CHROMIUM: misc: fuse: set tegra_sku_id

It looks like reading of the SKU ID got removed when moving the fuse
driver from mach-tegra to drivers/misc.  As a result, the CPU/GPU/SoC
speedo IDs were determined based on a SKU ID of 0x0.  Fix this by
setting tegra_sku_id and sku_info->sku_id based on FUSE_SKU_INFO.

BUG=None
TEST=Boot on Nyan; CPU scales up to 2.1Ghz again.

Change-Id: Ie3a81f554a0cefa4c9410d7effe52896fc64daf6
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186935
Reviewed-by: Dylan Reid <dgreid@chromium.org>
LPE: Enable jack detection for the Rambi platform

Detect jack events by exposing gpio lines and DAPM endpoints to the
ASoC jack API. Power is transferred between DAPM endpoints based on
the detected jack status.

BUG=chromium:339256
TEST=plug headphones or headset in while playing audio

Change-Id: Ic6b1efa510a8c6e00a57205f9a932e7ba2a99a15
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/183550
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
CHROMIUM: video: tegra: Bump up the emc clock if it's too low

tegra_emc_bw_to_freq_req() appears to underestimate the required
DRAM rate for low bandwidth requests.  If it estimates a low DRAM
rate (<= 20.4Mhz), then bump up it up to the next available rate.

BUG=none
TEST=After updates to 0x19 version of emc table (CL:186868 and
CL:186869), the norrin panel no longer shows corruption.

Change-Id: I4f62feaf8bd4613f8f8c81169321fbbe69111f49
Signed-off-by: David Ung <davidu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186938
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: memory: tegra124: support revision 0x19 EMC tables

The revision 0x19 table adds the setting of the MC_EMEM_ARB_MISC1
register.

BUG=none
TEST=Built kernel and boot. EMC scaling works on nyan-rev1.

Change-Id: I474ca7ab04cd45c4d19779163b2469f53533a9bc
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186868
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: dts: nyan: update revision 0x19 EMC tables

The patch updates EMC tables to revision 0x19.

BUG=none
TEST=Built kernel and boot. EMC scaling works on nyan-rev1.

Change-Id: I2d3db8b9e75e7aa59852c78d72700fb85095abc3
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186869
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: clk: tegra: add clock aliases for use by DVFS

Add aliases for a few more clocks on Tegra124 so that they can be
used by Tegra-DVFS.

BUG=None
TEST=Build and boot on Nyan

Change-Id: I0680bc6bf190e5adc666c27602e5ee8ab628f73d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187110
CHROMIUM: ARM: tegra124: dvfs: update Core DVFS table

Update memory related entries as per characterization results and add
some more clocks into the Core DVFS table so we won't under voltage when
operating those clocks.

BUG=None
TEST=boot and read sysfs under /sys/kernel/debug/tegra_dvfs/dvfs.

Change-Id: I9ee73ca22105139a86dcb7dae8205857fba01bda
Signed-off-by: Bill Huang <bilhuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186952
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: backing_dev: Fix hung task on sync

bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can happen since mod_delayed_work can now steal work from a work_queue.
This fixes the problem by using queue_delayed_work instead. This is a
regression from the move to the bdi workqueue design.

The reason that this causes a problem is that laptop-mode will change the
delay, dirty_writeback_centisecs, to 60000 (10 minutes) by default. In the case
that bdi_wakeup_thread_delayed races with sync_inodes_sb, sync will be stopped
for 10 minutes and trigger a hung task. Even if dirty_writeback_centisecs is
not long enough to cause a hung task, we still don't want to delay sync for
that long.

For the same reason, this also changes bdi_writeback_workfn to immediately
queue the work again in the case that the work_list is not empty. The same
problem can happen if the sync work is run on the rescue worker.

BUG=chrome-os-partner:25356
TEST=suspend_stress_test for about 500 iterations on rambi

Change-Id: I5353401d6e960b8f4ac4e48fa185584ca2a66260
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186655
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
UPSTREAM: writeback: fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

BUG=chrome-os-partner:25356
TEST=suspend_stress_test for about 500 iterations

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 146d7009b45cdb45ec3be8ad73177dae58f4bc91)
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

Change-Id: I3c051492f7f1e67e1cdb4e71c3645cd6cc95f154
Reviewed-on: https://chromium-review.googlesource.com/186666
Tested-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
CHROMIUM: mfd: Add DT include file for AS3722 PMIC

The version of the AS3722 MFD driver which landed in the ChromeOS
tree did not include the DT binding include file, but the one that
landed upstream did.  Pull it in from commit d460a6f ["mfd: Add
support for ams AS3722 PMIC"] upstream.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Florian Lobmaier <florian.lobmaier@ams.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

BUG=chrome-os-partner:25096
TEST=Build and boot on Nyan.

Change-Id: I48934bea1ae191a3130334a4e5a1039ac9b1dcba
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187155
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>