hid-logitech-wtp: Fixed bug which prevents TP from entering raw mode

The command ID has been fixed.

BUG=chromium:240850
TEST=manual test with T650

Change-Id: I5dc4dbf82a781404403bc460642f04d0b5c2ddaa
Signed-off-by: Dennis Kempin <denniskempin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51495
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
HID: multitouch: Add USBest Technology HID Touch Controller

Based on the kernel log

kernel: [104544.545947] input: USBest Technology SiS HID Touch Controller as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/input/input12
kernel: [104544.546425] hid-multitouch 0003:0457:1030.0005: input,hiddev0,hidraw3: USB HID v1.00 Mouse [USBest Technology SiS HID Touch Controller] on usb-0000:00:1d.0-1.4/input0

BUG=chromium:241565
TEST=I don't have the device with me to test.

Change-Id: Id1e1a35377631138f8d274c9bac9144e4751c08a
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51499
Reviewed-by: Dave Parker <dparker@chromium.org>
CHROMIUM: Disable runtime PM suspend for quirky xhci controllers.

If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).

Note that this change is only relevant when persist_enabled is not set
for USB devices.

BUG=chromium:239214
TEST=Manual. Verify on XHCI_RESET_ON_RESUME platform (Stout) that USB
controller doesn't go to runtime suspend and USB webcam continues to
function in Chrome.

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>

Change-Id: I89206cc1427d9a94d8e7ac912126d45c803dde3b
Reviewed-on: https://gerrit.chromium.org/gerrit/51378
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
CHROMIUM: Separate dark resume into its own sysfs attr group

This change separates the dark resume sysfs files into their own attribute
group. This way, we can add those sysfs files to only the devices that have a
driver that can make use of them. This also allows for adding the sysfs files to
devices whose drivers did not add the wakeup attribute group which the dark
resume sysfs files were part of before.

Dark resume functionality is also moved from drivers/base/power/main.c to its
own file.

BUG=chromium:226157
TEST=power_DarkResumeShutdownServer (has to be run in lab)

Change-Id: I916ca6208bf26dd5269ab288169f5d802996e3d9
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47287
Reviewed-by: Sameer Nanda <snanda@chromium.org>
CHROMIUM: Check dark resume state earlier

To prevent races with irq handlers for device irqs, check if the resume is a
dark resume before we enable device irqs in dpm_resume_noirq.

BUG=chromium:221857
TEST=power_DarkResumeShutdownServer (has to be run in lab)

Change-Id: I67e81995955a6e5dbc9d5fac0b06585c9ec5baf0
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47902
Reviewed-by: Sameer Nanda <snanda@chromium.org>
UPSTREAM: Don't disable hpet emulation on suspend

(This syncs up our early commit with the upstream version of the same).

There's a bug where rtc alarms are ignored after the rtc cmos suspends but
before the system finishes suspend. Since hpet emulation is disabled and it
still handles the interrupts, a wake event is never registered which is done
from the rtc layer. This reverts an earlier commit which disables hpet
emulation. To fix the problem mentioned in that commit, the hpet_rtc_timer_init
function is called directly on resume.

BUG=chromium:221857
TEST=suspend_stress_test and inserting delays in suspend path with an rtc alarm

Change-Id: I7969efd864b2d79802072e8167f764e680e3d2d3
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48836
CHROMIUM: drm/anx7808: DP Bandwidth setting.

Currently, we used the maximum DP bandwidth by default.  Now use the maximum
value allowed by the DP endpoint.

BUG=chrome-os-partner:19437
TEST=Plug in VGA dongle connected through to VGA monitor and see that
connection is established.

Change-Id: I5b53868a8082d0a8fec7e538d634bc48c54ed042
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51502
Reviewed-by: Sean Paul <seanpaul@chromium.org>
CHROMIUM: md: dm-bootcache: validate number of trace records

Added code to validate the number of trace records to prevent
unreasonable numbers that could overflow the calculations
for allocating memory for the trace buffer.

BUG=chromium:235953
TEST=POWER-ESC-F3 with USB stick, several times.
Signed-off-by: Paul Taysom <taysom@chromium.org>

Change-Id: Icd35d6aa367c967a8b6b7e21706d701b2e2ebafb
Reviewed-on: https://gerrit.chromium.org/gerrit/49556
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
Tested-by: Paul Taysom <taysom@chromium.org>
CHROMIUM: md: dm-bootcache: restricted trace records to a fraction of total memory

Added code restrict the total amount of memory the
trace records could take. Currently set at 10%.

BUG=chromium:235953
TEST=booted system with bootcache and made sure it came up.
Signed-off-by: Paul Taysom <taysom@chromium.org>

Change-Id: Ie5251602729fd593731b16fd8b9dfe34ab4e59a6
Reviewed-on: https://gerrit.chromium.org/gerrit/50891
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
CHROMIUM: rtc: cmos: Fix accidentally enabling rtc channel

During resume, we call hpet_rtc_timer_init after masking an irq bit in hpet.
This will cause the call to hpet_disable_rtc_channel to be done if RTC_AIE is
the only bit not masked.

BUG=chromium:242788
TEST=power_Resume

Change-Id: I761fcf6ed447d837778a923cb564de8a9f940187
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56157
CHROMIUM: tg3: Ensure boot code initialization complete before HW access

After resetting the device, the driver waits for a signature to be
updated to know that firmware has completed initialization. However, the
call to tg3_poll_fw() is being done too late and we're writing to the
GRC_MODE register before it has completely initialized, causing
contention with firmware.  This logic has existed since day one but is
causing PCIE link to go down randomly at startup on one platform once
every few hundred suspend/resume loops.

Move the tg3_poll_fw() up to before we write to the GRC_MODE register
after reset.

BUG=chrome-os-partner:18649
TEST=suspend/resume testing

Change-Id: Ica155976f32c8f42cbfc7df254ff8b120556f00c
Signed-off-by: Billy Tran <billy.tran@broadcom.com>
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56125
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
drm/exynos: Clean up subdrv->probe call

This patch just cleans up the subdrv->probe call by moving ret and a
useless comment.

BUG=None
TEST=Compiles

Change-Id: I4dda23a53318ec968ebb3b36ffc676193f6ba6dc
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49079
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: drm/exynos: grab a reference to the FB before waiting

Otherwise the FB could go away while we are waiting, and we are
completely oblivious to that.

BUG=chromium:241679
TEST=compiles, runs

Change-Id: I0c60da39f80e1bb507c42e7887d4f5d22dd81db5
Reviewed-on: https://gerrit.chromium.org/gerrit/55815
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: ASoC: max98095 - Enable DC blocking filter.

Enable the DC blocking filter on the record path.  This removes a
negative DC offset that can originate from the digital microphone.

BUG=none
TEST=arecord and open file in audacity check there isn't a DC offset.

Change-Id: I5744a33fc2bf704027fcefa5c8497b07b78fc819
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56345
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
CHROMIUM: HID: usbhid: ignore Jabra speakerphones HID interface

Add a quirk to ignore Jabra speakerphone 410 and 510 devices HID
interface.
On those devices, the USB audio interface is working nicely,
but the HID interface is not working with the kernel usbhid driver,
and it requires a specific userspace program.
We could unbind it from userspace but just attaching the usbhid driver has
sometimes nasty effects:
either confusing the device state machine or triggering a storm of volume key
events making eventual sound UI blinking like crazy.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=none
TEST=on Link, connect a Jabra 410 device and check that the usbhid driver
is not attached by looking at /sys/bus/usb/drivers/usbhid/

Change-Id: Icc1471a6c1f1b88474fad99352d44020a7b4f251
Reviewed-on: https://gerrit.chromium.org/gerrit/56264
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Revert "Add debugging to trace the loss of hidden ssid"

This reverts commit 077c4039518a9115a9b0bf5d063c37cc72773c0f.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:18057
TEST=manual,
Boot kernel ... no longer log messages in console about SSID.

Change-Id: I758284165ad8cad4eaa4837aef71b18554d9ab56
Reviewed-on: https://gerrit.chromium.org/gerrit/45428
Commit-Queue: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-by: Ashok Nagarajan <asnagarajan@chromium.org>
Tested-by: Ashok Nagarajan <asnagarajan@chromium.org>
UPSTREAM: rtc: add ability to push out an existing wakealarm using sysfs

This adds the ability for the rtc sysfs code to handle += characters at
the beginning of a wakealarm setting string.  This will allow the user to
attempt to push out an existing wakealarm by a provided amount.

In the case that the += characters are provided but the alarm is not
active -EINVAL is returned.

his is useful, at least for my purposes in suspend/resume testing.  The
basic test goes something like:

1. Set a wake alarm from userspace 5 seconds in the future

2. Start the suspend process (echo mem > /sys/power/state)

3. After ~2.5 seconds if userspace is still running (using another
   thread to check this), move the wake alarm 5 more seconds

If the "move" involves an unset of the wakealarm then there's a period
   of time where the system is midway through suspending but has no wake
   alarm.  It will get stuck.

We'd rather not remove the "move" since the idea is to avoid a
cancelled suspend when the alarm fires _during_ suspend.  It is
difficult for the test to tell the difference between a suspend that
was cancelled because the alarm fired too early and a suspend that was

This was cherry-picked from the kernel-next.git akpm branch.

BUG=chromium:239217
TEST=Manual, run suspend/wake testing on DUT, and some test commands on
the wakealarm file:
localhost rtc0 # cat since_epoch
1368751934
localhost rtc0 # echo 1368760000 > wakealarm
localhost rtc0 # cat wakealarm
1368760000
localhost rtc0 # echo +=5 > wakealarm
localhost rtc0 # cat wakealarm
1368760005
localhost rtc0 # echo 0 > wakealarm
localhost rtc0 # cat wakealarm
localhost rtc0 # echo +=5 > wakealarm
-bash: echo: write error: Invalid argument

Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Doug Anderson <dianders@chromium.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 19063741561c13df3d3d09138327c7f6f4256ce7)

Change-Id: Ib456d8823f1c95eeae4397fe54325a1e655f8a5b
Reviewed-on: https://gerrit.chromium.org/gerrit/56416
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
kbase: Don't crash when we have no context

Other places protect calls to kbase_device_trace_register_access with
if (kctx && kctx->jctx.tb)
So let's do the same here (although the kctx->jctx.tb isn't required
since it is tested again in kbase_device_trace_register_access.

BUG=chrome-os-partner:19593
TEST=can't repro, but compiles and runs

Change-Id: I00b37fa1ffe0775d12d84b5a4a325b4f4e198efa
Reviewed-on: https://gerrit.chromium.org/gerrit/55814
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: fs: ecryptfs: msync doesn't sync data

When msync is called on a memory mapped file, that
data is not flushed to the disk.

In Linux, msync calls fsync for the file. For ecryptfs,
fsync just calls the lower level file system's fsync.
Changed the ecryptfs fsync code to call filemap_write_and_wait
before calling the lower level fsync.

BUG=chromium:239536
TEST=platform_SyncCrash
Signed-off-by: Paul Taysom <taysom@chromium.org>

Change-Id: I05b31c4ba2f7b15371fcbb09dd06a37a8599cad6
Reviewed-on: https://gerrit.chromium.org/gerrit/56394
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Thieu Le <thieule@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
CHROMIUM: drm/exynos: fb: hold struct_mutex when calling cleanup

Caller of drm_framebuffer_cleanup() must hold mode config lock.
The originally caller of exynos_drm_fb_release() may have been holding the
lock, but not the worker thread on which exynos_drm_fb_release_work_fn()
is executed.

Since we just grabbed the lock to cleanup fb, let's keep holding it
while unref'ing the fb's gems.

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

BUG=none
TEST=sanity check UI; login/logout; VT-switch

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