UPSTREAM: HID: core: add "report" hook, called once the report has been parsed

This callback is called when the parsing of the report has been done
by hid-core (so after the calls to .event). The hid drivers can now
have access to the whole report by relying on the values stored in
the different fields.

BUG=chromium:318205
TEST=None

Change-Id: Ibd4c42f595c047f433a00363c51b1a066ae665cf
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://chromium-review.googlesource.com/183261
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
UPSTREAM: HID: multitouch: use the callback "report" instead of sequential events

Nexio 42" devices requires to rely on the HID field Contact
Count to compute the valid values. However, this field is
most of the time at the end of the report, meaning that we
need to get the all report parsed before processing it.

This patch does not introduce functional changes.

BUG=chromium:318205
TEST=None

Change-Id: I79ee788e5e492270720d81586d2f62b75d37ac8e
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://chromium-review.googlesource.com/183262
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
UPSTREAM: HID: multitouch: add support for Nexio 42" panel

This device is the worst device I saw. It keeps TipSwitch and InRange
at 1 for fingers that are not touching the panel.
The solution is to rely on the field ContactCount, which is accurate
as the correct information are packed at the begining of the frame.

Unfortunately, CountactCount is most of the time at the end of the report.
The solution is to pick it when we have the whole report in raw_UGevent.

BUG=chromium:318205
TEST=None

Change-Id: I669184746edfcf5e470eaefce145d1b36c966579
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://chromium-review.googlesource.com/183263
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
Support for CY-TM75 75 inch Touch Overlay

1. This device needs the same multi-touch class MT_CLS_ALWAYS_TRUE setting
as USB_DEVICE_ID_NEXIO_MULTITOUCH_420.

2. There is timeout error during initialization:
kernel: [   11.733104] hid-multitouch 0003:1870:0110.0001: usb_submit_urb(ctrl) failed: -1
kernel: [   11.734093] hid-multitouch 0003:1870:0110.0001: timeout initializing reports

Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.

BUG=chromium:318205
TEST=Connect the touch overlay with ChromeOS device, and up to 6 fingers multi-touch
     work well.

Change-Id: I6029bf5d269f536618706983673ae7341b87394e
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183264
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
ARM: dts: Don't name both 1.2V regulators the same

This avoids a warning at boot time:
  vdd_1v2: Failed to create debugfs directory

BUG=chrome-os-partner:25187
TEST=Boot up, no warning.

Change-Id: Id52861ee8e14ea079005bbedb873386a90782616
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183397
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: mwifiex: add placeholder for cfg80211 definitions in kernel 3.9+

For driver backport to work without touching wireless-3.8 stack,
copy over all needed new cfg80211 definitions from kernel 3.9+.

Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24804
TEST=pass compiliation with backport patches applied.

Change-Id: Ic26e6432ceed1bac22882a3e90b1c43a0e84ed02
Reviewed-on: https://chromium-review.googlesource.com/182193
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: add 802.11AC support

For STA mode, collect VHT realated IEs from the Beacons or Probe
Responses and append similar VHT related IEs to association
requests.

For AP mode, get VHT related capability information and share it
with cfg80211 at the time of wiphy register. This information is
further used by cfg80211 and hostapd to start an AP with 802.11AC
support.

Currently only 8897 supports 802.11AC.

This is collection of the following patches:

mwifiex: improve readability in 11ac mcsmap to maxrate conversion
mwifiex: make 11ac mcs rate tables global and const
mwifiex: make use of IEEE80211_VHT_MCS_NOT_SUPPORTED
mwifiex: fix wrong 11ac bits setting in fw_cap_info (already upstream)
mwifiex: cleanup VHT cap (already upstream)
mwifiex: add 802.11AC support (already upstream)

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:24804
TEST=associate to Buffalo WZR-D1800H AP (5G) and verify the
VHT IE in association request and response from AP in sniffer
captures.

Change-Id: I80c7c76609b6f4719de7a37b30ef9189949363e5
Reviewed-on: https://chromium-review.googlesource.com/182194
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: correct bss_mode check while appending vht operation IE

priv->bss_mode uses NL80211_IFTYPE_* definitions.
HostCmd_BSS_MODE_IBSS is used in ad-hoc start/join command between
driver and firmware.

Coincidentally both HostCmd_BSS_MODE_IBSS and NL80211_IFTYPE_STATION
are defined as 2. That explains why nobody complained.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:24804
TEST=No functional/behavior change. All existing features still
work as before.

Change-Id: I32d4bc7322e54704397f0dee9f1c5ca7444d623e
Reviewed-on: https://chromium-review.googlesource.com/182195
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: add support to configure VHT for AP mode

Currently, default VHT configuration from the firmware is used
for the VHT operations. Adding vhtcfg command to configure the
firmware based on input received from cfg.

Enable VHT for AP mode only when cfg80211_ap_settings has a
VHT IE i.e., when ieee80211ac is set to 1 in the hostapd.conf.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:24804
TEST=verify that micro-AP can be started on 2.4GHz and 5GHz
with HT IE in beacon and probe response. Other stations can
associate to uAP. Cannot test VHT on Snow as ieee80211ac=1
is not supported in current hostapd.

Change-Id: I11d3b14ac71c5063208f7de9345a4194a7f15fd2
Reviewed-on: https://chromium-review.googlesource.com/182196
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: use separate AMPDU tx/rx window sizes in 11ac networks

Newer 11ac enabled chipsets have more TX and RX buffers in FW
and hardware; so they may support larger TX and RX window sizes
for BA. Reset BA settings during association, adhoc join/start
or start_ap() if we are joining/creating 11ac network.

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Sagar Bijwe <bsagar@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:24804
TEST=add pr_info() in nl80211.c nl80211_put_sta_rate().
Associate to Buffalo WZR-D1800H AP (5G) and ping the AP.
Run iw mlan0 link, and then check dmesg to see VHT mcs/nss
debug logs printed in nl80211_put_sta_rate().
Start 11N uAP, other 11N STA can associate to it and data path
is working. Cannot test VHT on Snow as ieee80211ac=1 is not
supported in current hostapd.

Change-Id: I0d010402f6ff8e162b8b1caab7646554c4114692
Reviewed-on: https://chromium-review.googlesource.com/182197
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
UPSTREAM: mwifiex: remove unsupported code in 11ac

bit12 in fw_cap_info is for testing only.
Remove all related code.

Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24804
TEST=add pr_info() in nl80211.c nl80211_put_sta_rate().
Associate to Buffalo WZR-D1800H AP (5G) and ping the AP.
Run iw mlan0 link, and then check dmesg to see VHT mcs/nss
debug logs printed in nl80211_put_sta_rate().
Start 11N uAP, other 11N STA can associate to it and data path
is working. Cannot test VHT on Snow as ieee80211ac=1 is not
supported in current hostapd.

Change-Id: I0a85932050f67d398102024feb854a587e9e07b3
Reviewed-on: https://chromium-review.googlesource.com/183313
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
drm: Add drm_master_relax debugfs file (non-root set/drop master ioctls)

Writing 'Y' to /sys/kernel/debug/dri/drm_master_relax allows
non-CAP_SYS_ADMIN user to call the 2 ioctls DRM_IOCTL_SET_MASTER and
DRM_IOCTL_DROP_MASTER.

This makes it possible to run 2 X11 servers at the same time, where at
least one of them runs under a non-root user (e.g. Chromium OS X server
as xorg user, and a crouton X server as root).

The behavior is not modified if /sys/kernel/debug/dri/drm_master_relax
is kept to its default value ('N').

Modifying drm_master_relax is only possible by root user, so it cannot
possibly lead to exploits. Also, even when the flag is set to 'Y',
DROP_MASTER permissions are changed to DRM_MASTER which means that only
a process that has DRM master can drop it (which is actually quite
logical), and the SET_MASTER IOCTL is changed to DRM_AUTH which allows
all authenticated DRM users to get master.

R=seanpaul@chromium.org, dbehr@chromium.org
BUG=chromium:328115
TEST=With or without the debugfs flag, WebGL examples work, and we can
     switch between VT1 and VT2.
TEST=On a peppy in developer mode: With the debugfs flag to 'Y', Ubuntu
     saucy chroot generated by crouton (xfce target) is able to start a
     second X11 display. Switching back and forth between the two
     displays works, and 3D acceleration is working in the chroot.

Change-Id: Ib8c8a1a326f6808668e319de279c05ffdbfd2837
Signed-off-by: Nicolas Boichat <nicolas@boichat.ch>
Reviewed-on: https://chromium-review.googlesource.com/183190
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: David Schneider <dnschneid@chromium.org>
Tested-by: David Schneider <dnschneid@chromium.org>
UPSTREAM: diff for "mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling"

The upstream version of this patch is different.
This diff patch matches chromeos version to the upstream one.

1. remove mmc_fixup_broken_irq_polling() and add inline
   mmc_card_broken_irq_polling().
2. invoke the quirk handling after 'ret' value is validated.
3. remove unnecessary include for sdio_ops.h.

Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:24149
TEST=Remove MMC_CAP_SDIO_INT bit from exynos5250_dwmmc_caps[dw.mmc3].
With firmware v14.68.29.p22 the Wi-Fi driver doesn't get "data timeout
error" or "read mp_regs failed" message.

Change-Id: Ib3232ec079eced0ee62ff2128bea58d3bda95773
Reviewed-on: https://chromium-review.googlesource.com/183352
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
Revert "drm/exynos: Restore only the vblank register state in power_on"

This reverts commit 403162e6e7229952e0c8b8e86d5b2eda09ab93e4.

From my testing the above commit didn't actually fix the problem.
What was more important was that we added a disable of the IRQ in
fimd_poweroff().  Reverting the commit above and submitting one that
changes fimd_poweroff().

CQ-DEPEND=CL:I1c74ac2ac5fb8dcadb2d48288cf8740c4455c87b
BUG=chromium:326581
TEST=suspend_stress_test on snow and pit.
TEST=let screen time out on snow and pit and move cursor; no warn.
TEST=suspend_stress_test on snow and pit after screen timed out.
TEST=add kernel code to print at IRQ enable/disable and see balance.

Change-Id: I86fcae43023a863044177068cee2325ef80019ca
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183674
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
drm/exynos: Disable vblank() if we're going to reenable it.

To avoid getting unbalanced IRQ warnings, we should make sure that we
disable the vblank interrupt when we power off.

BUG=chromium:326581
TEST=suspend_stress_test on snow and pit.
TEST=let screen time out on snow and pit and move cursor; no warn.
TEST=suspend_stress_test on snow and pit after screen timed out.
TEST=add kernel code to print at IRQ enable/disable and see balance.

Change-Id: I1c74ac2ac5fb8dcadb2d48288cf8740c4455c87b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183675
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
HACK: TEMP: Add 50mV volatge offset for INT

We are still tuning ASV table for 5422, lets add a 50mv offset for
vdd_int for time being, /wo this system hangs after boot.

BUG=chrome-os-partner:24687
TEST=build and booted on pi, no more hangs observed

Change-Id: I4a600c9b9e5600a9d18ff5b1b9861ee3ccb6ed07
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/182270
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
ARM: dts: Promote cros-ec-keyboard to its own fragment

We include the same keyboard definition across many dts files.  Let's
move it to a fragment to avoid duplication.

This CL does make a few functional changes:
* Adds international "\" to kirby DTS
* Changes the name of the keyboard node on venice2 (I don't think this
  matters)
* Adds the special "BATTERY" key everywhere.  It shouldn't hurt to
  define this even on hardware where the EC is never sending it.

BUG=None
TEST=Build and boot; can still use keyboard.

Change-Id: Ib8a634f56097c01387aaf16f59e731389083dc0a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182665
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Tested-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: usb: quirks: Make DELAY_INIT wait 100ms between GetConfiguration requests

The Logitech HD Pro Webcam C920 is a very quirky device: we could
reproduce all kinds of rare enumeration failures due to broken responses
to the second (full) GetConfigurationDescriptor request. The DELAY_INIT
quirk (which delays one second after the GetDeviceDescriptor request)
helps a bit but is not perfectly reliable.

This patch adds another 100ms delay time between the first and the
second GetConfigurationDescriptor request for DELAY_INIT devices. This
seems to reliably deal with the problems we encountered on the C920, and
shouldn't have a negative impact on other devices using this quirk.

BUG=chrome-os-partner:24893
TEST=Manual

We should eventually try to push this upstream, but I'd like to wait on
how reliably it really solves the issue and what Logitech turns up in
their root-cause investigation first.

Change-Id: I7cd77a66c76a20b0ea3fbfd8061c155788b9bd11
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182702
Reviewed-by: Mohammed Habibulla <moch@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: ALSA: hda/ca0132 - Fix recording from mode id 0x8

The Chromebook Pixel has a microphone under the keyboard that
is attached to node id 0x8. Before this fix, recording would
always go to the main internal mic (node id 0x7).

BUG=chromium:334101
TEST=On pixel, 'arecord -f dat -D hw:0,2 /usr/local/test' to
record audio and verify it captures from the mic under keyboard.
While 'arecord -f dat -D hw:0,0' captures from the main mic.

Change-Id: I8b81ae6692523431f05fe4a7a30e8aa29d1507d4
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183947
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Revert "BACKPORT: drm/i915: update FBC maximum fb sizes"

This reverts commit dcf4377b17d7b8d2ab4ab708aef9c914047287c9.

It seems like the larger FBC sizes don't work at the hw level; they
cause GPU lockups and complete machine freezes. This is fairly
difficult to reproduce, so went unnoticed for a while.

Bug chromium:338588 has been filed to track solving this mystery and
reenabling FBC on link. For now, we just disable it and ship this
thing.

BUG=chromium:328929
TEST=on 8 link machines, run vimeo + webgl aquarium + youtube for 2 hours (so 16 hours of runtime total), no crash

Change-Id: I3098fd620fcb4ea0e4dc88372f7c45a6cf686563
Reviewed-on: https://chromium-review.googlesource.com/184063
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>