BACKPORT: drm: allow FB's in drm_mode_object_find

We do actually want to permit FB's in atomic case, since FB will be
looked up like any other object property value in a few code paths
(like property value validation).

So split out into an internal function without the WARN_ON() which
we can use in those special cases.

Signed-off-by: Rob Clark <robdclark@gmail.com>
(cherry picked from commit 1358cd58fc90e673397511988954c1c55e606412)
Signed-off-by: David Sodman <dsodman@chromium.org>

Conflicts:
	drivers/gpu/drm/drm_crtc.c

Change-Id: Ic507991801c921c33bed441935d7d11ec71c8504
Reviewed-on: https://chromium-review.googlesource.com/218974
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: David Sodman <dsodman@chromium.org>
Tested-by: David Sodman <dsodman@chromium.org>
CHROMIUM: mwifiex: add rx workqueue support

This patch adds RX work queue support to mwifiex.
Packets received are queued to internal queue which are then
processed by scheduling a work item for RX process.

RX work is enabled only on SMP systems.

Bug=none
Test=manual: run RX TCP/UDP traffic from AP backend.
TP is improved by 20-30%

Change-Id: Ibc22a56a94ff1d10448ed577fea46915d3a3e035
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/219913
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: usb: cdc-wdm: Clear read pipeline in case of error.

commit 73e06865ead1 ("USB: cdc-wdm: support back-to-back
USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications") implemented queued response
handling. This queue is processed every time the WDM_READ flag is cleared.

In case of a read error, userspace may not actually read the data, since the
driver returns an error through wdm_poll. After this, the underlying device may
attempt to send us more data, but the queue is not processed. While userspace is
also blocked, because the read error is never cleared.

After this patch, we proactively process the queue on a read error. If there was
an outstanding response to handle, that will clear the error (or go through the
same logic again, if another read error occurs). If there was no outstanding
response, this will bring the queue size back to 0, unblocking a future response
from the underlying device.

BUG=chrome-os-partner:30325
TEST=Run network_3GModemControl till we see -EPIPE from cdc-wdm driver. Ensure
that the system recovers, and the test passes.

Change-Id: I6ba444fe03c903b90186e9550c5ff145a93ca6fa
Signed-off-by: Prathmesh Prabhu <pprabhu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219924
Reviewed-by: Ben Chan <benchan@chromium.org>
CHROMIUM: send command 0 transaction after reading EDID

Command 4 works much more reliably for reading EDID than command 0, but
using it causes enabling HDCP to fail. Sending a dummy transaction with
command 0 after reading EDID fixes some internal state in Slimport bridge.

BUG=chromium:415996
TEST=connect HDMI monitor to Spring, open shell, DISPLAY=:0.0 \
xrandr -d :0 --output HDMI-1 --set 'Content Protection' Desired

Change-Id: I343a2f77ad88ca6bed5548a74c65bc1b67304646
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220241
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: ALSA: control: Don't access controls outside of protected regions

A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.

BUG=chromium:390318
TEST=build image on link, check audio playback/record function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d)
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>

Change-Id: Ibf1c1454e5b4cb6913c7cbdb1f38568c865e2cd4
Reviewed-on: https://chromium-review.googlesource.com/220297
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
BACKPORT: ALSA: control: Handle numid overflow

Each control gets automatically assigned its numids when the control is created.
The allocation is done by incrementing the numid by the amount of allocated
numids per allocation. This means that excessive creation and destruction of
controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
eventually overflow. Currently when this happens for the control that caused the
overflow kctl->id.numid + kctl->count will also over flow causing it to be
smaller than kctl->id.numid. Most of the code assumes that this is something
that can not happen, so we need to make sure that it won't happen

BUG=chromium:390318
TEST=build image on link, check audio playback/record function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit ac902c112d90a89e59916f751c2745f4dbdbb4bd)
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>

Change-Id: Ica890d852d61bebbc326f5e78f7ef0ee37e9e8f4
Reviewed-on: https://chromium-review.googlesource.com/220298
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
BACKPORT: ALSA: control: Make sure that id->index does not overflow

The ALSA control code expects that the range of assigned indices to a control is
continuous and does not overflow. Currently there are no checks to enforce this.
If a control with a overflowing index range is created that control becomes
effectively inaccessible and unremovable since snd_ctl_find_id() will not be
able to find it. This patch adds a check that makes sure that controls with a
overflowing index range can not be created.

BUG=chromium:390318
TEST=build image on link, check audio playback/record function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e)
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>

Change-Id: I1fdd745e878ef015275f741979fbfd7126498bce
Reviewed-on: https://chromium-review.googlesource.com/220299
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
BACKPORT: ALSA: control: Fix replacing user controls

There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.

The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.

Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.

Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.

BUG=chromium:390318
TEST=build image on link, check audio playback/record function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 82262a46627bebb0febcc26664746c25cef08563)
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>

Change-Id: Ib97f5e3beb0905f610b50c78f98a82cfaffb6b16
Reviewed-on: https://chromium-review.googlesource.com/220500
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8
BACKPORT: ALSA: control: Protect user controls against concurrent access

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

BUG=chromium:390318
TEST=build image on link, check audio playback/record function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92)
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>

Change-Id: Ie0b9e9f45910760cf80018598124fb9105c77094
Reviewed-on: https://chromium-review.googlesource.com/220501
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
Commit-Queue: Cheng-Yi Chiang <cychiang@chromium.org>
BACKPORT: HID: logitech-dj: Fix USB 3.0 issue

This fix (not very clean though) should fix the long time USB3
issue that was spotted last year. The rational has been given by
Hans de Goede:

 ----

I think the most likely cause for this is a firmware bug
in the unifying receiver, likely a race condition.

The most prominent difference between having a USB-2 device
plugged into an EHCI (so USB-2 only) port versus an XHCI
port will be inter packet timing. Specifically if you
send packets (ie hid reports) one at a time, then with
the EHCI controller their will be a significant pause
between them, where with XHCI they will be very close
together in time.

The reason for this is the difference in EHCI / XHCI
controller OS <-> driver interfaces.

For non periodic endpoints (control, bulk) the EHCI uses a
circular linked-list of commands in dma-memory, which it
follows to execute commands, if the list is empty, it
will go into an idle state and re-check periodically.

The XHCI uses a ring of commands per endpoint, and if the OS
places anything new on the ring it will do an ioport write,
waking up the XHCI making it send the new packet immediately.

For periodic transfers (isoc, interrupt) the delay between
packets when sending one at a time (rather then queuing them
up) will be even larger, because they need to be inserted into
the EHCI schedule 2 ms in the future so the OS driver can be
sure that the EHCI driver does not try to start executing the
time slot in question before the insertion has completed.

So a possible fix may be to insert a delay between packets
being send to the receiver.

 ----

I tested this on a buggy Haswell USB 3.0 motherboard, and I always
get the notification after adding the msleep.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

(cherry-picked from commit 42c22dbf81ebd1146960875ddfe71630cb2b3ae6)

BUG=None
TEST=compiles

Change-Id: Idf587ff46f4e2bc35dfbd8f82a190b8049585154
Reviewed-on: https://chromium-review.googlesource.com/221051
Reviewed-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Tested-by: Julien Racle <jracle@logitech.com>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Queue: Julien Racle <jracle@logitech.com>
UPSTREAM: USB: cdc-acm: Added support for the Lenovo RD02-D400 USB Modem

Signed-off-by: David Cluytens <david.cluytens@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3b59d16c513da258ec8f6a0b4db85f257a0380d6)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: Ie5b804e21cf1b9682db2ef7d61e052b530b002ba
Reviewed-on: https://chromium-review.googlesource.com/221627
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate()

If acm_submit_read_urbs() fails in acm_port_activate(), error handling
code calls usb_autopm_put_interface() while it is already called
before acm_submit_read_urbs(). The patch reorganizes error handling code
to avoid double decrement of USB interface's PM-usage counter.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 070c0b17f6a1ba39dff9be112218127e7e8fd456)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: I3f2e60fb77673582da4bb23f3922aa80c0e33a1a
Reviewed-on: https://chromium-review.googlesource.com/221628
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver

By specifying NO_UNION_NORMAL the ACM driver does only use the first two
USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA
interfaces are left to the USB serial driver.

Signed-off-by: Michael Ulbricht <michael.ulbricht@systec-electronic.com>
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 895d240d1db0b2736d779200788e4c4aea28a0c6)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: I0827b35889a9f609ec4476b582e8479e83a4e20e
Reviewed-on: https://chromium-review.googlesource.com/221629
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix write and suspend race

Fix race between write() and suspend() which could lead to writes being
dropped (or I/O while suspended) if the device is runtime suspended
while a write request is being processed.

Specifically, suspend() releases the write_lock after determining the
device is idle but before incrementing the susp_count, thus leaving a
window where a concurrent write() can submit an urb.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Cc: <stable@vger.kernel.org>        # v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5a345c20c17d87099224a4be12e69e5bd7023dca)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: I9b32550939c0bd752b052eba8fb417f2b6a16990
Reviewed-on: https://chromium-review.googlesource.com/221630
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix write and resume race

Fix race between write() and resume() due to improper locking that could
lead to writes being reordered.

Resume must be done atomically and susp_count be protected by the
write_lock in order to prevent racing with write(). This could otherwise
lead to writes being reordered if write() grabs the write_lock after
susp_count is decremented, but before the delayed urb is submitted.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Cc: <stable@vger.kernel.org>	# v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e144ed28bed10684f9aaec6325ed974d53f76110)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: Ibed4ce5b608c9a2482ba4de09f079fc60f363145
Reviewed-on: https://chromium-review.googlesource.com/221631
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix broken runtime suspend

The current ACM runtime-suspend implementation is broken in several
ways:

Firstly, it buffers only the first write request being made while
suspended -- any further writes are silently dropped.

Secondly, writes being dropped also leak write urbs, which are never
reclaimed (until the device is unbound).

Thirdly, even the single buffered write is not cleared at shutdown
(which may happen before the device is resumed), something which can
lead to another urb leak as well as a PM usage-counter leak.

Fix this by implementing a delayed-write queue using urb anchors and
making sure to discard the queue properly at shutdown.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Reported-by: Xiao Jin <jin.xiao@intel.com>
Cc: <stable@vger.kernel.org>	# v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 140cb81ac8c625942a1d695875932c615767a526)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: I5264a88e0cc14a809c8b1d16ebfa3a4f6eb7bc21
Reviewed-on: https://chromium-review.googlesource.com/221632
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix runtime PM for control messages

Fix runtime PM handling of control messages by adding the required PM
counter operations.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Cc: <stable@vger.kernel.org>	# v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bae3f4c53585e9a170da9436e0f06919874bda9a)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: Ib1bd8d55dc5de620a33975a6b6c7d87f07714a51
Reviewed-on: https://chromium-review.googlesource.com/221633
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix shutdown and suspend race

We should stop I/O unconditionally at suspend rather than rely on the
tty-port initialised flag (which is set prior to stopping I/O during
shutdown) in order to prevent suspend returning with URBs still active.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Cc: <stable@vger.kernel.org>	# v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ed797074031a37bb9bf4a70952fffc606b77274d)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: Iae2f8cfc7f7fb599ec4e4a7cc203b3f9bf54e9c6
Reviewed-on: https://chromium-review.googlesource.com/221634
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
UPSTREAM: USB: cdc-acm: fix potential urb leak and PM imbalance in write

Make sure to check return value of autopm get in write() in order to
avoid urb leak and PM counter imbalance on errors.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Cc: <stable@vger.kernel.org>	# v2.6.27
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 183a45087d126d126e8dd1d9b2602fc129dff9ad)
Signed-off-by: Ben Chan <benchan@chromium.org>

BUG=chromium:419242
TEST=`emerge-$BOARD chromeos-kernel-3_8`
TEST=Run network3g tests on DUTs with a modem that uses an ACM port.

Change-Id: Idd5c6b2347937333d4554a889583fa213bc40e8c
Reviewed-on: https://chromium-review.googlesource.com/221635
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>