CHROMIUM: ARM: dts: blaze: clock GEN2 I2C at 400KHz

Blaze shall be able to clock trackpad/touchpad I2C bus at 400KHz.
Change the dt setting accordingly to improve the performance.

BUG=chrome-os-partner:29023
TEST=emerged blaze kernel, captured the waveform from gen2 i2c bus,
scl running at ~400Kz and the waveform looks good.

Change-Id: I381627cca42e66406a90518a4fdac3e440f0c928
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/200720
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM : DPTF update to v8.0.10001

Fixes:
	Added "extern C" declarations for C++ SDK
	Added pragma pack code for data structures
	Removed SYSFS instrumentation

Other:
	Code clean-up
	Refactored event handling code
	Future policy support

BUG=chromium:360249
TEST=Manually tested
CQ-DEPEND=CL:200631

Change-Id: Ib2511e6fc17623479f1f40b13d8069290f92ae0e
Signed-off-by: Brad Geltz <brad.geltz@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/200633
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
CHROMIUM: mmc: tegra: use HW timeout corresponding to SW value

tegra_sdhci_issue_tuning_cmd() currently programs the maximum available
timeout value, which corresponds to about 650ms at 200Mhz, into
SDHCI_TIMEOUT_CONTROL, but we only poll SDHCI_INT_STATUS for 5ms before
giving up and resetting the controller.  Writes to SDHCI_SOFTWARE_RESET,
however, may stall until in-progress command has timed out, causing the
entire system to hang for that time.  Removing an SD card during tuning,
for example, could cause the entire system to hang for 100s of ms.
Instead of using the maximum timeout value, choose one which is about
equal to what we'll wait for in software before timing out and resetting.

BUG=chrome-os-partner:28547
TEST=Build and boot on Big

Change-Id: Ib30a9b2cd6cb114a8e74f83bf59513d5bf2dd763
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201158
Reviewed-by: Christopher Freeman <cfreeman@nvidia.com>
Tested-by: Christopher Freeman <cfreeman@nvidia.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: atmel_mxt_ts: Add sysfs for requesting T19 status

T19 status can be used to differentiate the touch sensors
that are attached to the touch controller. This CL adds a
sysfs entry for
1) when written to, it requests the touch controller to report the T19 status
2) when read, it returns the latest T19 status

BUG=chrome-os-partner:29065
TEST=tested on clapper that the T19 status can be read as 0x3C, which represents
the correct touch sensor.

Change-Id: I46d9793da242b07aa03b4cb6b1eaf538319b097b
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200814
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
UPSTREAM: mwifiex: fix PCIe hs_cfg cancel cmd timeout

For pcie8897, the hs_cfg cancel command (0xe5) times out when host
comes out of suspend. This is caused by an incompleted host sleep
handshake between driver and firmware.

Like SDIO interface, PCIe also needs to go through firmware power
save events to complete the handshake for host sleep configuration.
Only USB interface doesn't require power save events for hs_cfg.

Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>

BUG=chrome-os-partner:27663
TEST=suspend_stress_test

Change-Id: Ifbcdc59bbd69b9b9d3f06bbe19b5195b3c8da03d
Reviewed-on: https://chromium-review.googlesource.com/200810
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: n_tty: Fix n_tty_write crash when echoing in raw mode

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG=chromium:371214
TEST=nyan build & boot

Change-Id: I2ba8ccf646f2e0efa7bba1f0525b9f28a1c02bca
(cherry picked from upstream commit 4291086b1f081b869c6d79e5b7441633dc3ace00)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200625
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CHROMIUM: video: tegra: host: Do not dump channel if error

Do not dump channel state if the channel could not be initialized.

BUG=chrome-os-partner:29063
TEST=visit
https://www.khronos.org/registry/webgl/conformance-suites/1.0.0/extra/lots-of-polys-example.html
and let it run, see if it crashes the system

Change-Id: Ib1d8d0ccad0eb1254584e3fa6093c66921f36688
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/201071
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: config: enable Wacom tablet driver

BUG=chromium:194865
TEST=manually tested; with this patch, wacom tablet can work as a mouse device.

Change-Id: Icea3867887dea07cb15a9dc0ae7730fc3747d0b5
Tested-by: Hung-ying Tyan <tyanh@chromium.org>
Signed-off-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201207
Reviewed-by: Hung-ying Tyan <tyanh@chromium.org>
CHROMIUM: drm/i915/vlv: Fix BLM_PWM_ENABLE check in pwm invariant

Misplaced paren causing test to always fail.

BUG=chrome-os-partner:27096,chrome-os-partner:28914
TEST=Manual: Check that the screen immediately goes black at
minimum brightness.

Change-Id: If9d813ab4ef8cfd9c90f2183f1bb674172bdffe9
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/200809
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
UPSTREAM: sched: Remove redundant update_runtime notifier

migration_call() will do all the things that update_runtime() does.
So let's remove it.

Furthermore, there is potential risk that the current code will catch
BUG_ON at line 689 of rt.c when do cpu hotplug while there are realtime
threads running because of enabling runtime twice while the rt_runtime
may already changed.

Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1365685499-26515-1-git-send-email-zhangwm@marvell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit c5405a495e88d93cf9b4f4cc91507c7f4afcb901)

BUG=chrome-os-partner:29119
TEST=build and boot on nyan

Change-Id: I6809cb44998269e44458a6443f086f5bc05edd07
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201388
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: input: elants_i2c driver fixes from 3.8

CHROMIUM: input: elants_i2c driver bug fix

This patch fixes a bug from patch set 11 of CL I9dd69608792767e0794a80833d04b1f34957fc8b.
(CL Link https://chromium-review.googlesource.com/#/c/193588)

This bug arises from moving a if statement into a for loop.

Original:

if (finger_stat == 0)
	break;

After:

for (...; ... && i < num_fingers; ...)

It makes data parsing behavior and finger report uncorrect.
If a finger data is not with finger ID 0, parsing process will not get the correct data.
The scenario is as following:
1. One finger on touchscreen (with finger ID 0) and drawing
2. Add another finger on touchscreen (with finger ID 1), now drawing with two fingers on touchscreen.
3. The first finger (with finger ID 0) leaves touchscreen => parsing behavior is uncorrect and drawing breaks.

BUG=None
TEST=on Elan touchscreen, boot and touchscreen works.

Original-change-Id: Ie1b62bfdfc2901a0acec7958d7436052fa15f8b8
Originally-signed-off-by: Liang Po-Hsiang <iamshyang@gmail.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/201057
Originally-reviewed-by: Charles Mooney <charliemooney@chromium.org>
Originally-tested-by: Charles Mooney <charliemooney@chromium.org>
Originally-Commit-Queue: Charles Mooney <charliemooney@chromium.org>

CHROMIUM: input: elants_i2c version sysfs entries

This CL divides 2-byte test version into test version (1-byte) and solution version (1-byte).

BUG=None
TEST=on Elan touchscreen, boot and touchscreen works.

Original-change-Id: Ic3eff74de5aac64884fb113e40af36410796b3ba
Originally-signed-off-by: Liang Po-Hsiang <iamshyang@gmail.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/201048
Originally-reviewed-by: Charles Mooney <charliemooney@chromium.org>
Originally-tested-by: Charles Mooney <charliemooney@chromium.org>
Originally-Commit-Queue: Charles Mooney <charliemooney@chromium.org>

CHROMIUM: input: elants_i2c driver bug fix (update)

This patch is based on CL Ie1b62bfdfc2901a0acec7958d7436052fa15f8b8.

A new operation is added to reduce unnecessary computation if num_fingers becomes 0 in elan_mt_event().

BUG=None
TEST=on Elan touchscreen, boot and touchscreen works.

Original-change-Id: If9133bdfdba53e6c19ae243a4605915d801130f9
Originally-signed-off-by: Liang Po-Hsiang <iamshyang@gmail.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/201163
Originally-reviewed-by: Charles Mooney <charliemooney@chromium.org>
Originally-commit-Queue: Charles Mooney <charliemooney@chromium.org>
Originally-tested-by: Charles Mooney <charliemooney@chromium.org>

Change-Id: Iedea01dcf5cf33c8aa48ebad92ca6430db7ea9bb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201394
CHROMIUM: sdhci: Allow SHDCI Register Dump on Error

SDHCI driver would call sdhci_dumpregs() in case of many error
conditions. But pr_debug will not output anything unless changes
are made in both global kernel config and local file, which seems
to be excessive. Simply change to pr_err to get dump into dmesg.
This will save a lot of time by getting useful logs in case of
mmc error.

BUG=chrome-os-partner:29021
TEST=Manual: Check no extra reg dump in case of normal operation.

Change-Id: Iac0e403ddabdd72a4cada521b4b4309e13355915
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201384
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
UPSTREAM: cfg80211/mac80211: ignore signal if the frame was heard on wrong channel

On 2.4Ghz band, the channels overlap since the delta
between different channels is 5Mhz while the width of the
receiver is 20Mhz (at least).

This means that we can hear beacons or probe responses from
adjacent channels. These frames will have a significant
lower RSSI which will feed all kinds of logic with inaccurate
data. An obvious example is the roaming algorithm that will
think our AP is getting weak and will try to move to another
AP.

In order to avoid this, update the signal only if the frame
has been heard on the same channel as the one advertised by
the AP in its DS / HT IEs.
We refrain from updating the values only if the AP is
already in the BSS list so that we will still have a valid
(but inaccurate) value if the AP was heard on an adjacent
channel only.

To achieve this, stop taking the channel from DS / HT IEs
in mac80211. The DS / HT IEs is taken into account to
discard the frame if it was received on a disabled channel.
This can happen due to the same phenomenon: the frame is
sent on channel 12, but heard on channel 11 while channel
12 can be disabled on certain devices. Since this check
is done in cfg80211, stop even checking this in mac80211.

Cherry-picked from commit 3afc2167f60a3 upstream.

BUG=scanning may produce cross-channel RX with invalid RSSI
TEST=scan and check that RSSI doesn't wildly fluctuate

Change-Id: Id913e83de08436f879e6b259965542173f362606
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove unused rx_freq variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201571
Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: cfg80211: allow RSSI compensation

Channels in 2.4GHz band overlap, this means that if we
send a probe request on channel 1 and then move to channel
2, we will hear the probe response on channel 2. In this
case, the RSSI will be lower than if we had heard it on
the channel on which it was sent (1 in this case).

The firmware / low level driver can parse the channel in
the DS IE or HT IE and compensate the RSSI so that it will
still have a valid value even if we heard the frame on an
adjacent channel. This can be done up to a certain offset.

Add this offset as a configuration for the low level driver.
A low level driver that can compensate the low RSSI in this
case should assign the maximal offset for which the RSSI
value is still valid.

Cherry-picked from commit 67af9811539be upstream.

Change-Id: Ib4c844e171fea3f822a203eb36f4532e0d3889c8
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201572
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: ARM: dts: nyan: Enable internal pull-up of GPIO_PK4

Internal pull-down of GPIO_PK4 causes incorrect voltage(1V) of TS_RESET_L.

BUG=chrome-os-partner:29177
TEST=Built and booted Blaze. TS_RESET_L is 1.8V in CPU side.

Change-Id: Ib562f7ddb71b8321dc8d7b52aa7bde09138465b2
Signed-off-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/201581
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
BACKPORT: drm: Add panel support

Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.

Signed-off-by: Thierry Reding <treding@nvidia.com>
(cherry picked from commit aead40ea0b53a0e28d34adf7bb923ecb2968c04a)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

Conflicts:
	drivers/gpu/drm/Kconfig

BUG=chromium:375360
TEST=builds for a nyan target

Change-Id: I22e16932b9d61067e5b61257d303c11dcb6a4b5f
Reviewed-on: https://chromium-review.googlesource.com/200595
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: drm/panel: Add simple panel support

Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.

Support is added for two panels: An AU Optronics 10.1" WSVGA and a
Chunghwa Picture Tubes 10.1" WXGA panel.

Signed-off-by: Thierry Reding <treding@nvidia.com>
(cherry picked from commit 280921de7241ee63184c8baa89ec3fe0122dedb3)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
[marcheu: add include to make it compile]

BUG=chromium:375360
TEST=builds for a nyan target

Change-Id: Id11b1a2aee4164ddbcf8742ced420994dff6cd28
Reviewed-on: https://chromium-review.googlesource.com/200596
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: drm/panel: Add support for Panasonic VVX10F004B0

The Panasonic VVX10F004B0 is a 10.1" WUXGA TFT LCD panel connected using
four DSI lanes.

Signed-off-by: Thierry Reding <treding@nvidia.com>
(cherry picked from commit 210fcd9d9cf1ad6ebfae3b46b457e602c8f8cdc2)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

BUG=chromium:375360
TEST=builds for a nyan target

Change-Id: I3e568e552930bbb2d5fe3428da076522089cd28c
Reviewed-on: https://chromium-review.googlesource.com/200597
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: drm/panel: Add support for Samsung LTN101NT05 panel

The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
driver.

Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
(cherry picked from commit 6d54e3d275de861c0290c85fec8c0ed6deaf6ad5)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

BUG=chromium:375360
TEST=builds for a nyan target

Change-Id: Icdb4866674443098ac96aa3f20f34a8b1dca2030
Reviewed-on: https://chromium-review.googlesource.com/200598
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: drm/panel: Add support for Chunghwa CLAA101WA01A panel

The Chunghwa CLAA101WA01A is a 10.1" 1366x768 panel, which can be
supported by the simple panel driver.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
(cherry picked from commit 4c9307577ef686e041d1525047ffdebfc465e329)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

BUG=chromium:375360
TEST=builds for a nyan target

Change-Id: Ib2cf4ffb3fe2642fe54598542ecdec0abf740941
Reviewed-on: https://chromium-review.googlesource.com/200599
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>