git.cascardo.eti.br Git - cascardo/linux.git/log

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>

CHROMIUM: config: re-sync kernel config

TBR=sonnyrao,dianders
BUG=none

Change-Id: I60be015dc64c639ef5715b256a3d55298cdafdd7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48272
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>

BACKPORT: ASoC: max98088: Fix logging of hardware revision.

The hardware revision of the codec is based at 0x40. Subtract that
before convering to ASCII. The same as it is done for 98095.

BUG=chrome-os-partner:18551
TEST=check dmesg and see revision = 'A'

Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit 98682063549bedd6e2d2b6b7222f150c6fbce68c)

Change-Id: I942d832bceb9c42370a0dd8364040b157d7ffd77
Reviewed-on: https://gerrit.chromium.org/gerrit/48462
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>

Raises the limit of number of decodes in mfc_dec.

BUG=chromium:221501
TEST=Run a modified video_decode_accelerator_unittest on daisy and link

Signed-off-by: Owen Lin <owenlin@chromium.org>
Change-Id: If047c5aee937c51cbe57bda4a1b5feca975e9b12
Reviewed-on: https://gerrit.chromium.org/gerrit/48215
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: Owen Lin <owenlin@chromium.org>
Commit-Queue: Owen Lin <owenlin@chromium.org>

CHROMIIM: ALSA: hda/ca0132 - Add AEC level control.

When tuning controls are enabled, export a control to tune the level
of the echo canceller running on the ca0132 DSP.

Change-Id: Ie7717e88c8f5f10dc159f978f8fa5bff77e2a709
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48166
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>

[media] s5p-mfc: Fix frame skip bug

The issue was seen in VP8 decoding where the last frame was
skipped by the driver. This patch gets the correct frame_type value
to fix the bug.

Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
BUG=220645

Change-Id: I1784803e3b692afa22d4aa8c966c9f325a20aafd
Reviewed-on: https://gerrit.chromium.org/gerrit/44437
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>

CHROMIUM: Strengthen ghosting algorithm.

Previous commit added the interpretation of the virtual keystroke from
EC's MKBP, KEY_BATTERY, to allow EC to signal change in USB power for
Spring.

While the edit did address suppressing the input event the virtual
keystroke still plays into the ghosting calculation. This exposed
that the ghosting algorithm was too conservative as ctrl + u +
KEY_BATTERY triggered ghosting logic.

New algorithm correctly identifies all ghosting (3 or more) keystrokes
by factoring in whether the ghost key is valid.

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 at: r7 c6, pressed 2, teeth 0x4

Change-Id: I693bee2d0e54081c267f449f4b2c7f20a20749ff
Reviewed-on: https://gerrit.chromium.org/gerrit/46585
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

CHROMIUM: chromeos_laptop: Add MODULE_DEVICE_TABLE

If chromeos_laptop is built as a module, this will register
this driver as handling the various systems by dmi match,
so input devices, light sensors, and keyboard backlight are
still autoloaded on boot.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:38363
TEST=Modify chromeos/config/x86_64/common.config to set
CONFIG_CHROMEOS_LAPTOP=m
build, load this kernel and modules onto Lumpy.
Check that on boot, trackpad works without modprobing
for chromeos_laptop.

Change-Id: Ib0a8f2b1228fc208e17c716d545818ab8b823952
Reviewed-on: https://gerrit.chromium.org/gerrit/42269
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>

CHROMIUM: drm/exynos: hdmi: remove unused enabled variable

It is set but never checked.

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

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

CHROMIUM: drm/exynos: Always DPMS Off in encoder prepare and train dp link in DPMS On

In drm_crtc_helper_set_mode(), the basic sequence for encoders and crtcs
is:
->prepare()
->mode_set()
->commit()

For other drm drivers, .prepare does dpms(Off), and .commit does dpms(On).
Thus, the intention is for the .mode_set() callback is supposed to operate properly
in the dpms(Off) state.

For some reason, exynos was not doing dpms(Off) in .prepare, but it was
doing the dpms(On) in .commit, before calling an explicit
panel_ops->commit().

However, the dpms(On) in encoder .commit() never actually does anything,
since the .dpms routines call power on/off routines that are smart and
silently ignore requests that don't change the power state.
In particular, this dpms(On) wasn't able to actually commit changes,
such as enabling video and training the DP link.  Instead, we were
essentially relying on a explicit call to panel_ops->commit() in
encoder->commit() to do the commit.

Also, this means that when exynos_drm_encoder_mode_set calls
panel_ops->set_mode(), the current dpms/power state is whatever it was
before the call to drm_crtc_helper_set_mode().  This is almost always
DPMS(On).

DP link training uses the AUX channel which is only available when
DPMS(On).  A recent change to the dp driver to move link training to the
dp panel_ops->mode_set() seemed to work because, as noted above, we are
almost always in DPMS(On) for DP when we do mode_sets.

There is, however, one exception.  It is possible for userspace to explicit
turn DPMS(Off) the DP pipe.  To save power, for instance.  If this is
followed by a suspend/resume cycle, the resume path, will end up
calling DP mode_set() with dpms(Off).  This causes a soft lockup since the
AUX channel is not enabled when we try to do link training.

Instead, we just always do DPMS(Off) in .prepare(), get rid of the
explicit DP mode_set(), and let the encoder .commit call our DPMS(On)
which will train the link.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=(1) On daisy:
  set_short_powerd_timeouts ; echo 1 > /var/lib/power_manager/disable_idle_suspend
  wait ~20 seconds for powerd to turn off the LCD
  ./run_remote_tests.sh --board=daisy --remote=$IP power_Resume/control$
TEST=(2) Same as (1) but with HDMI monitor attached too
  => In this case powerd will switch to "presentation mode", so the turn
   LCD off time is ~45 seconds (and it takes two timeouts).
TEST=(3) suspend_stress_test   should survive even after LCD powers off

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

CHROMIUM: config: disable OABI support for exynos platforms

We've never shipped a device with userland code using OABI afaik, so
this is enabling code paths that is purely bloat. Disable it like we
have for all other arm platforms.

BUG=None
TEST=`emerge-daisy chromeos-kernel` works and doesn't have OABI enabled
Change-Id: Ie8a67b3db7faba3ac430e1de678e60b1fba1ffb5
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47911
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: drm/i915: repin bound framebuffers on resume

During suspend/resume all fences are reset, including their pin
count which is reset to 0. However a framebuffer can be bound across
suspend/resume, which means that after the buffer is unbound on
resume, the pin count for the buffer will be negative. Since the
fence pin count is now negative when available and zero when in use,
the buffer's fence will get recycled when the fence is in use which
is the opposite of what we want. The adverse effect is that since the
fence is recycled the tiling mode goes away while the buffer is being
displayed and we get lines/screens of garbage.

To fix this, we reallocate and repin the fences for all bound fbs on
resume, which ensures the pin count is right.

BUG=chromium:219172,chromium:225056
TEST=by hand, suspend/resume on alex, the artifacts are gone

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Change-Id: I9113078b0eb56e671dcca8dc9557a0c0c37f12e0
Reviewed-on: https://gerrit.chromium.org/gerrit/47933

CHROMIUM: config: turn off KDS and dma-buf on x86 systems

This is only required for Exynos based systems and makes no sense on
x86. This should save some memory.

BUG=none
TEST=kernel builds, boots on lumpy

Change-Id: I929f4205c2c050dab070311e577b88d8c2e1a7fe
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47784
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: config: disable rfkill

We don't use rfkill in ChromeOS.

The rfkill_poll causes 1 wakeup / 5 seconds / per device.

BUG=chromium:227114
TEST=More details in the bug.
TEST=But I verified that wifi still works and verified that wakeups are reduced.

Change-Id: I92aa7fe4e0dbf806fb63ead7f3ba883f79a1a213
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47808
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>

CHROMEOS: HACK: Work around bluetooth kernel panic.

This patch is originally from Doron Keren <doronkeren@ti.com>
http://www.spinics.net/lists/linux-bluetooth/msg15564.html . Original
description:

The patch fixes kernel panic which is due to race condition
between the setup of incomming connection and clean-up of the
dead one. Observed in the following case: attached HID device
disconnects unexpectedly (without performing ACL disconnect ),
the device tries to connect again before the ACL link time-out
fires, this translates to the HCI_DISCONNECT, HCI_CONNECT_REQ
events on the same handle, since HCI_DISCONNECT trigers the clean
up of the HID device and handled in different context, the
linking/unlinking connection object to sysfs, may mess up.

BUG=chromium:228937

TEST=The following used to cause a panic reliably, but now doesn't:
- have Apple Magic Trackpad connected and working
- sleep/wake computer
- immediately click/rub fingers on trackpad

Change-Id: I63e0e37afe572641d7bda593887d2e3269043b5a
Signed-off-by: Ilia Kolominsky <iliak@ti.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47653
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>

Adjust the MIF ASV logic to set the voltage to either ASV group

In the case the U-Boot sets the MIF voltage to 1.05v we need to set the
MIF voltage to the 1.00v if the MIF ASV group allows for it. In this case
we can now handle either MIF ASV voltage setting used by U-Boot.

BUG=chrome-os-partner:16895
TEST=Manual, run new kernel on DUT, verify MIF voltage.

Change-Id: I589844034889f0e9ddd55a62226dd4963a4d0eb4
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47757

CHROMIUM: md: dm-verity fixed setting error_behavior

Need to be able to set the error behavior from either the device table
or from the linux command line.

The code only handled setting from the linux command line which
broke the platform_DMVetiryCorruption test. This was not noticed
earlier because of another bug in error handling that was just
recently was fixed which exposed this problem.

Now the code defaults to the command line but overrides from
the device table.

BUG=chromium:229621
TEST=platform_DMVerityCorruption
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I32a516deb2bd564b599e73177e479cddec789dfb
Reviewed-on: https://gerrit.chromium.org/gerrit/47744
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>

BACKPORT: arm: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:

1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
return code already).

The switch_mm() code includes a DMB operation since the IPI is only sent
to CPUs running the same ASID.

BUG=chromium:226280
TEST=There's unfortunately no simple test to trigger this bug, since it
normally manifests vaguely by random crashes or bad data later during
runtime. General testing to make sure it doesn't add new problems (i.e,
BVT, regression suites) is the best approach, followed by observations
of crash rates from the field.

Change-Id: I8fa68bdac9594a90d29079244efa93750f4319e3
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47427
Reviewed-by: Doug Anderson <dianders@chromium.org>

Revert "UPSTREAM: ARM: Remove current_mm per-cpu variable"

This originally removed some not-needed code, but the recent A15 errata
workaround actually needs current_mm still around. So for bring this
code back for that reason.

This reverts commit 696cfa01f12ec85ac7122eb57d77c8598f79ff71.

BUG=chromium:226280
TEST=build kernel for daisy

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

mwifiex: remove redundant initialization for bss_descriptor

Initialization of bss_descriptor is unnecessary as the entire
structure will be overwritten by a memcpy.

BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.

Change-Id: I4e8cecbf862b75f94fa717007111d0d9f9c0a2e3
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47690
Reviewed-by: Doug Anderson <dianders@chromium.org>

mwifiex: fix use-after-free in beacon_ie processing

beacon_ie buffer is allocated in mwifiex_fill_new_bss_desc()
and the buffer pointer is saved in bss_desc->beacon_buf.

beacon_ie is freed before the function returns. However,
bss_desc->beacon_buf is still being accessed afterwards.

Fix it by allocating and freeing the beacon_ie buffer in
caller's scope.

BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.

Change-Id: If6ba90dc3a6d6890a4c891a0c4ab06d46f8cdcc9
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47621
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>

Add fallback power config values for Atmel T7

On suspend the atmel driver backs up the power configuration (T7) so
that it can restore it later on resume.  If the i2c transaction fails
when it's trying to read the current T7 config it sets a flag saying
that it was unable to back up the config, and then won't try to restore
it when the machine resumes.

A problem occurs if the i2c transaction to read the current config to
back it up on suspend fails, but the driver is still able to turn off
the touchpad.  Then on resume, it sees that it had failed to backup the
old values and never restores the T7 object.  As a result the
touchscreen/pad never wakes up.

Suspend:
1) Read current T7 config and back it up
2) Overwrite current config with suspend config
Resume
3) restore value stored in step 1

So if step 1 fails, but step 2 succedes we run into a dead touch device
on resume.  Reboot fixes everything, however.

This patch adds in some default values in the event that a failed backup
config is detected and makes sure the device actually gets turned on no
matter what on resume.

BUG=chrome-os-partner:17621
TEST=manually tested on Link

Change-Id: I325efae0eb2d801d07898ad29a09e3162e5b79e5
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47564
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMIUM: ALSA: hda/realtek - Check mic jack state when headphone jack state changes.

Usually the mic jack state changes will generate an unsol mic event,
and we can do auto-mic-switching at that time. But if the mic jack state
is gated by the headphone jack state, there may be no unsol mic event,
and we need to do auto-mic-switching in the unsol headphone event handler.

BUG=chromium:221938
TEST=plug/unplug 3.5mm headset and observe the capture source is switched correctly.
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: If057cc20b951fff05af1d6842cbc8e197a93a3f3
Reviewed-on: https://gerrit.chromium.org/gerrit/47231

CHROMIUM: md: dm-verity: error handling for bad block

In the legacy version of dm-verity, verity_error handled
many different errors. Now it only has to handle bad
hash errors. Simplified to the code to handle only that
case.

BUG=chromium:222545
TEST=./run_remote_tests.sh --board=$B --remote=$IP platform_CorruptRootfs/control

Change-Id: Iaef19a17bd46429cae3589096a8b21ea2d6b70b7
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46652

CHROMIUM: md: dm-verity: call to verity_error missing

The code path going through verity_work, was not calling
verity_error. This meant invalid block errors were not
being passed to the verity-chromeos error handler.

BUG=chromium:222545
TEST=manually corrupt root file system, reboot

Change-Id: I1f1c81feccc6ca5654dc81de3edfc97f240bea01
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46376
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>

TEMP: uvcvideo: Choose first (not last) of equal-sized alt settings

The LiteOn camera built into Spring boards has a weird bug: it reports
three alternate settings on its USB interface that all have the same
transfer size. Linux arbitrarily chooses the last of them, which seems
to work with EHCI but not with XHCI host controllers for reasons beyond
human understanding. Anyway, the first alternate setting seems to work
with both, so let's change the order for now until the vendor can fix
their firmware.

BUG=chrome-os-partner:18460
TEST=Make sure camera works on Spring EVT.

Change-Id: I7734a43b0383cb1d74f30e99a40cbce9db85c7c2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47319
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

UPSTREAM: [media] uvcvideo: Support super speed endpoints

Compute the maximum number of bytes per interval using the burst and
multiplier values for super speed endpoints.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
(cherry picked from commit 6fd90db8df379e215f2d495d0b4f3d2553c00277)

BUG=chrome-os-partner:18460
TEST=None

Change-Id: I0ad74ce6edb7316e51a7f5fb7f1d41b4f6e3880c
Reviewed-on: https://gerrit.chromium.org/gerrit/47318
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>

arm: exynos: Don't print out warning about negative ASV group

We have seen CPUs that end up with a calculated ASV group of -1.
According to Samsung these should be assigned group 0 and are no
problem, so we shouldn't warn about them. We'll also stop warning
about other negative ASV groups. If we need to find out the
calculated ASV group we can use the "EXYNOS5250: ORIG: %d MOD: %d
RESULT: %d" message and just to the math ourselves (ORIG-MOD).

BUG=chrome-os-partner:18505
TEST=Boot up a device with ASV group -1 and see the warning go away.

Change-Id: I7c20445b1fb5afc233614faace5f387e5c182a03
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47126
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>

Revert "drm/exynos: mixer: support for 800x600 resolution"

This reverts commit ed244d6a805b3c11a72dbce6307ed752e7c15848.

The 800x600 resolution does not work, so let's not expose it as
it causes black screens, especially with projectors where this mode
is very common (we don't have 1024x768 so it falls back to 800x600).

BUG=chromium:225983
TEST=by hand: the 24 inch Dell monitor now picks 640x480 and works fine

Conflicts:
drivers/gpu/drm/exynos/exynos_drm_hdmi.c

Change-Id: I0337a63767b8ed10f1879f8251f54ac6649b604b
Reviewed-on: https://gerrit.chromium.org/gerrit/47268
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: Restrict swapon() to "zram" devices / lock down zram

This cl contains three distinct changes collapsed into
one CL as per semenzato's request:
1. Restrict CONFIG_SWAP to ensure that only zram devices
   may be used.
2. Restrict zram to disallow open calls, even from root, if
   the device is claimed (e.g., by sys_swapon)
3. Add swapoff fallback when filp_open fails to use the path lookup.
   I don't believe swapoff needs filp_open() since kern_path()
   provides the data needed without a file object.
4. Add an open counter to zram to ensure that it is not opened more
   times than swapon(2) will claim it -- twice:
   - blkdev_get and filp_open (for swap_file)

Signed-off-by: Will Drewry <wad@chromium.org>
TEST=tested on lumpy; swapon, swapoff, change zram during swapon fails, change withotu swapon succeeds.
BUG=chromium:220974

Change-Id: Ic281a7004a81b2897cf0bf1c5d334351061261f1
Reviewed-on: https://gerrit.chromium.org/gerrit/46168
Tested-by: Will Drewry <wad@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Will Drewry <wad@chromium.org>

CHROMIUM: detect GPU memory mapped at < 1MB physaddr.

We want to check if we ever map GPU memory at < 1MB,
because of problems in Sandy Bridge (and possibly Ivy Bridge).

BUG=chromium:224320
TEST=compiled, booted
BRANCH=none

Change-Id: I731da19f2a4d5230f84b54dbfd3993a5cb8dfe72
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46716

CHROMIUM: xhci: Ignore spurious successful event on DWC3 controller

The DesignWare USB3 controller behaves the same as the Panther Point
chipset regarding success on short packets.
Let's define the same quirk (see original explanation below).
As DWC3 IP is the only xhci platform driver so far (both in our tree and
tip of upstream kernel), we can simply define it for all platform XHCI
controller.

This quirk was originally added to xhci-pci driver with the following
message in commit ad80833:
The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring.  If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring.  Then it puts a Transfer Event with a successful completion
code on the ring for the same TD.  The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event.  These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.

This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.

Change-Id: I2857226a763613109da767513f350db4081e45e2
Reviewed-on: https://gerrit.chromium.org/gerrit/47152
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>

BACKPORT: usb: xhci: Fix TRB transfer length macro used for Event TRB.

Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
Bulk transfer support". This patch will have issues applying to older
kernels.

Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.

Change-Id: Id33eaf62d67edcc5c79a187dd415b914133a58d3
Reviewed-on: https://gerrit.chromium.org/gerrit/47141
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>

BACKPORT: xhci: Add new short TX quirk for Fresco Logic host.

Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic".  When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine.  The device is:

Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.

The successful completion code and non-zero untransferred length is a
contradiction.  The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred.  Otherwise, the transfer
should be marked with a short packet completion code.  Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length.  With it, we know to trust
the untransferred length.

Add a new xHCI quirk for the Fresco Logic host controller.  If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning.  For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.

This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts."  That commit was marked for stable kernels as old
as 2.6.36.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.

Change-Id: I5d9ddabd5e8bddd6c2fd2acee2eb8251628f2b9d
Reviewed-on: https://gerrit.chromium.org/gerrit/47140
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>

UPSTREAM: loop: prevent bdev freeing while device in use

struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
block_device allocated first time we access /dev/loopXX and deallocated on
bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
we want that block_device stay alive until we destroy the loop device
with "losetup -d".

But because we do not hold /dev/loopXX inode its counter goes 0, and
inode/bdev can be destroyed at any moment. Usually it happens at memory
pressure or when user drops inode cache (like in the test below). When later in
loop_clr_fd() we want to use bdev we have use-after-free error with following
stack:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
  bd_set_size+0x10/0xa0
  loop_clr_fd+0x1f8/0x420 [loop]
  lo_ioctl+0x200/0x7e0 [loop]
  lo_compat_ioctl+0x47/0xe0 [loop]
  compat_blkdev_ioctl+0x341/0x1290
  do_filp_open+0x42/0xa0
  compat_sys_ioctl+0xc1/0xf20
  do_sys_open+0x16e/0x1d0
  sysenter_dispatch+0x7/0x1a

To prevent use-after-free we need to grab the device in loop_set_fd()
and put it later in loop_clr_fd().

The issue is reprodusible on current Linus head and v3.3. Here is the test:

  dd if=/dev/zero of=loop.file bs=1M count=1
  while [ true ]; do
    losetup /dev/loop0 loop.file
    echo 2 > /proc/sys/vm/drop_caches
    losetup -d /dev/loop0
  done

[ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
  time we call loop_set_fd() we check that loop_device->lo_state is
  Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
  it will get EBUSY.  And if we try to loop_clr_fd() on unbound loop
  device we'll get ENXIO.

  loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
  loop_device->lo_ctl_mutex. ]

Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium:221466
TEST=link build, manual testing

(cherry picked from upstream commit c1681bf8a7b1b98edee8b862a42c19c4e53205fd)
Change-Id: Ic728f6f5dc6664bbc06e0265345208a862130bac
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47072
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>

UPSTREAM: ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual
issue pipelines.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 418df63adac56841ef6b0f1fcf435bc64d4ed177)

Change-Id: I30ffc36e387901ab33739325ce22b6ee9da52da4
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47028
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

UPSTREAM: ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}

compiled as:

800554d0 <debug_mutex_lock_common>:
800554d0:       e92d4008        push    {r3, lr}
800554d4:       e1a00001        mov     r0, r1
800554d8:       e3a02010        mov     r2, #16 ; 0x10
800554dc:       e3a01011        mov     r1, #17 ; 0x11
800554e0:       eb04426e        bl      80165ea0 <memset>
800554e4:       e1a03000        mov     r3, r0
800554e8:       e583000c        str     r0, [r3, #12]
800554ec:       e5830000        str     r0, [r3]
800554f0:       e5830004        str     r0, [r3, #4]
800554f4:       e8bd8008        pop     {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.

This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).

Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:
-       str     lr, [sp, #-4]!
+       stmfd   sp!, {r8, lr}

and restore r8 on both exit paths:
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
(...)
        tst     r2, #16
        stmneia ip!, {r1, r3, r8, lr}
-       ldr     lr, [sp], #4
+       ldmfd   sp!, {r8, lr}

Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:
-       stmfd   sp!, {r4-r7, lr}
+       stmfd   sp!, {r4-r8, lr}

and restore r8 on both exit paths:
        bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+       ldmeqfd sp!, {r4-r8, pc}
(...)
        tst     r2, #16
        stmneia ip!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+       ldmfd   sp!, {r4-r8, lr}

Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".

Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 455bd4c430b0c0a361f38e8658a0d6cb469942b5)

Change-Id: Idfbebdd48103e5fa4ae7faeae78dfabace28f0a7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47027
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: config: Add vivi to base config for testing purposes

vivi is a virtual capture driver that acts like a camera. Add it to the default
build for testing purposes.
Eventually we'd like to have it built for testing images only.

BUG=chromium:223099
TEST=manual build and test

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Change-Id: Ic9b4f95eb10ee609d8e070cb93891164da37f4f4
Reviewed-on: https://gerrit.chromium.org/gerrit/46269
Commit-Queue: Pawel Osciak <posciak@google.com>
Reviewed-by: Pawel Osciak <posciak@google.com>
Tested-by: Pawel Osciak <posciak@google.com>

BACKPORT: drm/exynos: add property for plane zpos

The exynos drm driver used a specific ioctl - DRM_EXYNOS_PLANE_SET_ZPOS
to set zpos of plane. It can be substitute to property of plane. This
patch adds a property for plane zpos and removes
DRM_EXYNOS_PLANE_SET_ZPOS ioctl.

BUG=chromium:222980
TEST=Verified that cursor works when using property to set zpos.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit 00ae67cf26fad3889e71e3bdbec012b1f938dc0e)

Change-Id: I018b6475916f6bbff416d0313fe0c7c3c68217b8
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46957
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

BACKPORT: drm/exynos: use private plane for crtc

The crtc can use private plane instead it has overlay struct. It will be
helpful use plane feature from crtc later.

BUG=chromium:222980
TEST=By hand.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit b5d2eb3bd691c0b6869a2013e719a61c595d73a6)

Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I3385e40cac26ebb2d71670f71eb1d3f91638437e
Reviewed-on: https://gerrit.chromium.org/gerrit/46956
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: ASoC: max98088 - expose digital mic enable switches.

Add a control for enable right and left digital mic. This control
routes the digital mic input through the ADC. It must be disabled for
analog input to work.

BUG=chrome-os-partner:18454
TEST=toggle switches, see changes with i2cdump.

Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I8ed493ce9aea4f94f4feda23172e2e3251e27b51
Reviewed-on: https://gerrit.chromium.org/gerrit/46904
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: ASoC: daisy - different mic bias for spring.

Spring's mic bias control is "MICBIAS" not "MICBIAS2", set
appropriately.

BUG=chrome-os-partner:18454
TEST=boot; check mic bias register.

Change-Id: Ibd67346dbec153c2635b6a318143766f3f98155a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46932
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: input: cyapa - fix power mode switch problems

We have found that some commands may fail if the touchpad is
not running at the full mode. Moreover, setting new power modes
would take the amount of time roughly equal to the old scanrate
to complete. The patch fixes several places where the unsafe
commands might be run before completely returning to the full
mode. Meanwhile, the cyapa_set_power_mode function now returns
early if the mode to set is the same as the current one.

Signed-off-by: Tai-Hsu Lin <sheckylin@chromium.org>
BUG=chromium:196520
TEST=Repeatedly suspend/resume the device with Cypress touchpad for
a few hundred times. One should see errors about reading query data
in the /var/log/messages.

With the fix, one shouldn't see the error.

Change-Id: I95a843a077d5840c57cc24daf85b6549550fa73d
Reviewed-on: https://gerrit.chromium.org/gerrit/46115
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Tai-Hsu Lin <sheckylin@chromium.org>
Tested-by: Tai-Hsu Lin <sheckylin@chromium.org>

CHROMIUM: drm/exynos: Propagate controller's enable_vblank() result

The controller enable_vblank() can fail if, for example, it is requested
while suspended (fimd) or before the mixer is powered on.

In these cases, the error could should be propagated up to the higher
layers so they can deal with it appropriately (i.e., try again later).

In particular, this solves a race at HDMI hotplug where a userspace
WaitVBlank ioctl races with the hdmi/mixer power on sequence.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:223501
TEST=boot w/ HDMI disconnected. Login as guest. Plug HDMI cable.
Should see extended desktop, pointer should move on external monitor.

Change-Id: Id2c54ce8c1c500bc95321a6b00fa147348c29125
Reviewed-on: https://gerrit.chromium.org/gerrit/46399
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>

CHROMEOS: HID: Support for Logitech T651 Touchpad

This touchpad is similar to the T650, but has a few notable
differences:

- It connects via Bluetooth as opposed to the Unifying Receiver

- The raw data reports are in a unique format appended to normal mouse
  reports. The mouse reports must be ignored. Putting this pad into
  raw data mode will work as the T650 does, but Nestor Lopez Casado of
  Logitech advises against as that mode as it's not officially
  supported.

BUG=chromium:223138
TEST=Manually tested on device. Will add base regression tests.

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I9c6e3359f08508c54c47e79bec1bbc0121d0b06c
Reviewed-on: https://gerrit.chromium.org/gerrit/46683
Reviewed-by: Yufeng Shen <miletus@chromium.org>

UPSTREAM: drm: add plane properties

The omapdrm driver uses this for setting per-overlay rotation. It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.

Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 4d93914ae3db4a897ead4b1e33eca7cdfff4c6f7)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: I8f50d93443cc6c51f06d553cd0286fff11de3269
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40516
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: add 'count' to struct drm_object_properties

This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.

Change suggested by Ville Syrjälä.

Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 7f88a9bedfb814a2d4d537db8295c524298256cb)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: Ic184b52fb6d587a69943744e38f8f73bad2cb6e1
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40514
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: make the connector properties code use the object properties code

In the future, we may want to kill the internal functions:
- drm_connector_attach_property
- drm_connector_property_set_value
- drm_connector_property_get_value

It seems the IOCTL drm_mode_connector_property_set_ioctl will have to live, but
we may change libdrm to not use it anymore, if we want.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 0057d8dd8d378bf88f75736496d779f3c9454b5f)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: Id7f04a7b9e5b0dc40ef08e13405fe76f003ab898
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40513
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: add generic ioctls to get/set properties on any object

Useless for connector properties (since they already have their own
ioctls), but useful when we add properties to CRTCs, planes and other
objects.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c543188afb7a83e66161c026dc6fd5eb38dc0b63)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: Ia187a647bedeee39d16902c6df22e2cac04a74bc
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40512
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: create struct drm_object_properties and use it

For now, only connectors have it. In the future, all objects that need
properties should use it. Since the structure is referenced inside
struct drm_mode_object, we will be able to deal with object properties
without knowing the real type of the object.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 7e3bdf4a6dca9eb153cc20d69d717308a68bec00)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: Ic125db59d6c7a4d11671f5f3529a7bf409367e87
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40511
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: WARN() when drm_connector_attach_property fails

Also return void instead of int. We have more than 100 callers and
no one checks for the return value.

If this function fails the property won't be exposed by the get/set
ioctls, but we should probably survive. If this starts happening,
the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and
recompile the Kernel.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit afea2ad53f1fef0b57d0e59fa062f54797158b14)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: Ibcf34e79c3f310a53345bfde5ee7853495171ced
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40510
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: add drm_property_change_is_valid

Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 26a3481586eb1918a75d338e31c990deab06fb5b)

BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.

Change-Id: I09b99bf3cc8ad332c9129e59d4c030314a70da79
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40509
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: md: dm-verity-chromeos: changed how kernel parititon is corrupted

Changed the error handling to use the linux cmdline
to find the kernel partition to corrupt it so when
an error is detected in the root volume, the bios
will know to switch partitions.

BUG=chromium:222954
TEST=1. manually corrupt root partition and bootcache and reboot 2. manually corrupted root paritions with no bootcache
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I9ea8c5462d573fc8599be36b4c6eaf1f4c7eb99c
Reviewed-on: https://gerrit.chromium.org/gerrit/46375
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - Disregard matrix size for config update check

The config update's header check function compares the x size and y size bytes
in the raw config file with the corresponding bytes from the device.
Unfortunately, these bytes may be changed by changing T46 byte 1, so they
should not be treated as an immutable quality of the device.

We've run into several situations where a firmware update or an invalid
config update blows away the correct value in the device's registers,
and the driver refuses to update to restore the correct register config.

This change skips over the check of the x size and y size, and skips over
the info block crc check in case the size is different, as the crc comparison
with the device's info block crc will also fail.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:18386
TEST=Follow the steps below to write an incorrect value into the XYMode reg:
cd /sys/bus/i2c/devices/1-004b
echo "2e000100" > object
echo 1 > backupnv
echo "06000001" > object
shutdown -P now
Boot the system again.

With this fix, the trackpad should be functional, and the following should
be in /var/log/messages:
chromeos-touch-config-update[285]-atmel_mxt_tp: Device config checksum : a9ffd4
chromeos-touch-config-update[285]-atmel_mxt_tp: New config checksum : a84914

atmel_mxt_ts 1-004b: Using config file maxtouch-tp.cfg (size = 1102)
atmel_mxt_ts 1-004b: Config File: Version = OBP_RAW V1
atmel_mxt_ts 1-004b: Config File: Chip ID = 82 01 10 aa 13 0b 16
atmel_mxt_ts 1-004b: Matrix Xsize and Ysize mismatch. Updating.
atmel_mxt_ts 1-004b: Chip Info: 82 01 10 aa 10 0e 16
atmel_mxt_ts 1-004b: Config File: Config CRC = 56506a

Followed by the normal config update output, then confirmation the update worked:
chromeos-touch-config-update[285]-atmel_mxt_tp: Try #1: Checking new device csum a84914
chromeos-touch-config-update[285]-atmel_mxt_tp: Config update succeeded

Change-Id: I22046b6709bfbfc38e9105543cae9d5ff5e6e183
Reviewed-on: https://gerrit.chromium.org/gerrit/46471
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>

backlight: don't resume backlight for dark resume

For an idle suspend, we set the resume backlight sysfs file which is used during
resume in the kernel. This causes the screen to flash on for a moment during a
dark resume. This change prevents the backlight resume from doing anything
during a dark resume.

BUG=chrome-os-partner:9812
TEST=idle suspend system with dark resume (see backlight doesn't turn on)

Change-Id: Iccd02b99bdd682853fc9b184817c4d43028afcf6
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45824
Reviewed-by: Sameer Nanda <snanda@chromium.org>

Revert "CHROMIUM: Input: synaptics - skip trackpoint reconnect"

This reverts commit 6e600b92ec9ff57a6e4935ae31f3b6425c4c3344.

Due to the new trackpoint driver optimization, we no longer need this
workaround. The long trackpoint connect / reconnect sequence has been
mostly replaced by a power-on reset command which speeds things up
considerably.

TEST=Manual. Run powerd_suspend + wake, verify long trackpoint reconnect
delay no longer exists.
BUG=chrome-os-partner:18349

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

CHROMIUM: input: mouse - Optimize trackpoint init sequence.

The trackpoint driver sets various parameter default values, all of
which happen to be power-on defaults (Source: IBM TrackPoint Engineering
Specification. Version 4.0, also confirmed by empirical data).

By sending the power-on reset command to reset all parameters to
power-on state, we can skip the lengthy process of programming all
parameters. In testing, ~3 secs of time writing parameters was reduced
to .35 seconds waiting for power-on reset to complete.

TEST=Manual. Verify power-on reset initializes values to desired
defaults.
BUG=chrome-os-partner:18349

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

CHROMIUM: input: serio - Remove unnecessary port rescans.

When a serio_interrupt is received, if no driver is attached to the
port, a rescan event will be queued. Between the time the event is
queued and processed, it is possible that a driver will become attached
to the port (ex. through a previously queued ATTACH_DRIVER event). In
this case, the the driver / device will needlessly be initialized twice.

This change clears the queue of rescan events for a port if a driver
becomes attached to the port.

TEST=Manual. Verify that rescan does not occur due to trackpad interrupt
received in early boot on Stout platform.
BUG=chrome-os-partner:18327

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I43baf609e65c716628d37d157b26194085440850
Reviewed-on: https://gerrit.chromium.org/gerrit/46183
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>

HID: magicmouse: Set multi-touch keybits for Magic Mouse

(This was reverted because this causes Chrome to consider Magic Mouse as
a touchpad.  But once we switch mice to gestures library, I think it
should be fine to merge this change.)

The driver emits multi-touch events for Magic Trackpad as well as Magic
Mouse, but it does not set keybits that are related to multi-touch event
for Magic Mouse; so set these keybits.

The keybits that are not set cause trouble because user programs often
probe these keybits for self-configuration and thus they cannot operate
properly if the keybits are not set.

One of such troubles is that libevdev will not be able to emit correct
touch count, causing gestures library failed to do fling stop.

Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chromium-os:36322
TEST=On Snow, connect Magic Mouse and touch it; evtest should show
     BTN_TOUCH and BTN_TOOL_FINGER.

Event: time 1363905613.064416, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1363905613.064421, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1363905613.064423, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0

     Then test scroll and fling stop; it should work now.

     Finally, check /var/log/Xorg.0.log and does not see error
     message of "Too many fingers! Max is 1, but I got 2"

Original-Change-Id: Ie7fd4327935555f41577e2c8c6d6d78b52934f1a
Reviewed-on: https://gerrit.chromium.org/gerrit/41322
Commit-Queue: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
(cherry picked from commit 5c1386506de5237373db16f470d54e8a83afe318)

Change-Id: I6702dbf400aa28296308a467d065fd5a326ac30a
Reviewed-on: https://gerrit.chromium.org/gerrit/46169
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Queue: Che-Liang Chiou <clchiou@chromium.org>

CHROMEOS: Enable HID_LOGITECH_WTP

BUG=chromium-os:39354
TEST=manually tested on Link

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I102167f48fb1c4a2fefedd388af92455c2dba3dc
Reviewed-on: https://gerrit.chromium.org/gerrit/46011
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: HID: MT-B driver for Logitech wireless touchpads

This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"

This driver provides an MT-B driver for Logitech wireless
touchpads. It currently supports two models:

- Logitech Wireless Touchpad
- Logitech Wireless Rechargeable Touchpad T650

Documentation is provided at
https://drive.google.com/a/logitech.com/?tab=mo#folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28

BUG=chromium-os:39354
TEST=manually tested on Link

Change-Id: I0085dfb053f7b9c0931c39c0d28ba1608216a2a5
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46010
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: HID: Helper functions for Logitech HID++

This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"

HID++ is a Logitech-specific protocol for communicating with HID
devices. It can be used, for example, to probe properties of devices
(like touch surface dimensions, battery status, and more), and to set
state on a device (like a request to put the device into raw mode).

Documentation is provided at
https://drive.google.com/a/logitech.com/?tab=mo#folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28

BUG=chromium-os:39354
TEST=manually tested on Link

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I1b87558cc31cb77ef277820f0b00f3ea6e1b367e
Reviewed-on: https://gerrit.chromium.org/gerrit/46009
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: HID: logitech-dj: move .h file info .c file.

This is part of the next iteration of Nestor Lopez Casado's
introduction of HID++ support to the kernel from his patch "[PATCH
1/1] HID: Add full MT support for Logitech Wireless Touchpad"

These definitions are only used by the .c file.

BUG=chromium-os:39354
TEST=manually tested on Link

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: Ie745aad4dd782214725c0930ec3b82feed5554cd
Reviewed-on: https://gerrit.chromium.org/gerrit/46008
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: HID: logitech-dj: Delay creation of enumerated devices until connected.

This is necessary because it's impossible to communicate with devices
that aren't connected and future patches will need to communicate with
devices during probe().

By waiting until the device is connected, we ensure that we only
register the device when it's active and ready for use.

BUG=chromium-os:39354
TEST=manually tested on Link

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: Id5f2ae88839d1c39362cf0f9246a39d1f6e6238a
Reviewed-on: https://gerrit.chromium.org/gerrit/46007
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: Revert "HID: Fix logitech-dj: missing Unifying device issue"

This reverts commit 596264082f10dd4a567c43d4526b2f54ac5520bc.

The reverted commit was a workaround needed when drivers became unable
to communicate with devices during probe(). Now that such
communication is possible, the workaround is not needed.

BUG=chromium-os:39354
TEST=manually tested on Link

Change-Id: I75e27afbd1acfcb2fea2a7a645b4fcec3e31c417
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46006
Reviewed-by: Yufeng Shen <miletus@chromium.org>

CHROMEOS: HID: Fix logitech-dj: Allow incoming packets during probe().

Historically, logitech-dj communicated with the device during probe()
to query the list of devices attached. Later, a change was introduced
to hid-core that prevented incoming packets for a device during
probe(), as many drivers are unable to handle such input. That change
broke the device enumeration in logitech-dj, so commit
596264082f10dd4a56 was introduced to workaround that by waiting for
normal input before enumerating devices.

Now that drivers can opt-in to receive input during probe, this patch
changes logitech-dj to do that, so that it can successfully complete
enumeration of devices during probe().

BUG=chromium-os:39354
TEST=manually tested on Link

Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I2dca10a5c64f6c3e90ffb00547b47eaf94546eb6
Reviewed-on: https://gerrit.chromium.org/gerrit/46005
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>

CHERRY-PICK: UPSTREAM: HID: Separate struct hid_device's driver_lock into two locks.

This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).

Historically, three functions used driver_lock:

- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock

This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:

- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock

This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.

This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.

BUG=chromium-os:39354
TEST=manually tested on Link

(Hasn't quite landed upstream, yet, but this has passed review on linux-input)
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I737f6fc15911134b51273acf8d3de92fa5cc0f85
Reviewed-on: https://gerrit.chromium.org/gerrit/46004
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>

CHERRY-PICK: UPSTREAM: HID: Fix logitech-dj: missing Unifying device issue

This patch fixes an issue introduced after commit 4ea5454203d991ec
("HID: Fix race condition between driver core and ll-driver").

After that commit, hid-core discards any incoming packet that arrives while
hid driver's probe function is being executed.

This broke the enumeration process of hid-logitech-dj, that must receive
control packets in-band with the mouse and keyboard packets. Discarding mouse
or keyboard data at the very begining is usually fine, but it is not the case
for control packets.

This patch forces a re-enumeration of the paired devices when a packet arrives
that comes from an unknown device.

Based on a patch originally written by Benjamin Tissoires.

BUG=chromium-os:39354
TEST=manually tested on Link

(cherry picked from upstream commit 596264082f10dd4a567c43d4526b2f54ac5520bc)
Change-Id: I03408c97bb295599306ec74e55698076d5112f81
Cc: stable@vger.kernel.org # v3.2+
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46003
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>

CHERRY-PICK: UPSTREAM: dj: memory scribble in logi_dj

Allocate a structure not a pointer to it !

BUG=chromium-os:39354
TEST=manually tested on Link

(cherry picked from upstream commit 8a55ade76551e3927b4e41ee9e7751875d18bc25)
Change-Id: I36d4c6eec346aeb24d323cd6bcd426520d4dfdbd
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46002
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>