compiler-gcc.h: neatening

 - Move the inline and noinline blocks together

 - Comment neatening

 - Alignment of __attribute__ uses

 - Consistent naming of __must_be_array macro argument

 - Multiline macro neatening

Signed-off-by: Joe Perches <joe@perches.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

compiler-gcc: integrate the various compiler-gcc[345].h files

As gcc major version numbers are going to advance rather rapidly in the
future, there's no real value in separate files for each compiler
version.

Deduplicate some of the macros #defined in each file too.

Neaten comments using normal kernel commenting style.

Signed-off-by: Joe Perches <joe@perches.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

read/write chromeos vbc with sysfs

fixup dev_set_usb

fixup dev_set_usb

kernel: Replace timeconst.pl with a bc script

bc is the standard tool for multi-precision arithmetic.  We switched
to Perl because akpm reported a hard-to-reproduce build hang, which
was very odd because affected and unaffected machines were all running
the same version of GNU bc.

Unfortunately switching to Perl required a really ugly "canning"
mechanism to support Perl < 5.8 installations lacking the Math::BigInt
module.

It was recently pointed out to me that some very old versions of GNU
make had problems with pipes in subshells, which was indeed the
construct used in the Makefile rules in that version of the patch;
Perl didn't need it so switching to Perl fixed the problem for
unrelated reasons.  With the problem (hopefully) root-caused, we can
switch back to bc and do the arbitrary-precision arithmetic naturally.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>

ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.

Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

kernel: add support for gcc 5

We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.

Just copy the relevant bits out of include/linux/compiler-gcc4.h,
no new code is added as of now.

This fixes a build error when using gcc 5.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

set dev usb

fixup kernel loading firmware

firmware: use 'kernel_read()' to read firmware into kernel buffer

Fengguang correctly points out that the firmware reading should not use
vfs_read(), since the buffer is in kernel space.

The vfs_read() just happened to work for kernel threads, but sparse
warns about the incorrect address spaces, and it's definitely incorrect
and could fail for other users of the firmware loading.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

firmware: teach the kernel to load firmware files directly from the filesystem

This is a first step in allowing people to by-pass udev for loading
device firmware.  Current versions of udev will deadlock (causing us to
block for the 30 second timeout) under some circumstances if the
firmware is loaded as part of the module initialization path, and this
is causing problems for media drivers in particular.

The current patch hardcodes the firmware path that udev uses by default,
and will fall back to the legacy udev mode if the firmware cannot be
found there.  We'd like to add support for both configuring the paths
and the fallback behaviour, but in the meantime this hopefully fixes the
immediate problem, while also giving us a way forward.

[ v2: Some VFS layer interface cleanups suggested by Al Viro ]
[ v3: use the default udev paths suggested by Kay Sievers ]

Suggested-by: Ivan Kalvachev <ikalvachev@gmail.com>
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Kay Sievers <kay@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mwifiex: wait for firmware

vfs: Fix /proc/<tid>/fdinfo/<fd> file handling

Cyrill Gorcunov reports that I broke the fdinfo files with commit
30a08bf2d31d ("proc: move fd symlink i_mode calculations into
tid_fd_revalidate()"), and he's quite right.

The tid_fd_revalidate() function is not just used for the <tid>/fd
symlinks, it's also used for the <tid>/fdinfo/<fd> files, and the
permission model for those are different.

So do the dynamic symlink permission handling just for symlinks, making
the fdinfo files once more appear as the proper regular files they are.

Of course, Al Viro argued (probably correctly) that we shouldn't do the
symlink permission games at all, and make the symlinks always just be
the normal 'lrwxrwxrwx'.  That would have avoided this issue too, but
since somebody noticed that the permissions had changed (which was the
reason for that original commit 30a08bf2d31d in the first place), people
do apparently use this feature.

[ Basically, you can use the symlink permission data as a cheap "fdinfo"
  replacement, since you see whether the file is open for reading and/or
  writing by just looking at st_mode of the symlink.  So the feature
  does make sense, even if the pain it has caused means we probably
  shouldn't have done it to begin with. ]

Reported-and-tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

CHROMIUM: dts: spring: Disable Exynos RTC.

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19491
TEST=manual, boot on Spring

  - See only one rtc device
  ls -altr /dev/rtc*
  crw------- 1 root root 254, 0 May 15 11:45 /dev/rtc0
  lrwxrwxrwx 1 root root      4 May 15 11:45 /dev/rtc -> rtc0

  - See system clock set from s5m-rtc
  dmesg | grep "system clock"
  [    3.605657] s5m-rtc s5m-rtc: setting system clock to 2013-05-15 18:45:51 UTC (1368643551)

Change-Id: I14347169d6d8b5eb444ffbcdfdb0c0f065a70dcb
Reviewed-on: https://gerrit.chromium.org/gerrit/51348
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

CHROMIUM: security: use -fstack-protector-strong

Build the kernel with -fstack-protector-strong to gain the additional
checks without the performance hit of -fstack-protector-all. This grows
the uncompressed kernel image by less than 0.16% on x86:

-rwxr-xr-x 1 keescook portage 118219343 Apr 17 12:26 /build/link/var/cache/portage/sys-kernel/chromeos-kernel/vmlinux
-rwxr-xr-x 1 keescook portage 118407919 Apr 19 15:00 /build/link/var/cache/portage/sys-kernel/chromeos-kernel/vmlinux

ARM's compressed boot code now triggers stack protection, so a static
guard was added. Since it is only doing decompression and it's been
validated by the firmware, the exposure here is very small. Once it
switches to the full kernel, random stack protection is back to normal.

BUG=chromium:233757
TEST=link and daisy build & boot

Change-Id: I512fb6444463e12a8e04428b6203a00b460a79ae
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48703
Reviewed-by: Will Drewry <wad@chromium.org>

hid-logitech-wtp: refactoring for extensibility

Refactored the driver to allow for future devices to be added.

- Changed the initialization procedure to support multiple hidpp
  features. Each feature has methods attached to it, that take care of
  init, polling and parsing of events.
- During init, the driver selects the first available feature that is
  supported (Currently only TouchPadRawXY is supported).
- All device-specific branches are happening during the init method.
  e.q. don't send T651 to raw mode.
- TouchpadRawXY allows two different event formats. Raw or attached to
  the end of the mouse events. The init method decides which one to use.
- The data structures now reflect the data required to generate the
  output, no longer the data available from the device.
- Reordered and renamed to reflect feature-specific code and generic
  code.
BUG=chromium:240850
TEST=manually test with all 3 previously supported touchpads.

Change-Id: I24f67868aa6c26a55193a24c636f0a15a6d70e53
Signed-off-by: Dennis Kempin <denniskempin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50754
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>

CHROMIUM: chromeos_acpi: Enable USB wake from S3

Enable wake from USB devices for x86. Confirmed working on link.
Should likely work on lumpy as well.

BUG=chromium:240942
TEST=Connect a USB keyboard to external USB port. Suspend device using
"powerd_suspend" or idle suspend. After the system has suspended, hit a
key on USB keyboard. The system should resume.

Signed-off-by: Sameer Nanda <snanda@chromium.org>
Change-Id: Ia06b996a67abbf7943d081bf56f01db08292ccba
Reviewed-on: https://gerrit.chromium.org/gerrit/43152
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>

CHROMIUM: mfd: s5m: Enable RTC as wakeup source in suspend.

CL adds necessary power management functions to enable PMICs RTC wake
alarm as a wake source.

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19427
TEST=manual,

rtc=`readlink /dev/rtc`
echo "+10s" > /sys/class/rtc/${rtc}/wakealarm
echo mem > /sys/power/state

Change-Id: I155ccd6f058cdf8ed362a2c128226c5904379432
Reviewed-on: https://gerrit.chromium.org/gerrit/51338
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>

CHROMIUM: drm/anx7808: anx7808 disconnect handling

Currently, if the analogix dongle is disconnected during setup, the setup
function will get stuck.  Handle this by checking for polling error even during
connection process.

BUG=chrome-os-partner:19436
TEST=Plug in a MyDP dongle without connecting to any monitor, then disconnect.
Following that, plug in with connection to monitor.  See that connection is
established.

Change-Id: Ib531547b744d9bd8d07b933448fefc7af6158c4e
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51301
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: ALSA: ASoC: exynos hdmi - fix audio transfer on unplug

Because hotplug handling timeout was increased,
it is no longer safe to read HDMI_MODE_SEL in hdmi_audio_hotplug_func,
since HDMI might be off at that time.

This broke transferring audio to internal speakers on HDMI unplug,
since bogus value was read.

So, move the code that handles DVI plugging inside "if (plugged)",
where reading HDMI registers is safe, since it is powered on.

BUG=chromium:222145,chromium:239641
TEST=Various HDMI/DVI plug/unplug scenarios, the most complex being:
play music, plug HDMI, suspend, unplug HDMI, plug DVI, resume,
listen to sound on internal speakers.

Signed-off-by: Yuly Novikov <ynovikov@chromium.org>
Change-Id: I9d27d0e388f444756576e643e20811901c6afe85
Reviewed-on: https://gerrit.chromium.org/gerrit/51178
Reviewed-by: Dylan Reid <dgreid@chromium.org>

CHROMIUM: drm/anx7808: Add anx7808 to spring.

BUG=chrome-os-partner:16196
TEST=Plug in HDMI connector to external monitor, power up, and see video.

Change-Id: Ic5c2d2b10ba40f342fe3687b4244bfc8c463d539
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50541

CHROMIUM: config: Configure anx7808 bridge in Exynos5.

MyDP is a system for video over USB that is used in the Spring project.
Add it to the default build for exynos5 based systems.

BUG=chrome-os-partner:16196
TEST=on Spring, plug a myDP cable, HDMI dongle, or VGA dongle and see video.

Change-Id: Iab53cb95ec3aab004c1efdd508a62504fa9dd7c5
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50540

CHROMIUM: drm/anx7808: Adds a binding for anx7808.

BUG=chrome-os-partner:16196
TEST=Tested on spring, with HDMI dongle connected to 1080p and 720p monitors.

Change-Id: Ib1c42c0b8c9cb49a0823bdf4ce21ea170a09fc59
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50539

CHROMIUM: drm/anx7808: Train link, config output.

Adds a function that manages the video pipleline through ANX7808.

Adds a timer to debounce the cable detect signal.

Adds a workqueue on which management function runs.

BUG=chrome-os-partner:16196
TEST=Plug in HDMI connector to external monitor, power up, and see video.

Change-Id: I45440b43033304e1703113ec2e949ca39ad17071
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49561

CHROMIUM: drm/anx7808: Initialize video pipeline.

Adds routines that initialize the video pipeline, HDMI receiver and DP
transmitter, in anx7808 chip.

BUG=chrome-os-partner:16196
TEST=With verbose logging, and HDMI cable plugged into monitor, see:
"Video resolution: 2200x1125"

On the console, do "xrandr -d :0" and see:

eDP-1 connected 1366x768+0+0 0mm x 0mm
  1366x768       59.9*+
HDMI-1 connected 1920x1080+0+768 553mm x 311mm
  1920x1080      60.0*+   50.0
  1920x1080i     30.0     25.0
  1680x1050      60.0
  1440x900       59.9
  1280x720       60.0     50.0
  720x576        50.0
  720x480        59.9
  640x480        60.0

Change-Id: I583ced0a331326e8251a18ee04157de261af7849
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49560

CHROMIUM: drm/anx7808: Add Aux channel reading.

Adds register writing functions and helper functions for setting and clearing
bits.

Adds aux channel read function.

Adds DPCD read function.

Adds a code to print the firmware version of an HDMI dongle, when debugging is
on.

BUG=chrome-os-partner:16196
TEST=With verbose logging, see "ANX7730 Firmware version 0x0d."

Change-Id: I71f0778b9226685d0645234466517818330e61f3
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48861

CHROMIUM: drm/anx7808: Add cable detection IRQ.

Adds a function that detects when the cable is inserted.

BUG=chrome-os-partner:16196
TEST=Run on spring with verbose logging, plug in cable, and observe
"Detected cable insertion." in the logs.

Change-Id: I9a79e8755b6d4e402bf90d0f355b83762c270969
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48757

CHROMIUM: drm/anx7808: Add hardware probe.

Adds register definitions and functions to read registers.

Adds a hardware probe function that reads configuration registers to determine
whether hardware is present and responds as expected.

BUG=chrome-os-partner:16196
TEST=Run on spring with verbose logging, and observe "ANX7808 found." in logs.

Change-Id: I577bbb022e78f4a1c41be1096e740bd3a4463697
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48756

CHROMIUM: drm/anx7808: Adds a skeleton driver for Analogix 7808 Chip.

Adds a driver that reads parameters from device tree, requests resources
(memory, GPIOs, regulator) from kernel.

BUG=chrome-os-partner:16196
TEST=With verbose logging, see "ANX7808 initialization successful."

Change-Id: I3b492096a776e18bec5bbb928b49c27d42b31f90
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48755
Reviewed-by: Sean Paul <seanpaul@chromium.org>

CHROMIUM: Remove "DP Hotplug" in mach-exynos.

Spring is not using the dedicated DP_HPD pin (but a vanilla GPIO)

The only difference between calling exynos_fimd_gpio_setup_24bpp() and calling
exynos_fimd_gpio_setup_24bpp() (which is actually called by the former) is the
pin muxing for DP_HPD pin (aka GPX0_7)

BUG=chrome-os-partner:16196
TEST=See that slimport driver gets through initialization.

Change-Id: I5d26228d4a3027f9669022dc3a12ead70cf202b4
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50538

UPSTREAM: perf: Treat attr.config as u64 in perf_swevent_init()

Trinity discovered that we fail to check all 64 bits of
attr.config passed by user space, resulting to out-of-bounds
access of the perf_swevent_enabled array in
sw_perf_event_destroy().

Introduced in commit b0a873ebb ("perf: Register PMU
implementations").

Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: davej@redhat.com
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
BUG=chromium:240706
TEST=link build, exploit fails

Change-Id: I69496233eb3f1b8c5411685a5c546255c6e6be38
Signed-off-by: Kees Cook <keescook@chromium.org>
[upstream commit 8176cced706b5e5d15887584150764894e94e02f]
Reviewed-on: https://gerrit.chromium.org/gerrit/51134
Reviewed-by: Julien Tinnes <jln@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

asoc: samsung: hdmi: Increase the initialization delay

This patch increases the initialization wait time in the samsung hdmi
audio driver to 3 seconds. The wait time was previously 5ms which did
not leave enough time for the hdmi video driver to debounce hotplug and
initialize the hardware.

BUG=chromium:239641
TEST=Tested on snow, hotplug transferred audio between device & monitor

Change-Id: I86f7526923d77e753d0a5546fdeafbe7ee11e1fe
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51118
Reviewed-by: Dylan Reid <dgreid@chromium.org>

CHROMIUM: mwifiex: Dereference bss only if it is non-null

Commit:
  0ec8d6f mwifiex: fix use-after-free in beacon_ie processing

introduced an issue where the "bss" pointer was dereferenced
in mwifiex_bss_start() before a NULL check.  Fix this.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:19392
TEST=Change AP SSID while associating.

Change-Id: Iff8e02719f2c2e4f6560fab2dcfc65620c15ac31
Reviewed-on: https://gerrit.chromium.org/gerrit/51015
Commit-Queue: Paul Stewart <pstew@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>

Avoid NULL master_priv access in i915 kernel driver

In several places, including the interrupt handler, the driver assumes
it can deref. dev->primary->master->driver_priv if dev->primary->master
is non-NULL.  This wasn't true if drm_open_helper was midway through, so
rearrange the initialization order.

It looks as if http://crbug.com/221684 was caused by this, although I
have no direct repro.  I can produce the same kernel crash by adding a
delay to drm_open_helper and unplugging the monitor at the right time.

v2: Address this in drm_open_helper instead of the various access points --
basically Stephane's fix.

BUG=chromium:221684
TEST=The monitor unplug scenario doesn't bring down Link
Change-Id: I545f79422577cfe4cdd96e430b6bc902ccb1cab3
Reviewed-on: https://gerrit.chromium.org/gerrit/50407
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stuart Abercrombie <sabercrombie@chromium.org>
Tested-by: Stuart Abercrombie <sabercrombie@chromium.org>

CHROMIUM: config: exynos5: Enable s5m-rtc driver.

Signed-off-by: Todd Broch <tbroch@chromium.org>
CQ-DEPEND=I2ce54c0a4bf6d6d00b011a41f43c4ba899f05dc8
BUG=chrome-os-partner:19036
TEST=manual, compiles & kernel boots.  Clock keeps time across reboots
and power off.

Change-Id: Ifd2ab0bc5ef78d3c9b9c4fc582767b48610ac1f2
Reviewed-on: https://gerrit.chromium.org/gerrit/50531
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

CHROMIUM: rtc: s5m-rtc: Real-time clock driver for s5m8767.

Driver largely based off implementation in
  git://git.insignal.co.kr/samsung/exynos/android/kernel/samsung/exynos3.0

Although it would not backport cleanly.  Commits were:

  a781deb rtc: s5m: Modify read function for s5m8763
  e03092e rtc: Fix the minor bug for s5m8767a
  6f82705 rtc: Set initial time in s5m8767a rtc
  9e47078 mfd: Add wtsr and smpl function for s5m8767a
  49f0e86 rtc: Modify rtc_set_time for s5m rtc driver
  537c944 rtc: Modify s5m8767a EVT3 rtc driver
  4c0332b rtc: Add s5m rtc driver

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19036
TEST=manual, compiles & kernel boots.

Change-Id: I06e01e0171bd2f044977c0f4dfe34cea7641a35f
Reviewed-on: https://gerrit.chromium.org/gerrit/50530
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

CHROMIUM: mfd: s5m: Refactor regmap usage.

Refactor s5m_bulk|reg_* functions usage of regmap to facilitate
multiple regmapped devices in preparation for using s5m-rtc.

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19036
TEST=manual, compiles & kernel boots.

Change-Id: I4ac47de476cd6d94ebd751fa0aee7800f369b1ad
Reviewed-on: https://gerrit.chromium.org/gerrit/50529
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>

mwifiex: abort remaining scan commands when association started

A full-channel scan is split to multiple scan commands in driver
before they are sent to firmware. When each scan result is back
the SSID entries are parsed and informed to cfg80211 directly.

It's observed that sometimes userspace may initiate association
as soon as the target AP is found. During the 4-way handshake
firmware may go off-channel to scan the remaining channels.
This causes the 4-way handshake to fail.

Fix it by checking 'scan_block' flag and aborting the remaining
scan in this case. 'scan_block' flag is set after association
and before 4-way handshake. It gets cleared after 4-way handshake
is completed.

BUG=chrome-os-partner:18188
TEST=autotest against CrOS_chaos_WesternDigital_5 (Jason Abele)

Change-Id: Ibda61178f2aee7228989bedb511eb2abc5a40343
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50687
Reviewed-by: Paul Stewart <pstew@chromium.org>

mwifiex: remove global user_scan_cfg variable

As the variable is used only for preparation of internal scan
commands, we don't need to keep it allocated until the entire
scan completes. We will define it as a local variable and free
immediately after it's use.

New flag 'scan_aborting' is added to handle race between
mwifiex_close() and scan handler. Previously user_scan_cfg
pointer used to take care of this.

This patch fixes a memory leak in mwifiex_cfg80211_scan after
running "iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio".

BUG=None
TEST="iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio";
"echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak"

Change-Id: I3ab5aacf1bec957c6279a784d9ed557bf0691f2c
Reported-by: Daniel Drake <dsd@laptop.org> [OLPC]
Tested-by: Daniel Drake <dsd@laptop.org> [OLPC]
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50686
Reviewed-by: Paul Stewart <pstew@chromium.org>

mwifiex: scan delay timer cleanup in unload path

Return from scan delay timer routine if surprise_removed flag
is true. Also, cancel the timer in unload path.

This fixes a crash when scan delay timer accesses structures
that have been freed already.

Tested with "iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio"

BUG=None
TEST="iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio";
"echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak"

Change-Id: Ia69b70ecc8b208fce4c2c3f39ec6e2d4042962f6
Reported-by: Daniel Drake <dsd@laptop.org> [OLPC]
Tested-by: Daniel Drake <dsd@laptop.org> [OLPC]
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50685
Reviewed-by: Paul Stewart <pstew@chromium.org>

mwifiex: rename mwifiex_free_adapter() routine in init.c

We have two different static routines with name
mwifiex_free_adapter(). The routine in main.c actually frees the
adapter structure.

We will rename other routine in init.c to mwifiex_adapter_cleanup()
to avoid confusion.

BUG=None
TEST="iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio";
"echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak"

Change-Id: I84933ea996d6d0f6568b2ae915ade5214e25790a
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50684
Reviewed-by: Paul Stewart <pstew@chromium.org>

UPSTREAM mwifiex: fix memory leak issue when driver unload

After unregister_netdevice() call the request is queued and
reg_state is changed to NETREG_UNREGISTERING.
As we check for NETREG_UNREGISTERED state, free_netdev() never
gets executed causing memory leak.

Initialize "dev->destructor" to free_netdev() to free device
data after unregistration.

BUG=None
TEST="iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio";
"echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak"

Change-Id: I4ac505e2711770a2536dd5434e5dc2ff020e406b
Cc: <stable@vger.kernel.org>
Reported-by: Daniel Drake <dsd@laptop.org>
Tested-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50683
Reviewed-by: Paul Stewart <pstew@chromium.org>

CHROMIUM: ALSA: ASoC: exynos hdmi - disable audio in DVI mode

exynos-hdmi-audio used to configure HDMI to send ACR and AUI infoframes
even when DVI sink was plugged using HDMI-DVI cable.
This would cause monitor to go to sleep.

So, don't configure audio if HDMI is in DVI mode,
assuming the graphics driver already disabled it.

Also, if HDMI audio jack hotplugging was previously reported,
report that it was unplugged when DVI mode is detected.

BUG=chromium:222145
TEST=Unplug/plug HDMI-DVI cable, observe monitor working properly.
     Boot with HDMI-HDMI cable plugged in, unplug/plug,
     play sound and hear it on monitor's speakers.

Signed-off-by: Yuly Novikov <ynovikov@chromium.org>
Change-Id: Ia6d677ff82beb64ff53ed7c4bfb09658668fbd9b
Reviewed-on: https://gerrit.chromium.org/gerrit/50726
Reviewed-by: Dylan Reid <dgreid@chromium.org>

arm: exynos5: fix the number of GPIO groups on bank A

The GPIO bank A has 21 groups :
A0->A3, B0->B3, C0->C4, DO->D1, Y0->Y6

Let's update the constant to match the groups declare in the samsung
GPIO driver, else the GPIO irq driver won't find its babies.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
TEST=on Spring, try to get GPF0[0] as an interrupt.

Change-Id: I44396611d9da618dfe2a739892be4f0924a6f8cf
Reviewed-on: https://gerrit.chromium.org/gerrit/50710
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>

UPSTREAM: USB: option: add Huawei E5331

Another device using CDC ACM with vendor specific protocol to mark
serial functions.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit daec90e7382cbd0e73eb6861109b3da91e5ab1f3)

Change-Id: Ib13e341a812af0619fdf4ffb809e6bb50d83a05e
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50574
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: add Huawei "ACM" devices using protocol = vendor

The USB device descriptor of one identity presented by a few
Huawei morphing devices have serial functions with class codes
02/02/ff, indicating CDC ACM with a vendor specific protocol. This
combination is often used for MSFT RNDIS functions, and the CDC
ACM class driver will therefore ignore such functions.

The CDC ACM class driver cannot support functions with only 2
endpoints.  The underlying serial functions of these modems are
also believed to be the same as for alternate device identities
already supported by the option driver. Letting the same driver
handle these functions independently of the current identity
ensures consistent handling and user experience.

There is no need to blacklist these devices in the rndis_host
driver. Huawei serial functions will either have only 2 endpoints
or a CDC ACM functional descriptor with bmCapabilities != 0, making
them correctly ignored as "non RNDIS" by that driver.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1f3f687722fd9b29a0c2a85b4844e3b2a3585c63)

Signed-off-by: Ben Chan <benchan@chromium.org>
Conflicts:
drivers/usb/serial/option.c

Change-Id: I8a020cb3cfac933200fb6b8b5581a51fe1ef1c09
Reviewed-on: https://gerrit.chromium.org/gerrit/50573
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>

UPSTREAM: USB: option: blacklist network interface on ZTE MF880

The driver description files gives these names to the vendor specific
functions on this modem:

 diag: VID_19D2&PID_0284&MI_00
 nmea: VID_19D2&PID_0284&MI_01
 at:   VID_19D2&PID_0284&MI_02
 mdm:  VID_19D2&PID_0284&MI_03
 net:  VID_19D2&PID_0284&MI_04

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fab38246f318edcd0dcb8fd3852a47cf8938878a)

Change-Id: If40a3ca9fffaa28660ea3982fef57ac0a4e4f53d
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50572
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: blacklist network interface on Huawei E173

The Huawei E173 will normally appear as 12d1:1436 in Linux.  But
the modem has another mode with different device ID and a slightly
different set of descriptors. This is the mode used by Windows like
this:

  3Modem:      USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
  Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
  Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
  PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003

All interfaces have the same ff/ff/ff class codes in this mode.
Blacklisting the network interface to allow it to be picked up by
the network driver.

Cc: stable <stable@vger.kernel.org>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f36446cf9bbebaa03a80d95cfeeafbaf68218249)

Change-Id: I539d5879c3004f1a22532337c84cce8b2f47a2a7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50571
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: add new zte 3g-dongle's pid to option.c

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Rui li <li.rui27@zte.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 31b6a1048b7292efff8b5b53ae3d9d29adde385e)

Change-Id: I34dab64e2a7c442a396cb21b554c57f6c48321a6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50570
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: add more ZTE devices

Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4b35f1c52943851b310afb09047bfe991ac8f5ae)

Change-Id: Iaba97c0798546fb378d3913eb018a7bc52bd2950
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50569
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: blacklist net interface on ZTE devices

Based on information from the ZTE Windows drivers.

Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1452df6f1b7e396d89c2a1fdbdc0e0e839f97671)

Change-Id: Ic34ea8cf65c826766e7ef583411ce36e9182b6b6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50568
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: blacklist QMI interface on ZTE MF683

Interface #5 on ZTE MF683 is a QMI/wwan interface.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Cc: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 160c9425ac52cb30502be2d9c5e848cec91bb115)

Change-Id: I9dad94c5bfab2c752d1b93cd177f70ab47726b3e
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50567
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: replace ZTE K5006-Z entry with vendor class rule

Fix the ZTE K5006-Z entry so that it actually matches anything

  commit f1b5c997 USB: option: add ZTE K5006-Z

added a device specific entry assuming that the device would use
class/subclass/proto == ff/ff/ff like other ZTE devices. It
turns out that ZTE has started using vendor specific subclass
and protocol codes:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1018 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE LTE Technologies MSM
S:  SerialNumber=MF821Vxxxxxxx
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

We do not have any information on how ZTE intend to use these
codes, but let us assume for now that the 3 sets matching
serial functions in the K5006-Z always will identify a serial
function in a ZTE device.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ba9edaa468869a8cea242a411066b0f490751798)

Change-Id: I684108af3b0ccd94c0909b5e43eaa0c0772d49c4
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50566
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: add ZTE K5006-Z

The ZTE (Vodafone) K5006-Z use the following
interface layout:

00 DIAG
01 secondary
02 modem
03 networkcard
04 storage

Ignoring interface #3 which is handled by the qmi_wwan
driver.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f1b5c997e68533df1f96dcd3068a231bca495603)

Change-Id: Iac1d47ba7798ed27a903eb5c7266b98134f5d27b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50565
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: support the new interfaces of Huawei Data Card devices in option driver

In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices. And at the same time, remove the
redundant declarations from option.c.

Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ee6f827df9107139e8960326e49e1376352ced4d)

Change-Id: I909c57e51b88891616d80df128dcd39e9d11c73b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50564
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: add ZTE MF821D

Sold by O2 (telefonica germany) under the name "LTE4G"

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 09110529780890804b22e997ae6b4fe3f0b3b158)

Change-Id: I76097c70b04b835739dd7c49cbb227663aa40b82
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50563
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: add ZTE MF60

Switches into a composite device by ejecting the initial
driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
and mass storage.  Let this driver manage the two serial
interfaces:

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1402 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE WCDMA Technologies MSM
S:  SerialNumber=xxxxx
C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8e16e33c168a6efd0c9f7fa9dd4c1e1db9a74553)

Change-Id: I82d92464ece3b9e5dbadf9b5637dd7ceae2cf81b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50562
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: clean up probe coding style

Clean up option probe by introducing intermediate variables and fixing
up comments.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 378fac2a46decbcd16b42044303ba8a1a3f8001e)

Change-Id: I0ba9fbbabc05f314742cbdb58d231f5e12dc45c7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50561
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: Updated Huawei K4605 has better id

Later firmwares for this device now have proper subclass and
protocol info so we can identify it nicely without needing to use
the blacklist. I'm not removing the old 0xff matching as there
may be devices in the field that still need that.

Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 42ca7da1c2363dbef4ba1b6917c4c02274b6a5e2)

Change-Id: I9baea88b9f9d3fb1de84a296f3fe1765b5f2f110
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50560
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: option: Add Vodafone/Huawei K5005 support

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4cbbb039a9719fb3bba73d255c6a95bc6dc6428b)

Change-Id: Ibb164ad28a58da63eafb5d7b0ca3a1e46fe0a2dc
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50559
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: perf tools: fix -ldw/-lelf link test when static linking

Since libelf sometimes uses libpthread, we have to list that after -lelf
when someone tries to build statically.  Else things go boom:
Makefile:479: *** No libelf.h/libelf found, please install \
libelf-dev/elfutils-libelf-devel.  Stop.

Similarly, the -ldw test fails as it often uses -lz:
Makefile:462: No libdw.h found or old libdw.h found or elfutils is older \
than 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev

And if we add debugging to try-cc, we see:
+ echo '#include <dwarf.h>

int main(void)
{
        Dwarf *dbg = dwarf_begin(0, DWARF_C_READ);
        return (long)dbg;
}'
+ i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
-ldw -lelf -static -lpthread -lrt -lelf -lm -o .24368
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateInit_'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflate'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateReset'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateEnd'

+ echo '#include <libelf.h>

int main(void)
{
        Elf *elf = elf_begin(0, ELF_C_READ, 0);
        return (long)elf;
}'
+ i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
-static -lpthread -lrt -lelf -lm -o .19216
/usr/lib/libelf.a(elf_begin.o):function file_read_elf: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function read_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_unlock'
/usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_wrlock'
/usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_rdlock'
/usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_unlock'

BUG=None
TEST=`LDFLAGS=-static emerge-x86-alex perf` works

Change-Id: Idfa38ae36d22bcc669199bbd8e74f83eb97ddda9
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50498
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: drm/exynos: Fixup init failure cleanup path

Backport from 3.8-rebase version of this patch.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
TEST=by hand
BUG=none

Original-Change-Id: Ia0c0de4f49efe0d6dca09507372add5d0d533028
Reviewed-on: https://gerrit.chromium.org/gerrit/49146
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit fa2b424b2108697ee5a971bc00b9a8bb75f66b41)

Change-Id: I09d0d33a9499945e67fb8416c0074a440fd5b5a2
Reviewed-on: https://gerrit.chromium.org/gerrit/50188
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

Revert "Add implementation of poll() to dma_buf using KDS"

This reverts commit 5d1bb28fa72400006b3956ab7d869dffd091af23.

There are no users of dma-buf poll(), this isn't upstream, and we aren't
carrying it forward to 3.8.

Revert from 3.4 to keep 3.8 & 3.4 more consistent.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=none

Change-Id: Ia6628aef06f5ee228f3ac479bfa0e75b45573f04
Reviewed-on: https://gerrit.chromium.org/gerrit/50187
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: fix 800x600 resolution for exynos5 hdmi

800x600 resolution is not cleanly supported by the exynos5 mixer block.
Hw team suggested following workaround to enable the above resolution.

1) In MIXER_CFG register, set HD_SD and HD_MODE bits to 1.
2) In MIXER0_GRAPHIC0_DXY, set MIXER0_GRP0_DX to 32.
3) In MIXER_TVOUT_CFG, Change 3D one path mode to 3D two path AFTER 1 FRAME.

BUG=chrome-os-partner:12643 & chromium:225983
TEST:
1) Booted with HDMI Connectd to Sink that supports only 800x600
2) HDMI Unplug-plug scenarios
3) S2R by running powerd_dbus_suspend

Change-Id: Ic5952ff3982c4923eabb69febeabfeb445e7a79c
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Shirish S <s.shirish@samsung.com>
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47650
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Shirish S <shirish@chromium.org>

CHROMIUM: ARM: exynos: busfreq: Fix array-out-of-bound access.

In the 1st loop of
arch/arm/mach-exynos/busfreq_opp_exynos5.c:show_time_in_state, sprintf
accesses data->time_in_state[PPMU_MIF][i], where i ranges [0..6], but
time_in_state is defined as array[2][4]. Fixed by change time_in_state
definition.

BUG=None
TEST=Build successfully

Change-Id: I2d4cab59281509e33d34b55892f18635e8b7fa09
Signed-off-by: Han Shen <shenhan@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49266
Reviewed-by: Olof Johansson <olofj@chromium.org>

wireless-next: rtl8192c:dm: Properly initialize local array and set value.

GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c".  This patch adds
initialization to the variable and properly sets its value.

Signed-off-by: Han Shen (shenhan@google.com)
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit 7c8f0db0d024efda38976fc2acf7743f458e1d96)

Conflicts:
        drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c

TEST=Built using newest compiler.
BUG=None

Signed-off-by: Han Shen (shenhan@google.com)
Change-Id: Id7f48f33df1d5629ade21c67ede6960e73040e82
Reviewed-on: https://gerrit.chromium.org/gerrit/47279
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Han Shen <shenhan@google.com>
Commit-Queue: Han Shen <shenhan@google.com>

CHROMIUM: usb: ehci: Only sleep for post-resume handover if devices use persist

The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the companion controller can actually see it during its
own resume path.

However, if the device doesn't use persist, this is entirely
unnecessary. We might just as well ignore it and have the normal device
detection/reset/handoff code handle it asynchronously when it eventually
shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.

BUG=chromium:222484
TEST=Suspend/resume Snow with a USB keyboard plugged in, make sure
keyboard still works afterwards.

Has been sent upstream, chances for merge were looking good...

Change-Id: I3bc9a86e464a70231cfdd1b013ef0a0cb98eff09
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48945
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>

drm/exynos: Debounce gpio hotplug interrupts

Debounce the gpio (external) hotplug interrupts. This patch debounces
hotplug interrupts generated while the HDMI block is off. The reason
this is needed is that we get multiple (5) interrupts every time a
monitor is inserted which causes us to needlessly enable and disable the
IP block.

BUG=chromium:220033
TEST=Tested using an HDMI analyzer. Many hotplugs without any 20s freeze

Change-Id: I9c5d61364790f4110fc758a93fabac48b646b3fa
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49349
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

Fix display underruns on Pineview with 2048x1280 VGA display.

Higher dot clocks were working because pixel doubling was enabled.

Lower the apparently arbitrary threshold so it's enabled for 2048x1280.

Intel hasn't felt moved to document any of this, so this is purely empirical.

The original threshold was introduced here:
http://cgit.freedesktop.org/~anholt/xf86-video-intel/commit/?id=8fcf9a81179ee8577ddab5e904c58fbfd14cf59c

BUG=chromium:219562
TEST=All previously working U3011 modes + 2048x1280 work
Change-Id: I69f47b6ef292d65dc1a3ff6288c33eaa4c1cd894
Reviewed-on: https://gerrit.chromium.org/gerrit/49434
Reviewed-by: Stuart Abercrombie <sabercrombie@chromium.org>
Tested-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stuart Abercrombie <sabercrombie@chromium.org>

CHROMIUM: config: re-sync kernel config after dma-buf kds separation

Now, this is only set for exynos:
CONFIG_DMA_SHARED_BUFFER_USES_KDS=y

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:232913
TEST=compile kernel for x86 and arm and verify it still boots

Change-Id: I7f5d9471a7fde4dd01a02ce5f383ab931c47353f
Reviewed-on: https://gerrit.chromium.org/gerrit/48630
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: dma-buf/kds: allow KDS to be compiled out if dma-buf is enabled

The original KDS patches added CONFIG_DMA_SHARED_BUFFER_USES_KDS but
didn't use it to guard the kds integration into dma-bufs in a way
that would allow dma-buf to be built with KDS compiled without
requiring KDS.

Fix this by more carefully guarding the integration points, and not
unconditionally selecting KDS when dma-buf is enabled.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:232913
TEST=compile kernel for x86 and arm and verify it still boots

Change-Id: I878d1313ce6b43477fd6c87d394728283ad4f9e6
Reviewed-on: https://gerrit.chromium.org/gerrit/48608
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>

UPSTREAM: staging: gdm72xx: cancel work when driver unloads

cancel the work function at driver unload stage and remove
the function from the queue

Cc: Ben Chan <benchan@chromium.org>
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c0352cb71d3d573a33af92d320f29f1c79d71b8b)

Change-Id: I8c4e522270b4acad07d125398b1afe4a14810f16
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49427
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: staging/gdm72xx: Remove duplicated code in gdm_qos.c

The first branch of the if statement is ended with a return thus there
is no need for an else if, and thus we can move the duplicated code to
the top and use it for the other two branches.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d38529100d0f2e844df5f06d67dae8dd32086ec1)

Change-Id: I9ad27e507f0f66a821dd9c2327dc67cc69bc8a10
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49426
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: staging/gdm72xx: Remove unused variable in gdm_qos.c

len is never read after assignment, thus can be removed.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eb986df15c86b66a51f6e82f4706bc825444670b)

Change-Id: I23e845226e446fb1cbc8568949be0d956baf350b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49425
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: staging/gdm72xx: Include corresponding header file (fix sparse warning)

sdio_boot.c and netlink_k.c both have a corresponding header file with
their function prototypes but fail to include them, which leads to the
following sparse warnings:
sdio_boot.c:135:5: warning: symbol 'sdio_boot' was not declared. Should it be static?
netlink_k.c:89:13: warning: symbol 'netlink_init' was not declared. Should it be static?
netlink_k.c:109:6: warning: symbol 'netlink_exit' was not declared. Should it be static?
netlink_k.c:114:5: warning: symbol 'netlink_send' was not declared. Should it be static?

-> Add the include files and silence the warning

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a6000538e402ef2479a16ff789059c78a152be9d)

Change-Id: Id26144d3d78f9a0de1be70e5f3a2bed1fccae25f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49424
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: dts: spring: Explicitly disable unused LDOs

Some LDO's are enabled by default at poweron but unused in Spring.
This CL disables them explicitly.

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19067
TEST=manual
  ldo_base=0x5e
  for ldo in 4 5 11 13 17 ; do
    echo -n "LDO${ldo}: "
    i2cget -y -f 0 0x66 $(($ldo_base + $ldo))
  done

LDO4: 0x04
LDO5: 0x04
LDO11: 0x14
LDO13: 0x14
LDO17: 0x28
Note all bits <7:6> are zero'd

Change-Id: I9e8f6966a0a573f622f86cd07aeb7d61e495db1b
Reviewed-on: https://gerrit.chromium.org/gerrit/49718
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

CHROMIUM: md: dm-bootcache: reinitialize bio structure

The bootcache code does multiple large reads and was reusing the bio structure.
Some device drivers appear to leave some clutter in the bio structure.
Between large reads, the bootcache now frees and reallocates the bio structure.

BUG=chrome-os-partner:18830
TEST=POWER-ESC-F3 with USB stick, several times.
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I5b835b5f0606f6eb4116fc9719d96a48d0155f57
Reviewed-on: https://gerrit.chromium.org/gerrit/49121
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Paul Taysom <taysom@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>

CHROMIUM: add warning test to /proc/breakme

This is mainly for testing the Chrome OS warning collection
and analysis tools.

BUG=chromium:227080
TEST=manually tested

Change-Id: I0a99d2f87cf1e1354a0feaf3cd5386396d7da381
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49488
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: input: mouse - Fix trackpoint re-probe on resume.

During suspend, power may be cut to the trackpoint. If so, the
trackpoint will automatically begin its power-on diagnostics upon being
re-powered. If trackpoint_reconnect is called before the diagnostics
complete, the probe ID command will be lost, and reconnect will fail.
This will lead to re-probe, which takes several seconds on Stout due to
the trackpoint / trackpad pass-through design.

The fix here is to make a second attempt if the initial commands on
reconnect fail, which should give the trackpoint enough time to come out
of power-on diagnostics.

TEST=suspend/resume test for 3000 iterations without re-enumeration.
BUG=chromium:220389

Change-Id: I1ff8d3accdde86184864915d540b870ed33feee4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49228
Reviewed-by: Chung-yih Wang <cywang@chromium.org>

CHROMIUM: ath: Add ATH_DEFER_EEPROM_REGULATORY option

Add option to disable the internal regulatory mask
sourced from EEPROM data.  This does not affect CRDA
regulatory operation, but nevertheless this option
should not be used by default.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium:218911
TEST=Recompile with and without flag, ensure EEPROM
regulatory still works with this change disabled using
world regulatory EEPROM card an "iw reg set" command.

Change-Id: I20de00c7c6ea57124df1da8b052e573920579614
Reviewed-on: https://gerrit.chromium.org/gerrit/49176
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>

drm/exynos: Add 1024x768/1280x800 HDMI resolutions

This patch adds 1024x768 and 1280x800 HDMI resolutions by redistributing
vertical lines to the blanking period from the active area. The result
is that userspace is exposed resolutions which fit into the mixer's
scanning guidelines (720 lines), and the monitor thinks it's getting the
full monty. For example, 1024x768 looks like 1024x720 from userspace's
perspective, but 1024x768 from the monitor's perspective.

BUG=chromium:221411, chrome-os-partner:14238
TEST=Tested by hand with 1024x768

Change-Id: I6dcfe6260504e38aa604c5b19abc2bd716bbf729
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48830
Reviewed-by: Mark Hayter <mdhayter@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

google memconsole: use ioremap_cache()

The memconsole code was using ioremap() which defaults to using
an uncacheable mapping. When using PAT this creates a PAT entry
as uncached-minus. When a userspace program, such as cbmem,
wants to mmap() the memory area not using O_SYNC by way of /dev/mem
it creates a conflicting entry and fails. Correct this situation
by using ioreamp_cache() becaus the cbmem memconsole lives in memory
that is just reserved from the OS -- not in mmio space.

BUG=None
BRANCH=None
TEST=Tested on Pixel with new cbmem utlity. No errors.

Change-Id: Iff8a160205bf59e4c4d0e9508832901f8dbd1cde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48654

CHROMIUM: config: Disable USB persist by default

We had it this way before, this is just part of a patch series to move
from our hardcoded hack to the new upstream Kconfig method.

BUG=None
TEST=None

Change-Id: Id67bc7b618547f16a209dbf12c4e1f9ce7bde279
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49016
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>

UPSTREAM: usb: Make USB persist default configurable

Commit 9214d1d8 set the USB persist flag as a default for all devices.
This might be desirable for some distributions, but it certainly has its
trade-offs... most importantly, it can significantly increase system
resume time, because the kernel blocks on resuming (and sometimes
resetting) USB devices before it unfreezes userspace.

This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.

[edited the Kconfig help text a bit - gregkh]

Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4f48203881ce947a0cbd8ae7b1a1a1b04aaa3766)
Cherry picked from upstream's gregkh/usb.git/usb-next

Conflicts:
    drivers/usb/core/Kconfig (trivial merge with old deprecated configs)
    drivers/usb/core/quirks.c (renamed USB_QUIRK_RESET to the older
            USB_QUIRK_RESET_MORPHS)

BUG=None
TEST=None

Change-Id: Ib63d2ed955e2916598d5ecd2d75aab9260594368
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49015
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>

Revert "CHROMIUM: Disable USB persist system-wide by default."

This reverts commit c3d39c8b090f77d253ef70a6bc747e3bd095347c.

Turns out the Kconfig version of this change did get picked up by gregkh
upstream after all. So we can revert this and roll with the upstream
version instead.

BUG=None
TEST=None

Change-Id: I96f74c914c75bd3c9b8a7cde0d682de157ee3e10
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49014
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>

CHROMIUM: uvcvideo: Handle status_start while status_stop is in progress.

While usb_kill_urb is in progress, calls to usb_submit_urb will fail
with -EPERM (documented in Documentation/usb/URB.txt). The UVC driver
does not correctly handle this case -- there is no synchronization
between uvc_v4l2_open / uvc_status_start and uvc_v4l2_release /
uvc_status_stop.

This patch adds a retry / timeout when uvc_status_open / usb_submit_urb
returns -EPERM. This usually means that usb_kill_urb is in progress, and
we just need to wait a while.

BUG=chromium:226216
TEST=Manual. Repeat suspend / resume on Stout many times, verify that
open() on /dev/video0 never fails.

Change-Id: I8a69dab345a18c89e175bd916aa943edd080b6cc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48982
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

[media] v4l2: mem2mem: save irq flags correctly

<NO UPSTREAM MERGE REQUIRED>

Save flags correctly when taking spinlocks in v4l2_m2m_try_schedule.

BUG=None
TEST=local build, run on CrOS snow

Change-Id: I1705c3466dde52db7021fe1e79aef0bba2d68367
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48347
Reviewed-by: Pawel Osciak <posciak@chromium.org>

UPSTREAM: usb: dwc3: debugfs: fix regdump offset

As with dwc_readl/writel, the global registers are specified as
offsets starting from the beginning of the xHCI address space,
but the memory region pointed to by dwc->regs already maps to
the start of the global addresses. Fix by offsetting each of the
regs relative to DWC3_GLOBALS_REGS_START.

Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
(cherry picked from commit 1604c1e760119ab3fe9f71679ebaeb058d3d8ae1)
Cherry pick from Linus' tree, applied cleanly

BUG=chromium:229725
TEST='cat /sys/kernel/debug/dwc3.0/regdump' should not crash on Snow.

Change-Id: Ic58153b9c3f4135355094a5dc49ad0fabb2fcd25
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48554
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

BACKPORT: TPM: Retry SaveState command in suspend path

If the TPM has already been sent a SaveState command before the driver
is loaded it may have problems sending that same command again later.

This issue is seen with the Chromebook Pixel due to a firmware bug in
the legacy mode boot path which is sending the SaveState command
before booting the kernel.  More information is available at
http://crbug.com/203524

This change introduces a retry of the SaveState command in the suspend
path in order to work around this issue.  A future firmware update
should fix this but this is also a trivial workaround in the driver
that has no effect on systems that do not show this problem.

When this does happen the TPM responds with a non-fatal TPM_RETRY code
that is defined in the specification:

  The TPM is too busy to respond to the command immediately, but the
  command could be resubmitted at a later time.  The TPM MAY return
  TPM_RETRY for any command at any time.

It can take several seconds before the TPM will respond again.  I
measured a typical time between 3 and 4 seconds and the timeout is set
at a safe 7 seconds.  (note: upstream is 5 seconds right now)

It is also possible to reproduce this with commands via /dev/tpm0.
The bug linked above has a python script attached which can be used to
test for this problem.  I tested a variety of TPMs from Infineon,
Nuvoton, Atmel, and STMicro but was only able to reproduce this with
LPC and I2C TPMs from Infineon.

The TPM specification only loosely defines this behavior:

  TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
  The TPM MAY declare all preserved values invalid in response to any
  command other than TPM_Init.

  TCG PC Client BIOS Spec 1.21 section 8.3.1.
  After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
  commands before transitioning to S3 without issuing another
  TPM_SaveState command.

  TCG PC Client TIS 1.21, section 4. Power Management:
  The TPM_SaveState command allows a Static OS to indicate to the TPM
  that the platform may enter a low power state where the TPM will be
  required to enter into the D3 power state.  The use of the term "may"
  is significant in that there is no requirement for the platform to
  actually enter the low power state after sending the TPM_SaveState
  command.  The software may, in fact, send subsequent commands after
  sending the TPM_SaveState command.

BUG=chrome-os-partner:18686
TEST=originally tested on pixel for crbug.com/203524

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
(backported from commit 32d33b29ba077d6b45de35f2181e0a7411b162f4)

Change-Id: I023103b69e5253dc98b289c25853104a08f4787f
Reviewed-on: https://gerrit.chromium.org/gerrit/48812
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>

v4l2: dequeue buffers properly on VIDIOC_STREAMOFF

<UPSTREAM MERGE NOT REQUIRED>

Instead of just marking all buffers as dequeued on STREAMOFF, properly
dequeue them -- this will, most notably, make sure that any mapped
DMABUF buffers will be properly unmapped.

BUG=chromium:232121
TEST=local build, run on CrOS snow

Change-Id: Ide111378caa70cf603b3edec65b4dedd0f1e1ea0
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48346
Reviewed-by: Pawel Osciak <posciak@chromium.org>

CHROMIUM: mkbp: Optimize ghosting algorithm.

Previous algorithm was a bit conservative and complicating with
respect to identifying key ghosting.  This CL uses the bitops hamming
weight function (hweight8) to count the number of matching rows for
colM & colN.  If that number is > 1 ghosting is present.

Additionally it removes NULL keys and our one virtual keypress
KEY_BATTERY from consideration as these inputs are never physical
keypresses.

Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:18354
TEST=manual
1. using evtest I now see ctrl-U
2. escape sequence ctrl-U correctly display 'webpage source'
3. w/ #define DEBUG in mkbp.c no longer see below when ctrl-U pressed
   chromeos-ec-i2c 4-001e: ghost found ...

Change-Id: Ifc98b527c3ee4daffa9d8c726429fdd1b35970fa
Reviewed-on: https://gerrit.chromium.org/gerrit/48789
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

Revert "CHROMIUM: Strengthen ghosting algorithm."

This reverts commit 688c20f457b6111755cf1f9f1b1472693a4a4ed9.

Change-Id: Ifd0e81a8ffe58bc6c9ebe2eb01345f7f65e360a1
Reviewed-on: https://gerrit.chromium.org/gerrit/48788
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

Revert "WORKAROUND: mkbp: Remove KEY_BATTERY from valid keys."

This reverts commit 20dd2301234bc0f57018e4b51380e53f652ac30c.

This temporary workaround eliminated bug introduced by commit:
  688c20f CHROMIUM: Strengthen ghosting algorithm.

That CL introduced a bug where the virtual key, KEY_BATTERY, falsely
ghosted to a bunch of other key sequences.  That change is also being
reverted.

Change-Id: I6e8959595cba088e6a55d45311fbe9534f3c75f5
Reviewed-on: https://gerrit.chromium.org/gerrit/48787
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

WORKAROUND: mkbp: Remove KEY_BATTERY from valid keys.

  While previous ghosting fix:
    688c20f CHROMIUM: Strengthen ghosting algorithm.

  Did help rule out null keys it was thought it would also correctly
  identify 3 vs. 4 keypresses (sharing row/col) regardless of whether
  key was virtual (KEY_BATTERY) or real.  It does not however.

  This change migrates KEY_BATTERY to invalid key while algorithm is
  further refined.

BUG=chrome-os-partner:18814
TEST=manual
boot Spring plugged after an EC reset and see no ghosting issues for
sequences ctrl + u|w|n|t

Change-Id: I1038a18c353e84a52ad77e44e497c747d310addf
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48674
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: ALSA: hda: cirrus: Add pin configs for lumpy.

The SPDIF output pin on lumpy is not connected, but the lumpy BIOS
doesn't set the config for it correctly.

The only difference between the new verbs here and the verbs in BIOS is
to specify the SPDIF output is not connected.

BUG=chromium:233458
TEST=install new kernel on lumpy, and use "aplay -l" to verify the
"Cirrus Digital" device is gone.

Change-Id: Iab087a33f4fde84c16d73b7054663d051fba7391
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48610
Reviewed-by: Dylan Reid <dgreid@chromium.org>

CHROMIUM: drm/exynos: Remove panel_ops->commit

The explicit panel_ops->commit() functions are really just doing what
DPMS(On) should be doing.  In fact, hdmi_commit literally gets called
twice in the mode_set path: once in DPMS(On) and again in the explicitly
by exynos_drm_encoder_commit().

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=Sanity check LCD display
TEST=Sanity check HDMI attached monitor at Boot
TEST=Sanity check HDMI attached monitor hotplug 2 times
TEST=run_remote_tests.sh --board=daisy --remote=${IP} power_Resume/control$

Change-Id: I07ce63255d5d209b127babd24213f70e42131185
Reviewed-on: https://gerrit.chromium.org/gerrit/47755
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMIUM: signal: stop info leak via the tkill and the tgkill syscalls

This fixes a kernel memory contents leak via the tkill and tgkill syscalls
for compat processes.

This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field
when handling signals delivered from tkill.

The place of the infoleak:

int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
{
        ...
        put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
        ...
}

Signed-off-by: Emese Revfy <re.emese@gmail.com>
Reviewed-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
BUG=chromium:223444
TEST=link build, PoC fails to show leaks

[ sent to lkml: http://marc.info/?l=linux-kernel&m=136622640810847&w=2 ]
Change-Id: If7603776a2f5dc28dceef4034f80b6979d18ca80
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48390
Reviewed-by: Will Drewry <wad@chromium.org>

CHROMIUM: config: enable errata 798181

BUG=chromium:226280
TEST=none

Change-Id: Ifdfd073d93b02c3007233bdc91f11a2f7e861ceb
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48273
Reviewed-by: Doug Anderson <dianders@chromium.org>

BACKPORT: r8169: fix auto speed down issue

It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.

Check the link partner ability to determine which speed to set.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e2409d83434d77874b461b78af6a19cd6e6a1280)

BUG=chrome-os-partner:18211.
TEST=manual. Test ethernet plug/unplug, verify link status detection.

Change-Id: I3166710a102ab9c2aef6590717d500c02fca3cac
Reviewed-on: https://gerrit.chromium.org/gerrit/48361
Tested-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Bowgo Tsai <bowgotsai@chromium.org>