CHROMIUM: mwifiex: Send individual channel TLVs

This is a workaround for possible buffering issues for scans
in environments where BSSes are plentiful.  This improves
reliability of scanning by breaking up the scan commands.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:14655
TEST=Testbed runs.

Change-Id: If2f8a6558561efbf36998a8ebdf2ce9ebec3dcdd
Reviewed-on: https://gerrit.chromium.org/gerrit/35435
Reviewed-by: Ryan Cairns <rtc@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>

MALI: TX011-r1p2-04dev0 : wk39 kbase

Merge in wk39 kbase from ARM.

BUG=none
TEST=build and run on daisy

Change-Id: Id7d6f0797d1d5af08a6bf729583b4f9a67bb352b
Signed-off-by: John Rees <john.rees@arm.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34754
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Anush Elangovan <anush@chromium.org>
Tested-by: Anush Elangovan <anush@chromium.org>

UPSTREAM: ALSA: hda - Fix leftover codec->power_transition

When the codec turn-on operation is canceled by the immediate
power-on, the driver left the power_transition flag as is.
This caused the persistent avoidance of power-save behavior.

Cc: <stable@vger.kernel.org> [v3.5+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 535b6c51fe8293c88ce919cdfc4390c67a1cb6d1)

BUG=chrome-os-partner:15121
TEST=turn on tracepoints for hda_power_up/hda_power_down and verify
hda_power_down is called after specified timeout.

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

UPSTREAM: USB: option: fix memory leak

Fix memory leak introduced by commit 383cedc3bb435de7a2 ("USB: serial:
full autosuspend support for the option driver") which allocates
usb-serial data but never frees it.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b9c3aab315b51f81649a0d737c4c73783fbd8de0)

Change-Id: I21100086dfb256d5f7b2d14ee9b92b6bf1ae086e
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35407
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: block: Remove deadlock in disk_clear_events

In disk_clear_events, do not put work on system_nrt_freezable_wq. Instead, put
it on system_nrt_wq.

There is a race between probing a usb and suspending the device. Since probing a
usb calls disk_clear_events, which puts work on a frozen workqueue, probing
cannot finish after the workqueue is frozen. However, suspending cannot finish
until the usb probe is finished, so we get a deadlock.

BUG=chrome-os-partner:14892, chromium-os:35228
TEST=suspend resume with usb device plugged in

Change-Id: Ife0103207c84eab162c93781d0d986eae50475d8
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35324
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>

drm/exynos: check kds_async_waitall return value

BUG=chrome-os-partner:15053
TEST=VT switch. Log in/out. Suspend/resume. Web GL.
TEST=All testing done with slub_debug=FZPUA

Change-Id: Icd578c762aba112a1713af0436fe884147cbbef7
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35066
Tested-by: Abhinav Kochhar <abhinav@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: config: unset CONFIG_USB_NET_GOBI

CONFIG_USB_NET_GOBI is now configured by cros-kernel2.eclass based on
the 'gobi' use flag instead.

BUG=chromium-os:35212
TEST=Tested the following:
1. gobi.ko is built when `USE=gobi emerge-$BOARD chromeos-kernel`
1. gobi.ko is not built when `USE=-gobi emerge-$BOARD chromeos-kernel`
2. gobi.ko is built for x86-mario, x86-alex, x86-zgb, lumpy and daisy.

Change-Id: Iafec83c7596d0a6ae2eb359c5e4c4071e2cb3d14
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35258
Reviewed-by: Mike Frysinger <vapier@chromium.org>

Only poll for HDMI disconnects.

We need polling because the HPD line status cannot be read, but waking up the CPU consumes power.

It is only the disconnect case that suffers from unplug ordering problems with the DDC lines, so restrict polling to that.

TEST=Slow HDMI unplugging is still detected.  Polling doesn't occur if there isn't an HDMI cable attached.
BUG=chrome-os-partner:13495

Change-Id: I47801812c41e0e6b01865aadb9404cd8da795c54
Reviewed-on: https://gerrit.chromium.org/gerrit/35293
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Stuart Abercrombie <sabercrombie@chromium.org>
Tested-by: Stuart Abercrombie <sabercrombie@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>

ARM: EXYNOS5: Update LCD data to expect 70.0 MHz, not 70.5 MHz

In 10eecb8c304133439e96bd9f3ba09d64c4e952b2 I changed VPLL to
70.0 MHz but forgot to update the LCD data.  I have verified
that this isn't harmful (it picks the closest value which
is 70.0), but it's good to make it right.

Thanks to Alim for pointing this out.

BUG=chrome-os-partner:12498
TEST=Run flicker-detect

Change-Id: Ib143f45d05c2cd20355748005068922f0d6b12dc
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35278
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: DMA: PL330: move tasklet_kill before the spin lock

Tasklet_kill should not be called after taking out the lock.
This may "yield" the cpu while the lock is taken and can cause
potential soft lockup.
Moved tasklet_kill call before the spin lock.

There is a crash report related to the same issue:

<0>[71100.087651] BUG: soft lockup - CPU#1 stuck for 12s! [cras:2027]
<5>[71100.087821] Modules linked in: rfcomm i2c_dev uinput isl29018(C)
industrialio(C) sbs_battery mwifiex_sdio mwifiex spidev btmrvl_sdio
cfg80211 btmrvl bluetooth fuse nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter xt_mark ip6_tables qcserial usb_wwan gobi usbnet
uvcvideo videobuf2_vmalloc joydev
<5>[71100.089452]
<5>[71100.089527] Pid: 2027, comm:                 cras
<5>[71100.089669] CPU: 1    Tainted: G         C    (3.4.0 #1)
<5>[71100.089836] PC is at tasklet_kill+0x74/0x90
<5>[71100.089971] LR is at tasklet_kill+0x68/0x90
<5>[71100.090097] pc : [<80030fa0>]    lr : [<80030f94>]    psr:
20070013
<5>[71100.090212] sp : e58abdc8  ip : 00000000  fp : e58abddc
<5>[71100.090364] r10: eeb7e700  r9 : ee128800  r8 : ee114080
<5>[71100.090507] r7 : ee129224  r6 : 400f0013  r5 : ef01d464  r4 :
ef01d460
<5>[71100.090675] r3 : 00000001  r2 : 00000003  r1 : ef01d464  r0 :
00000002
<5>[71100.090844] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment user
<5>[71100.091023] Control: 10c5387d  Table: a78ec06a  DAC: 00000015
<5>[71100.091233] [<800154ac>] (unwind_backtrace+0x0/0xec) from
[<804e066c>] (dump_stack+0x20/0x24)
<5>[71100.091480] [<804e066c>] (dump_stack+0x20/0x24) from [<8000f828>]
(show_regs+0x4c/0x58)
<5>[71100.091721] [<8000f828>] (show_regs+0x4c/0x58) from [<8008077c>]
(watchdog_timer_fn+0x134/0x1c8)
<5>[71100.091980] [<8008077c>] (watchdog_timer_fn+0x134/0x1c8) from
[<8004da7c>] (__run_hrtimer+0x138/0x210)
<5>[71100.092246] [<8004da7c>] (__run_hrtimer+0x138/0x210) from
[<8004e6f8>] (hrtimer_interrupt+0x120/0x248)
<5>[71100.092509] [<8004e6f8>] (hrtimer_interrupt+0x120/0x248) from
[<80023258>] (exynos4_mct_tick_isr+0x58/0x60)
<5>[71100.092777] [<80023258>] (exynos4_mct_tick_isr+0x58/0x60) from
[<80081620>] (handle_irq_event_percpu+0x8c/0x244)
<5>[71100.093055] [<80081620>] (handle_irq_event_percpu+0x8c/0x244) from
[<80081824>] (handle_irq_event+0x4c/0x6c)
<5>[71100.093330] [<80081824>] (handle_irq_event+0x4c/0x6c) from
[<80084734>] (handle_fasteoi_irq+0xe4/0x150)
<5>[71100.093590] [<80084734>] (handle_fasteoi_irq+0xe4/0x150) from
[<80080dd0>] (generic_handle_irq+0x3c/0x50)
<5>[71100.093854] [<80080dd0>] (generic_handle_irq+0x3c/0x50) from
[<8000ef04>] (handle_IRQ+0x88/0xc8)
<5>[71100.094106] [<8000ef04>] (handle_IRQ+0x88/0xc8) from [<80008564>]
(gic_handle_irq+0x44/0x68)
<5>[71100.094357] [<80008564>] (gic_handle_irq+0x44/0x68) from
[<8000db40>] (__irq_svc+0x40/0x60)
<5>[71100.094553] Exception stack(0xe58abd80 to 0xe58abdc8)
<5>[71100.094698] bd80: 00000002 ef01d464 00000003 00000001 ef01d460
ef01d464 400f0013 ee129224
<5>[71100.094895] bda0: ee114080 ee128800 eeb7e700 e58abddc 00000000
e58abdc8 80030f94 80030fa0
<5>[71100.095086] bdc0: 20070013 ffffffff
<5>[71100.095247] [<8000db40>] (__irq_svc+0x40/0x60) from [<80030fa0>]
(tasklet_kill+0x74/0x90)
<5>[71100.095501] [<80030fa0>] (tasklet_kill+0x74/0x90) from
[<80245e84>] (pl330_free_chan_resources+0x34/0xac)
<5>[71100.095769] [<80245e84>] (pl330_free_chan_resources+0x34/0xac)
from [<80243be4>] (dma_release_channel+0x98/0xdc)
<5>[71100.096045] [<80243be4>] (dma_release_channel+0x98/0xdc) from
[<8002636c>] (samsung_dmadev_release+0x18/0x20)
<5>[71100.096319] [<8002636c>] (samsung_dmadev_release+0x18/0x20) from
[<803f3a44>] (dma_hw_free+0x64/0x70)
<5>[71100.096588] [<803f3a44>] (dma_hw_free+0x64/0x70) from [<803eaf50>]
(soc_pcm_hw_free+0x98/0xe8)
<5>[71100.096839] [<803eaf50>] (soc_pcm_hw_free+0x98/0xe8) from
[<803d8614>] (snd_pcm_common_ioctl1+0x2e4/0xd38)
<5>[71100.097106] [<803d8614>] (snd_pcm_common_ioctl1+0x2e4/0xd38) from
[<803d9804>] (snd_pcm_playback_ioctl1+0x3ac/0x3d0)
<5>[71100.097389] [<803d9804>] (snd_pcm_playback_ioctl1+0x3ac/0x3d0)
from [<803d9860>] (snd_pcm_playback_ioctl+0x38/0x44)
<5>[71100.097680] [<803d9860>] (snd_pcm_playback_ioctl+0x38/0x44) from
[<800fef68>] (do_vfs_ioctl+0x4f4/0x568)
<5>[71100.097944] [<800fef68>] (do_vfs_ioctl+0x4f4/0x568) from
[<800ff03c>] (sys_ioctl+0x60/0x84)
<5>[71100.098188] [<800ff03c>] (sys_ioctl+0x60/0x84) from [<8000df00>]
(ret_fast_syscall+0x0/0x30)

BUG=chrome-os-partner:15093
TEST=ran multimedia tests for multiple hours without any issues
Signed-off-by: abhinav <abhinav@chromium.org>
Change-Id: Ic83c97b70f0c5f685c50a6a874f52798884d10f0
Reviewed-on: https://gerrit.chromium.org/gerrit/35233
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>

drm/exynos: configure HDMIPHY poweron/off sequence

This patch adds the code required to configure the power on and
off sequence of the HDMIPHY via the dedicated I2C.

BUG=chrome-os-partner:15089
TEST=ctrl + f4 displays the chrome login screen on HDMI,
S2R works fine.

Change-Id: I84e6b43af5f0a23294e67a9b1b791f9f75d54740
Signed-off-by: Naveen Krishna Chatradhi <naveen@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34997
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: ALSA: hda/ca0132: Turn on headphone amp only when a headphone is plugged.

The patch is provided by Creative.

BUG=none
TEST=plug/unplug a headphone and verify the AMP pin is high only when a
headphone is plugged.

Change-Id: I0d8a3113d9fcfe7ffddd69cfc7c0b0b9ce728ae3
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35234
Reviewed-by: Dylan Reid <dgreid@chromium.org>

drm/exynos: FIMD: keep track of suspended windows and resume them

Otherwise our screen stays black until we get a page flip.

BUG=chrome-os-partner:14978
TEST=by hand

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

drm/exynos: remove extra kds slot error message

This message is no longer needed. Its only purpose now is to fill
up the log and add confusion.

BUG=chromium-os:15053
TEST=compile. boot.

Change-Id: Id6d85dd1c8436ca5da9382adeab079bfea7fabb1
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35113
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Anush Elangovan <anush@google.com>

UPSTREAM: net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200

One of the modes of Huawei E367 has this QMI/wwan interface:

 I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
 E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
 E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
 E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms

Huawei use subclass and protocol to identify vendor specific
functions, so adding a new vendor rule for this combination.

The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
the same subclass to identify the QMI/wwan function.  Replace the
existing device specific UML290 entries with generic vendor matching,
adding support for the Pantech P4200.

The ZTE MF683 has 6 vendor specific interfaces, all using
ff/ff/ff for cls/sub/prot.  Adding a match on interface #5 which
is a QMI/wwan interface.

Cc: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 42d94dcb68b939c72fded1b3974cd240723afa0c)

Change-Id: Iaac2eaefd103e2cd51d7069ae09eecc025875bc7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35031
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: call subdriver with control intf only

This fixes a hang on suspend due to calling wdm_suspend on
the unregistered data interface. The hang should have been
a NULL pointer reference had it not been for a logic error
in the cdc_wdm code.

  commit 230718bd net: qmi_wwan: bind to both control and data interface

changed qmi_wwan to use cdc_wdm as a subdriver for devices with
a two-interface QMI/wwan function.  The commit failed to update
qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
either a single combined interface function, or no subdriver at all.

The result was that we called into the subdriver both when the
control interface was suspended and when the data interface was
suspended.  Calling the subdriver suspend function with an
unregistered interface is not supported and will make the
subdriver bug out.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8624dd2a3e33b647cd672211b54ba276ddee2a2c)

Change-Id: I198c038b6560b8638ad5d67e1d3fa07edabf901c
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35030
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: fix Gobi device probing for un2430

HP un2430 is a Gobi 3000 device. It was mistakenly treated as Gobi 1000
in patch b9f90eb2740203ff2592efe640409ad48335d1c2.

I own this device and qmi_wwan works again with this fix.

Signed-off-by: Pierre Sauter <pierre.sauter@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b48d6f8bed430922f78f648d1f73f7c1591e472c)

Change-Id: I1437384b0d27e74f8a13b63c729864ea0fe29d46
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35029
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: use a single bind function for all device types

Refactoring the bind code lets us use a common driver_info struct
for all supported devices, simplifying the code a bit.  The
real advantage is that devices using the CDC ECM interface
layout now also can be added dynamically using the new_id sysfs
interface.  This simplifies testing of new devices.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit bd877e489126b2214f971ae8ef7bd17b48a94a7b)

Change-Id: I94d77f53b09d51094d57e215fe08741cef12fc49
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35028
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: increase max QMI message size to 4096

QMI requests exceeding 1500 bytes are possible and
device firmware does not handle fragmented messages
very well.  It is therefore necessary to increase
the maximum message size from the current 512 bytes.

The protocol message size limit is not documented
in any publicly known source, but the out of tree
driver from CodeAurora use 4 kB.  This is therefore
chosen as the new arbitrary default until the real
limit is known.

This should allow any QMI message to be transmitted
without fragmentation, fixing known issues with GPS
assistance data upload.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3ee2403739db7ec8b683e6451c3401ad716ad5a2)

Change-Id: I36df647599423d9a06f5087fe05d295111e0f737
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35027
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: add several new Gobi devices

Gobi devices are composite, needing both the qcserial and
qmi_wwan drivers to support all functions.  Re-syncing the
list of supported devices with qcserial.

Cc: Aleksander Morgado <aleksander@lanedo.com>
Cc: Thomas Tuttle <ttuttle@chromium.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@tempietto.lan>
(cherry picked from commit 5002200599429e83fc13e0d9a2d4788b79515b0c)

Change-Id: I5aed156191f5e411293f9359030f8564958f0131
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35026
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: new device: Foxconn/Novatel E396

Foxconn-branded Novatel E396, Gobi3k modem.

Cc: Dan Williams <dcbw@redhat.com>
Cc: Bjørn Mork <bjorn@mork.no>
Cc: Ben Chan <benchan@google.com>
Signed-off-by: Aleksander Morgado <aleksander@lanedo.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit fa026e223df2514b271b20f839ab05d7f21181b9)

Change-Id: Ia8eafb206bc40f405adb3a0ad6e4d04aae36a37d
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35025
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: new devices: UML290 and K5006-Z

Newer firmware versions for the Pantech UML290 use a different
subclass ID.  The Windows driver match on both IDs, so we do
that as well.

The ZTE (Vodafone) K5006-Z is a new device.

Cc: Dan Williams <dcbw@redhat.com>
Cc: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 10cbc1d97a7c7f9ae862fffe27b771ef0da9c461)

Change-Id: Ic9630ac614800c1d235ad380b950f0e70bfa79ab
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35024
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: compress device_id list using macros

Take advantage of the matching macros to make the device id
list easier to read and maintain.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5ea429638fbd9f18e6837e3e83a1f517741ec43b)

Change-Id: Ibdc03a8242a495b729ad1d7712b17e8c5c1e4af7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35023
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: add Sierra Wireless devices

Add 6 new devices and one modified device, based on
information from laptop vendor Windows drivers.

Sony provides a driver with two new devices using
a Gobi 2k+ layout (1199:68a5 and 1199:68a9).  The
Sony driver also adds a non-standard QMI/net
interface to the already supported 1199:9011
Gobi device. We do not know whether this is an
alternate interface number or an additional
interface which might be present, but that doesn't
really matter.

Lenovo provides a driver supporting 4 new devices:
 - MC7770 (1199:901b) with standard Gobi 2k+ layout
 - MC7700 (0f3d:68a2) with layout similar to MC7710
 - MC7750 (114f:68a2) with layout similar to MC7710
 - EM7700 (1199:901c) with layout similar to MC7710

Note regaring the three devices similar to MC7710:

The Windows drivers only support interface #8 on these
devices.  The MC7710 can support QMI/net functions on
interface #19 and #20 as well, and this driver is
verified to work on interface #19 (a firmware bug is
suspected to prevent #20 from working).

We do not enable these additional interfaces until they
either show up in a Windows driver or are verified to
work in some other way.  Therefore limiting the new
devices to interface #8 for now.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 9b469a60d68b13c288d5c3fc23de29d9d482dbe6)

Change-Id: I98d1ea52e8be28abdc36cd33ef23c95665028ced
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35022
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: use fixed interface number matching

This driver support many composite USB devices where the
interface class/subclass/protocol provides no information
about the interface function. Interfaces with different
functions may all use ff/ff/ff, like this example of
a device with three serial interfaces and three QMI/wwan
interfaces:

T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=116 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1199 ProdID=68a2 Rev= 0.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=MC7710
S:  SerialNumber=3581780xxxxxx
C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=19 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#=20 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms

Instead of class/subclass/protocol the vendor use fixed
interface numbers for each function, and the Windows
drivers use these numbers to match driver and function.

The driver has had its own interface number whitelisting
code to simulate this functionality.  Replace this with
generic interface number matching now that the USB subsystem
support is there. This
 - removes the need for a driver_info structure per
   interface number,
 - avoids running the probe function for unsupported
   interfaces, and
 - simplifies the code.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 03304bcb5ec4421c0d272d7f8d688804d82b1efd)

Change-Id: I8eff39c02bea213a95b2cb83d0db994c63fc3870
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35021
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: add ZTE MF821D

Sold by O2 (telefonica germany) under the name "LTE4G"

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit db8dacf953a70274172236957a4b97d4fdb376f0)

Change-Id: I81c1c758cb9b80243409a628f7a64593556a563c
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35020
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: make dynamic device IDs work

The usbnet API use the device ID table to store a pointer to
a minidriver. Setting a generic pointer for dynamic device
IDs will in most cases make them work as expected.  usbnet
will otherwise treat the dynamic IDs as blacklisted. That is
rarely useful.

There is no standard class describing devices supported by
this driver, and most vendors don't even provide enough
information to allow vendor specific wildcard matching. The
result is that most of the supported devices must be
explicitly listed in the device table.  Allowing dynamic IDs
to work both simplifies testing and verification of new
devices, and provides a way for end users to use a device
before the ID is added to the driver.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1817e83d6ccf992164dd83522b2d1c22b1a85977)

Change-Id: I4cd1c6049a88520f29af31719325c74b2749a115
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35019
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: add ZTE MF60

Adding a device with limited QMI support. It does not support
normal QMI_WDS commands for connection management. Instead,
sending a QMI_CTL SET_INSTANCE_ID command is required to
enable the network interface:

  01 0f 00 00 00 00 00 00  20 00 04 00 01 01 00 00

A number of QMI_DMS and QMI_NAS commands are also supported
for optional device management.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6fecd35d4cd79fc75e8290abb86734c18500d2a2)
(cherry picked form commit 04c9f416e371cff076a8b3279fb213628915d059)

Change-Id: I75a68bd192da5c2b0cd67040313a1deebd632565
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35018
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: fix Oops while disconnecting

usbnet_disconnect() will set intfdata to NULL before calling
the minidriver unbind function.  The cdc_wdm subdriver cannot
know that it is disconnecting until the qmi_wwan unbind
function has called its disconnect function.  This means that
we must be able to support the cdc_wdm subdriver operating
normally while usbnet_disconnect() is running, and in
particular that intfdata may be NULL.

The only place this matters is in qmi_wwan_cdc_wdm_manage_power
which is called from cdc_wdm.  Simply testing for NULL
intfdata there is sufficient to allow it to continue working
at all times.

Fixes this Oops where a cdc-wdm device was closed while the
USB device was disconnecting, causing wdm_release to call
qmi_wwan_cdc_wdm_manage_power after intfdata was set to
NULL by usbnet_disconnect:

[41819.087460] BUG: unable to handle kernel NULL pointer dereference at 00000080
[41819.087815] IP: [<f8640458>] qmi_wwan_manage_power+0x68/0x90 [qmi_wwan]
[41819.088028] *pdpt = 000000000314f001 *pde = 0000000000000000
[41819.088028] Oops: 0002 [#1] SMP
[41819.088028] Modules linked in: qmi_wwan option usb_wwan usbserial usbnet
cdc_wdm nls_iso8859_1 nls_cp437 vfat fat usb_storage bnep rfcomm bluetooth
parport_pc ppdev binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables
x_tables dm_crypt uvcvideo snd_hda_codec_realtek snd_hda_intel
videobuf2_core snd_hda_codec joydev videodev videobuf2_vmalloc
hid_multitouch snd_hwdep arc4 videobuf2_memops snd_pcm snd_seq_midi
snd_rawmidi snd_seq_midi_event ath9k mac80211 snd_seq ath9k_common ath9k_hw
ath snd_timer snd_seq_device sparse_keymap dm_multipath scsi_dh coretemp
mac_hid snd soundcore cfg80211 snd_page_alloc psmouse serio_raw microcode
lp parport dm_mirror dm_region_hash dm_log usbhid hid i915 drm_kms_helper
drm r8169 i2c_algo_bit wmi video [last unloaded: qmi_wwan]
[41819.088028]
[41819.088028] Pid: 23292, comm: qmicli Not tainted 3.4.0-5-generic #11-Ubuntu GIGABYTE T1005/T1005
[41819.088028] EIP: 0060:[<f8640458>] EFLAGS: 00010246 CPU: 1
[41819.088028] EIP is at qmi_wwan_manage_power+0x68/0x90 [qmi_wwan]
[41819.088028] EAX: 00000000 EBX: 00000000 ECX: 000000c3 EDX: 00000000
[41819.088028] ESI: c3b27658 EDI: 00000000 EBP: c298bea4 ESP: c298be98
[41819.088028]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[41819.088028] CR0: 8005003b CR2: 00000080 CR3: 3605e000 CR4: 000007f0
[41819.088028] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[41819.088028] DR6: ffff0ff0 DR7: 00000400
[41819.088028] Process qmicli (pid: 23292, ti=c298a000 task=f343b280 task.ti=c298a000)
[41819.088028] Stack:
[41819.088028]  00000000 c3b27658 e2a80d00 c298beb0 f864051a c3b27600 c298bec0 f9027099
[41819.088028]  c2fd6000 00000008 c298bef0 c1147f96 00000001 00000000 00000000 f4e54790
[41819.088028]  ecf43a00 ecf43a00 c2fd6008 c2fd6000 ebbd7600 ffffffb9 c298bf08 c1144474
[41819.088028] Call Trace:
[41819.088028]  [<f864051a>] qmi_wwan_cdc_wdm_manage_power+0x1a/0x20 [qmi_wwan]
[41819.088028]  [<f9027099>] wdm_release+0x69/0x70 [cdc_wdm]
[41819.088028]  [<c1147f96>] fput+0xe6/0x210
[41819.088028]  [<c1144474>] filp_close+0x54/0x80
[41819.088028]  [<c1046a65>] put_files_struct+0x75/0xc0
[41819.088028]  [<c1046b56>] exit_files+0x46/0x60
[41819.088028]  [<c1046f81>] do_exit+0x141/0x780
[41819.088028]  [<c107248f>] ? wake_up_state+0xf/0x20
[41819.088028]  [<c1053f48>] ? signal_wake_up+0x28/0x40
[41819.088028]  [<c1054f3b>] ? zap_other_threads+0x6b/0x80
[41819.088028]  [<c1047864>] do_group_exit+0x34/0xa0
[41819.088028]  [<c10478e8>] sys_exit_group+0x18/0x20
[41819.088028]  [<c15bb7df>] sysenter_do_call+0x12/0x28
[41819.088028] Code: 04 83 e7 01 c1 e7 03 0f b6 42 18 83 e0 f7 09 f8 88 42
18 8b 43 04 e8 48 9a dd c8 89 f0 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 90
<f0> ff 88 80 00 00 00 0f 94 c0 84 c0 75 b7 31 f6 8b 5d f4 89 f0
[41819.088028] EIP: [<f8640458>] qmi_wwan_manage_power+0x68/0x90 [qmi_wwan] SS:ESP 0068:c298be98
[41819.088028] CR2: 0000000000000080
[41819.149492] ---[ end trace 0944479ff8257f55 ]---

Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak@gmail.com>
Cc: <stable@vger.kernel.org> # v3.4
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d9b8706843a501034d09bea63ca6723a2ed02b11)

Conflicts:

drivers/net/usb/qmi_wwan.c

(cherry picked conflict resolution from commit b26d344c6b87058ae3e8f919a18580abfc4204eb)

Change-Id: I1d47a2cc772bbb8c7335d2f307068d2d05e95a42
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35017
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: simplify a check in qmi_wwan_bind()

This code is easier to read if we specify which flags we want at the
condition instead of at the top of the function.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5ac24979dcb3418a295e11823c1f2506df1d9926)

Change-Id: I3b1a7d724d113b5788dad4c59c99f1b7b371905f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35016
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: fix Gobi device probing

Ignoring interfaces with additional descriptors is not a reliable
method for locating the correct interface on Gobi devices.  There
is at least one device where this method fails:
https://bbs.archlinux.org/viewtopic.php?id=143506

The result is that the AT command port (interface #2) is hidden
from qcserial, preventing traditional serial modem usage:

[   15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
[   15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[   15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
[   15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
[   15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[   15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
[   15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
[   15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
[   15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
[   15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1

Use static interface numbers taken from the interface map in
qcserial for all Gobi devices instead:

Gobi 1K USB layout:
0: serial port (doesn't respond)
1: serial port (doesn't respond)
2: AT-capable modem port
3: QMI/net

Gobi 2K+ USB layout:
0: QMI/net
1: DM/DIAG (use libqcdm from ModemManager for communication)
2: AT-capable modem port
3: NMEA

This should be more reliable over all, and will also prevent the
noisy "probe failed" messages.  The whitelisting logic is expected
to be replaced by direct interface number matching in 3.6.

Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
Cc: <stable@vger.kernel.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
Cc: <stable@vger.kernel.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
Cc: <stable@vger.kernel.org> # v3.4
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b9f90eb2740203ff2592efe640409ad48335d1c2)

Conflicts:

drivers/net/usb/qmi_wwan.c

(cherry picked conflict resolution from commit e486463e82e4dca9e8f4413649088b21c9ff87e5)

Change-Id: Ibb3715bcaf22979ba5ebf2d1ec23fba336f0f8fe
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35015
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: use module_usb_driver macro

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 677a3d60fb3153f786a0d28fcf0287670e7bd3c2)

Change-Id: I99dc4671c06fd338913fcfed0f43e12585c539e6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35014
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: shorten driver description

The description is used in ethtool fixed length fields.  Make
it shorter to avoid truncation.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a40345b5b4a09ff8539aaafeb2c612db6d0b4d1b)

Change-Id: Ic53b2a602dfa8b066de4f9219dbf5436b8ed9f63
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35013
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: bind to both control and data interface

Always bind to control interface regardless of whether
it is a shared interface or not.

A QMI/wwan function is required to provide both a control
interface (QMI) and a data interface (wwan).  All devices
supported by this driver do so.  But the vendors may
choose to use different USB descriptor layouts, and some
vendors even allow the same device to present different
layouts.

Most of these devices use a USB descriptor layout with a
single USB interface for both control and data.  But some
split control and data into two interfaces, bound together
by a CDC Union descriptor on the control interface. Before
the cdc-wdm subdriver support was added, this split was
used to let cdc-wdm drive the QMI control interface and
qmi_wwan drive the wwna data interface.

This split driver model has a number of issues:
 - qmi_wwan must match on the data interface descriptor,
   which often are indistiguishable from data interfaces
   belonging to other CDC (like) functions like ACM
 - supporting a single QMI/wwan function requires adding
   the device to two drivers
 - syncronizing the probes among a number of drivers, to
   ensure selecting the correct driver, is difficult unless
   all drivers match on the same interface

This patch resolves these problems by using the same
probing mechanism as cdc-ether for devices with a two-
interface USB descriptor layout.  This makes the driver
behave consistently, supporting both the control and data
part of the QMI/wwan function, regardless of the USB
descriptors.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 230718bda1be24119d9e25623d90fa5da3079aa9)

Change-Id: Iddc884c8c16d002e52b9709d6596dd8c86d4ba04
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35012
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: rearranging to prepare for code sharing

Most of the subdriver registration code can be reused for devices
with separate control and data interfaces.  Move the code a bit
around to prepare for such reuse.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f47cd1360f36e599815650522986673b9aa83393)

Change-Id: Ica96b7eb66a9436d11e458bff48f23835cf5d471
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35011
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: define a structure for driver specific state

usbnet allocates a fixed size array for minidriver specific
state.  Naming the fields and taking advantage of type checking
is a bit more failsafe than casting array elements each time
they are referenced.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 853c24f79dd6f4a3d6d7b52f235fe121aee08b45)

Change-Id: I7195d5feca2e7ce99189b379ee4fa2c75a4a361b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35010
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: Add Sierra Wireless device IDs

Some additional Gobi3K IDs found in the BSD/GPL licensed
out-of-tree GobiNet driver from Sierra Wireless.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5e071b5d1aa6928f8d695c15f52a949d70b8d7fb)

Change-Id: Idc245f27ef22d38b2efd9b418e9f8b18f622358d
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35009
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z

Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f7142e6c226076fd40c2ebaad9fb0c9a631b790e)

Change-Id: I30409b4fce0c67b5caf3987377d0eb28cb320aaa
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35008
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z

Add the ZTE (Vodafone) K3765-Z to the whitelist. This requires the
previous patch to make the whitelist with forced interface 4 generic
or the device fails to initialise. After applying this patch and
loading the Option driver without usb-modeswitch's bind all
interfaces trick, a wwan0 net interface and /dev/cdc-wdm0 device
file were created. Using Bjorn Mork's perl connection script a
connection was made to a mobile network using QMI and the network
interface's IPv4 address was configured OK.

Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8965c98fdebedce077257241957b205515dd1a5f)

Change-Id: Id7fdf80108d8a0a45e2f73badb7cb8332c7a09f3
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35007
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: USB: qmi_wwan: Make forced int 4 whitelist generic

Change the forced interface 4 whitelist to use the generic shared
binder instead of the Gobi specific one. Certain ZTE devices
(K3520-Z & K3765-Z) don't work with the Gobi version, but function
quite happily with the generic. This has been tested with the following
devices:
K3520-Z
K3565-Z
K3765-Z
K4505-Z
It hasn't been tested with the ZTE MF820D, which is the only other
device that uses this whitelist at present. Although Bjorn doesn't
expect any problems, any testing with that device would be appreciated.

Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 00001880cd8faaa349fe2ebb158f7e0cd8026048)

Change-Id: I003ecd9bdff5903038952f92573d655bd2b6e057
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35006
Reviewed-by: Olof Johansson <olofj@chromium.org>

UPSTREAM: net: qmi_wwan: Add Vodafone/Huawei K5005 support

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 88c16dc3bb61a1c1e9d4c78f45cc2107bc8d5249)

Change-Id: I9ad0894ba77909a58a7e93010b42a68ed9370074
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35005
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: Input: atmel_mxt_ts - release all fingers on resume

Currently lid close/open can generate noise touch events on system
suspend and resume. One case is that touch down is generated before
suspend, and touch liftoff is processed on resume. The driver will
discard any pending messages on resume which might make the system
enter ghost finger state (touch down without ever liftoff).

To workaround the ghost finger case, this patch forces release of
all possible fingers on resume. And to avoid the unwanted click
resulted from the forced release, move these fingers first to (0,0)
and assign them with maximal PRESSURE and TOUCH_MAJOR value so to
make them look like palms.

Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chromium:154383
TEST=use evtest to monitor the touch device; put fingers on the
     touch device; close the lid; remove fingers after making
     sure the system enters suspend; Open the lid;
     Make sure to see finger move events with pressue and
     touch_major = 255 and the release events.

Change-Id: Ic9f0659a2e731c2db03255eb2107be88b333541a
Reviewed-on: https://gerrit.chromium.org/gerrit/35046
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Ready: Yufeng Shen <miletus@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>

CHROMIUM: LSM: add module loading restrictions

Only allow modules to be loaded from the same initial file system.

At run-time, if root device is writable (dm-verity disabled), the restriction
can be disabled via the sysctl "/proc/sys/kernel/chromiumos/module_locking".

BUG=chromium-os:34134
TEST=parrot build & boot, manual testing

Change-Id: I2ee7b15fb70b342ba8ffbdb74a0377215187924a
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34306
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: finit_module: add syscall to ARM

Add finit_module syscall to the ARM syscall list.

BUG=chromium-os:34134
TEST=snow build, manual testing

[accepted into Rusty's modules-wip tree for linux-next:
 http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=shortlog;h=refs/heads/modules-wip]
Change-Id: I7d35fd0cc98ff29e2a8dfae166d704d348908a2a
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34305
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: finit_module: add syscall to asm-generic

This adds the finit_module syscall to the generic syscall list.

BUG=chromium-os:34134
TEST=parrot build & boot, manual testing

[accepted into Rusty's modules-wip tree for linux-next:
 http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=shortlog;h=refs/heads/modules-wip]
Change-Id: Ifeb1db7350685967ee9d4cffe06d1df689e289bd
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34304
Reviewed-by: Olof Johansson <olofj@chromium.org>

CHROMIUM: security: introduce kernel_module_from_file hook

Now that kernel module origins can be reasoned about, provide a hook to
the LSMs to make policy decisions about the module file.

Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Acked-by: Eric Paris <eparis@redhat.com>
[accepted into Rusty's modules-wip tree for linux-next:
 http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=shortlog;h=refs/heads/modules-wip]
BUG=chromium-os:34134
TEST=parrot build, manual testing

Change-Id: I97f5cc0a0f3c1c04e1dc886d6d20f5a6d82326ac
Reviewed-on: https://gerrit.chromium.org/gerrit/34303
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Kees Cook <keescook@chromium.org>

CHROMIUM: module: add syscall to load module from fd

Instead of (or in addition to) kernel module signing, being able to reason
about the origin of a kernel module would be valuable in situations
where an OS already trusts a specific file system, file, etc, due to
things like security labels or an existing root of trust to a partition
through things like dm-verity.

This introduces a new syscall (currently only on x86), similar to
init_module, that has only two arguments. The first argument is used as
a file descriptor to the module and the second argument is a pointer to
the NULL terminated string of module arguments.

Signed-off-by: Kees Cook <keescook@chromium.org>
[accepted into Rusty's modules-wip tree for linux-next:
 http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=shortlog;h=refs/heads/modules-wip]
BUG=chromium-os:34134
TEST=parrot build, manual testing

Change-Id: I51122d61d0085ed40d2ac9b542646b28d066d5e3
Reviewed-on: https://gerrit.chromium.org/gerrit/34302
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Kees Cook <keescook@chromium.org>

ARM: EXYNOS5: Switch VPLL to 70.0MHz

Switch to 70.0 MHz.  These PMSK values come from Samsung SLSI
and pass EMI/RFI.  The 70.5 MHz values were found to flicker a
little bit and so we're hoping these won't cause flicker.

>>> (p, m, s, k) = 3, 140, 4, 0
>>> print (((m + ctypes.c_int16(k).value / 65536.) *
       fin / (p * (2 ** s))) / 1000000)
70.0
>>> print "Between 700 and 1400: ", ((float(fin) * m) / p) / 1000000
Between 700 and 1400:  1120.0

BUG=chrome-os-partner:12498
TEST=Run flicker-detect

Change-Id: I427f2ca93863b392d449324eb9d6af47460d6267
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35088
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: Input: cyapa - Enable debug on various error paths.

Selectively enable i2c debugging on certain error paths.
When poll state returns an error, debug will be enabled.
Add more debugging on bl_activate, bl_deactivate, and bl_exit
functions.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:34776
TEST=run
/opt/google/touchpad/firmware/chromeos-touch-firmwareupdater -d cyapa -f
Interrupt the forced update by shutting the machine down, pressing the power
button.
On the next boot, the trackpad should recover, and checking dmesg,
check to see that cyapa debug output is enabled after the failure
to transition to OP mode, up to the recovery firmware update
and then stops being verbose when we enter OP mode finally.

Change-Id: If9b7efb4605fb6ecdab67321f29f01d302d7119a
Reviewed-on: https://gerrit.chromium.org/gerrit/34965
Commit-Ready: Benson Leung <bleung@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>

drm/exynos: flip_apply the correct buffer

From the initial report:

<snip>
There's an issue with the queueing up swaps with future_kds_extra.
When we do so, we still immediately write the fb that we should flip
to into the crtc (in exynos_drm_crtc_page_flip). The KDS callback
displays whatever is the fb currently stored there
(exynos_drm_kds_callback -> exynos_drm_crtc_page_flip_apply).

So when we get a second flip request before the first has completed,
we overwrite the fb that the first flip was intended to flip to.
This breaks the relationship between the KDS resource that we wait
for and the buffer that we scan out. This clearly has the potential
to cause tearing.
</snip>

Fix is to flip_apply the fb that we are getting the callback for.

BUG=chrome-os-partner:14195,chrome-os-partner:14940
TEST=Verified that WebGL aquarium is fixed.

Change-Id: I87a1e3ff60437da92a68266f81fc7bcd6288542c
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34974

drm/exynos: Set the encoder's dpms state once we successfully set it.

Otherwise we try to go to suspend, set the state, fail to change the
actual dpms state. Then we try to resume and we get an unbalanced irq
error because we reenable something which is already enabled.

BUG=none
TEST=by hand: compiles, runs, try suspend/resume

Change-Id: I81d5bf2abe95baad73a40c2970033b3b2146a8c5
Reviewed-on: https://gerrit.chromium.org/gerrit/34978
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Erat <derat@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>

CHROMIUM: ALSA: hda/ca0132: Stop streaming when switching between dmic/amic1.

When switching between microphones, if an active recording stream is
running, it has to be stopped before the switching, otherwise the
parameters won't be applied correctly.

The patch is provided by Creative.

BUG=chrome-os-partner:14920
TEST=use "arecord -f cd -B 10000 -d 20 1.wav"
to record audio, and plug/unplug headphone while recording.

Change-Id: I7cb94d4391e3e1525955c70a55c999458f62be30
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34993
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Ready: Chih-Chung Chang <chihchung@google.com>
Tested-by: Chih-Chung Chang <chihchung@google.com>

UPSTREAM: USB: add USB_VENDOR_AND_INTERFACE_INFO() macro

A lot of Broadcom Bluetooth devices provides vendor specific interface
class and we are getting flooded by patches adding new device support.
This change will help us enable support for any other Broadcom with vendor
specific device that arrives in the future.

Only the product id changes for those devices, so this macro would be
perfect for us:

{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Henrik Rydberg <rydberg@bitmath.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d81a5d1956731c453b85c141458d4ff5d6cc5366)

Change-Id: Ib758edf203e02a0e9cff2c053d8739b409f36f24
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34929
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

UPSTREAM: USB: allow match on bInterfaceNumber

Some composite USB devices provide multiple interfaces
with different functions, all using "vendor-specific"
for class/subclass/protocol.  Another OS use interface
numbers to match the driver and interface. It seems
these devices are designed with that in mind - using
static interface numbers for the different functions.

This adds support for matching against the
bInterfaceNumber, allowing such devices to be supported
without having to resort to testing against interface
number whitelists and/or blacklists in the probe.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 81df2d594340dcb6d1a02191976be88a1ca8120c)

Change-Id: I4c3449d5d58a06566a2f4279366c07ccda5da0a1
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34928
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

CHROMIUM: config: Renormalize splitconfig

Just ran: ./chromeos/scripts/kernelconfig oldconfig
...and hit return for everything.  AKA: no functional change
here, this just tells us where we are.

BUG=chrome-os-partner:14297
TEST=build ok. booted on snow and play multimedia apps
 run ./chromeos/scripts/kernelconfig oldconfig to normalize config

Change-Id: I4a04b37486c0dab4ce10181fd427d3654ef989db
Signed-off-by: abhinav <abhinav@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34992
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>

ARM: MM: Add the workaround of Errata 766421

This patch adds the workaround of errata 766421 that adds 'dmb' when changing
the translation regime after conditions that the errata 766421 may occur.
Concretely, Add 'dmb' when changing ASID and secure state for cortex-A15 r0p4.

BUG=chrome-os-partner:14297
TEST=build ok, booted kernel

Change-Id: Ib41b855798b71ecf973578305e81cefe754bb1f4
Signed-off-by: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Abhinav <abhinav@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34991
Reviewed-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

drm/exynos: STANDBY should turn the panel off.

BUG=none
TEST=by hand: compiles, runs, try suspend/resume

Change-Id: I6e25995a923ec39df035a12e31ee5e7090351a9d
Reviewed-on: https://gerrit.chromium.org/gerrit/34977
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>

UPSTREAM: drm: consistently name interlaced modes

At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:

        <horizontal-res>x<vertical-res><interlace-char>

eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.

However, timings parsed using the tables in drm_edid_modes.h do not
have the 'i' suffix.  You are left to deduce that they're interlaced
from xrandr's output by the lower vertical refresh frequencies.

This patch changes the interlaced mode names in drm_edid_modes.h to
follow the style set by drm_mode_set_name(), which makes it clear
in xrandr which modes are interlaced and which are not (as xrandr
groups the refresh rates on a line according to the name field.)

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
BUG=chrome-os-partner:12642
TEST=Tested on snow with xrandr to set and verify interlaced mode

(cherry picked from commit 4a1897d268bcde8a8d0ba7d3d887d70e66b4d6f1)
Change-Id: I24c5cba9f284945b7c1ab29068687a42dc49f08a
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34747
Reviewed-by: Shirish S <shirish@chromium.org>
Tested-by: Shirish S <shirish@chromium.org>
Commit-Ready: Shirish S <shirish@chromium.org>

UPSTREAM: xhci: Fix bug after deq ptr set to link TRB.

commit 50d0206fcaea3e736f912fd5b00ec6233fb4ce44 upstream.

This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches.  The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.

The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB.  The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added.  It assumed that the dequeue pointer could never
point to a link TRB.  It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.

This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land.  It would then read from
that memory to determine if it was a link TRB.  Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.

Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of.  inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.

The only reason the original code worked at all is because there was
only one ring segment.  With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync.  On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:

ERROR Transfer event TRB DMA ptr not part of current TD

This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),

https://bugzilla.kernel.org/show_bug.cgi?id=43333

and possibly other general protection fault bugs as well.

This patch should be backported to kernels as old as 2.6.31.  A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.

We were seeing below kernel crash:
[  158.665996] GPT: Use GNU Parted to correct GPT errors.
[  158.671143]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[  158.683382] Unable to handle kernel paging request at virtual address f004e00c
[  158.689120] pgd = 80004000
[  158.691809] [f004e00c] *pgd=af006811, *pte=00000000, *ppte=00000000
[  158.698062] Internal error: Oops: 7 [#1] SMP ARM
[  158.702660] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat i2c_dev uinput uvcvideo videobuf2_vmalloc rfcomm isl29018(C) industrialio(C) sbs_battery spidev btmrvl_sdi$
[  158.728961] CPU: 0    Tainted: G         C    (3.4.0 #6)
[  158.734260] PC is at inc_deq+0x110/0x130
[  158.738163] LR is at finish_td+0x154/0x238
[  158.742242] pc : [<80320ff8>]    lr : [<80323b90>]    psr: 80070193
[  158.742245] sp : 8072dd20  ip : ef39ca80  fp : 8072dd34
[  158.753698] r10: f0010510  r9 : 00000002  r8 : edaac300
[  158.758906] r7 : 00000000  r6 : eda52130  r5 : ef015000  r4 : ef39ca80
[  158.765416] r3 : f004e000  r2 : e83e9f00  r1 : edaac300  r0 : ef015000
[  158.771927] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  158.779304] Control: 10c5387d  Table: addd006a  DAC: 00000015
[  158.785033] Process swapper/0 (pid: 0, stack limit = 0x8072c2f8)
[  158.791022] Stack: (0x8072dd20 to 0x8072e000)

BUG=chrome-os-partner:14992
TEST=Tested with 'Nobility NH-13' usb 3.0 device detected and
enumerated properly; could play an audio file present
in the device; No kernel crash after testing 20 times.

Change-Id: I3c689bd811fef6f91260e97cf6f1cb202ed899cc
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1aac2e73a8af6ce1cd6e938967dd17e2c8d38994)
Reviewed-on: https://gerrit.chromium.org/gerrit/34879
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

UPSTREAM: xhci: Fix hang on back-to-back Set TR Deq Ptr commands.

commit 0d9f78a92ef5e97d9fe51d9215ebe22f6f0d289d upstream.

The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in.  At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:

xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD

However, it turned out to be an xHCI driver bug in the ring expansion
patches.  The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:

 ______________                     _____________
|              |              ---> | setup TRB B |
 ______________               |     _____________
|              |              |    |  data TRB B |
 ______________               |     _____________
| setup TRB A  | <-- deq      |    |  data TRB B |
 ______________               |     _____________
| data TRB A   |              |    |             | <-- enq, deq''
 ______________               |     _____________
| status TRB A |              |    |             |
 ______________               |     _____________
|  link TRB    |---------------    |  link TRB   |
 _____________  <--- deq'           _____________

TD A (the first control transfer) stalls on the data phase.  That halts
the ring.  The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.

Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs.  That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer.  On the first call this would work fine, and the
software dequeue pointer would move to deq'.

However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued.  That would move
the hardware dequeue pointer to deq''.  Once that command completed,
update_ring_for_set_deq_completion would run again.

The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.

The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB.  This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.

If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment.  Thus, the deq_seg and the
software dequeue pointer would get out of sync.

When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer.  Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.

The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.

This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6369ba0290fa7daa177375407a12e07 "xHCI: count free
TRBs on transfer ring"

We were seeing below kernel crash:
[  158.665996] GPT: Use GNU Parted to correct GPT errors.
[  158.671143]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[  158.683382] Unable to handle kernel paging request at virtual address f004e00c
[  158.689120] pgd = 80004000
[  158.691809] [f004e00c] *pgd=af006811, *pte=00000000, *ppte=00000000
[  158.698062] Internal error: Oops: 7 [#1] SMP ARM
[  158.702660] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat i2c_dev uinput uvcvideo videobuf2_vmalloc rfcomm isl29018(C) industrialio(C) sbs_battery spidev btmrvl_sdi$
[  158.728961] CPU: 0    Tainted: G         C    (3.4.0 #6)
[  158.734260] PC is at inc_deq+0x110/0x130
[  158.738163] LR is at finish_td+0x154/0x238
[  158.742242] pc : [<80320ff8>]    lr : [<80323b90>]    psr: 80070193
[  158.742245] sp : 8072dd20  ip : ef39ca80  fp : 8072dd34
[  158.753698] r10: f0010510  r9 : 00000002  r8 : edaac300
[  158.758906] r7 : 00000000  r6 : eda52130  r5 : ef015000  r4 : ef39ca80
[  158.765416] r3 : f004e000  r2 : e83e9f00  r1 : edaac300  r0 : ef015000
[  158.771927] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  158.779304] Control: 10c5387d  Table: addd006a  DAC: 00000015
[  158.785033] Process swapper/0 (pid: 0, stack limit = 0x8072c2f8)
[  158.791022] Stack: (0x8072dd20 to 0x8072e000)

BUG=chrome-os-partner:14992
TEST=Tested with 'Nobility NH-13' usb 3.0 device detected and
enumerated properly; could play an audio file present
in the device; No kernel crash after testing 20 times.

Change-Id: I909dd3fc9513bcdf97fcc3ca5993de1cd18742b0
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b62d32b9166b085a487916eca514b59b5ffdf2b7)
Reviewed-on: https://gerrit.chromium.org/gerrit/34878
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

UPSTREAM: xhci: Reset reserved command ring TRBs on cleanup.

commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.

When the xHCI driver needs to clean up memory (perhaps due to a failed
register restore on resume from S3 or resume from S4), it needs to reset
the number of reserved TRBs on the command ring to zero.  Otherwise,
several resume cycles (about 30) with a UAS device attached will
continually increment the number of reserved TRBs, until all command
submissions fail because there isn't enough room on the command ring.

This patch should be backported to kernels as old as 2.6.32,
that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d
"USB: xhci: Change how xHCI commands are handled."

We were seeing below kernel crash:
[  158.665996] GPT: Use GNU Parted to correct GPT errors.
[  158.671143]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[  158.683382] Unable to handle kernel paging request at virtual address f004e00c
[  158.689120] pgd = 80004000
[  158.691809] [f004e00c] *pgd=af006811, *pte=00000000, *ppte=00000000
[  158.698062] Internal error: Oops: 7 [#1] SMP ARM
[  158.702660] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat i2c_dev uinput uvcvideo videobuf2_vmalloc rfcomm isl29018(C) industrialio(C) sbs_battery spidev btmrvl_sdi$
[  158.728961] CPU: 0    Tainted: G         C    (3.4.0 #6)
[  158.734260] PC is at inc_deq+0x110/0x130
[  158.738163] LR is at finish_td+0x154/0x238
[  158.742242] pc : [<80320ff8>]    lr : [<80323b90>]    psr: 80070193
[  158.742245] sp : 8072dd20  ip : ef39ca80  fp : 8072dd34
[  158.753698] r10: f0010510  r9 : 00000002  r8 : edaac300
[  158.758906] r7 : 00000000  r6 : eda52130  r5 : ef015000  r4 : ef39ca80
[  158.765416] r3 : f004e000  r2 : e83e9f00  r1 : edaac300  r0 : ef015000
[  158.771927] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  158.779304] Control: 10c5387d  Table: addd006a  DAC: 00000015
[  158.785033] Process swapper/0 (pid: 0, stack limit = 0x8072c2f8)
[  158.791022] Stack: (0x8072dd20 to 0x8072e000)

BUG=chrome-os-partner:14992
TEST=Tested with 'Nobility NH-13' usb 3.0 device detected and
enumerated properly; could play an audio file present
in the device; No kernel crash after testing 20 times.

Change-Id: Ie8da96a6efaea1edc5f7bef71fa1d2e212c2b7d6
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.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 c9022f1306507d81a527c86ec756c938c3b8bc70)
Reviewed-on: https://gerrit.chromium.org/gerrit/34877
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

UPSTREAM: xhci: Don't free endpoints in xhci_mem_cleanup()

commit 32f1d2c536d0c26c5814cb0e6a0606c42d02fac1 upstream.

This patch fixes a few issues introduced in the recent fix
[f8a9e72d: USB: fix resource leak in xhci power loss path]

- The endpoints listed in bw table are just links and each entry is an
 array member of dev->eps[].  But the commit above adds a kfree() call
 to these instances, and thus it results in memory corruption.

- It clears only the first entry of rh_bw[], but there can be multiple
  ports.

- It'd be safer to clear the list_head of ep as well, not only
  removing from the list, as it's checked in
  xhci_discover_or_reset_device().

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

We were seeing below kernel crash:
[  158.665996] GPT: Use GNU Parted to correct GPT errors.
[  158.671143]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[  158.683382] Unable to handle kernel paging request at virtual address f004e00c
[  158.689120] pgd = 80004000
[  158.691809] [f004e00c] *pgd=af006811, *pte=00000000, *ppte=00000000
[  158.698062] Internal error: Oops: 7 [#1] SMP ARM
[  158.702660] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat i2c_dev uinput uvcvideo videobuf2_vmalloc rfcomm isl29018(C) industrialio(C) sbs_battery spidev btmrvl_sdi$
[  158.728961] CPU: 0    Tainted: G         C    (3.4.0 #6)
[  158.734260] PC is at inc_deq+0x110/0x130
[  158.738163] LR is at finish_td+0x154/0x238
[  158.742242] pc : [<80320ff8>]    lr : [<80323b90>]    psr: 80070193
[  158.742245] sp : 8072dd20  ip : ef39ca80  fp : 8072dd34
[  158.753698] r10: f0010510  r9 : 00000002  r8 : edaac300
[  158.758906] r7 : 00000000  r6 : eda52130  r5 : ef015000  r4 : ef39ca80
[  158.765416] r3 : f004e000  r2 : e83e9f00  r1 : edaac300  r0 : ef015000
[  158.771927] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  158.779304] Control: 10c5387d  Table: addd006a  DAC: 00000015
[  158.785033] Process swapper/0 (pid: 0, stack limit = 0x8072c2f8)
[  158.791022] Stack: (0x8072dd20 to 0x8072e000)

BUG=chrome-os-partner:14992
TEST=Tested with 'Nobility NH-13' usb 3.0 device detected and
enumerated properly; could play an audio file present
in the device; No kernel crash after testing 20 times.

Change-Id: I17dca4fed48492b4a12a9678bf028ba7384a8a5e
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
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 708053a5a4e304915aae1ecab2e5fea9921c9f82)
Reviewed-on: https://gerrit.chromium.org/gerrit/34876
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

UPSTREAM: USB: fix resource leak in xhci power loss path

commit f8a9e72d125f4e00ec529ba67b674321a1f3bf31 upstream.

Some more data structures must be freed and counters
reset if an XHCI controller has lost power. The failure
to do so renders some chips inoperative after a certain number
of S4 cycles.

This patch should be backported to kernels as old as 3.2,
that contain the commits c29eea621900f18287d50519f72cb9113746d75a
"xhci: Implement HS/FS/LS bandwidth checking." and
commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe
"xhci: Implement HS/FS/LS bandwidth checking."

We were seeing below kernel crash:
[  158.665996] GPT: Use GNU Parted to correct GPT errors.
[  158.671143]  sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[  158.683382] Unable to handle kernel paging request at virtual address f004e00c
[  158.689120] pgd = 80004000
[  158.691809] [f004e00c] *pgd=af006811, *pte=00000000, *ppte=00000000
[  158.698062] Internal error: Oops: 7 [#1] SMP ARM
[  158.702660] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat i2c_dev uinput uvcvideo videobuf2_vmalloc rfcomm isl29018(C) industrialio(C) sbs_battery spidev btmrvl_sdio btmrvl bluetooth fuse nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_mark mwifiex_sdio mwifiex cfg80211 joydev
[  158.728961] CPU: 0    Tainted: G         C    (3.4.0 #6)
[  158.734260] PC is at inc_deq+0x110/0x130
[  158.738163] LR is at finish_td+0x154/0x238
[  158.742242] pc : [<80320ff8>]    lr : [<80323b90>]    psr: 80070193
[  158.742245] sp : 8072dd20  ip : ef39ca80  fp : 8072dd34
[  158.753698] r10: f0010510  r9 : 00000002  r8 : edaac300
[  158.758906] r7 : 00000000  r6 : eda52130  r5 : ef015000  r4 : ef39ca80
[  158.765416] r3 : f004e000  r2 : e83e9f00  r1 : edaac300  r0 : ef015000
[  158.771927] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  158.779304] Control: 10c5387d  Table: addd006a  DAC: 00000015
[  158.785033] Process swapper/0 (pid: 0, stack limit = 0x8072c2f8)
[  158.791022] Stack: (0x8072dd20 to 0x8072e000)

BUG=chrome-os-partner:14992
TEST=Tested with 'Nobility NH-13' usb 3.0 device detected and
enumerated properly; could play an audio file present
in the device; No kernel crash after testing 20 times.

Change-Id: I26908e7905bf9b7ef292c4e57d73812bf2dda2da
Signed-off-by: Vikas C Sajjan <vikas.sajjan@samsung.com>
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 61fb50b8328e61b6038d99c6333a60b5b02328d8)
Reviewed-on: https://gerrit.chromium.org/gerrit/34875
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>

CHROMIUM: ALSA: ASoC: max98095 - Don't enable VDDPU by default.

The DSP clock selection was also setting bit four of the config register
which enables a pullup resistor between AVDD and JACKSNS.  The datasheet
specifies that this should not be set at the same time as MICBIAS2.
Setting both results in noise on MIC2, which is obvious on Daisy without
this fix.

BUG=chrome-os-partner:14903
TEST=arecord with headset listen for noise.  i2cdump shows register 45
doesn't have VDDPU set.

Change-Id: I5aa0e8be2652e550fef0942f16ea9214fe9571d5
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34679
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Tested-by: Evan Ragsdale <evan.ragsdale@maximintegrated.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>

ARM: EXYNOS5: Switch VPLL to 70.5MHz

Switch to 70.5 MHz.  These PMSK values comes from Samsung SLSI
and pass EMI/RFI.  We believe that they don't cause flicker.

>>> (p, m, s, k) = 2, 94, 4, 0
>>> print (((m + ctypes.c_int16(k).value / 65536.) *
           fin / (p * (2 ** s))) / 1000000)
70.5
>>> print "Between 700 and 1400: ", ((float(fin) * m) / p) / 1000000
Between 700 and 1400:  1128.0

BUG=chrome-os-partner:12498
TEST=Run flicker-detect

Change-Id: If41cd082acc344b9396073ca28d10c90f2a5574d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34836
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>

UPSTREAM: USB: serial: Enforce USB driver and USB serial driver match

We need to make sure that the USB serial driver we find
matches the USB driver whose probe we are currently
executing. Otherwise we will end up with USB serial
devices bound to the correct serial driver but wrong
USB driver.

An example of such cross-probing, where the usbserial_generic
USB driver has found the sierra serial driver:

May 29 18:26:15 nemi kernel: [ 4442.559246] usbserial_generic 4-4:1.0: Sierra USB modem converter detected
May 29 18:26:20 nemi kernel: [ 4447.556747] usbserial_generic 4-4:1.2: Sierra USB modem converter detected
May 29 18:26:25 nemi kernel: [ 4452.557288] usbserial_generic 4-4:1.3: Sierra USB modem converter detected

sysfs view of the same problem:

bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/sierra/
total 0
--w------- 1 root root 4096 May 29 18:23 bind
lrwxrwxrwx 1 root root    0 May 29 18:23 module -> ../../../../module/usbserial
--w------- 1 root root 4096 May 29 18:23 uevent
--w------- 1 root root 4096 May 29 18:23 unbind
bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/sierra/
total 0
--w------- 1 root root 4096 May 29 18:23 bind
lrwxrwxrwx 1 root root    0 May 29 18:23 module -> ../../../../module/sierra
-rw-r--r-- 1 root root 4096 May 29 18:23 new_id
lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0/ttyUSB0
lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB1 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2/ttyUSB1
lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3/ttyUSB2
--w------- 1 root root 4096 May 29 18:23 uevent
--w------- 1 root root 4096 May 29 18:23 unbind

bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/usbserial_generic/
total 0
lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0
lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2
lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.3 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3
--w------- 1 root root 4096 May 29 18:33 bind
lrwxrwxrwx 1 root root    0 May 29 18:33 module -> ../../../../module/usbserial
--w------- 1 root root 4096 May 29 18:22 uevent
--w------- 1 root root 4096 May 29 18:33 unbind
bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/generic/
total 0
--w------- 1 root root 4096 May 29 18:33 bind
lrwxrwxrwx 1 root root    0 May 29 18:33 module -> ../../../../module/usbserial
-rw-r--r-- 1 root root 4096 May 29 18:33 new_id
--w------- 1 root root 4096 May 29 18:22 uevent
--w------- 1 root root 4096 May 29 18:33 unbind

So we end up with a mismatch between the USB driver and the
USB serial driver.  The reason for the above is simple: The
USB driver probe will succeed if *any* registered serial
driver matches, and will use that serial driver for all
serial driver functions.

This makes ref counting go wrong. We count the USB driver
as used, but not the USB serial driver.  This may result
in Oops'es as demonstrated by Johan Hovold <jhovold@gmail.com>:

[11811.646396] drivers/usb/serial/usb-serial.c: get_free_serial 1
[11811.646443] drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 0
[11811.646460] drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB0
[11811.646766] usb 6-1: pl2303 converter now attached to ttyUSB0
[11812.264197] USB Serial deregistering driver FTDI USB Serial Device
[11812.264865] usbcore: deregistering interface driver ftdi_sio
[11812.282180] USB Serial deregistering driver pl2303
[11812.283141] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[11812.283272] usbcore: deregistering interface driver pl2303
[11812.301056] USB Serial deregistering driver generic
[11812.301186] usbcore: deregistering interface driver usbserial_generic
[11812.301259] drivers/usb/serial/usb-serial.c: usb_serial_disconnect
[11812.301823] BUG: unable to handle kernel paging request at f8e7438c
[11812.301845] IP: [<f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial]
[11812.301871] *pde = 357ef067 *pte = 00000000
[11812.301957] Oops: 0000 [#1] PREEMPT SMP
[11812.301983] Modules linked in: usbserial(-) [last unloaded: pl2303]
[11812.302008]
[11812.302019] Pid: 1323, comm: modprobe Tainted: G        W    3.4.0-rc7+ #101 Dell Inc. Vostro 1520/0T816J
[11812.302115] EIP: 0060:[<f8e38445>] EFLAGS: 00010246 CPU: 1
[11812.302130] EIP is at usb_serial_disconnect+0xb5/0x100 [usbserial]
[11812.302141] EAX: f508a180 EBX: f508a180 ECX: 00000000 EDX: f8e74300
[11812.302151] ESI: f5050800 EDI: 00000001 EBP: f5141e78 ESP: f5141e58
[11812.302160]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[11812.302170] CR0: 8005003b CR2: f8e7438c CR3: 34848000 CR4: 000007d0
[11812.302180] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[11812.302189] DR6: ffff0ff0 DR7: 00000400
[11812.302199] Process modprobe (pid: 1323, ti=f5140000 task=f61e2bc0 task.ti=f5140000)
[11812.302209] Stack:
[11812.302216]  f8e3be0f f8e3b29c f8e3ae00 00000000 f513641c f5136400 f513641c f507a540
[11812.302325]  f5141e98 c133d2c1 00000000 00000000 f509c400 f513641c f507a590 f5136450
[11812.302372]  f5141ea8 c12f0344 f513641c f507a590 f5141ebc c12f0c67 00000000 f507a590
[11812.302419] Call Trace:
[11812.302439]  [<c133d2c1>] usb_unbind_interface+0x51/0x190
[11812.302456]  [<c12f0344>] __device_release_driver+0x64/0xb0
[11812.302469]  [<c12f0c67>] driver_detach+0x97/0xa0
[11812.302483]  [<c12f001c>] bus_remove_driver+0x6c/0xe0
[11812.302500]  [<c145938d>] ? __mutex_unlock_slowpath+0xcd/0x140
[11812.302514]  [<c12f0ff9>] driver_unregister+0x49/0x80
[11812.302528]  [<c1457df6>] ? printk+0x1d/0x1f
[11812.302540]  [<c133c50d>] usb_deregister+0x5d/0xb0
[11812.302557]  [<f8e37c55>] ? usb_serial_deregister+0x45/0x50 [usbserial]
[11812.302575]  [<f8e37c8d>] usb_serial_deregister_drivers+0x2d/0x40 [usbserial]
[11812.302593]  [<f8e3a6e2>] usb_serial_generic_deregister+0x12/0x20 [usbserial]
[11812.302611]  [<f8e3acf0>] usb_serial_exit+0x8/0x32 [usbserial]
[11812.302716]  [<c1080b48>] sys_delete_module+0x158/0x260
[11812.302730]  [<c110594e>] ? mntput+0x1e/0x30
[11812.302746]  [<c145c3c3>] ? sysenter_exit+0xf/0x18
[11812.302746]  [<c107777c>] ? trace_hardirqs_on_caller+0xec/0x170
[11812.302746]  [<c145c390>] sysenter_do_call+0x12/0x36
[11812.302746] Code: 24 02 00 00 e8 dd f3 20 c8 f6 86 74 02 00 00 02 74 b4 8d 86 4c 02 00 00 47 e8 78 55 4b c8 0f b6 43 0e 39 f8 7f a9 8b 53 04 89 d8 <ff> 92 8c 00 00 00 89 d8 e8 0e ff ff ff 8b 45 f0 c7 44 24 04 2f
[11812.302746] EIP: [<f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial] SS:ESP 0068:f5141e58
[11812.302746] CR2: 00000000f8e7438c

Fix by only evaluating serial drivers pointing back to the
USB driver we are currently probing.  This still allows two
or more drivers to match the same device, running their
serial driver probes to sort out which one to use.

Cc: stable@vger.kernel.org # 3.0, 3.2, 3.3, 3.4
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Tested-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 954c3f8a5f1b7716be9eee978b3bc85bae92d7c8)

Change-Id: I88a1156e4a2556200ce832b2d9391fb0136afb68
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34863
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>

Revert "CHROMIUM: mwifiex: Increase channel dwell time"

This reverts commit 77a52db0f68664c4cbcbd73eeffe3cb0456cef99

Change-Id: I843cd59dc3a4788b6ac889d7a4dbd2f34e2d3005
Reviewed-on: https://gerrit.chromium.org/gerrit/34893
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>

UPSTREAM: ARM: dma-mapping: Fix potential memory leak in atomic_pool_init()

When either of __alloc_from_contiguous or __alloc_remap_buffer fails
to provide a valid pointer, allocated memory is freed up and an error
is returned. 'pages' was however not freed before returning error.

BUG=chrome-os-partner:13939
TEST=Built kernel and booted on snow.

Change-Id: Ie04339638da85aae1ba74ddb186ce563ff1f7ee0
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
(cherry picked from commit ec10665cbf271fb1f60daeb194ad4f2cdcdc59d9)
Reviewed-on: https://gerrit.chromium.org/gerrit/34741
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>

UPSTREAM: HID: hidraw: don't deallocate memory when it is in use

When a device is unplugged, wait for all processes that have opened the device
to close before deallocating the device.

Signed-off-by: Ratan Nalumasu <ratan@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BUG=chromium-os:35053
TEST=parrot build, made sure HID devices plugging/unplugging works

(cherry picked from commit 4fe9f8e203fdad1524c04beb390f3c6099781ed9)
Change-Id: I9b88409e376607c88a9aec4f8cdb95945d471b54
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34674
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>

UPSTREAM: mwifiex: report received management frames to cfg80211

Process the management frames received from firmware and report
them to cfg80211.

Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Kevin Gan <ganhy@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:14959
TEST=pass pre-WiFi Cert. test case 5.2.48

Change-Id: I060da9544b9892a5ecadb38a891d37474f76f389
Reviewed-on: https://gerrit.chromium.org/gerrit/34852
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

UPSTREAM: mwifiex: implement cfg80211 mgmt_frame_register handler

Add a new command to implement mgmt_frame_register.

Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:14959
TEST=pass pre-WiFi Cert. test case 5.2.48

Change-Id: I7ff7594ec8b7d407b8425210f2830586136ff39c
Reviewed-on: https://gerrit.chromium.org/gerrit/34851
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

UPSTREAM: mwifiex: advertise mgmt_stype to cfg80211

Advertise supported management frame types to cfg80211.

Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:14959
TEST=pass pre-WiFi Cert. test case 5.2.48

Change-Id: I4498bc5e9812fb00ad33f83ab20ef66774dd8210
Reviewed-on: https://gerrit.chromium.org/gerrit/34850
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

UPSTREAM: mwifiex: implement cfg80211 mgmt_tx handler

Implement mgmt_tx in cfg80211 ops through data path.
Advertise probe resp offload and skip to send probe resp in AP
or GO mode.

Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:14959
TEST=pass pre-WiFi Cert. test case 5.2.48

Change-Id: I056dff29b152d82d75f9b7867462ddaac9ff5c20
Reviewed-on: https://gerrit.chromium.org/gerrit/34849
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

CHROMIUM: mwifiex: Increase channel dwell time

Increase channel dwell time for active-scan channels (which also
happen to be the channels that tend to have the most congestion).
In congested channels, we have tested this to improve the chance
of scan success by over a factor of 3.  Scan time is still less
than 7 seconds which is still faster than some mac80211-based
chipsets.

Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:14655
TEST=Scan loops, interop test

Change-Id: I2e279d6f6e9719bbf2d7317f139ef58431fe92a2
Reviewed-on: https://gerrit.chromium.org/gerrit/34838
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>

arm: exynos5: Fix clock divider value

Input frequency of DIV_ACLK_66 is over spec:

MPLL_USER(800 MHz) --> DIV_ACLK_66_PRE(division 2) --> DIV_ACLK_66(division 6) --> ACLK_66(66 MHz)
Max input frequency of DIV_ACLK_66 is 133 MHz, but output frequency of DIV_ACLK_66_PRE is 400 MHz.
So, divider values were changed as follows:
MPLL_USER(800 MHz) --> DIV_ACLK_66_PRE(division 6) --> DIV_ACLK_66(division 2) --> ACLK_66(66 MHz)

Max input frequency of dividers reference "Table 7-5 ~ 10" of User's Manual.
(Picked from Android Exynos Git - b2a697456709d7832d4a65c880cbd1b43dd317c9)

BUG=chrome-os-partner:14467
TEST=Build and boot, browse, run video playback.
     Run 40 s2r cycles successfully.

Change-Id: Id930ac1b97868dafaf5114e076e6ee0eee7ce802
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34272
Reviewed-by: Doug Anderson <dianders@chromium.org>

UPSTREAM: mwifiex: update cfg80211 with correct reason code when connection is lost

Driver gets LINK_LOST, DEAUTHENTICATED and DISASSOCIATED events
from firmware when connection is lost in different scenarios.
Currently we are using common code WLAN_REASON_DEAUTH_LEAVING
for these cases.

This patch adds support to parse an actual reason code from
firmware event body and send it to cfg80211.
WLAN_REASON_DEAUTH_LEAVING code is used if deauth is initiated
by our device.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:14966
TEST=check driver/wpa_supplicant logs and confirm that application
is informed with correct reason codes in various scenarios.

Change-Id: I18d2dd312576f19d59d7b916e93ca03daf584130
Reviewed-on: https://gerrit.chromium.org/gerrit/34848
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

UPSTREAM: mwifiex: update cfg80211 with correct reason code when association fails

This patch adds support to send correct reason code got from
firmware when association attempt fails. Also, the error message
displayed for association failure due to network incompatibility
is modified. Current message "cannot find ssid.." misleads user.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:14966
TEST=check driver/wpa_supplicant logs and confirm that application
is informed with correct reason codes in various scenarios.

Change-Id: If89a1e85af82d8054fc65a8d6b95a3961ccd987b
Reviewed-on: https://gerrit.chromium.org/gerrit/34847
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

CHROMIUM: ALSA: ASoC: exynos hdmi - always set switch state.

Don't drop the enable/disable switch toggle if it is called when HDMI is
not connected.  If it is dropped, user space has to call it with timing
constraints that it can't know.  Let the switch toggle if hotplug isn't
set, audio will be configured when hotplug is detected.

BUG=chrome-os-partner:14435
TEST=toggle HDMI switch and check that it is set.

Change-Id: I6c553cf4ada19616783ceffe111459b046d01b6f
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34579
Reviewed-by: Rahul Sharma <rahul.sharma@samsung.com>
Tested-by: Rahul Sharma <rahul.sharma@samsung.com>

exynos5: snow: Use recommended values for pixel clock and LCD timings

Changed the pixel clock frequency and LCD timings according to
the datasheet. This patch seems to have fixed the flickering issue.
EMI is expected to be fine with this patch.

BUG=chrome-os-partner:12498
TEST=No flickering observed for almost 12 hours.

Change-Id: I228a88f38a7b79aa33fa34dc4be98b7aa822d713
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34343
Reviewed-by: Sean Paul <seanpaul@chromium.org>

modpost: Permit .GCC.command.line sections

Allow .GCC.command.line sections in modules to prevent modpost warnings:
WARNING: sound/usb/snd-usbmidi-lib.o (.GCC.command.line): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.

BUG=None
TEST=Warnings disappear with this change.
  Deployed kernel to system and no obvious regressions.
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Change-Id: Iefe98bb2b71cee8fb72dc9e6ce25c7be240f6609
Reviewed-on: https://gerrit.chromium.org/gerrit/34667
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@chromium.org>

mwifiex: reset scan_processing flag in failure cases

scan_processing flag should be reset when scan request is failed
due to some reasons Ex. memory allocation failure etc. Otherwise
further scan requests will be blocked.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:14486
TEST=AP doing WPA and group rekeying every 600s;
DUT connects and is doing a ping with 2 second interval;
On DUT, run "while true; do iw mlan0 scan > /dev/null; done"

Change-Id: Ie0dcf5ac74cdec5c9ae3261180923a1405d5e2c7
Reviewed-on: https://gerrit.chromium.org/gerrit/34715
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Ready: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>

mwifiex: return -EBUSY if scan request cannot be honored

There are cases we cannot scan when a request is received.
For example, during WPA group key negotiation the scan request
will be blocked. We should return an error code to cfg80211
because cfg80211_scan_done will never be called.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:14486
TEST=Scan in a tight loop while switching between networks.

Change-Id: If76544345e9300693c41f6ba07bd508706279305
Reviewed-on: https://gerrit.chromium.org/gerrit/34629
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>

drm/exynos: fix trace events

The trace events were getting called from the wrong location.

We also need to add a fake_flip_complete event to support the
kds changes.

BUG=chromium-os:35009
TEST=Verified the events are reported correctly.

Change-Id: I6b1095b9d76a3be8c721c0232066ef60ee40b41e
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34594
Reviewed-by: Sam Leffler <sleffler@chromium.org>

CHROMIUM: gpu: i915: optimize vblank timeout

On the resume path, wait_for_vblank is called 4 times and waits until its
timeout. To reduce the delays on that path, let's compute the maximum vblank
delay instead of always using the arbitrary 50 ms value.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13364
TEST=On Link, measure resume time and see a 130ms improvement.

Change-Id: I88231de43573432b6d71255f622eb9860fe3c28d
Reviewed-on: https://gerrit.chromium.org/gerrit/34624
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>

gpu: vithar: Change pm policy to always-on from demand

Switching to an always-on policy from the current on-demand
policy. This is because dynamic GPU power management should
be only done using the coarse-demand policy.

BUG=chrome-os-partner:14828
TEST=Multiple webgl apps tested.
Power Measurement variation from demand to always-on (in mW):
1) dut_idle.sh: 1.5 -> 13.5
2) No browser window (logged in): 1.9 -> 14.6
3) Browser window (Full screen): 6 -> 20
4) Aquarium: ~615 either way
5) Many Planets: ~715 either way

Change-Id: I8c209be1cd9b0f0cc9a2cf4ba78a7ba00316793c
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34509
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>

ASoC: Samsung: Remove pm get_sync and put_sync functionality

Get sync and put sync is already added for cpu dai, codec dai
and platform devices in the soc-pcm file before startup and after
shutdown respectively. So this is not adding any purpose here.

BUG=chrome-os-partner:12579
TEST=Tested by playing audio using aplay command and QCTool.

Change-Id: I0f855ca17206c23625758930d8aa613bc7206af2
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/33297
Reviewed-by: Dylan Reid <dgreid@chromium.org>

arm: exynos: Disable GIC interrupts before suspend

Make sure GIC interrupts are disabled prior to suspend.

BUG=chrome-os-partner:12807
TEST=suspend_stress_test with no cpu_do_idle failures
  All other resume mechanisms still work (rtc0&1, keyboard,
  trackpad, lid, power)
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Change-Id: I0cf464b9c04bbd3ba9fe83d09c0a65a125221bf3
Reviewed-on: https://gerrit.chromium.org/gerrit/34541
Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com>
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>

drm/exynos: hdmi: Add additional PHY configs

Add HDMI PHY configurations to support pixel clock rates of 25.2MHz,
40MHz, 65MHz, 146.25MHz, 108MHz, 106.5MHz, 108MHz, 83MHz, 36MHz.

BUG=chrome-os-partner:12643
TEST=Tested with 640x480, 800x600, 1024x768

Change-Id: I5388856d93f3b133da085cd9ec9f3611ebc43133
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32155

drm/exynos: mixer: Support more than TV resolutions

Extend the mixer configuration to include all resolutions that can be
generated by the mixer. This adds 640x480 and 1680x1050, along with any
other non-standard modes that fit within the permissible ranges.

BUG=chrome-os-partner:12643
TEST=Tested on snow with the above resolutions

Change-Id: Ief7a0892640ef3c5bcf6cb82f58eb472d3c0a2cc
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32245

drm: Set the plane's crtc before calling disable_plane.

Some drivers like exynos need the crtc to be able to disable the plane,
so set it before calling disable_plane.

BUG=chrome-os-partner:13583
TEST=by hand

Change-Id: I163584aede53eda82b4eabc28fa9253fd4551970
Reviewed-on: https://gerrit.chromium.org/gerrit/34597
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Anush Elangovan <anush@google.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>

drm/exynos: add more parallelism to page_flip

We add more parallelism by returning the vblank even early and
relying on kds to prevent the GPU from rendering to a buffer
that is still being scanned out.

BUG=chrome-os-partner:12170
TEST=VT switch. Log in/out. Suspend/resume. Web GL. Youtube. HDMI. UI restart.
TEST=All testing done with slub_debug=FZPUA

Change-Id: Idfb42132186a10975ffbb2be9cb934530f3dacc6
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34560
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

drm/exynos: use kds resource in destory_fb

Use a kds resource to prevent us from unmapping an fb while its
still being scanned out. This is especially important with the
concurrent page flip patches because we are flipping multiple
buffers concurrently.

BUG=chrome-os-partner:12170
TEST=VT switch. Log in/out. Suspend/resume.

Change-Id: I73813706d235456453a10a89e130e04ba9c894b1
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34559
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

drm/exynos: release kds resource from finish_page_flip

finish_page_flip is the correct location to release the kds resource.
This is a refactoring patch for future CLs.

BUG=chrome-os-partner:12170
TEST=VT switch. Log in/out. Suspend/resume.

Change-Id: Ibc13a3ef12bde60821eab09eb4b1eda5279a8e10
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34558
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

drm/exynos: Zero the dma_addr before decreasing the refcount

Otherwise if refcount goes to 0, the buffer is freed, and we do
a use-after-free when setting the dma_addr.

BUG=chrome-os-partner:14832
TEST=compiles

Change-Id: Ie75426b43b6d3519afdab38f19031cf494715ca9
Reviewed-on: https://gerrit.chromium.org/gerrit/34532
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>

Revert "drm/exynos: release kds resource from finish_page_flip"

This reverts commit f4bd46c23bb7a328051b062aeb0ce327df4a948d.

BUG=chrome-os-partner:14832
TEST=With slub debugging and 3 reverts can 'restart ui' with
no slub failures.

Change-Id: I3ffd21d63efe6b2ea826f5b1b3a5f8f0e324031e
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34520
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>

Revert "drm/exynos: use kds resource in destory_fb"

BUG=chrome-os-partner:14832
TEST=With slub debugging and 3 reverts can 'restart ui' with
no slub failures.

This reverts commit 423930311564ed77225e0537624299427ec9d4b5.

Change-Id: I4985c963ae6482c5a20fdf2cf9cd47321c46f99a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34519
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>

Revert "drm/exynos: add more parallelism to page_flip"

BUG=chrome-os-partner:14832
TEST=With slub debugging and 3 reverts can 'restart ui' with
no slub failures.

This reverts commit 4ae1bdaf32162d57f9584873f0be89e7ebf1485e.

Change-Id: I2e6a4e2b8db2df714fad36c7b91ad747ed32ae24
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34518
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>

ARM: SAMSUNG: adc: make waitq part of client structure

Moved local waitq instance from s3c_adc_read function to s3c_adc_client
structure which is global. This makes the ADC operation more robust and
ensure there is no memory corruption.

Occasional cases (during stress test) found src_adc_read function
woke up and exited before completing last action (spinlock restore) in the
__wake_up function which is part of ADC IRQ handler. This caused memory
corruption and found subsequent function crashed due to this.

BUG=chromeos-partner:14648
TEST=Ran ADC stress test for several hours
 cd /sys/devices/platform/ncp15wb473.0/
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&
 while true; do cat temp1_input > /dev/null; done&

Change-Id: I52730669b2537cae32b8f4ef94750d8723c4cd6a
Signed-off-by: Sunil Mazhavanchery <sunilm@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/34504
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

CHROMIUM: exynos: Resume exynos4 timer (FRC) earlier

The kernel sched_clock uses FRC as its time source, so we should
ensure FRC resumes before sched_clock. We can do this by registering
the resume function via syscore_ops.

On Exynos 5250 the FRC starts ticking immediately on resume. We reset
it a second time in exynos4_frc_resume(), which makes sched_clock jump
forward by almost one period.

BUG=chrome-os-partner:14527,chrome-os-partner:13515
TEST=suspend the system, check dmesg for a 100+ second time jump

Change-Id: Ia78353b5841cdd5fb82c918d508021c5684f0d5c
Signed-off-by: Michael Spang <spang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34149
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com>

CHROMIUM: ALSA: hda/ca0132 - latency patch from Creative.

This patch includes three changes:
1. Handle latency in speaker mode.
2. Playback effects to What U Hear recording.
3. Correct VoiceFC control name and Munchkin effect.

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

Change-Id: I32eb5a21e5a585ddac46b8c4270c17cbf9ae6295
Signed-off-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34408
Reviewed-by: Dylan Reid <dgreid@chromium.org>