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>

CHERRY-PICK: UPSTREAM: HID: logitech: don't use stack based dj_report structures

On a system with a logitech wireless keyboard/mouse and DMA-API debugging
enabled, this warning appears at boot:

kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7()
kernel: Hardware name: MS-7593
kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29]

Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode
use a structure allocated with kzalloc rather than a stack based one.

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

(cherry picked from upstream commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407)
Change-Id: I47b321dd07480bf39bd06c740163506153d83d08
Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46001
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: logitech: read all 32 bits of report type bitfield

On big-endian systems (e.g., Apple PowerBook), trying to use a
logitech wireless mouse with the Logitech Unifying Receiver does not
work with v3.2 and later kernels.  The device doesn't show up in
/dev/input.  Older kernels work fine.

That is because the new hid-logitech-dj driver claims the device.  The
device arrival notification appears:

20 00 41 02 00 00 00 00 00 00 00 00 00 00 00

and we read the report_types bitfield (02 00 00 00) to find out what
kind of device it is.  Unfortunately the driver only reads the first 8
bits and treats that value as a 32-bit little-endian number, so on a
powerpc the report type seems to be 0x02000000 and is not recognized.

Even on little-endian machines, connecting a media center remote
control (report type 00 01 00 00) with this driver loaded would
presumably fail for the same reason.

Fix both problems by using get_unaligned_le32() to read all four
bytes, which is a little clearer anyway.  After this change, the
wireless mouse works on Hugo's PowerBook again.

Based on a patch by Nestor Lopez Casado.
Addresses http://bugs.debian.org/671292

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

(cherry picked from upstream commit 44d27f7dfedd9aadc082cda31462f6600f56e4ec)
Change-Id: I1658d00ed657950b094f88170d065f5bdab8a898
Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar>
Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/46000
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: hid-logitech: Collect report descriptors before sending

The current code allows several consecutive calls to hid_parse_report(),
which may have happened to work before, but would cause a memory leak
and generally be incorrect. This patch collects all the reports
before sending them once.

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

(cherry picked from upstream commit 2a039bf5a6caa6b41c3839c1e3a19b20fb38270b)
Change-Id: Ide9e8c95c99e27a9cb28e1f88c54a12c65098aa6
Cc: Nestor Lopez Casado <nlopezcasad@logitech.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-on: https://gerrit.chromium.org/gerrit/45999
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>

UPSTREAM: USB: XHCI: fix memory leak of URB-private data

commit 48c3375c5f69b1c2ef3d1051a0009cb9bce0ce24 upstream.

This patch (as1640) fixes a memory leak in xhci-hcd.  The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers.  The patch adds a kfree() call so
that all paths end up freeing the memory properly.

This patch should be backported to kernels as old as 2.6.36, that
contain the commit 8e51adccd4c4b9ffcd509d7f2afce0a906139f75 "USB: xHCI:
Introduce urb_priv structure"

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-and-tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 235b62026c1f73decda124912930e322dc8ec57d)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Fix TD size for isochronous URBs.

commit f18f8ed2a9adc41c2d9294b85b6af115829d2af1 upstream.

To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size.  Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field.  The TD size calculation did not mask off those bits before using
the field.  This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.

For example:
 - an isoc endpoint has 2 additional service opportunites and
   a max packet size of 1020 bytes
 - a frame transfer buffer contains 3060 bytes
 - one frame buffer crosses a 64KB boundary, and must be split into
   one 1276 byte TRB, and one 1784 byte TRB.

The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.

For this TD, the number of packets to be transferred is (3060 / 1020),
or 3.  The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder.  After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.

The old code would calculate the TD size for the first TRB as:

total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)

The math should have been:

total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2

Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as

total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1

Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format."  It may not apply well to kernels older
than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d018dbbf6e7e3d588b09273c38ea57bc666d474c)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Fix isoc TD encoding.

commit 760973d2a74b93eb1697981f7448f0e62767cfc4 upstream.

An isochronous TD is comprised of one isochronous TRB chained to zero or
more normal TRBs.  Only the isoc TRB has the TBC and TLBPC fields.  The
normal TRBs must set those fields to zeroes.  The code was setting the
TBC and TLBPC fields for both isoc and normal TRBs.  Fix this.

This should be backported to stable kernels as old as 3.0, that contain
the commit b61d378f2da41c748aba6ca19d77e1e1c02bcea5 " xhci 1.0: Set
transfer burst last packet count field."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1757e241ae2c9758bd983250b94328bddeff8760)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: drivers: xhci: fix incorrect bit test

commit ba7b5c22d33136a5612ca5ef8d31564dcc501126 upstream.

Fix incorrect bit test that originally showed up in
4ee823b83bc9851743fab756c76b27d6a1e2472b "USB/xHCI: Support
device-initiated USB 3.0 resume."

Use '&' instead of '&&'.

This should be backported to kernels as old as 3.4.

Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5c59de0a37d7721221550c2be2b07ea41966bf40)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: usb: Using correct way to clear usb3.0 device's remote wakeup feature.

commit 54a3ac0c9e5b7213daa358ce74d154352657353a upstream.

Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.

This should be backported to kernels as old as 3.4, that contain the
commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote
wakeup for USB3 devices."

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7ad8ac9444d54af92c61c2fa7d02cbf96c990bc5)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: hub: handle claim of enabled remote wakeup after reset

commit 07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream.

Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7dd830b8315230e29f958fd0e039e9eecad28c5d)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: EHCI: fix bug in scheduling periodic split transfers

commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d upstream.

This patch (as1654) fixes a very old bug in ehci-hcd, connected with
scheduling of periodic split transfers.  The calculations for
full/low-speed bus usage are all carried out after the correction for
bit-stuffing has been applied, but the values in the max_tt_usecs
array assume it hasn't been.  The array should allow for allocation of
up to 90% of the bus capacity, which is 900 us, not 780 us.

The symptom caused by this bug is that any isochronous transfer to a
full-speed device with a maxpacket size larger than about 980 bytes is
always rejected with a -ENOSPC error.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5b70af1c0b0088151a1e7a8917527e190ddd76d7)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: EHCI: fix timer bug affecting port resume

commit ee74290b7853db9d5fd64db70e5c175241c59fba upstream.

This patch (as1652) fixes a long-standing bug in ehci-hcd.  The driver
relies on status polls to know when to stop port-resume signalling.
It uses the root-hub status timer to schedule these status polls.  But
when the driver for the root hub is resumed, the timer is rescheduled
to go off immediately -- before the port is ready.  When this happens
the timer does not get re-enabled, which prevents the port resume from
finishing until some other event occurs.

The symptom is that when a new device is plugged in, it doesn't get
recognized or enumerated until lsusb is run or something else happens.

The solution is to re-enable the root-hub status timer after every
status poll while a port resume is in progress.

This bug hasn't surfaced before now because we never used to try to
suspend the root hub in the middle of a port resume (except by
coincidence).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Norbert Preining <preining@logic.at>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f4cc7a1602ed1bb673cf86b6ccc10f72e1cfaae4)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: fix endpoint-disabling for failed config changes

commit 36caff5d795429c572443894e8789c2150dd796b upstream.

This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller.  The controller needs to
be told to disable the endpoints that have been enabled for the new
config.  The existing code does this, but before storing the
information about which endpoints were enabled!  As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.

The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config.  If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble.  The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 828b18866ce0907fdb67afe143d5d851deb9fec6)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Handle HS bulk/ctrl endpoints that don't NAK.

commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.

A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK.  If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).

The xHCI code to compute the NAK interval does not handle the special
case of zero properly.  The current code unconditionally subtracts one
from bInterval and uses it as an exponent.  This causes a very large
bInterval to be used, and warning messages like these will be printed:

usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes

This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.

This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".

Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 74abeffd733e53f83e94fc0d90c0a105af7c58ae)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Avoid "dead ports", add roothub port polling.

commit c52804a472649b2e5005342308739434cbd51119 upstream.

The USB core hub thread (khubd) is designed with external USB hubs in
mind.  It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.

The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits.  When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event.  If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.

This means that the hub code may lose port status changes because of
race conditions between clearing change bits.  The user sees this as a
"dead port" that doesn't react to device connects.

The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.

We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's.  Instead, stop the port polling timer, and
unconditionally restart it when the host resumes.  If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.

This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4ceac47e41f4d587fa71a26dc87335d639a32520)

Conflicts:
drivers/usb/host/xhci.c

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: Ignore port state until reset completes.

commit 4f43447e62b37ee19c82a13f72f35b1ca60a74d3 upstream.

The port reset code bails out early if the current connect status is
cleared (device disconnected).  If we're issuing a hot reset, it may
also look at the link state before the reset is finished.

Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state.  Therefore we can't trust it until the
reset finishes.  Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.

The port state during reset is also unknown for USB 2.0 hubs.  The hub
sends a reset signal by driving the bus into an SE0 state.  This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.

Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.

Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant.  When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.

This patch should be backported to all stable kernels.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 870826a75318bfee80967140ce3eb6b55e1e9759)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: Allow USB 3.0 ports to be disabled.

commit 41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream.

If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port.  Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects.  To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.

The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes.  We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect.  However,
external USB 3.0 hubs don't need this code.  They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set.  Therefore it doesn't make sense to
put this code in the USB core.

This patch is part of a series to fix several reports of infinite loops
on device enumeration failure.  This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller.  The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.

This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a723a6cf79aa2e283d5134adf2787b8a35e0b8f3)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: Ignore xHCI Reset Device status.

commit 8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream.

When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host.  The xHC then updates its internal
representation of the USB device to the 'Default' device state.  If the
device was already in the Default state, the xHC will complete the
command with an error status.

If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.

For example, usb_reset_and_verify_device calls into hub_port_init in a
loop.  Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers.  Then the port will be disabled, but the udev will remain in
tact.  usb_reset_and_verify_device will call into hub_port_init again.

On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command.  This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail.  The port will be disabled, and
the device won't be able to enumerate.

Fix this by ignoring the return value of the HCD reset_device callback.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 36f037316ff169ca111917d6b1d2546d243a2f78)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: USB: Handle auto-transition from hot to warm reset.

commit 1c7439c61fa6516419c32a9824976334ea969d47 upstream.

USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset.  In that case, the warm reset change bit
will be set, and the link state change bit may also be set.  Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs.  If these bits are not cleared, we may lose port change events
from the roothub.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 98e5587b9abe155e356d9eef3be6b1472c508c96)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xHCI: Fix TD Size calculation on 1.0 hosts.

commit 4525c0a10dff7ad3669763c28016c7daffc3900e upstream.

The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB.  The TD Size value for the last TRB in a TD must
always be zero.

The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong.  First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10.  The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.

Third, it uses roundup instead of DIV_ROUND_UP.  The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up.  DIV_ROUND_UP is the right function to use
in that case.

With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0

With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0

This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ceb58b9ffa579690f6124fd49dc1734071544f50)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Fix conditional check in bandwidth calculation.

commit 392a07ae3316f2b90b39ce41e66d6f6b5c95de90 upstream.

David reports that at drivers/usb/host/xhci.c:2257:

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}

The static analyser cppcheck says

[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.

Maybe the original programmer intention was something like

static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
    return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}

Fix this.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 2b69899934c63b7b9432568584fb4c4a2924f40c "xhci: USB
3.0 BW checking."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 363cfe8903364aed741cc5c7f31610581a135be8)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: usb hub: send clear_tt_buffer_complete events when canceling TT clear work

commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c upstream.

There is a race condition in the USB hub code with regard to handling
TT clear requests that can get the HCD driver in a deadlock. Usually
when an TT clear request is scheduled it will be executed immediately:

<7>[    6.077583] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[    6.078041] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[    6.078299] hub_tt_work:731
<7>[    9.309089] usb 2-1.5: link qh1-0e01/f4d506c0 start 0 [1/2 us]
<7>[    9.324526] ehci_hcd 0000:00:1d.0: reused qh f4d4db00 schedule
<7>[    9.324539] usb 2-1.3: link qh1-0e01/f4d4db00 start 0 [1/2 us]
<7>[    9.341530] usb 1-1.1: link qh4-0e01/f397aec0 start 2 [1/2 us]
<7>[   10.116159] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[   10.116459] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[   10.116537] hub_tt_work:731

However, if a suspend operation is triggered before hub_tt_work is
scheduled, hub_quiesce will cancel the work without notifying the HCD
driver:

<3>[   35.033941] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d80
<5>[   35.034022] sd 0:0:0:0: [sda] Stopping disk
<7>[   35.034039] hub 2-1:1.0: hub_suspend
<7>[   35.034067] usb 2-1: unlink qh256-0001/f3b1ab00 start 1 [1/0 us]
<7>[   35.035085] hub 1-0:1.0: hub_suspend
<7>[   35.035102] usb usb1: bus suspend, wakeup 0
<7>[   35.035106] ehci_hcd 0000:00:1a.0: suspend root hub
<7>[   35.035298] hub 2-0:1.0: hub_suspend
<7>[   35.035313] usb usb2: bus suspend, wakeup 0
<7>[   35.035315] ehci_hcd 0000:00:1d.0: suspend root hub
<6>[   35.250017] PM: suspend of devices complete after 216.979 msecs
<6>[   35.250822] PM: late suspend of devices complete after 0.799 msecs
<7>[   35.252343] ehci_hcd 0000:00:1d.0: wakeup: 1
<7>[   35.262923] ehci_hcd 0000:00:1d.0: --> PCI D3hot
<7>[   35.263302] ehci_hcd 0000:00:1a.0: wakeup: 1
<7>[   35.273912] ehci_hcd 0000:00:1a.0: --> PCI D3hot
<6>[   35.274254] PM: noirq suspend of devices complete after 23.442 msecs
<6>[   35.274975] ACPI: Preparing to enter system sleep state S3
<6>[   35.292666] PM: Saving platform NVS memory
<7>[   35.295030] Disabling non-boot CPUs ...
<6>[   35.297351] CPU 1 is now offline
<6>[   35.300345] CPU 2 is now offline
<6>[   35.303929] CPU 3 is now offline
<7>[   35.303931] lockdep: fixing up alternatives.
<6>[   35.304825] Extended CMOS year: 2000

When the device will resume the EHCI driver will get stuck in
ehci_endpoint_disable waiting for the tt_clearing flag to reset:

<0>[   47.610967] usb 2-1.3: **** DPM device timeout ****
<7>[   47.610972]  f2f11c60 00000092 f2f11c0c c10624a5 00000003 f4c6e880 c1c8a4c0 c1c8a4c0
<7>[   47.610983]  15c55698 0000000b f56b34c0 f2a45b70 f4c6e880 00000082 f2a4602c f2f11c30
<7>[   47.610993]  c10787f8 f4cac000 f2a45b70 00000000 f4cac010 f2f11c58 00000046 00000001
<7>[   47.611004] Call Trace:
<7>[   47.611006]  [<c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611019]  [<c10787f8>] ? lock_release_holdtime.part.22+0x88/0xf0
<7>[   47.611026]  [<c103ed46>] ? lock_timer_base.isra.35+0x26/0x50
<7>[   47.611034]  [<c17592d3>] ? schedule_timeout+0x133/0x290
<7>[   47.611044]  [<c175b43e>] schedule+0x1e/0x50
<7>[   47.611051]  [<c17592d8>] schedule_timeout+0x138/0x290
<7>[   47.611057]  [<c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611063]  [<c103e560>] ? usleep_range+0x40/0x40
<7>[   47.611070]  [<c1759445>] schedule_timeout_uninterruptible+0x15/0x20
<7>[   47.611077]  [<c14935f4>] ehci_endpoint_disable+0x64/0x160
<7>[   47.611084]  [<c147d1ee>] ? usb_hcd_flush_endpoint+0x10e/0x1d0
<7>[   47.611092]  [<c1165663>] ? sysfs_add_file+0x13/0x20
<7>[   47.611100]  [<c147d5a9>] usb_hcd_disable_endpoint+0x29/0x40
<7>[   47.611107]  [<c147fafc>] usb_disable_endpoint+0x5c/0x80
<7>[   47.611111]  [<c147fb57>] usb_disable_interface+0x37/0x50
<7>[   47.611116]  [<c1477650>] usb_reset_and_verify_device+0x4b0/0x640
<7>[   47.611122]  [<c1474665>] ? hub_port_status+0xb5/0x100
<7>[   47.611129]  [<c147a975>] usb_port_resume+0xd5/0x220
<7>[   47.611136]  [<c148877f>] generic_resume+0xf/0x30
<7>[   47.611142]  [<c14821a3>] usb_resume+0x133/0x180
<7>[   47.611147]  [<c1473b10>] ? usb_dev_thaw+0x10/0x10
<7>[   47.611152]  [<c1473b1d>] usb_dev_resume+0xd/0x10
<7>[   47.611157]  [<c13baa60>] dpm_run_callback+0x40/0xb0
<7>[   47.611164]  [<c13bdb03>] ? pm_runtime_enable+0x43/0x70
<7>[   47.611171]  [<c13bafc6>] device_resume+0x1a6/0x2c0
<7>[   47.611177]  [<c13ba940>] ? dpm_show_time+0xe0/0xe0
<7>[   47.611183]  [<c13bb0f9>] async_resume+0x19/0x40
<7>[   47.611189]  [<c10580c4>] async_run_entry_fn+0x64/0x160
<7>[   47.611196]  [<c104a244>] ? process_one_work+0x104/0x480
<7>[   47.611203]  [<c104a24c>] ? process_one_work+0x10c/0x480
<7>[   47.611209]  [<c104a2c0>] process_one_work+0x180/0x480
<7>[   47.611215]  [<c104a244>] ? process_one_work+0x104/0x480
<7>[   47.611220]  [<c1058060>] ? async_schedule+0x10/0x10
<7>[   47.611226]  [<c104c15c>] worker_thread+0x11c/0x2f0
<7>[   47.611233]  [<c104c040>] ? manage_workers.isra.27+0x1f0/0x1f0
<7>[   47.611239]  [<c10507f8>] kthread+0x78/0x80
<7>[   47.611244]  [<c1750000>] ? timer_cpu_notify+0xd6/0x20d
<7>[   47.611253]  [<c1050780>] ? __init_kthread_worker+0x60/0x60
<7>[   47.611258]  [<c176357e>] kernel_thread_helper+0x6/0xd
<7>[   47.611283] ------------[ cut here ]------------

This patch changes hub_quiesce behavior to flush the TT clear work
instead of canceling it, to make sure that no TT clear request remains
uncompleted before suspend.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 891fe9688fbd2ef1c04d8314b74c0037be2adb89)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Fix potential NULL ptr deref in command cancellation.

commit 43a09f7fb01fa1e091416a2aa49b6c666458c1ee upstream.

The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled.  This
could cause a NULL pointer deference later in the function when next_trb
is called.  It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI:
handle command after aborting the command ring".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 325c6bf91fd3c2e4fea473e9ca4eb30666dadb52)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xHCI: handle command after aborting the command ring

commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d upstream.

According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.

To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c4f132c4c23d6b822242c98def8be15182c24ff4)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xHCI: cancel command after command timeout

commit 6e4468b9a0793dfb53eb80d9fe52c739b13b27fd upstream.

The patch is used to cancel command when the command isn't
acknowledged and a timeout occurs.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 75382341d888ba0132c5eeb94711840acf972034)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xHCI: add aborting command ring function

commit b92cc66c047ff7cf587b318fe377061a353c120f upstream.

Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.

To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.

Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2818247b6565b7adfbcd53b74509448a8e1fad84)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xHCI: add cmd_ring_state

commit c181bc5b5d5c79b71203cd10cef97f802fb6f9c1 upstream.

Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.

This patch should be backported to kernels as old as 3.0.  The commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command.  This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.

Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1976fffe9dc839e9d25c903a65723600f7641a50)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Intel Panther Point BEI quirk.

commit 80fab3b244a22e0ca539d2439bdda50e81e5666f upstream.

When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB.  This causes
the host controller to place an event on the event ring, but not send an
interrupt.  When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.

However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated.  This means URBs stop completing, and the
USB device disconnect is not noticed.  Something like a USB headset will
cause mplayer to hang when the device is disconnected.

If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.

The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.

Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.

This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 59b91d284b24d4ec17f917421b169fcb40805544)

Conflicts:
drivers/usb/host/xhci-pci.c
drivers/usb/host/xhci.h

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: xhci: Fix invalid loop check in xhci_free_tt_info()

commit 46ed8f00d8982e49f8fe2c1a9cea192f640cb3ba upstream.

xhci_free_tt_info() may access the invalid memory when it removes the
last entry but the list is not empty.  Then tt_next reaches to the
list head but it still tries to check the tt_info of that entry.

This patch fixes the bug and cleans up the messy code by rewriting
with a simple list_for_each_entry_safe().

This patch should be backported to kernels as old as 3.2, that contain
the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store
information about roothubs and TTs."

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b063a624f08cfa64c2d9162d1525da95519e6156)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

UPSTREAM: usbcore: enable USB2 LPM if port suspend fails

commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.

USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".

Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit edad2199132a88f160c4939d1ad3eecc4c33b211)

BUG=None
TEST=Together with other cherry-picks: run BVT trybots on all platforms,
manually confirm that USB network/storage/input devices still work
(including across suspend/resume)

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

Revert "Revert "UPSTREAM: mmc: dw_mmc: correct the calculation for CLKDIV""

This reverts commit f786fcc8d52e5a7d15a90cf266f2ac1d40f54a5e

Cannot reproduce "won't boot" with "normal" FW versions. See bug for details.

Change-Id: Ibb2730ecef525831883ff26bc04c72a55f47f06d
Reviewed-on: https://gerrit.chromium.org/gerrit/46128
Reviewed-by: Grant Grundler <grundler@chromium.org>
Tested-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>

CHROMIUM: CONFIG: Add debug info

This was default on all builds but got lost in a kernel rebase. It
adds no-overhead to release builds since they are stripped but means
the vmlinux we get from the bots has symbols.

BUG=chromium:222294
TEST=Build the kernel and run with it.  Use kgdb with this kernel.

Change-Id: Ief705b2a1a09917b6885ed84c7a405cb12e105f2
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33566
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

samsung: snow: bitfix: Don't bail if we can't recover unused memory

The bitfix code has the requirement that you can only recover an
entire 8K chunk of memory at a time, even though memory can be
"skipped" (not processed by bitfix) in 4K chunks.  If we ever detect
corruption in a 8K chunk that contained skipped pages then we'd bail
and reboot.

The original concept of "skipping" pages was there for sacred areas of
memory: the stack, console buffer, MMU structures, etc.  For these
areas of memory the above logic makes a lot of sense.  Dealing with a
page at a time meant that we could still _detect_ corruption on that
page.  ...and we could even fix it!  ...but since evidence suggested
that if one half of a chunk was corrupted that there's a good chance
of corruption in the other half, we chose to bail and reboot.

The above logic didn't take into account that we added another reason
for skipping a page: if it was unused.  For part of a chunk is unused
then we should just recover the half of the chunk that we care about
and not worry about corruption in the other half.

BUG=chromium-os:39522
TEST=suspend_stress_test

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

UPSTREAM: mmc: dw_mmc: enable controller interrupt before calling mmc_start_host

As mmc_start_host is getting called before enabling the dw_mmc controller
interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
very first command sent by the sdio_reset.

This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG=n.
This patch enables the dw_mmc controller interrupt before mmc_start_host.

BUG=chrome-os-partner:17015
TEST=Stress test on flaky device that generates CRC errors.

Signed-off-by: Yuvaraj CD <yuvaraj.cd@samsung.com>
Reviewed-by: Girish K S <girish.shivananjappa@linaro.org>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Change-Id: I02ffde04115a707d03d694d3539b3111007cd58c
(cherry picked from commit 2da1d7f2948900cd50d38643db39f790edb3cc96)
Reviewed-on: https://gerrit.chromium.org/gerrit/45581
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>

UPSTREAM: mmc: dw_mmc: correct mishandling error interrupt

Datasheet of SYNOPSYS mentions that DTO(Data Transfer Over) interrupt
will be raised even if some error interrupts, however it is actually
found that DTO does not occur. SYNOPSYS has confirmed this issue.
Current implementation defers the call of tasklet_schedule until DTO
when the error interrupts is happened. This patch fixes error handling.

BUG=chrome-os-partner:17015
TEST=Stress test on flaky device that generates CRC errors.

Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Change-Id: I6c9d0ccff6f23d41f9f9eb15de99fffdb3422dff
(cherry picked from commit 9b2026a12511439d906a5d8d302ae285ebe7378a)
Reviewed-on: https://gerrit.chromium.org/gerrit/45580
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>

UPSTREAM: mmc: dw_mmc: amend using error interrupt status

RINTSTS status includes masked interrupts as well as unmasked.
data_status and cmd_status are set by value of RINTSTS in interrupt handler
and tasklet finally uses it to decide whether error is happened or not.
In addition, MINTSTS status is used for setting data_status in PIO.
Masked error interrupt will not be handled and that status can be considered
non-error case.

BUG=chrome-os-partner:17015
TEST=Stress test on flaky device that generates CRC errors.

Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed By: Girish K S <girish.shivananjappa@linaro.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Change-Id: Ibf3eb215ad9b03593cf486fe483428510eb5c175
(cherry picked from commit 182c90815993452f1902837cc342ac2c05ef13f5)
Reviewed-on: https://gerrit.chromium.org/gerrit/45579
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>

UPSTREAM: mmc: dw_mmc: fix error handling in PIO mode

Data transfer will be continued until all the bytes are transmitted,
even if data crc error occurs during a multiple-block data transfer.
This means RXDR/TXDR interrupts will occurs until data transfer is
terminated. Early setting of host->sg to NULL prevents going into
xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts
occurs. And checking error interrupt status in the xxx_data_pio functions
is no need because dw_mci_interrupt does do the same. This patch also
removes it.

BUG=chrome-os-partner:17015
TEST=Stress test on flaky device that generates CRC errors.

Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Change-Id: I8f33ed81c9034c1127a363aef303f82a02acc44c
(cherry picked from commit e74f3a9c993a088f0a067e13941075e4acb7300a)
Reviewed-on: https://gerrit.chromium.org/gerrit/45578
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>

CHROMIUM: arm: exynos: s5p-mfc: Disable PMU configuration for MFC

For s5p-mfc, initializing the PMU configuration for the MFC block
appears to occasionally cause the MFC block to run in a
lower-performance state during video decoding, resulting in sub-realtime
performance for 1080p video decoding.  Revert the PMU configuration,
just for the MFC block, while further debugging occurs.

BUG=chromium:220275
TEST=local build, run on snow

Change-Id: I70b04de1cd872a9b87b6e8cf8e7e85e48c87ad87
Reviewed-on: https://gerrit.chromium.org/gerrit/45928
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>

s5p-mfc: end-of-stream handling in encoder bug fix

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit eb36209297b7aadbd3144c74cb79d35704c3086e
Original commit message as follows:

  In some circumstances after issuing the V4L2_ENC_CMD_STOP the application
  could freeze. This patch prevents this behavior.

Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: I4c2befaedf39882c86b694ce30d25367449b1260
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45101

s5p-mfc: Fix kernel warning on memory init

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit 6e83e6e25eb49dc57a69b3f8ecc1e764c9775101
Original commit message as follows:

  Cleaned up the memory devices allocation code and added
  missing device_initialize() call to remove the kernel warning
  during memory allocations.

Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: Ie9cf1d8fcdc3e70acf23329449c8985eab5cd68e
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45100

s5p-mfc: Use WARN_ON(condition) directly

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit e82564475eab196b2e8a11572fff8e268329530e
Original commit message as follows:

  Use WARN_ON(condition) directly instead of wrapping around an if
  condition.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: Iea1296a0452dd1b948bd1e6ba41b3e8149f579a3
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45099

s5p-mfc: Use NULL instead of 0 for pointer

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit 0e5d61d87b3a1ad5591e0dfbe4c548f862e9f5a6
Original commit message as follows:

  Fixes the following warning:
  drivers/media/video/s5p-mfc/s5p_mfc_opr.c:56:27: warning:
  Using plain integer as NULL pointer

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: I94dadee385729b0bd35639d6a1f3b3f937370499
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45098

s5p-mfc: Fix a watchdog bug

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit 33133ea7aca7eedf8b1b4cee514c76dce7654a8c
Original commit message as follows:

  Fixed wrong condition in firmware reload function used by the watchdog.

Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: I484659ec7100051b83df128a6aef28f02df91a3e
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45097

CHROMIUM: s5p-mfc: fix DISPLAY_DELAY

V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE is being
ignored, and the display delay is always being applied.  Fix this.

Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium:175638
BUG=chromium-os:38121
BUG=chromium-os:38376
BUG=chromium-os:38693
TEST=local build, run on snow

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

CHROMIUM: s5p-mfc: Fix input/output format reporting

The video encode/decode paths have duplicated logic between
VIDIOC_TRY_FMT and VIDIOC_S_FMT that should be de-duped.  Also, video
decode reports V4L2_PIX_FMT_NV12MT_16X16 output format, regardless of
what the actual output has been set at.  Fix this.

Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
TEST=local build, run on snow

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

exynos/mfc: add mfc device to power domain

This patch adds the mfc device to the genpd by calling the
function 'pm_genpd_of_add_device_by_name'. The power domain
is found by searching for a of property 'samsung,pd' in the of node.

BUG=chrome-os-partner:11793
Test=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: I171fab67eb63a2e779dd2405befb080b35fa018e
Signed-off-by: Naveen krishna Chatradhi <ch.naveen@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29164
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45653
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>

exynos/mfc: add sysmmu power on/off calls

This patch calls the sysmmu driver helper functions for resuming
and suspending its two sysmmus during mfc power on/off. This is required
for the sysmmus to resume/suspend along with the parent mfc device.

BUG=chrome-os-partner:11793
TEST=MFC/GSC/Sysmmu get suspended after probe and resume upon
video playback. Tested on Daisy.

Change-Id: I3faacf3dfc397c72402e9c981ff314007c94887d
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/29165
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42960
Commit-Queue: John Sheu <sheu@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44767

arm: exynos: sysmmu: release iommu mapping during module exit

This change will add support for detaching iommu mapping, domain
and switchoff the hardware for an attached device.

This commit adds the following changes:
a) support in dma-mapping framework to call iommu_detach_device()
b) support in the exynos to call arm_iommu_detach_device() and
   arm_iommu_release_mapping()
c) changes to the module exit of drm_drv, drm_fimd, gsc, tv and mfc

BUG=chrome-os-partner:11310
TEST=none

Change-Id: I35afd8c96ea3ad8427d9b8a7c0cf449aa4121f4e
Signed-off-by: Subash Patel <subash.ramaswamy@linaro.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27362
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Anush Elangovan <anush@google.com>
Reviewed-by: Anush Elangovan <anush@google.com>
Reviewed-by: Pawel Osciak <posciak@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45652
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>

ARM: EXYNOS: MFC: Add IOMMU mapping to MFC probe

IOMMU mapping is created for mfc device during probe. This
requires the sysmmu_l and sysmmu_r property be set in the DTS
file. First, the sysmmu device nodes are found and then the
sysmmu platform devices are retrieved. A IOMMU mapping is then created
for mfc_l and mfc_r devices.

Change-Id: Ic7e6669911d2629c8872e78e5e187950484a8c35
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/42958
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45096
Reviewed-by: John Sheu <sheu@chromium.org>

s5p-mfc: remove V4L2_FL_LOCK_ALL_FOPS from s5p-mfc

<UPSTREAM MERGE NOT REQUIRED>

The upstream (3.9+) s5p-mfc driver handles its own locking.

BUG=chromium-os:38376
TEST=local build, run on snow

Change-Id: I0aaff284a6b0a156f10d5dca39b5ee37f3287e9c
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45095

CHROMIUM: rtc: fix bug with setting control register

A bit in the RTC_CONTROL register was accidentally lost in cmos_caused_wake.
It seems that this effectively moved us from 24 hour format to 12 hour format in
practice. This can cause the time from the RTC to be misinterpreted, so the
system will read the wrong time from the RTC. It might then go back to an
old value for the system time (and also store that in the RTC).

BUG=chromium:216936
TEST=suspend resume system (with dark resume happening)

Change-Id: I1425b857caf49ce3e538dfc05b981153729565f9
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45823
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>

s5p-mfc: merge upstream merge

<UPSTREAM MERGE NOT REQUIRED>

linux-media commit a32f7d1ad3744914273c6907204c2ab3b5d496a0
Only changes to drivers/media/video/s5p-mfc are merged here.
Original commit message follows:

  Merge branch 'v4l_for_linus' into staging/for_v3.9

  * v4l_for_linus: (464 commits)
    [media] uvcvideo: Set error_idx properly for S_EXT_CTRLS failures
    [media] uvcvideo: Cleanup leftovers of partial revert
    [media] uvcvideo: Return -EACCES when trying to set a read-only control
    Linux 3.8-rc3
    mm: reinstante dropped pmd_trans_splitting() check
    cred: Remove tgcred pointer from struct cred
    drm/ttm: fix fence locking in ttm_buffer_object_transfer
    ARM: clps711x: Fix bad merge of clockevents setup
    ARM: highbank: save and restore L2 cache and GIC on suspend
    ARM: highbank: add a power request clear
    ARM: highbank: fix secondary boot and hotplug
    ARM: highbank: fix typos with hignbank in power request functions
    ARM: dts: fix highbank cpu mpidr values
    ARM: dts: add device_type prop to cpu nodes on Calxeda platforms
    drm/prime: drop reference on imported dma-buf come from gem
    xen/netfront: improve truesize tracking
    ARM: mx5: Fix MX53 flexcan2 clock
    ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array
    sctp: fix Kconfig bug in default cookie hmac selection
    EDAC: Cleanup device deregistering path
    ...

  Conflicts:
    drivers/media/pci/dm1105/dm1105.c
    drivers/media/video/soc_camera/mx2_camera.c

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

CHROMIUM: Disable USB persist system-wide by default.

This patch effectively reverts upstream commit 9214d1d8, which enabled
USB persist by default. We have long had disabled persist on ChromeOS
through an explicit sysfs write from powerd_suspend to save kernel
resume time. This change will make that solution obsolete by disabling
persist by default from the kernel, resulting in a much cleaner system
state that does not flip-flop between persist/non-persist during
suspend/resume. This will also solve issues with autosuspend on drivers
that do not provide a reset_resume method.

BUG=chrome-os-partner:17609
TEST=Boot kernel, make sure that /sys/bus/usb/devices/*/power/persist
are all zeroes (and stay that way over suspend and when plugging in more
devices).

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

CHROMIUM: MFC video nodes should start from video10

This restores a patch that was overwritten by MFC driver backport.
This workaround is required for factory camera tests that don't understand
mem2mem devices and fail on trying to interrogate MFC.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=chromium:222071
TEST=manual

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

Restrict DP sink wake up to non-EDP.

Doing it on EDP was producing a kernel warning with screen power down.

BUG=chrome-os-partner:17893
TEST=No warning with screen power down.  Apple mini DP->VGA adapter still works.

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

v4l2-dev: add flag to have the core lock all file operations

This used to be the default if the lock pointer was set, but now that lock is by
default only used for ioctl serialization. Those drivers that already used
core locking have this flag set explicitly, except for some drivers where
it was obvious that there was no need to serialize any file operations other
than ioctl.

The drivers that didn't need this flag were:

drivers/media/radio/dsbr100.c
drivers/media/radio/radio-isa.c
drivers/media/radio/radio-keene.c
drivers/media/radio/radio-miropcm20.c
drivers/media/radio/radio-mr800.c
drivers/media/radio/radio-tea5764.c
drivers/media/radio/radio-timb.c
drivers/media/video/vivi.c
sound/i2c/other/tea575x-tuner.c

The other drivers that use core locking and where it was not immediately
obvious that this flag wasn't needed were changed so that the flag is set
together with a comment that that driver needs work to avoid having to
set that flag. This will often involve taking the core lock in the fops
themselves.

Eventually this flag should go and it should not be used in new drivers.

There are a few reasons why we want to avoid core locking of non-ioctl
fops: in the case of mmap this can lead to a deadlock in rare situations
since when mmap is called the mmap_sem is held and it is possible for
other parts of the code to take that lock as well (copy_from_user()/copy_to_user()
perform a down_read(&mm->mmap_sem) when a page fault occurs).

It is very unlikely that that happens since the core lock serializes all
fops, but the kernel warns about it if lock validation is turned on.

For poll it is also undesirable to take the core lock as that can introduce
increased latency. The same is true for read/write.

While it was possible to make flags or something to turn on/off taking the
core lock for each file operation, in practice it is much simpler to just
not take it at all except for ioctl and leave it to the driver to take the
lock. There are only a handful fops compared to the zillion ioctls we have.

I also wanted to make it obvious which drivers still take the lock for all
fops, so that's why I chose to have drivers set it explicitly.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change-Id: I0dc54aee9b2797dd1e799254a928af06524f45b0
Reviewed-on: https://gerrit.chromium.org/gerrit/45651
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>

Bluetooth: update stack to 3.8

AceLan Kao (3):
      Bluetooth: Add support for IMC Networks [13d3:3393]
      Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]
      Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]

Anderson Lizardo (1):
      Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

Andre Guedes (48):
      Bluetooth: Check FINDING state in interleaved discovery
      Bluetooth: Add hci_cancel_le_scan() to hci_core
      Bluetooth: LE support for MGMT stop discovery
      Bluetooth: Replace EPERM by EALREADY in hci_cancel_inquiry
      Bluetooth: Refactor stop_discovery
      Bluetooth: Add Periodic Inquiry command complete handler
      Bluetooth: Add HCI_PERIODIC_INQ to dev_flags
      Bluetooth: Check HCI_PERIODIC_INQ in start_discovery
      Bluetooth: Ignore inquiry results from periodic inquiry
      Bluetooth: Add Periodic Inquiry command complete handler
      Bluetooth: Add HCI_PERIODIC_INQ to dev_flags
      Bluetooth: Remove MGMT_ADDR_INVALID macro
      Bluetooth: Remove useless code in hci_connect
      Bluetooth: Move address type macros to bluetooth.h
      Bluetooth: Rename link_to_mgmt to link_to_bdaddr
      Bluetooth: Add address type to struct sockaddr_l2
      Bluetooth: Rename mgmt_to_le to bdaddr_to_le
      Bluetooth: Move bdaddr_to_le to hci_core
      Bluetooth: Add dst_type parameter to hci_connect
      Bluetooth: Use address type info from user-space
      Bluetooth: Remove advertising cache
      Bluetooth: Change default MTU for L2CAP ATT channel
      Bluetooth: Check MTU value in l2cap_sock_setsockopt_old
      Bluetooth: Rename L2CAP_LE_DEFAULT_MTU
      Bluetooth: Filter duplicated reports in LE scan
      Bluetooth: Remove magic value in disconnect mgmt handler
      Bluetooth: Use GFP_KERNEL in mgmt_handlers
      Bluetooth: Use GFP_KERNEL in mgmt_pending_add
      Bluetooth: Use GFP_KERNEL in mgmt events functions
      Bluetooth: Remove missing code
      Bluetooth: Use lmp_bredr_capable where applicable
      Bluetooth: Use lmp_le_capable where applicable
      Bluetooth: Use lmp_ssp_capable where applicable
      Bluetooth: Use lmp_esco_capable where applicable
      Bluetooth: Use lmp_rswitch_capable where applicable
      Bluetooth: Use lmp_sniff_capable where applicable
      Bluetooth: Use lmp_sniffsubr_capable where applicable
      Bluetooth: Use lmp_no_flush_capable where applicable
      Bluetooth: Remove locking in hci_user_passkey_request_evt
      Bluetooth: Trivial refactoring
      Bluetooth: Fix hci_le_conn_complete_evt
      Bluetooth: Remove unneeded code
      Bluetooth: Refactor hci_cs_le_create_conn
      Bluetooth: Find hci_conn by BT_CONNECT state
      Bluetooth: Lookup hci_conn in hci_le_conn_complete_evt
      Bluetooth: Refactor in hci_le_conn_complete_evt
      Bluetooth: Fix use-after-free bug in SMP
      Bluetooth: Fix hci_conn timeout routine

Andrei Emeltchenko (181):
      Revert "CHROMIUM: bluetooth: initialize rfc struct in l2cap_core.c"
      Bluetooth: trivial: Correct endian conversion
      Bluetooth: Correct type for hdev lmp_subver
      Bluetooth: Correct type for ediv to __le16
      Bluetooth: Fix extra conversion to __le32
      Bluetooth: Correct chan->psm endian conversions
      Bluetooth: Correct ediv in SMP
      Bluetooth: Correct length calc in L2CAP conf rsp
      Bluetooth: Correct CID endian notation
      Bluetooth: Convert error codes to le16
      Bluetooth: trivial: Fix endian conversion mode
      Bluetooth: trivial: Correct types
      Bluetooth: Fix type in cpu_to_le conversion
      Bluetooth: Fix opcode access in hci_complete
      Bluetooth: trivial: Remove sparse warnings
      Bluetooth: Silence sparse warning
      Bluetooth: Comments and style fixes
      Bluetooth: Remove unneeded timer clear
      Bluetooth: Make L2CAP chan_add functions static
      Bluetooth: Remove unneeded zero initialization
      Bluetooth: Add Read Local AMP Info to init
      Bluetooth: Adds set_default function in L2CAP setup
      Bluetooth: Fix debug printing unallocated name
      Bluetooth: trivial: Remove empty line
      Bluetooth: Remove unneeded calculation and magic number
      Bluetooth: Silent sparse warnings
      Bluetooth: Use defined link key size
      Bluetooth: Preserve L2CAP flags values
      Bluetooth: trivial: Remove empty line
      Bluetooth: Define L2CAP conf continuation flag
      Bluetooth: Define and use PSM identifiers
      Bluetooth: Use __constant when dealing with constants
      Bluetooth: Use __constant modifier in HCI code
      Bluetooth: Define HCI AMP cmd struct
      Bluetooth: Move clean up code and set of SOCK_ZAPPED to l2cap_sock.c
      Bluetooth: Add l2cap_chan->ops->ready()
      Bluetooth: trivial: Use defined PSMLEN instead of magic
      Bluetooth: A2MP: Create A2MP channel
      Bluetooth: A2MP: AMP Manager basic functions
      Bluetooth: A2MP: Build and Send msg helpers
      Bluetooth: A2MP: Add chan callbacks
      Bluetooth: A2MP: Definitions for A2MP commands
      Bluetooth: A2MP: Define A2MP status codes
      Bluetooth: A2MP: Process A2MP messages
      Bluetooth: A2MP: Process A2MP Command Reject
      Bluetooth: A2MP: Process A2MP Discover Request
      Bluetooth: A2MP: Process A2MP Change Notify
      Bluetooth: A2MP: Process A2MP Get Info Request
      Bluetooth: A2MP: Process A2MP Get AMP Assoc Request
      Bluetooth: A2MP: Process A2MP Create Physlink Request
      Bluetooth: A2MP: Process A2MP Disc Physlink Request
      Bluetooth: A2MP: Process A2MP Command Responses
      Bluetooth: A2MP: Handling fixed channels
      Bluetooth: A2MP: Manage incoming connections
      Bluetooth: Do not check func ready existence
      Bluetooth: A2MP: Do not reference hci_conn
      Bluetooth: Make l2cap_data_channel return void
      Bluetooth: Make l2cap_conless_channel return void
      Bluetooth: Make l2cap_att_channel return void
      Bluetooth: Remove magic disconnect reason
      Bluetooth: Use standard HCI cmd timeout for RESET
      Bluetooth: Update HCI timeouts constants to use msecs_to_jiffies
      Bluetooth: Add opcode to error message
      Bluetooth: Correct debug print specifier for u16 objects
      Bluetooth: Fix not setting HCI_RESET flag for AMP
      Bluetooth: Fix compile warnings in mgmt
      Bluetooth: Use AUTO_OFF constant in jiffies
      Bluetooth: btmrvl: Do not send vendor events to bluetooth stack
      Bluetooth: Improve debugging messages for hci_conn
      Bluetooth: Fix warning: using int as NULL pointer
      Bluetooth: Route traffic only through BR/EDR controller
      Bluetooth: bluecard_cs: Shorten scope for iobase
      Bluetooth: Do not auto off AMP controller
      Bluetooth: btmrvl: trivial style fixes
      Bluetooth: debug: Add printing num of cmds queued
      Bluetooth: debug: Correct types specifiers for L2CAP
      Bluetooth: debug: Print CID and PSM in hex format
      Bluetooth: debug: Add debug to l2cap_security_cfm
      Bluetooth: debug: Use standard hex object specifiers in hci_event
      Bluetooth: debug: Print l2cap_chan refcount
      Bluetooth: debug: Print amp_mgr refcnt
      Bluetooth: mgmt: Managing only BR/EDR HCI controllers
      Bluetooth: debug: Fix printing A2MP cmd code format
      Bluetooth: debug: Fix printing refcnt for hci_conn
      Bluetooth: trivial: Fix mixing spaces and tabs in smp
      Bluetooth: Define AMP controller statuses
      Bluetooth: Do not shadow hdr variable
      Bluetooth: Fix processing A2MP chan in security_cfm
      Bluetooth: Make connect / disconnect cfm functions return void
      Bluetooth: smp: Fix possible NULL dereference
      Bluetooth: trivial: Shorten variable scope
      Bluetooth: trivial: Use preferred method for NULL check
      Bluetooth: Remove unneeded zero init
      Bluetooth: trivial: Make hci_chan_del return void
      Bluetooth: trivial: Remove empty line
      Bluetooth: debug: Print refcnt for hci_dev
      Bluetooth: AMP: Add Read Data Block Size to amp_init
      Bluetooth: Fix freeing uninitialized delayed works
      Bluetooth: Add HCI logical link cmds definitions
      Bluetooth: A2MP: Create amp_mgr global list
      Bluetooth: AMP: Use HCI cmd to Read AMP Info
      Bluetooth: AMP: Use HCI cmd to Read Loc AMP Assoc
      Bluetooth: A2MP: Process Discover Response
      Bluetooth: AMP: Physical link struct and helpers
      Bluetooth: AMP: Remote AMP ctrl definitions
      Bluetooth: AMP: Handle create / disc phylink req
      Bluetooth: A2MP: Process A2MP Getinfo Rsp
      Bluetooth: A2MP: Process A2MP Get AMP Assoc Rsp
      Bluetooth: Choose connection based on capabilities
      Bluetooth: AMP: Add AMP key calculation
      Bluetooth: AMP: Create Physical Link
      Bluetooth: AMP: Write remote AMP Assoc
      Bluetooth: A2MP: Add fallback to normal l2cap init sequence
      Bluetooth: AMP: Process Chan Selected event
      Bluetooth: AMP: Accept Physical Link
      Bluetooth: AMP: Handle Accept phylink command status evt
      Bluetooth: Use %pMR in debug instead of batostr
      Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr
      Bluetooth: Use %pMR instead of baswap in seq_show
      bluetooth: Remove unneeded batostr function
      Bluetooth: Factor out hci_queue_acl
      Bluetooth: Factor out Create Configuration Response
      Bluetooth: Use %zu print specifier for size_t type
      Bluetooth: A2MP: Correct assoc_len size
      Bluetooth: btmrvl: Correct num_block name
      Bluetooth: btmrvl: Use DIV_ROUND_UP macro
      Bluetooth: btmrvl: Fix skb buffer overflow
      Bluetooth: A2MP: Fix potential NULL dereference
      Bluetooth: AMP: Fix possible NULL dereference
      Bluetooth: Fix dereference after NULL check
      Bluetooth: AMP: Factor out amp_ctrl_add
      Bluetooth: AMP: Factor out phylink_add
      Bluetooth: AMP: Use block_mtu for AMP controller
      Bluetooth: Adjust L2CAP Max PDU size for AMP packets
      Bluetooth: L2CAP: Fix using default Flush Timeout for EFS
      Bluetooth: btmrv: Use %*ph specifier instead of print_hex_dump_bytes
      Bluetooth: Allow to set flush timeout
      Bluetooth: AMP: Handle AMP_LINK timeout
      Bluetooth: AMP: Add handle to hci_chan structure
      Bluetooth: AMP: Handle number of compl blocks for AMP_LINK
      Bluetooth: AMP: Handle AMP_LINK connection
      Bluetooth: AMP: Hanlde AMP_LINK case in conn_put
      Bluetooth: AMP: Use Loglink handle in ACL Handle field
      Bluetooth: AMP: Handle complete frames in l2cap
      Bluetooth: AMP: Drop packets when no l2cap conn exist
      Bluetooth: Send EFS Conf Rsp only for BR/EDR chan
      Bluetooth: Zero bredr pointer when chan is deleted
      Bluetooth: AMP: Get amp_mgr reference in HS hci_conn
      Bluetooth: trivial: Remove unneeded assignment
      Bluetooth: Use helper function sending EFS conf rsp
      Bluetooth: AMP: Process Physical Link Complete evt
      Bluetooth: AMP: Process Logical Link complete evt
      Bluetooth: Add put(hcon) when deleting hchan
      Bluetooth: trivial: Fix braces style and remove empty line
      Bluetooth: Save hs_hchan instead of hs_hcon in loglink complete
      Bluetooth: Return correct L2CAP response type
      Bluetooth: Derive remote and local amp id from chan struct
      Bluetooth: AMP: Add Logical Link Create function
      Bluetooth: AMP: Process Disc Logical Link
      Bluetooth: AMP: Process Disc Physical Link Complete evt
      Bluetooth: AMP: Remove hci_conn receiving error command status
      Bluetooth: Disconnect logical link when deleting chan
      Bluetooth: AMP: Check for hs_hcon instead of ctrl_id
      Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evt
      Bluetooth: Process Create Chan Request
      Bluetooth: Rename ctrl_id to remote_amp_id
      Bluetooth: Use __l2cap_no_conn_pending helper
      Bluetooth: Remove unneeded local_amp_id initialization
      Bluetooth: Refactor locking in amp_physical_cfm
      Bluetooth: Disable FCS only for new HS channels
      Bluetooth: trivial: Use __constant for constants
      Bluetooth: Fix sending L2CAP Create Chan Req
      Bluetooth: Set local_amp_id after getting Phylink Completed evt
      Bluetooth: Improve error message printing
      Bluetooth: AMP: Set no FCS for incoming L2CAP chan
      Bluetooth: Refactor l2cap_send_disconn_req
      Bluetooth: AMP: Mark controller radio powered down after HCIDEVDOWN
      Bluetooth: AMP: Check that AMP is present and active
      Bluetooth: Fix missing L2CAP EWS Conf parameter
      Bluetooth: Process receiving FCS_NONE in L2CAP Conf Rsp
      Bluetooth: trivial: Change NO_FCS_RECV to RECV_NO_FCS

Andrzej Kaczmarek (5):
      Bluetooth: Allow only one LE connection attempt
      Bluetooth: Return proper mgmt state when LE pairing connection failed
      Bluetooth: Fix not removing hci_conn for failed LE connection
      Bluetooth: mgmt: Fix enabling SSP while powered off
      Bluetooth: mgmt: Fix enabling LE while powered off

Bing Zhao (1):
      Bluetooth: btmrvl: add SD8787 Bluetooth AMP device ID

Cristian Chilipirea (1):
      Bluetooth: Fixed checkpatch warnings

David Herrmann (5):
      Bluetooth: Remove redundant hdev->parent field
      Bluetooth: vhci: Ignore return code of nonseekable_open()
      Bluetooth: Move hci_alloc/free_dev close to hci_register/unregister_dev
      Bluetooth: Move device initialization to hci_alloc_dev()
      Bluetooth: Remove unneeded initialization in hci_alloc_dev()

Denis Kirjanov (1):
      Bluetooth:Replace list_for_each with list_for_each_entry() helper

Devendra Naga (1):
      Bluetooth: cleanup dtl1_config

Dmitry Kasatkin (1):
      Bluetooth: Add function to derive AMP key using hmac

Eldad Zack (1):
      Bluetooth: bnep: use constant for ethertype

Frédéric Dalleau (2):
      Bluetooth: Add BT_DEFER_SETUP option to sco socket
      Bluetooth: Implement deferred sco socket setup

Giancarlo Formicuccia (1):
      Bluetooth: add support for atheros 0930:0219

Gustavo Padovan (59):
      Bluetooth: Remove sk parameter from l2cap_chan_create()
      Bluetooth: Remove err parameter from alloc_skb()
      Bluetooth: remove unneeded declaration of sco_conn_del()
      Bluetooth: Remove unneeded elements from size calculation
      Bluetooth: Remove hlen variable
      Bluetooth: Fix wrong set of skb fragments
      Bluetooth: Fix packet size provided to the controller
      Bluetooth: Fix skb length calculation
      Bluetooth: improve readability of l2cap_seq_list code
      Bluetooth: report the right security level in getsockopt
      Bluetooth: Create flags for bt_sk()
      Bluetooth: Report proper error number in disconnection
      Bluetooth: Fix coding style in mgmt.c
      Bluetooth: Fix coding style in sco.c
      Bluetooth: Fix coding style in hci_sock.c
      Bluetooth: Fix coding style in hci_sysfs.c
      Bluetooth: Fix coding style in hci_event.c
      Bluetooth: Fix coding style in hci_conn.c
      Bluetooth: Fix coding style in hci_core.c
      Bluetooth: Do not purge queue in Basic Mode
      Bluetooth: Remove double check for BT_CONNECTED
      Bluetooth: Remove dead int returns
      Bluetooth: Fix trailing whitespaces in license text
      Bluetooth: Remove most of the inline usage
      Bluetooth: Remove 'register' usage from the subsystem
      Bluetooth: Fix coding style in include/net/bluetooth
      Bluetooth: Fix coding style in the subsystem
      Bluetooth: Remove unnecessary headers include
      Bluetooth: Remove unneeded EXPORT_SYMBOL
      Bluetooth: Use lmp_ssp_capable() macro
      Bluetooth: Get a more accurate L2CAP PDU len
      Bluetooth: Remove extra l2cap_state_change(BT_CONNECTED)
      Bluetooth: Use l2cap_chan_ready() in LE path
      Bluetooth: Use chan as parameters for l2cap chan ops
      Bluetooth: Use chan->state instead of sk->sk_state
      Bluetooth: Move check for backlog size to l2cap_sock.c
      Bluetooth: check for already existent channel before create new one
      Bluetooth: Create function to return the ERTM header size
      Bluetooth: Remove unused err var from l2cap_segment_sdu()
      Bluetooth: Create empty l2cap ops function
      Bluetooth: Fix style in hidp code
      Bluetooth: Fix possible deadlock in SCO code
      Bluetooth: Use USB_VENDOR_AND_INTERFACE() for Broadcom devices
      Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
      Bluetooth: Fix two warnings in BT_DBG
      Bluetooth: Fix L2CAP coding style
      Bluetooth: Remove GFP_ATOMIC usage from l2cap_core.c
      Bluetooth: use l2cap_chan_set_err()
      Bluetooth: Use locked l2cap_state_change()
      Bluetooth: Call ops->teardown() without checking for NULL
      Bluetooth: Move bt_accept_enqueue() to l2cap_sock.c
      Bluetooth: Add chan->ops->defer()
      Bluetooth: Rename __l2cap_connect() to l2cap_connect()
      Bluetooth: Replace *_init() for *_setup()
      Bluetooth: Add missing lock nesting notation
      Bluetooth: cancel power_on work when unregistering the device
      Bluetooth: Move double negation to macros
      Revert "Bluetooth: Fix possible deadlock in SCO code"
      Bluetooth: Check if the hci connection exists in SCO shutdown

Hemant Gupta (5):
      Bluetooth: Send correct address type for LTK
      Bluetooth: Fix clearing discovery type when stopping discovery
      Bluetooth: mgmt: Fix missing connect failed event for LE
      Bluetooth: mgmt: Fix address type while loading Long Term Key
      Bluetooth: Don't distribute keys in case of Encryption Failure

Henrik Rydberg (1):
      Bluetooth: Add support for Apple vendor-specific devices

Ido Yariv (1):
      Bluetooth: Search global l2cap channels by src/dst addresses

Jaganath Kanakkassery (5):
      Bluetooth: Refactor PIN code rejection to use user_pairing_resp()
      Bluetooth: Move l2cap_chan_hold/put to l2cap_core.c
      Bluetooth: Free the l2cap channel list only when refcount is zero
      Bluetooth: Fix socket not getting freed if l2cap channel create fails
      Bluetooth: Fix authentication if acl data comes before remote feature evt

Jaroslav Resler (1):
      Bluetooth: Add support for BCM20702A0 [04ca, 2003]

Jeff Cook (1):
      Bluetooth: Add support for BCM20702A0 [0b05, 17b5]

Jefferson Delfes (2):
      Bluetooth: Fix flags of mgmt_device_found event
      Bluetooth: Force the process of unpair command if disconnect failed

Jesper Juhl (1):
      Bluetooth: btmrvl_sdio: remove pointless conditional before release_firmware()

Joe Perches (1):
      bluetooth: Convert compare_ether_addr to ether_addr_equal

Johan Hedberg (49):
      Bluetooth: Fix Inquiry with RSSI event mask
      Bluetooth: Fix SMP pairing method selection
      Bluetooth: Fix deadlock and crash when SMP pairing times out
      Bluetooth: Fix SMP security elevation from medium to high
      Bluetooth: Add support for encryption key refresh
      Bluetooth: Change page scan interval in fast connectable mode
      Bluetooth: Initial skeleton for Three-wire UART (H5) support
      Bluetooth: Add basic state tracking to Three-wire UART driver
      Bluetooth: Add initial reliable packet support for Three-wire UART
      Bluetooth: Add basic packet parsing to Three-wire UART driver
      Bluetooth: Add initial packet sending support to Three-wire UART
      Bluetooth: Add Three-wire header value convenience macros
      Bluetooth: Fix/implement Three-wire reliable packet sending
      Bluetooth: Add support for Three-wire Link Control packets
      Bluetooth: Simplify hci_uart_tty_close logic
      Bluetooth: Add delayed init sequence support for UART controllers
      Bluetooth: Use delayed init for Three-wire UART
      Bluetooth: Improve rx debug logs for Three-wire UART
      Bluetooth: Add initial sleep support to Three-wire UART
      Bluetooth: Add initialization tracking to HCI Three-wire driver
      Bluetooth: Implement proper low-power support for Three-wire UART
      Bluetooth: Remove unnecessary h5_build_pkt function
      Bluetooth: Improve Three-wire UART configuration handling
      Bluetooth: Introduce a flags variable to Three-wire UART state
      Bluetooth: mgmt: Implement support for passkey notification
      Bluetooth: Update management interface revision
      Bluetooth: SMP: Fix setting unknown auth_req bits
      Bluetooth: Add initial support for LE-only controllers
      Bluetooth: Fix LE MTU reporting for HCIGETDEVINFO
      Bluetooth: Add setting of the LE event mask
      Bluetooth: Read adversiting channel TX power during init sequence
      Bluetooth: Fix HCI command sending when powering on LE-only adapters
      Bluetooth: mgmt: Restrict BR/EDR settings to BR/EDR-only adapters
      Bluetooth: Fix updating host feature bits for LE
      Bluetooth: Add missing feature test macros
      Bluetooth: Make use feature test macros
      Bluetooth: Add flag for LE GAP Peripheral role
      Bluetooth: Disallow LE scanning and connecting in peripheral role
      Bluetooth: Fix setting host feature bits for SSP
      Bluetooth: Fix sending unnecessary HCI_Write_SSP_Mode command
      Bluetooth: Fix unnecessary EIR update during powering on
      Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
      Bluetooth: Fix parameter order of hci_get_route
      Bluetooth: Fix having bogus entries in mgmt_read_index_list reply
      Bluetooth: Fix memory leak when removing a UUID
      Bluetooth: Use proper invalid value for tx_power
      Bluetooth: Add support for setting LE advertising data
      Bluetooth: Fix updating advertising state flags and data
      Bluetooth: Fix handling of unexpected SMP PDUs

Lamarque V. Souza (1):
      HID: hidp: fallback to input session properly if hid is blacklisted

Lukasz Rymanowski (1):
      Bluetooth: Remove not needed status parameter

Manoj Iyer (1):
      Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0

Marcel Holtmann (12):
      Bluetooth: Add TX power tag to EIR data
      Bluetooth: Handle EIR tags for Device ID
      Bluetooth: Add management command for setting Device ID
      Bluetooth: Fix broken usage of put_unaligned_le16
      Bluetooth: Fix broken usage of get_unaligned_le16
      Bluetooth: Update management interface revision
      Bluetooth: Split error handling for L2CAP listen sockets
      Bluetooth: Split error handling for SCO listen sockets
      Bluetooth: Don't check source address in SCO bind function
      Bluetooth: Restrict to one SCO listening socket
      Bluetooth: Enable Low Energy support by default
      Bluetooth: Notify about device registration before power on

Marcos Chaparro (1):
      Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027]

Marek Vasut (1):
      Bluetooth: Support AR3011 in Acer Iconia Tab W500

Masatake YAMATO (8):
      Bluetooth: /proc/net/ entries for bluetooth protocols
      Bluetooth: Added /proc/net/bnep via bt_procfs_init()
      Bluetooth: Added /proc/net/cmtp via bt_procfs_init()
      Bluetooth: Added /proc/net/hci via bt_procfs_init()
      Bluetooth: Added /proc/net/hidp via bt_procfs_init()
      Bluetooth: Added /proc/net/l2cap via bt_procfs_init()
      Bluetooth: Added /proc/net/rfcomm via bt_procfs_init()
      Bluetooth: Added /proc/net/sco via bt_procfs_init()

Mat Martineau (66):
      Bluetooth: Add definitions and struct members for new ERTM state machine
      Bluetooth: Add a structure to carry ERTM data in skb control blocks
      Bluetooth: Add the l2cap_seq_list structure for tracking frames
      Bluetooth: Functions for handling ERTM control fields
      Bluetooth: Improve ERTM sequence number offset calculation
      Bluetooth: Remove duplicate structure members from bt_skb_cb
      Bluetooth: Move recently-added ERTM header packing functions
      Bluetooth: Initialize new l2cap_chan structure members
      Bluetooth: Remove unused function
      Bluetooth: Make better use of l2cap_chan reference counting
      Bluetooth: Add Code Aurora Forum copyright
      Bluetooth: Refactor L2CAP ERTM and streaming transmit segmentation
      Bluetooth: Update tx_send_head when sending ERTM data
      Bluetooth: Initialize the transmit queue for L2CAP streaming mode
      Bluetooth: Fix a redundant and problematic incoming MTU check
      Bluetooth: Restore locking semantics when looking up L2CAP channels
      Bluetooth: Lock the L2CAP channel when sending
      Bluetooth: Free allocated ERTM SREJ list if init fails
      Bluetooth: Fix early return from l2cap_chan_del
      Bluetooth: Change default state of ERTM disable flag
      Bluetooth: Add a new L2CAP ERTM transmit state machine.
      Bluetooth: Refactor l2cap_streaming_send
      Bluetooth: Refactor l2cap_ertm_send
      Bluetooth: Refactor l2cap_send_sframe
      Bluetooth: Consolidate common receive code for ERTM and streaming mode
      Bluetooth: Add streaming mode receive and incoming packet classifier
      Bluetooth: Remove receive code that has been superceded
      Bluetooth: Refactor l2cap_send_ack
      Bluetooth: Use the transmit state machine for busy state changes
      Bluetooth: Update l2cap_send_i_or_rr_or_rnr to fit the spec better
      Bluetooth: Add the ERTM receive state machine
      Bluetooth: Add implementation for retransmitting all unacked frames
      Bluetooth: Send SREJ frames when packets go missing
      Bluetooth: Reassemble all available data when retransmissions succeed.
      Bluetooth: Handle SREJ requests to resend unacked frames
      Bluetooth: Handle incoming REJ frames
      Bluetooth: Use new header structures in l2cap_send_rr_or_rnr
      Bluetooth: Check rules when setting retransmit or monitor timers
      Bluetooth: Use the ERTM transmit state machine from timeout handlers
      Bluetooth: Simplify the ERTM ack timeout
      Bluetooth: Remove unneccesary inline
      Bluetooth: Set txwin values for streaming mode
      Bluetooth: Remove unused ERTM control field macros
      Bluetooth: Enable ERTM by default
      Bluetooth: Send a configuration request after security confirmation
      Bluetooth: Use tx window from config response for ack timing
      Bluetooth: Process create response and connect response identically
      Bluetooth: Factor out common L2CAP connection code
      Bluetooth: Add new l2cap_chan struct members for high speed channels
      Bluetooth: Add L2CAP create channel request handling
      Bluetooth: Remove unnecessary intermediate function
      Bluetooth: Lookup channel structure based on DCID
      Bluetooth: Channel move request handling
      Bluetooth: Add new ERTM receive states for channel move
      Bluetooth: Add move channel confirm handling
      Bluetooth: Add state to hci_chan
      Bluetooth: Move channel response
      Bluetooth: Add logical link confirm
      Bluetooth: Add move confirm response handling
      Bluetooth: Handle physical link completion
      Bluetooth: Flag ACL frames as complete for AMP controllers
      Bluetooth: Do not send data during channel move
      Bluetooth: Configure appropriate timeouts for AMP controllers
      Bluetooth: Ignore BR/EDR packet size constraints when fragmenting for AMP
      Bluetooth: Do not retransmit data during a channel move
      Bluetooth: Start channel move when socket option is changed

Mathias Krause (6):
      Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
      Bluetooth: HCI - Fix info leak via getsockname()
      Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
      Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
      Bluetooth: RFCOMM - Fix info leak via getsockname()
      Bluetooth: L2CAP - Fix info leak via getsockname()

Michael Gruetzner (1):
      Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C

Mikel Astiz (6):
      Bluetooth: Use unsigned int instead of signed int
      Bluetooth: Remove unnecessary check
      Bluetooth: btusb: Dynamic alternate setting
      Bluetooth: Add more HCI error codes
      Bluetooth: Fix minor coding style in hci_event.c
      Bluetooth: mgmt: Add device disconnect reason

Paulo Sérgio (1):
      Bluetooth: Fix error status when pairing fails

Peng Chen (1):
      Bluetooth: add support for atheros 0489:e057

Peter Senna Tschudin (5):
      Bluetooth: bluecard_cs.c: removes unnecessary semicolon
      Bluetooth: hci_ldisc.c: removes unnecessary semicolon
      Bluetooth: hci_ll.c: removes unnecessary semicolon
      Bluetooth: hci_vhci.c: removes unnecessary semicolon
      Bluetooth: btuart_cs.c: removes unnecessary semicolon

Ram Malovany (3):
      Bluetooth: Fix using NULL inquiry entry
      Bluetooth: Fix using a NULL inquiry cache entry
      Bluetooth: Set name_state to unknown when entry name is empty

Rami Rosen (1):
      Bluetooth: remove unused member of hci_dev.

Sachin Kamat (12):
      Bluetooth: Use devm_kzalloc in bcm203x.c file.
      Bluetooth: Use devm_kzalloc in bfusb.c file
      Bluetooth: Use devm_kzalloc in bluecard_cs.c file
      Bluetooth: Use devm_kzalloc in bpa10x.c file
      Bluetooth: Use devm_kzalloc in bt3c_cs.c file
      Bluetooth: Use devm_kzalloc in btmrvl_sdio.c file
      Bluetooth: Use devm_kzalloc in btsdio.c file
      Bluetooth: Use devm_kzalloc in btuart_cs.c file
      Bluetooth: Use devm_kzalloc in btusb.c file
      Bluetooth: Use devm_kzalloc in btwilink.c file
      Bluetooth: Use devm_kzalloc in dtl1_cs.c file
      Bluetooth: Use module_platform_driver() in btwilink.c file

Sasha Levin (2):
      Bluetooth: Really fix registering hci with duplicate name
      Bluetooth: don't attempt to free a channel that wasn't created

Syam Sidhardhan (13):
      Bluetooth: mgmt: Remove unwanted goto statements
      Bluetooth: remove header declared but not defined
      Bluetooth: Remove strtoba header declared but not defined
      Bluetooth: Remove unused hci_le_ltk_reply()
      Bluetooth: Remove unused hci_le_ltk_neg_reply()
      Bluetooth: debug: Correct the PSM printing
      Bluetooth: Use kref for l2cap channel reference counting
      Bluetooth: Use __constant modifier for L2CAP SMP CID
      Bluetooth: Use __constant modifier for RFCOMM PSM
      Bluetooth: trivial: Remove newline before EOF
      Bluetooth: Replace include linux/module.h with linux/export.h
      Bluetooth: Remove unnecessary include export.h
      Bluetooth: mgmt: Use __constant when dealing with constants

Szymon Janc (8):
      Bluetooth: mgmt: Fix some code style and indentation issues
      Bluetooth: mgmt: Don't allow to set invalid value to DeviceID source
      Bluetooth: Remove unused HCI timeouts definitions
      Bluetooth: Fix using uninitialized option in RFCMode
      Bluetooth: Fix legacy pairing with some devices
      Bluetooth: Increase HCI command tx timeout
      Bluetooth: Remove OOB data if device was discovered in band
      Bluetooth: Fix sending HCI commands after reset

Ulisses Furquim (1):
      Bluetooth: Fix registering hci with duplicate name

Vinicius Costa Gomes (13):
      Bluetooth: Add support for reusing the same hci_conn for LE links
      Bluetooth: Fix checking the wrong flag when accepting a socket
      Bluetooth: Remove some functions from being exported
      Bluetooth: Rename LE and ACL connection functions
      Bluetooth: Refactor LE connection into its own function
      Bluetooth: Refactor ACL connection into its own function
      Bluetooth: Refactor SCO connection into its own function
      Bluetooth: Simplify a the connection type handling
      Bluetooth: Add type information to the hci_connect() debug statement
      Bluetooth: Fix establishing ESCO links
      Bluetooth: Change signature of smp_conn_security()
      Bluetooth: Fix sending a HCI Authorization Request over LE links
      Bluetooth: Fix not removing power_off delayed work

Vishal Agarwal (3):
      Bluetooth: Fix EIR data generation for mgmt_device_found
      Bluetooth: Fix LE pairing completion on connection failure
      Bluetooth: Fix sending HCI_Disconnect only when connected

Wei Yongjun (1):
      Bluetooth: btmrvl: remove pointless conditional before kfree_skb()

Yevgeniy Melnichuk (1):
      Bluetooth: Add support for Sony Vaio T-Series

Zhao Hongjiang (1):
      net: change return values from -EACCES to -EPERM

BUG=chromium-os:38832
TEST=emerge-${BOARD} chromeos-kernel

Change-Id: I8e22c32da0c9b07a9dcc27ef91dcafd1f5a221da
Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44888

CHROMIUM: cpufreq: interactive: run at fraction of hispeed_freq when load is low

When load is below go_hispeed_load, apply the percentage of CPU load to
a max frequency of hispeed_freq instead of the max speed.  This avoids
jumping too quickly to hispeed_freq when it is a relatively low
percentage of max speed.  This also allows go_hispeed_load to be set to
a high percentage relative to hispeed_freq (as a percentage of max speed,
again useful when hispeed_freq is a low fraction of max speed), to cap
larger loads at hispeed_freq.  For example, a load of 60% will typically
move to 60% of hispeed_freq, not 60% of max speed.  This causes the
governor to apply two different speed caps, depending on whether load is
below or above go_hispeed_load.

Also fix the type of hispeed_freq, which was u64, to match other
speed data types (and avoid overhead and allow division).

Signed-off-by: Todd Poynor <toddpoynor@google.com>
BUG=chrome-os-partner:11515
TEST=boot snow and sanity check governor stats (should be noop w/ current settings)

Change-Id: Ie2d0668be161c074aaad77db2037505431457b3a
Reviewed-on: https://gerrit.chromium.org/gerrit/38230
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>

CHROMIUM: spring: dts: Use MAX98089 codec for audio.

Switch from 98095 for EVT build.

BUG=chrome-os-partner:17794
TEST=Play audio on Spring from speakers and headphones.

Change-Id: I1da995e905956c56a1c86f27eb71b735fc847a44
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43359
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: ASoC: samsung: Daisy - be specific about MAX98088/9

Spring uses the MAX98089 codec, which is supported by max98088.c.  For
device tree indicate 98089 in case there is a need to differentiate in
the future.

BUG=chrome-os-partner:17794
TEST=play audio on snow and spring.

Change-Id: I9930363408e499c59ae66dd9719005eb769eb46e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44446
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: Input: synaptics - report ABS_X, ABS_Y positions on Cr48

Signed-off-by: Chung-yih Wang <cywang@chromium.org>
BUG=chromium:191329
TEST=on device, type 'evtest' and enter the ID for touchpad device
  Press a finger on the pad and see if there is ABS_X, ABS_Y
  printed from evtest.

Change-Id: If2ff89aabbcee348f401c3c3f16543fac93d5d2e
Reviewed-on: https://gerrit.chromium.org/gerrit/45392
Commit-Queue: Chung-yih Wang <cywang@chromium.org>
Tested-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>

CHROMIUM: md: dm-verity: Fix to avoid a deadlock in dm-bufio

Changed the dm-verity prefetching to use a worker thread to avoid
a deadlock in dm-bufio.

If generic_make_request is called recursively, it queues the I/O
request on the current->bio_list without making the I/O request
and returns. The routine making the recursive call cannot wait
for the I/O to complete.

The deadlock occurred when one thread grabbed the bufio_client
mutex and waited for an I/O to complete but the I/O was queued
on another thread's current->bio_list and it was waiting to get
the mutex held by the first thread.

The fix allows only one I/O request from dm-verity to dm-bufio
per thread. To do this, the prefetch requests were queued on worker
threads.

In addition to avoiding the deadlock, this fix made a slight
improvement in performance.

seconds_kernel_to_login:
  with prefetch:    8.43s
  without prefetch: 9.2s
  worker prefetch:  8.28s

BUG=chromium-os:39148
TEST=./run_remote_tests.sh --board=$B --remote=$IP suite:smoke
Signed-off-by: Paul Taysom <taysom@chromium.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@kernel.org
Change-Id: I5f3cddfed507abfb8198fee71e713495f076b772
Reviewed-on: https://gerrit.chromium.org/gerrit/42422
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>

CHROMIUM: md: dm-verity fixes chromeos needs

This CL has all the changes that needed to be made to
the upstream version of dm-verity.
1. Notify
2. Same paramaters as the old version of dm-verity
3. Opening device by uuid

See CL 41206

At Mandeep's suggestion, I've modified the upstream version of
verity to accept the legacy parameters. This means we can move
to the upstream version of verity without making changes to
out build, install and signing scripts.

Results from platform_BootPerfServer/control.perfalerts
on a Lucas
      baseline CL
reboot_in_syslog 23 111
seconds_firmware_boot 30.86 30.75
seconds_kernel_to_chrome_exec 4.64 4.82
seconds_kernel_to_chrome_main 5.55 6.11
seconds_kernel_to_login 8.32 8.14
seconds_kernel_to_network 8.73 8.17
seconds_kernel_to_startup 1.63 1.72
seconds_kernel_to_startup_done 2.4 2.37
seconds_kernel_to_x_started 4.55 4.73
seconds_power_on_to_kernel 30.86 30.75
seconds_power_on_to_login 39.18 38.89 (30 sec wait for dev)

BUG=chromium-os:31803
TEST=platform_DMVerityCorruption, platform_DMVerityBitCorruption

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

CHROMIUM: md: dm-verity convert to upstream version

This CL only has the upstream version of dm-verity.c.
It was take from the 3.4.22 version of linux.
I've also removed dm-verity.h and dm-bht.c which are not
part of the upstream version of verity.
Removed the old documenation and added the new documents.
The next CL will have have the changes to make it work.

BUG=chromium-os:31803
TEST=platform_DMVerityCorruption, platform_DMVerityBitCorruption

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

CHROMIUM: input: cyapa - handling rt_suspend for fw_update

This patch handle the case where fw update may fail if the
device is currently runtime suspended. It forces the device
to resume before issuing soft reset. The patch also increases
waiting time/retry counts for a few commands.

Signed-off-by: Tai-Hsu Lin <sheckylin@chromium.org>
CQ-DEPEND=If3bd68194309bbe225c2357609ede1a7595b5eba
BUG=chromium-os:39500
TEST=echo 1000 > ${DEVICE_PATH}/power/runtime_suspend_scanrate/ms
echo -n 1 > ${DEVICE_PATH}/update_fw

Before the fix, fw update would fail. After the fix, it should
succeed.

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

CHROMIUM: input: cyapa - adding more debug message

The patch adds debug messages when entering most functions
so that the call stack is more visible for the developer. It
also adds messages for some cases where the errors were silently
handled before.

Signed-off-by: Tai-Hsu Lin <sheckylin@chromium.org>
BUG=chromium-os:39606
TEST=boot a machine with Cypress trackpad and check the dmesg.

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

CHROMIUM: charger-manager: Rewrite probe function

Split the probe function into separate functions in preparation for device
tree enablement.

Drop the extra rtc warning in the setup function and just do it once in
the probe function.

BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
See that the charger-manager still probes and appears to run correctly.

Change-Id: Ied0ddbc57c83869eb75a5b769ed2233b7742af15
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43025
Reviewed-by: Benson Leung <bleung@chromium.org>

CHROMIUM: drm/i915: bounds check execbuffer relocations

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

BUG=chromium-os:39733
TEST=link build, PoC fails

[sending upstream]

Change-Id: Ifdd4ae846042852a4462d70cfa3c3b84d5a9d133
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45118
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: signal: always clear sa_restorer on execve

When the new signal handlers are set up, the location of sa_restorer is
not cleared, leaking a parent process's address space location to
children.  This allows for a potential bypass of the parent's ASLR by
examining the sa_restorer value returned when calling sigaction().

Based on what should be considered "secret" about addresses, it only
matters across the exec not the fork (since the VMAs haven't changed until
the exec).  But since exec sets SIG_DFL and keeps sa_restorer, this is
where it should be fixed.

Given the few uses of sa_restorer, a "set" function was not written since
this would be the only use.  Instead, we use __ARCH_HAS_SA_RESTORER, as
already done in other places.

Example of the leak before applying this patch:

$ cat /proc/$$/maps
...
7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
...
$ ./leak
...
7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
...
1 0 (nil) 0x7fb9f30b94a0
2 4000000 (nil) 0x7f278bcaa4a0
3 4000000 (nil) 0x7f278bcaa4a0
4 0 (nil) 0x7fb9f30b94a0
...

BUG=chromium:177956
TEST=link build, PoC fails to show leaks

[sent upstream https://lkml.org/lkml/2013/3/11/498]
[changed #ifdef for pre-3.9 defines]
Change-Id: Icb92cc8a616f326f8df783b749ba1ffad24d98ce
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45130
Reviewed-by: Julien Tinnes <jln@chromium.org>

CHROMIUM: power,mkbp: Update PSU status via EC's MKBP.

EC has only one interrupt to the AP which is used to
signal keyboard input has arrived.

In order to signal change in power supply unit status (PSU) without
complicating and slowing keyboard response, we've added a virtual
keystroke, KEY_BATTERY, to signal change in PSU state.

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

1. Plug-in AC supply, boot and login as root
2. Examine current PSU type
   cat /sys/class/power_supply/cros_ec-charger/type
   Mains
3. Unplug PSU, repeat 2. see same result
4. From EC console press 'BATTERY_KEY'
   kpbress 0 7 1
5. Re-examine PSU type
   cat /sys/class/power_supply/cros_ec-charger/type
   UNKNOWN

Repeat steps 1-5 for various PSUs

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

CHROMIUM: ALSA: hda/ca0132 - Fix division by zero in ca0132_update_latency()

The original code avoids the division if the runtime parameters have
not been set by checking if it is still in the SNDRV_PCM_STATE_OPEN
state. However if the system is suspended between snd_pcm_open() and
snd_pcm_hw_params(), the state is changed from SNDRV_PCM_STATE_OPEN to
SNDRV_PCM_STATE_SUSPENDED, and the check misses the case.

The new check just looks at the runtime parameters directly to see if
it is already set.

BUG=chromium-os:39661
TEST=compile kernel

Change-Id: I2ba983e00e61c330fe04a5a93f34101f01893ac3
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/45022