UPSTREAM: net/l2tp: don't fall back on UDP [get|set]sockopt

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: James Chapman <jchapman@katalix.com>
Acked-by: David Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=chromium:398109
TEST=Copmile only for regressions -- this code does not build on ChromeOS

Cherry picked from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3cf521f7dc87c031617fd47e4b7aa2593c2f3daf

Change-Id: I7a3a2e0fc635d943cc5e81913aada6ecc2052e0c
Reviewed-on: https://chromium-review.googlesource.com/210040
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Restore ath9k driver state after hardware reset failed.

When reset failed for setting channel due to calibration timeout, continue
on with complete reset to restore the driver to a good state (re-enable interrupts).

Signed-off-by: Peter Qiu <zqiu@chromium.org>

BUG=chromium:309148
TEST=compile

Change-Id: I61e6bba0f518145e19ad5e1e04e188e3d43900ae
Reviewed-on: https://chromium-review.googlesource.com/209840
Tested-by: Peter Qiu <zqiu@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Peter Qiu <zqiu@chromium.org>
CHROMIUM: mwifiex: avoid processing RX packets with invalid length

If rx_len received in interface header from FW is more than
RX buffer size, skb_put for such length results into skb_panic.
Avoid this by not processing such packets. We just print a warning
for such packets and free skb.

BUG=chrome-os-partner:30989
TEST=simulate an invalid Rx length case by hacking the rx_len
field. Observed rx_len error message in dmesg and system ran
without crash. Tested on Peach_pit.

Change-Id: I2ac6215d5f9e7346f4a6399f950f5aa1ebe84cc8
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marc Yang <yangyang@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/210417
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: drm/exynos add hdmi_encoder_mode_valid

Added connector argument to encoder mode_valid function and implement it
in exynos driver. The method for finding connector from hdmi_encoder_mode_fixup
cannot be used in this case because the pointers between connectors and
encoders are not set up yet at startup. The new hdmi_encoder_mode_valid
calls into mixer and hdmi functions to determine validity of video modes
based on display clocks, hdisplay x vdisplay and adjusts modes unsupported
in mixer in the same way as hdmi_mode_valid.

BUG=chromium:397362,374985
TEST=boot up skate or daisy_spring with 2560x1XXX external monitor attached
Signed-off-by: Dominik Behr <dbehr@chromium.org>

Change-Id: Ic22bb45da071a525ff4687ce8936ada842a91069
Reviewed-on: https://chromium-review.googlesource.com/209958
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Dominik Behr <dbehr@chromium.org>
Tested-by: Dominik Behr <dbehr@chromium.org>
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8
CHROMIUM: mac8011: provide debugfs file to wake queues

On devices that use the ath9k driver, we've observed some cases
where the mac80211 TX queues get stuck in a stopped state. This
case is surprising, since the TX queues are stopped due to
power-save mode, even though we are not associated with an AP.

We don't know why that's happening. For now, we want to work
around the issue, rather than root-cause it. To that end, this
CL adds a debugfs file that userspace can use to forcibly wake
queues.

Signed-off-by: quiche@chromium.org

BUG=chromium:392209
TEST=compile

Change-Id: I90f24dafe58ded211f6af3356693b8e4a5470e5d
Reviewed-on: https://chromium-review.googlesource.com/211712
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
CHROMIUM: mwifiex: Don't balk on corrupted IEs

Some older APs may have trailing garbage in the IE data in
probe responses.  The beacon data is correct, and despite
trailing garbage, the probe response is also correct.
Instead of failing the association process due to the corrupt
IE payload, we should allow the association process to proceed
as well as it can, or at least validate whether it has enough
data to succeed.

Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=chromium:395795
TEST=Manual: Associate with AP with symptoms of chromium:395795

Change-Id: Ibf935366d4d1cf3d6c7b16ebdc887e06885f024a
Reviewed-on: https://chromium-review.googlesource.com/211890
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Nick Tran <ntran@marvell.com>
Reviewed-by: Kiavash Faraji <kiavash@google.com>
Tested-by: Kiavash Faraji <kiavash@google.com>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Reviewed-by: Avinash Patil <patila@marvell.com>
CHROMIUM: Add support for Logitech TK820

The TK820 is a keyboard that sports a big square touchpad.
This device supports the x6100 hidpp feature for raw data reporting.

Besides adding the Wireless PID to the list of this driver supported
devices, some extra tweaks were needed to convey the keyboard part
of the device.

Parsing of the keyboard part of the hid descriptor is still performed
by hid_core, as well as the forwarding of the keyboard events to the
appropriate input device.

(cherry picked from e6768ccb04c1649355317808396a5534d4930522 in 3.14)

BUG=none
TEST=Tested on 3.14 lumpy hw with a TK820/K830 at Logitech.

Change-Id: I884cce7d629c4be73567de112996a1edda488940
Reviewed-on: https://chromium-review.googlesource.com/212021
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Commit-Queue: Nestor Lopez Casado <nlopezcasad@logitech.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
CONFIG: Enable IWLXVT for pineview

This adds the iwlxvt module for falco_li and other 3.8-WiFi systems
on pineview.

Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=None
TEST=emerge-falco chromeos-kernel-3_8
emerge-falco_li chromeos-kernel-3_8

Change-Id: Ia67f68a535f215f6f1cbac0a24e5cb9542d0af5f
Reviewed-on: https://chromium-review.googlesource.com/212266
Reviewed-by: Huan Liao <huanl@google.com>
Reviewed-by: Peter Qiu <zqiu@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8
ARM: Fix [-Wparentheses] in mali_kbase_replay

This patch fixes the warning by insulating the "if" in the macro from
a following 'else'.

drivers/gpu/arm/midgard/mali_kbase_replay.c: In function ‘dump_job_head’:
drivers/gpu/arm/midgard/mali_kbase_replay.c:101:5: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
  if (job->flags & JOB_FLAG_DESC_SIZE)
     ^

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chrome-os-partner:31345
TEST=emerge-peach_pi chromeos-kernel-3_8

Change-Id: I85e6643775736bce6e73187187a9f54d48e5db21
Reviewed-on: https://chromium-review.googlesource.com/212286
Reviewed-by: David Garbett <David.Garbett@arm.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Add common kernel config options for virtio scsi support (needed for GCE).

This CL includes components that are needed for running Chromium OS in
Google Compute Engine and these components are explicitly included
in the kernel not as modules.

BUG=chromium:391105
TEST=Tested with changes in: cl:206583 in addition to uploading
the vm image to gce, creating an instance, and ssh'ing into it.
To use: USE=gce build_packages, build_image test, image_to_vm --test_image.

Change-Id: I3a97f635a2760a662b9924126b30563564120e0a
Signed-off-by: Chris Sosa <sosa@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211666
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: mmc: core: Stop bkops for eMMC only from mmc suspend

Move mmc suspend specific operations to be executed from the .suspend
callback in the mmc bus_ops. This simplifies the mmc_suspend_host
function which is supposed to handle nothing but common suspend tasks.

Since eMMC can be considered non-removable there are no need to check
for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 39b9431b0f371294dd2d1a492cf77f2f17390a1f)

Conflicts:
	drivers/mmc/core/mmc.c

CQ-DEPEND=CL:212104
BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I826e2ff06e344d5bc4f575d31f5686615c493b31
Reviewed-on: https://chromium-review.googlesource.com/212066
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Puthikorn Voravootivat <puthik@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Add bus_ops for runtime pm callbacks

SDIO is the only protocol that uses runtime pm for the card device
right now. To provide the option for sd and mmc to use runtime pm as
well the bus_ops callback are extended with two new functions. One for
runtime_suspend and one for runtime_resume.

This patch will also implement the callbacks for SDIO to make sure
existing functionality is maintained. It also prepares to move
away from using the mmc_power_restore_host API, since it is not
needed when using runtime PM.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 12d01d0b813b93e7bde1b5f468b5c85aa8b33590)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: Idab37d7700f79620efa43d9a571e4f2a3df35ffa
Reviewed-on: https://chromium-review.googlesource.com/212067
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Puthikorn Voravootivat <puthik@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: block: Enable runtime pm for mmc blkdevice

Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to be configurable somehow since it needs to be trimmed depending
on the power save algorithm.

For SD-combo cards, we are still leaving the enablement of runtime PM
to the SDIO init sequence since it depends on the capabilities of the
SDIO func driver.

Moreover, when the blk device is being suspended, we make sure the device
will be runtime resumed. The reason for doing this is that we want the
host suspend sequence to be unaware of any runtime power save operations
done for the card in this phase. Thus it can just handle the suspend as
the card is fully powered from a runtime perspective.

Finally, this patch prepares to make it possible to move BKOPS handling
into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
accomplished.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit e94cfef698aae6b209d8918dd319312e4b02118d)

Conflicts:
	drivers/mmc/card/block.c

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I2f06537e68efd737669a3b266300d92b8ed9bbf1
Reviewed-on: https://chromium-review.googlesource.com/212068
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Support aggressive power management for (e)MMC/SD

Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.

Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latency. This latency
is card-specific, experiments has shown in general that SD-cards
has quite poor initialization time, around 300ms-1100ms. eMMC is
not surprisingly far better but still a couple of hundreds of ms
has been observed.

Except for the request latency, it is important to know that
suspending the card will also prevent the card from executing
internal house-keeping operations in idle mode. This could mean
degradation in performance.

To use this feature make sure the request inactivity timeout is
chosen carefully. This has not been done as a part of this patch.

Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
by setting CONFIG_MMC_UNSAFE_RESUME.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit c4d770d72492df510077b277f21ac5f0dad9e5eb)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I32f96656d65136f0b7a9115db7915c45477d9df3
Reviewed-on: https://chromium-review.googlesource.com/212069
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Restructure and simplify code for mmc sleep|awake

The mmc_card_sleep|awake APIs are not being used since the support is
already properly encapsulated within the suspend sequence. Sleep|awake
command is also specific for eMMC.

We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
move the code into the mmc specific core instead. This also includes
the mmc ops function, mmc_sleepawake. All releated functions have then
become static and we have got far less code to maintain.

Additionally this patch also simplifies the code from mmc_sleepawake,
since it is only used to put the card to sleep and not awake.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 07a682160866e302d696f5c76d74024d575fb79d)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I30abf0397f8be8213d184011cc3bac47201c3603
Reviewed-on: https://chromium-review.googlesource.com/212090
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Remove unnecessary check for the remove callback

For every bus_ops type the .remove callback always exist, thus there
are no need to check the existence of it, before we decide to call it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 58a8a4a1a5da4694a3a069de5e0a8c15995e7b5f)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I75210e11b6429c77da479056d7f502f8bb22527e
Reviewed-on: https://chromium-review.googlesource.com/212091
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Validate suspend prerequisites for SDIO at SUSPEND_PREPARE

This patch moves the validation for all the suspend prerequisites to be
done at SUSPEND_PREPARE notification. Previously in the SDIO case parts
of the validation was done from mmc_suspend_host.

This patch invents a new pre_suspend bus_ops callback and implements it
for SDIO. Returning an error code from it, will mean at SUSPEND_PREPARE
notification, the card will be removed before proceeding with the
suspend sequence.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 810caddba42a54fe5db4e2664757a9a334ba359c)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: I38a645a242ad5317cf9e86f8f5ad3a3a1222688e
Reviewed-on: https://chromium-review.googlesource.com/212092
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
UPSTREAM: mmc: core: Push common suspend|resume code into each bus_ops

By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.

Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 74590263384e5d4601de7f0ee2790477578829ea)

BUG=chromium:383481
TEST=run bvt-inline and bvt-cq suite on spring

Change-Id: Ib368d55f78038f522e183a214e156e711281d30b
Reviewed-on: https://chromium-review.googlesource.com/212093
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>