Bjørn Mork [Wed, 13 Feb 2013 22:41:34 +0000 (23:41 +0100)]
UPSTREAM: USB: option: add Huawei "ACM" devices using protocol = vendor
The USB device descriptor of one identity presented by a few
Huawei morphing devices have serial functions with class codes
02/02/ff, indicating CDC ACM with a vendor specific protocol. This
combination is often used for MSFT RNDIS functions, and the CDC
ACM class driver will therefore ignore such functions.
The CDC ACM class driver cannot support functions with only 2
endpoints. The underlying serial functions of these modems are
also believed to be the same as for alternate device identities
already supported by the option driver. Letting the same driver
handle these functions independently of the current identity
ensures consistent handling and user experience.
There is no need to blacklist these devices in the rndis_host
driver. Huawei serial functions will either have only 2 endpoints
or a CDC ACM functional descriptor with bmCapabilities != 0, making
them correctly ignored as "non RNDIS" by that driver.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
1f3f687722fd9b29a0c2a85b4844e3b2a3585c63)
Signed-off-by: Ben Chan <benchan@chromium.org>
Conflicts:
drivers/usb/serial/option.c
Change-Id: I8a020cb3cfac933200fb6b8b5581a51fe1ef1c09
Reviewed-on: https://gerrit.chromium.org/gerrit/50573
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Bjørn Mork [Wed, 19 Dec 2012 14:15:17 +0000 (15:15 +0100)]
UPSTREAM: USB: option: blacklist network interface on ZTE MF880
The driver description files gives these names to the vendor specific
functions on this modem:
diag: VID_19D2&PID_0284&MI_00
nmea: VID_19D2&PID_0284&MI_01
at: VID_19D2&PID_0284&MI_02
mdm: VID_19D2&PID_0284&MI_03
net: VID_19D2&PID_0284&MI_04
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
fab38246f318edcd0dcb8fd3852a47cf8938878a)
Change-Id: If40a3ca9fffaa28660ea3982fef57ac0a4e4f53d
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50572
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Sun, 25 Nov 2012 16:05:10 +0000 (17:05 +0100)]
UPSTREAM: USB: option: blacklist network interface on Huawei E173
The Huawei E173 will normally appear as 12d1:1436 in Linux. But
the modem has another mode with different device ID and a slightly
different set of descriptors. This is the mode used by Windows like
this:
3Modem: USB\VID_12D1&PID_140C&MI_00\6&
3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&
3A1D2012&0&0001
Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&
3A1D2012&0&0002
PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&
3A1D2012&0&0003
All interfaces have the same ff/ff/ff class codes in this mode.
Blacklisting the network interface to allow it to be picked up by
the network driver.
Cc: stable <stable@vger.kernel.org>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
f36446cf9bbebaa03a80d95cfeeafbaf68218249)
Change-Id: I539d5879c3004f1a22532337c84cce8b2f47a2a7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50571
Reviewed-by: Olof Johansson <olofj@chromium.org>
li.rui27@zte.com.cn [Tue, 20 Nov 2012 06:31:47 +0000 (14:31 +0800)]
UPSTREAM: USB: add new zte 3g-dongle's pid to option.c
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Rui li <li.rui27@zte.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
31b6a1048b7292efff8b5b53ae3d9d29adde385e)
Change-Id: I34dab64e2a7c442a396cb21b554c57f6c48321a6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50570
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Thu, 18 Oct 2012 15:14:17 +0000 (17:14 +0200)]
UPSTREAM: USB: option: add more ZTE devices
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
4b35f1c52943851b310afb09047bfe991ac8f5ae)
Change-Id: Iaba97c0798546fb378d3913eb018a7bc52bd2950
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50569
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Thu, 18 Oct 2012 15:19:53 +0000 (17:19 +0200)]
UPSTREAM: USB: option: blacklist net interface on ZTE devices
Based on information from the ZTE Windows drivers.
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
1452df6f1b7e396d89c2a1fdbdc0e0e839f97671)
Change-Id: Ic34ea8cf65c826766e7ef583411ce36e9182b6b6
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50568
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Wed, 19 Sep 2012 20:02:12 +0000 (22:02 +0200)]
UPSTREAM: USB: option: blacklist QMI interface on ZTE MF683
Interface #5 on ZTE MF683 is a QMI/wwan interface.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Cc: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
160c9425ac52cb30502be2d9c5e848cec91bb115)
Change-Id: I9dad94c5bfab2c752d1b93cd177f70ab47726b3e
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50567
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Tue, 11 Sep 2012 07:40:31 +0000 (09:40 +0200)]
UPSTREAM: USB: option: replace ZTE K5006-Z entry with vendor class rule
Fix the ZTE K5006-Z entry so that it actually matches anything
commit
f1b5c997 USB: option: add ZTE K5006-Z
added a device specific entry assuming that the device would use
class/subclass/proto == ff/ff/ff like other ZTE devices. It
turns out that ZTE has started using vendor specific subclass
and protocol codes:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=19d2 ProdID=1018 Rev= 0.00
S: Manufacturer=ZTE,Incorporated
S: Product=ZTE LTE Technologies MSM
S: SerialNumber=MF821Vxxxxxxx
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 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=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 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#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
We do not have any information on how ZTE intend to use these
codes, but let us assume for now that the 3 sets matching
serial functions in the K5006-Z always will identify a serial
function in a ZTE device.
Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
ba9edaa468869a8cea242a411066b0f490751798)
Change-Id: I684108af3b0ccd94c0909b5e43eaa0c0772d49c4
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50566
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Wed, 15 Aug 2012 13:43:33 +0000 (15:43 +0200)]
UPSTREAM: USB: option: add ZTE K5006-Z
The ZTE (Vodafone) K5006-Z use the following
interface layout:
00 DIAG
01 secondary
02 modem
03 networkcard
04 storage
Ignoring interface #3 which is handled by the qmi_wwan
driver.
Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
f1b5c997e68533df1f96dcd3068a231bca495603)
Change-Id: Iac1d47ba7798ed27a903eb5c7266b98134f5d27b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50565
Reviewed-by: Olof Johansson <olofj@chromium.org>
fangxiaozhi [Wed, 8 Aug 2012 09:24:45 +0000 (09:24 +0000)]
UPSTREAM: USB: support the new interfaces of Huawei Data Card devices in option driver
In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices. And at the same time, remove the
redundant declarations from option.c.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
ee6f827df9107139e8960326e49e1376352ced4d)
Change-Id: I909c57e51b88891616d80df128dcd39e9d11c73b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50564
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Thu, 12 Jul 2012 10:37:32 +0000 (12:37 +0200)]
UPSTREAM: USB: option: 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>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
09110529780890804b22e997ae6b4fe3f0b3b158)
Change-Id: I76097c70b04b835739dd7c49cbb227663aa40b82
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50563
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Mon, 2 Jul 2012 17:53:55 +0000 (19:53 +0200)]
UPSTREAM: USB: option: add ZTE MF60
Switches into a composite device by ejecting the initial
driver CD. The four interfaces are: QCDM, AT, QMI/wwan
and mass storage. Let this driver manage the two serial
interfaces:
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=19d2 ProdID=1402 Rev= 0.00
S: Manufacturer=ZTE,Incorporated
S: Product=ZTE WCDMA Technologies MSM
S: SerialNumber=xxxxx
C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
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#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
8e16e33c168a6efd0c9f7fa9dd4c1e1db9a74553)
Change-Id: I82d92464ece3b9e5dbadf9b5637dd7ceae2cf81b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50562
Reviewed-by: Olof Johansson <olofj@chromium.org>
Johan Hovold [Wed, 30 May 2012 10:25:00 +0000 (12:25 +0200)]
UPSTREAM: USB: option: clean up probe coding style
Clean up option probe by introducing intermediate variables and fixing
up comments.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
378fac2a46decbcd16b42044303ba8a1a3f8001e)
Change-Id: I0ba9fbbabc05f314742cbdb58d231f5e12dc45c7
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50561
Reviewed-by: Olof Johansson <olofj@chromium.org>
Andrew Bird [Mon, 28 May 2012 11:43:06 +0000 (12:43 +0100)]
UPSTREAM: USB: option: Updated Huawei K4605 has better id
Later firmwares for this device now have proper subclass and
protocol info so we can identify it nicely without needing to use
the blacklist. I'm not removing the old 0xff matching as there
may be devices in the field that still need that.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
42ca7da1c2363dbef4ba1b6917c4c02274b6a5e2)
Change-Id: I9baea88b9f9d3fb1de84a296f3fe1765b5f2f110
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50560
Reviewed-by: Olof Johansson <olofj@chromium.org>
Bjørn Mork [Sat, 19 May 2012 17:20:50 +0000 (19:20 +0200)]
UPSTREAM: USB: option: Add Vodafone/Huawei K5005 support
Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
4cbbb039a9719fb3bba73d255c6a95bc6dc6428b)
Change-Id: Ibb164ad28a58da63eafb5d7b0ca3a1e46fe0a2dc
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50559
Reviewed-by: Olof Johansson <olofj@chromium.org>
Mike Frysinger [Wed, 8 May 2013 21:51:11 +0000 (17:51 -0400)]
CHROMIUM: perf tools: fix -ldw/-lelf link test when static linking
Since libelf sometimes uses libpthread, we have to list that after -lelf
when someone tries to build statically. Else things go boom:
Makefile:479: *** No libelf.h/libelf found, please install \
libelf-dev/elfutils-libelf-devel. Stop.
Similarly, the -ldw test fails as it often uses -lz:
Makefile:462: No libdw.h found or old libdw.h found or elfutils is older \
than 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev
And if we add debugging to try-cc, we see:
+ echo '#include <dwarf.h>
int main(void)
{
Dwarf *dbg = dwarf_begin(0, DWARF_C_READ);
return (long)dbg;
}'
+ i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
-ldw -lelf -static -lpthread -lrt -lelf -lm -o .24368
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateInit_'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflate'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateReset'
/usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateEnd'
+ echo '#include <libelf.h>
int main(void)
{
Elf *elf = elf_begin(0, ELF_C_READ, 0);
return (long)elf;
}'
+ i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
-static -lpthread -lrt -lelf -lm -o .19216
/usr/lib/libelf.a(elf_begin.o):function file_read_elf: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function read_file: error: undefined reference to 'pthread_rwlock_init'
/usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_unlock'
/usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_wrlock'
/usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_rdlock'
/usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_unlock'
BUG=None
TEST=`LDFLAGS=-static emerge-x86-alex perf` works
Change-Id: Idfa38ae36d22bcc669199bbd8e74f83eb97ddda9
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50498
Reviewed-by: Olof Johansson <olofj@chromium.org>
Daniel Kurtz [Mon, 6 May 2013 17:36:42 +0000 (10:36 -0700)]
CHROMIUM: drm/exynos: Fixup init failure cleanup path
Backport from 3.8-rebase version of this patch.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
TEST=by hand
BUG=none
Original-Change-Id: Ia0c0de4f49efe0d6dca09507372add5d0d533028
Reviewed-on: https://gerrit.chromium.org/gerrit/49146
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit
fa2b424b2108697ee5a971bc00b9a8bb75f66b41)
Change-Id: I09d0d33a9499945e67fb8416c0074a440fd5b5a2
Reviewed-on: https://gerrit.chromium.org/gerrit/50188
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Sat, 4 May 2013 04:11:11 +0000 (21:11 -0700)]
Revert "Add implementation of poll() to dma_buf using KDS"
This reverts commit
5d1bb28fa72400006b3956ab7d869dffd091af23.
There are no users of dma-buf poll(), this isn't upstream, and we aren't
carrying it forward to 3.8.
Revert from 3.4 to keep 3.8 & 3.4 more consistent.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=none
Change-Id: Ia6628aef06f5ee228f3ac479bfa0e75b45573f04
Reviewed-on: https://gerrit.chromium.org/gerrit/50187
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Shirish S [Fri, 5 Apr 2013 11:52:00 +0000 (07:52 -0400)]
CHROMIUM: fix 800x600 resolution for exynos5 hdmi
800x600 resolution is not cleanly supported by the exynos5 mixer block.
Hw team suggested following workaround to enable the above resolution.
1) In MIXER_CFG register, set HD_SD and HD_MODE bits to 1.
2) In MIXER0_GRAPHIC0_DXY, set MIXER0_GRP0_DX to 32.
3) In MIXER_TVOUT_CFG, Change 3D one path mode to 3D two path AFTER 1 FRAME.
BUG=chrome-os-partner:12643 & chromium:225983
TEST:
1) Booted with HDMI Connectd to Sink that supports only 800x600
2) HDMI Unplug-plug scenarios
3) S2R by running powerd_dbus_suspend
Change-Id: Ic5952ff3982c4923eabb69febeabfeb445e7a79c
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Shirish S <s.shirish@samsung.com>
Signed-off-by: Akshay Saraswat <Akshay.s@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47650
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Shirish S <shirish@chromium.org>
Han Shen [Fri, 26 Apr 2013 00:06:14 +0000 (17:06 -0700)]
CHROMIUM: ARM: exynos: busfreq: Fix array-out-of-bound access.
In the 1st loop of
arch/arm/mach-exynos/busfreq_opp_exynos5.c:show_time_in_state, sprintf
accesses data->time_in_state[PPMU_MIF][i], where i ranges [0..6], but
time_in_state is defined as array[2][4]. Fixed by change time_in_state
definition.
BUG=None
TEST=Build successfully
Change-Id: I2d4cab59281509e33d34b55892f18635e8b7fa09
Signed-off-by: Han Shen <shenhan@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49266
Reviewed-by: Olof Johansson <olofj@chromium.org>
Han Shen [Wed, 3 Apr 2013 21:36:38 +0000 (14:36 -0700)]
wireless-next: rtl8192c:dm: Properly initialize local array and set value.
GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c". This patch adds
initialization to the variable and properly sets its value.
Signed-off-by: Han Shen (shenhan@google.com)
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit
7c8f0db0d024efda38976fc2acf7743f458e1d96)
Conflicts:
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
TEST=Built using newest compiler.
BUG=None
Signed-off-by: Han Shen (shenhan@google.com)
Change-Id: Id7f48f33df1d5629ade21c67ede6960e73040e82
Reviewed-on: https://gerrit.chromium.org/gerrit/47279
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Han Shen <shenhan@google.com>
Commit-Queue: Han Shen <shenhan@google.com>
Julius Werner [Sat, 20 Apr 2013 01:16:34 +0000 (18:16 -0700)]
CHROMIUM: usb: ehci: Only sleep for post-resume handover if devices use persist
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the companion controller can actually see it during its
own resume path.
However, if the device doesn't use persist, this is entirely
unnecessary. We might just as well ignore it and have the normal device
detection/reset/handoff code handle it asynchronously when it eventually
shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
BUG=chromium:222484
TEST=Suspend/resume Snow with a USB keyboard plugged in, make sure
keyboard still works afterwards.
Has been sent upstream, chances for merge were looking good...
Change-Id: I3bc9a86e464a70231cfdd1b013ef0a0cb98eff09
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48945
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Sean Paul [Fri, 26 Apr 2013 20:06:43 +0000 (16:06 -0400)]
drm/exynos: Debounce gpio hotplug interrupts
Debounce the gpio (external) hotplug interrupts. This patch debounces
hotplug interrupts generated while the HDMI block is off. The reason
this is needed is that we get multiple (5) interrupts every time a
monitor is inserted which causes us to needlessly enable and disable the
IP block.
BUG=chromium:220033
TEST=Tested using an HDMI analyzer. Many hotplugs without any 20s freeze
Change-Id: I9c5d61364790f4110fc758a93fabac48b646b3fa
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49349
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Stuart Abercrombie [Mon, 29 Apr 2013 22:07:29 +0000 (15:07 -0700)]
Fix display underruns on Pineview with 2048x1280 VGA display.
Higher dot clocks were working because pixel doubling was enabled.
Lower the apparently arbitrary threshold so it's enabled for 2048x1280.
Intel hasn't felt moved to document any of this, so this is purely empirical.
The original threshold was introduced here:
http://cgit.freedesktop.org/~anholt/xf86-video-intel/commit/?id=
8fcf9a81179ee8577ddab5e904c58fbfd14cf59c
BUG=chromium:219562
TEST=All previously working U3011 modes + 2048x1280 work
Change-Id: I69f47b6ef292d65dc1a3ff6288c33eaa4c1cd894
Reviewed-on: https://gerrit.chromium.org/gerrit/49434
Reviewed-by: Stuart Abercrombie <sabercrombie@chromium.org>
Tested-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stuart Abercrombie <sabercrombie@chromium.org>
Daniel Kurtz [Fri, 19 Apr 2013 09:23:38 +0000 (17:23 +0800)]
CHROMIUM: config: re-sync kernel config after dma-buf kds separation
Now, this is only set for exynos:
CONFIG_DMA_SHARED_BUFFER_USES_KDS=y
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:232913
TEST=compile kernel for x86 and arm and verify it still boots
Change-Id: I7f5d9471a7fde4dd01a02ce5f383ab931c47353f
Reviewed-on: https://gerrit.chromium.org/gerrit/48630
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Wed, 24 Apr 2013 04:27:38 +0000 (12:27 +0800)]
CHROMIUM: dma-buf/kds: allow KDS to be compiled out if dma-buf is enabled
The original KDS patches added CONFIG_DMA_SHARED_BUFFER_USES_KDS but
didn't use it to guard the kds integration into dma-bufs in a way
that would allow dma-buf to be built with KDS compiled without
requiring KDS.
Fix this by more carefully guarding the integration points, and not
unconditionally selecting KDS when dma-buf is enabled.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:232913
TEST=compile kernel for x86 and arm and verify it still boots
Change-Id: I878d1313ce6b43477fd6c87d394728283ad4f9e6
Reviewed-on: https://gerrit.chromium.org/gerrit/48608
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Devendra Naga [Sat, 13 Apr 2013 14:46:51 +0000 (20:16 +0530)]
UPSTREAM: staging: gdm72xx: cancel work when driver unloads
cancel the work function at driver unload stage and remove
the function from the queue
Cc: Ben Chan <benchan@chromium.org>
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
c0352cb71d3d573a33af92d320f29f1c79d71b8b)
Change-Id: I8c4e522270b4acad07d125398b1afe4a14810f16
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49427
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Peter Huewe [Tue, 19 Feb 2013 17:50:20 +0000 (18:50 +0100)]
UPSTREAM: staging/gdm72xx: Remove duplicated code in gdm_qos.c
The first branch of the if statement is ended with a return thus there
is no need for an else if, and thus we can move the duplicated code to
the top and use it for the other two branches.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
d38529100d0f2e844df5f06d67dae8dd32086ec1)
Change-Id: I9ad27e507f0f66a821dd9c2327dc67cc69bc8a10
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49426
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Peter Huewe [Tue, 19 Feb 2013 17:50:19 +0000 (18:50 +0100)]
UPSTREAM: staging/gdm72xx: Remove unused variable in gdm_qos.c
len is never read after assignment, thus can be removed.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
eb986df15c86b66a51f6e82f4706bc825444670b)
Change-Id: I23e845226e446fb1cbc8568949be0d956baf350b
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49425
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Peter Huewe [Tue, 19 Feb 2013 17:50:18 +0000 (18:50 +0100)]
UPSTREAM: staging/gdm72xx: Include corresponding header file (fix sparse warning)
sdio_boot.c and netlink_k.c both have a corresponding header file with
their function prototypes but fail to include them, which leads to the
following sparse warnings:
sdio_boot.c:135:5: warning: symbol 'sdio_boot' was not declared. Should it be static?
netlink_k.c:89:13: warning: symbol 'netlink_init' was not declared. Should it be static?
netlink_k.c:109:6: warning: symbol 'netlink_exit' was not declared. Should it be static?
netlink_k.c:114:5: warning: symbol 'netlink_send' was not declared. Should it be static?
-> Add the include files and silence the warning
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
a6000538e402ef2479a16ff789059c78a152be9d)
Change-Id: Id26144d3d78f9a0de1be70e5f3a2bed1fccae25f
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49424
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Todd Broch [Wed, 1 May 2013 02:01:12 +0000 (19:01 -0700)]
CHROMIUM: dts: spring: Explicitly disable unused LDOs
Some LDO's are enabled by default at poweron but unused in Spring.
This CL disables them explicitly.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:19067
TEST=manual
ldo_base=0x5e
for ldo in 4 5 11 13 17 ; do
echo -n "LDO${ldo}: "
i2cget -y -f 0 0x66 $(($ldo_base + $ldo))
done
LDO4: 0x04
LDO5: 0x04
LDO11: 0x14
LDO13: 0x14
LDO17: 0x28
Note all bits <7:6> are zero'd
Change-Id: I9e8f6966a0a573f622f86cd07aeb7d61e495db1b
Reviewed-on: https://gerrit.chromium.org/gerrit/49718
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Paul Taysom [Thu, 25 Apr 2013 00:19:58 +0000 (17:19 -0700)]
CHROMIUM: md: dm-bootcache: reinitialize bio structure
The bootcache code does multiple large reads and was reusing the bio structure.
Some device drivers appear to leave some clutter in the bio structure.
Between large reads, the bootcache now frees and reallocates the bio structure.
BUG=chrome-os-partner:18830
TEST=POWER-ESC-F3 with USB stick, several times.
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I5b835b5f0606f6eb4116fc9719d96a48d0155f57
Reviewed-on: https://gerrit.chromium.org/gerrit/49121
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Paul Taysom <taysom@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
Luigi Semenzato [Mon, 29 Apr 2013 17:10:25 +0000 (10:10 -0700)]
CHROMIUM: add warning test to /proc/breakme
This is mainly for testing the Chrome OS warning collection
and analysis tools.
BUG=chromium:227080
TEST=manually tested
Change-Id: I0a99d2f87cf1e1354a0feaf3cd5386396d7da381
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49488
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Shawn Nematbakhsh [Thu, 25 Apr 2013 21:30:04 +0000 (14:30 -0700)]
CHROMIUM: input: mouse - Fix trackpoint re-probe on resume.
During suspend, power may be cut to the trackpoint. If so, the
trackpoint will automatically begin its power-on diagnostics upon being
re-powered. If trackpoint_reconnect is called before the diagnostics
complete, the probe ID command will be lost, and reconnect will fail.
This will lead to re-probe, which takes several seconds on Stout due to
the trackpoint / trackpad pass-through design.
The fix here is to make a second attempt if the initial commands on
reconnect fail, which should give the trackpoint enough time to come out
of power-on diagnostics.
TEST=suspend/resume test for 3000 iterations without re-enumeration.
BUG=chromium:220389
Change-Id: I1ff8d3accdde86184864915d540b870ed33feee4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49228
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Paul Stewart [Thu, 25 Apr 2013 14:39:54 +0000 (07:39 -0700)]
CHROMIUM: ath: Add ATH_DEFER_EEPROM_REGULATORY option
Add option to disable the internal regulatory mask
sourced from EEPROM data. This does not affect CRDA
regulatory operation, but nevertheless this option
should not be used by default.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium:218911
TEST=Recompile with and without flag, ensure EEPROM
regulatory still works with this change disabled using
world regulatory EEPROM card an "iw reg set" command.
Change-Id: I20de00c7c6ea57124df1da8b052e573920579614
Reviewed-on: https://gerrit.chromium.org/gerrit/49176
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Sean Paul [Mon, 22 Apr 2013 17:00:11 +0000 (13:00 -0400)]
drm/exynos: Add 1024x768/1280x800 HDMI resolutions
This patch adds 1024x768 and 1280x800 HDMI resolutions by redistributing
vertical lines to the blanking period from the active area. The result
is that userspace is exposed resolutions which fit into the mixer's
scanning guidelines (720 lines), and the monitor thinks it's getting the
full monty. For example, 1024x768 looks like 1024x720 from userspace's
perspective, but 1024x768 from the monitor's perspective.
BUG=chromium:221411, chrome-os-partner:14238
TEST=Tested by hand with 1024x768
Change-Id: I6dcfe6260504e38aa604c5b19abc2bd716bbf729
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48830
Reviewed-by: Mark Hayter <mdhayter@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Aaron Durbin [Fri, 19 Apr 2013 15:35:04 +0000 (10:35 -0500)]
google memconsole: use ioremap_cache()
The memconsole code was using ioremap() which defaults to using
an uncacheable mapping. When using PAT this creates a PAT entry
as uncached-minus. When a userspace program, such as cbmem,
wants to mmap() the memory area not using O_SYNC by way of /dev/mem
it creates a conflicting entry and fails. Correct this situation
by using ioreamp_cache() becaus the cbmem memconsole lives in memory
that is just reserved from the OS -- not in mmio space.
BUG=None
BRANCH=None
TEST=Tested on Pixel with new cbmem utlity. No errors.
Change-Id: Iff8a160205bf59e4c4d0e9508832901f8dbd1cde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48654
Julius Werner [Wed, 24 Apr 2013 00:54:20 +0000 (17:54 -0700)]
CHROMIUM: config: Disable USB persist by default
We had it this way before, this is just part of a patch series to move
from our hardcoded hack to the new upstream Kconfig method.
BUG=None
TEST=None
Change-Id: Id67bc7b618547f16a209dbf12c4e1f9ce7bde279
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49016
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Julius Werner [Wed, 13 Mar 2013 22:57:31 +0000 (15:57 -0700)]
UPSTREAM: usb: Make USB persist default configurable
Commit
9214d1d8 set the USB persist flag as a default for all devices.
This might be desirable for some distributions, but it certainly has its
trade-offs... most importantly, it can significantly increase system
resume time, because the kernel blocks on resuming (and sometimes
resetting) USB devices before it unfreezes userspace.
This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.
[edited the Kconfig help text a bit - gregkh]
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit
4f48203881ce947a0cbd8ae7b1a1a1b04aaa3766)
Cherry picked from upstream's gregkh/usb.git/usb-next
Conflicts:
drivers/usb/core/Kconfig (trivial merge with old deprecated configs)
drivers/usb/core/quirks.c (renamed USB_QUIRK_RESET to the older
USB_QUIRK_RESET_MORPHS)
BUG=None
TEST=None
Change-Id: Ib63d2ed955e2916598d5ecd2d75aab9260594368
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49015
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Julius Werner [Tue, 23 Apr 2013 23:46:30 +0000 (16:46 -0700)]
Revert "CHROMIUM: Disable USB persist system-wide by default."
This reverts commit
c3d39c8b090f77d253ef70a6bc747e3bd095347c.
Turns out the Kconfig version of this change did get picked up by gregkh
upstream after all. So we can revert this and roll with the upstream
version instead.
BUG=None
TEST=None
Change-Id: I96f74c914c75bd3c9b8a7cde0d682de157ee3e10
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49014
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Shawn Nematbakhsh [Tue, 23 Apr 2013 22:50:23 +0000 (15:50 -0700)]
CHROMIUM: uvcvideo: Handle status_start while status_stop is in progress.
While usb_kill_urb is in progress, calls to usb_submit_urb will fail
with -EPERM (documented in Documentation/usb/URB.txt). The UVC driver
does not correctly handle this case -- there is no synchronization
between uvc_v4l2_open / uvc_status_start and uvc_v4l2_release /
uvc_status_stop.
This patch adds a retry / timeout when uvc_status_open / usb_submit_urb
returns -EPERM. This usually means that usb_kill_urb is in progress, and
we just need to wait a while.
BUG=chromium:226216
TEST=Manual. Repeat suspend / resume on Stout many times, verify that
open() on /dev/video0 never fails.
Change-Id: I8a69dab345a18c89e175bd916aa943edd080b6cc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48982
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
John Sheu [Wed, 17 Apr 2013 05:24:39 +0000 (22:24 -0700)]
[media] v4l2: mem2mem: save irq flags correctly
<NO UPSTREAM MERGE REQUIRED>
Save flags correctly when taking spinlocks in v4l2_m2m_try_schedule.
BUG=None
TEST=local build, run on CrOS snow
Change-Id: I1705c3466dde52db7021fe1e79aef0bba2d68367
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48347
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Jack Pham [Mon, 10 Dec 2012 22:28:13 +0000 (14:28 -0800)]
UPSTREAM: usb: dwc3: debugfs: fix regdump offset
As with dwc_readl/writel, the global registers are specified as
offsets starting from the beginning of the xHCI address space,
but the memory region pointed to by dwc->regs already maps to
the start of the global addresses. Fix by offsetting each of the
regs relative to DWC3_GLOBALS_REGS_START.
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
(cherry picked from commit
1604c1e760119ab3fe9f71679ebaeb058d3d8ae1)
Cherry pick from Linus' tree, applied cleanly
BUG=chromium:229725
TEST='cat /sys/kernel/debug/dwc3.0/regdump' should not crash on Snow.
Change-Id: Ic58153b9c3f4135355094a5dc49ad0fabb2fcd25
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48554
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Duncan Laurie [Mon, 22 Apr 2013 21:01:49 +0000 (14:01 -0700)]
BACKPORT: TPM: Retry SaveState command in suspend path
If the TPM has already been sent a SaveState command before the driver
is loaded it may have problems sending that same command again later.
This issue is seen with the Chromebook Pixel due to a firmware bug in
the legacy mode boot path which is sending the SaveState command
before booting the kernel. More information is available at
http://crbug.com/203524
This change introduces a retry of the SaveState command in the suspend
path in order to work around this issue. A future firmware update
should fix this but this is also a trivial workaround in the driver
that has no effect on systems that do not show this problem.
When this does happen the TPM responds with a non-fatal TPM_RETRY code
that is defined in the specification:
The TPM is too busy to respond to the command immediately, but the
command could be resubmitted at a later time. The TPM MAY return
TPM_RETRY for any command at any time.
It can take several seconds before the TPM will respond again. I
measured a typical time between 3 and 4 seconds and the timeout is set
at a safe 7 seconds. (note: upstream is 5 seconds right now)
It is also possible to reproduce this with commands via /dev/tpm0.
The bug linked above has a python script attached which can be used to
test for this problem. I tested a variety of TPMs from Infineon,
Nuvoton, Atmel, and STMicro but was only able to reproduce this with
LPC and I2C TPMs from Infineon.
The TPM specification only loosely defines this behavior:
TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
The TPM MAY declare all preserved values invalid in response to any
command other than TPM_Init.
TCG PC Client BIOS Spec 1.21 section 8.3.1.
After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
commands before transitioning to S3 without issuing another
TPM_SaveState command.
TCG PC Client TIS 1.21, section 4. Power Management:
The TPM_SaveState command allows a Static OS to indicate to the TPM
that the platform may enter a low power state where the TPM will be
required to enter into the D3 power state. The use of the term "may"
is significant in that there is no requirement for the platform to
actually enter the low power state after sending the TPM_SaveState
command. The software may, in fact, send subsequent commands after
sending the TPM_SaveState command.
BUG=chrome-os-partner:18686
TEST=originally tested on pixel for crbug.com/203524
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
(backported from commit
32d33b29ba077d6b45de35f2181e0a7411b162f4)
Change-Id: I023103b69e5253dc98b289c25853104a08f4787f
Reviewed-on: https://gerrit.chromium.org/gerrit/48812
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
John Sheu [Wed, 17 Apr 2013 05:04:18 +0000 (22:04 -0700)]
v4l2: dequeue buffers properly on VIDIOC_STREAMOFF
<UPSTREAM MERGE NOT REQUIRED>
Instead of just marking all buffers as dequeued on STREAMOFF, properly
dequeue them -- this will, most notably, make sure that any mapped
DMABUF buffers will be properly unmapped.
BUG=chromium:232121
TEST=local build, run on CrOS snow
Change-Id: Ide111378caa70cf603b3edec65b4dedd0f1e1ea0
Signed-off-by: John Sheu <sheu@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48346
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Todd Broch [Fri, 19 Apr 2013 23:48:03 +0000 (16:48 -0700)]
CHROMIUM: mkbp: Optimize ghosting algorithm.
Previous algorithm was a bit conservative and complicating with
respect to identifying key ghosting. This CL uses the bitops hamming
weight function (hweight8) to count the number of matching rows for
colM & colN. If that number is > 1 ghosting is present.
Additionally it removes NULL keys and our one virtual keypress
KEY_BATTERY from consideration as these inputs are never physical
keypresses.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:18354
TEST=manual
1. using evtest I now see ctrl-U
2. escape sequence ctrl-U correctly display 'webpage source'
3. w/ #define DEBUG in mkbp.c no longer see below when ctrl-U pressed
chromeos-ec-i2c 4-001e: ghost found ...
Change-Id: Ifc98b527c3ee4daffa9d8c726429fdd1b35970fa
Reviewed-on: https://gerrit.chromium.org/gerrit/48789
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Todd Broch [Fri, 19 Apr 2013 23:44:22 +0000 (16:44 -0700)]
Revert "CHROMIUM: Strengthen ghosting algorithm."
This reverts commit
688c20f457b6111755cf1f9f1b1472693a4a4ed9.
Change-Id: Ifd0e81a8ffe58bc6c9ebe2eb01345f7f65e360a1
Reviewed-on: https://gerrit.chromium.org/gerrit/48788
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Todd Broch [Fri, 19 Apr 2013 23:43:45 +0000 (16:43 -0700)]
Revert "WORKAROUND: mkbp: Remove KEY_BATTERY from valid keys."
This reverts commit
20dd2301234bc0f57018e4b51380e53f652ac30c.
This temporary workaround eliminated bug introduced by commit:
688c20f CHROMIUM: Strengthen ghosting algorithm.
That CL introduced a bug where the virtual key, KEY_BATTERY, falsely
ghosted to a bunch of other key sequences. That change is also being
reverted.
Change-Id: I6e8959595cba088e6a55d45311fbe9534f3c75f5
Reviewed-on: https://gerrit.chromium.org/gerrit/48787
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Todd Broch [Fri, 19 Apr 2013 17:49:02 +0000 (10:49 -0700)]
WORKAROUND: mkbp: Remove KEY_BATTERY from valid keys.
While previous ghosting fix:
688c20f CHROMIUM: Strengthen ghosting algorithm.
Did help rule out null keys it was thought it would also correctly
identify 3 vs. 4 keypresses (sharing row/col) regardless of whether
key was virtual (KEY_BATTERY) or real. It does not however.
This change migrates KEY_BATTERY to invalid key while algorithm is
further refined.
BUG=chrome-os-partner:18814
TEST=manual
boot Spring plugged after an EC reset and see no ghosting issues for
sequences ctrl + u|w|n|t
Change-Id: I1038a18c353e84a52ad77e44e497c747d310addf
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48674
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Chih-Chung Chang [Fri, 19 Apr 2013 03:56:24 +0000 (11:56 +0800)]
CHROMIUM: ALSA: hda: cirrus: Add pin configs for lumpy.
The SPDIF output pin on lumpy is not connected, but the lumpy BIOS
doesn't set the config for it correctly.
The only difference between the new verbs here and the verbs in BIOS is
to specify the SPDIF output is not connected.
BUG=chromium:233458
TEST=install new kernel on lumpy, and use "aplay -l" to verify the
"Cirrus Digital" device is gone.
Change-Id: Iab087a33f4fde84c16d73b7054663d051fba7391
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48610
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Daniel Kurtz [Fri, 12 Apr 2013 06:47:37 +0000 (14:47 +0800)]
CHROMIUM: drm/exynos: Remove panel_ops->commit
The explicit panel_ops->commit() functions are really just doing what
DPMS(On) should be doing. In fact, hdmi_commit literally gets called
twice in the mode_set path: once in DPMS(On) and again in the explicitly
by exynos_drm_encoder_commit().
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=Sanity check LCD display
TEST=Sanity check HDMI attached monitor at Boot
TEST=Sanity check HDMI attached monitor hotplug 2 times
TEST=run_remote_tests.sh --board=daisy --remote=${IP} power_Resume/control$
Change-Id: I07ce63255d5d209b127babd24213f70e42131185
Reviewed-on: https://gerrit.chromium.org/gerrit/47755
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Emese Revfy [Wed, 17 Apr 2013 19:03:26 +0000 (12:03 -0700)]
CHROMIUM: signal: stop info leak via the tkill and the tgkill syscalls
This fixes a kernel memory contents leak via the tkill and tgkill syscalls
for compat processes.
This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field
when handling signals delivered from tkill.
The place of the infoleak:
int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
{
...
put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
...
}
Signed-off-by: Emese Revfy <re.emese@gmail.com>
Reviewed-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
BUG=chromium:223444
TEST=link build, PoC fails to show leaks
[ sent to lkml: http://marc.info/?l=linux-kernel&m=
136622640810847&w=2 ]
Change-Id: If7603776a2f5dc28dceef4034f80b6979d18ca80
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48390
Reviewed-by: Will Drewry <wad@chromium.org>
Olof Johansson [Tue, 16 Apr 2013 22:16:17 +0000 (15:16 -0700)]
CHROMIUM: config: enable errata 798181
BUG=chromium:226280
TEST=none
Change-Id: Ifdfd073d93b02c3007233bdc91f11a2f7e861ceb
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48273
Reviewed-by: Doug Anderson <dianders@chromium.org>
hayeswang [Sun, 31 Mar 2013 17:02:04 +0000 (17:02 +0000)]
BACKPORT: r8169: fix auto speed down issue
It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.
Check the link partner ability to determine which speed to set.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit
e2409d83434d77874b461b78af6a19cd6e6a1280)
BUG=chrome-os-partner:18211.
TEST=manual. Test ethernet plug/unplug, verify link status detection.
Change-Id: I3166710a102ab9c2aef6590717d500c02fca3cac
Reviewed-on: https://gerrit.chromium.org/gerrit/48361
Tested-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Bowgo Tsai <bowgotsai@chromium.org>
Olof Johansson [Tue, 16 Apr 2013 22:15:27 +0000 (15:15 -0700)]
CHROMIUM: config: re-sync kernel config
TBR=sonnyrao,dianders
BUG=none
Change-Id: I60be015dc64c639ef5715b256a3d55298cdafdd7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48272
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Dylan Reid [Wed, 17 Apr 2013 03:02:34 +0000 (20:02 -0700)]
BACKPORT: ASoC: max98088: Fix logging of hardware revision.
The hardware revision of the codec is based at 0x40. Subtract that
before convering to ASCII. The same as it is done for 98095.
BUG=chrome-os-partner:18551
TEST=check dmesg and see revision = 'A'
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
(cherry picked from commit
98682063549bedd6e2d2b6b7222f150c6fbce68c)
Change-Id: I942d832bceb9c42370a0dd8364040b157d7ffd77
Reviewed-on: https://gerrit.chromium.org/gerrit/48462
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Owen Lin [Wed, 3 Apr 2013 07:26:48 +0000 (15:26 +0800)]
Raises the limit of number of decodes in mfc_dec.
BUG=chromium:221501
TEST=Run a modified video_decode_accelerator_unittest on daisy and link
Signed-off-by: Owen Lin <owenlin@chromium.org>
Change-Id: If047c5aee937c51cbe57bda4a1b5feca975e9b12
Reviewed-on: https://gerrit.chromium.org/gerrit/48215
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: Owen Lin <owenlin@chromium.org>
Commit-Queue: Owen Lin <owenlin@chromium.org>
Chee Kin Cheong [Mon, 15 Apr 2013 22:25:49 +0000 (15:25 -0700)]
CHROMIIM: ALSA: hda/ca0132 - Add AEC level control.
When tuning controls are enabled, export a control to tune the level
of the echo canceller running on the ca0132 DSP.
Change-Id: Ie7717e88c8f5f10dc159f978f8fa5bff77e2a709
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48166
Reviewed-by: Hsinyu Chao <hychao@chromium.org>
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
John Sheu [Wed, 27 Feb 2013 23:18:15 +0000 (15:18 -0800)]
[media] s5p-mfc: Fix frame skip bug
The issue was seen in VP8 decoding where the last frame was
skipped by the driver. This patch gets the correct frame_type value
to fix the bug.
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
BUG=220645
Change-Id: I1784803e3b692afa22d4aa8c966c9f325a20aafd
Reviewed-on: https://gerrit.chromium.org/gerrit/44437
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Todd Broch [Tue, 26 Mar 2013 22:53:49 +0000 (15:53 -0700)]
CHROMIUM: Strengthen ghosting algorithm.
Previous commit added the interpretation of the virtual keystroke from
EC's MKBP, KEY_BATTERY, to allow EC to signal change in USB power for
Spring.
While the edit did address suppressing the input event the virtual
keystroke still plays into the ghosting calculation. This exposed
that the ghosting algorithm was too conservative as ctrl + u +
KEY_BATTERY triggered ghosting logic.
New algorithm correctly identifies all ghosting (3 or more) keystrokes
by factoring in whether the ghost key is valid.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:18354
TEST=manual
1. using evtest I now see ctrl-U
2. escape sequence ctrl-U correctly display 'webpage source'
3. w/ #define DEBUG in mkbp.c no longer see below when ctrl-U pressed
chromeos-ec-i2c 4-001e: ghost found at: r7 c6, pressed 2, teeth 0x4
Change-Id: I693bee2d0e54081c267f449f4b2c7f20a20749ff
Reviewed-on: https://gerrit.chromium.org/gerrit/46585
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Benson Leung [Wed, 30 Jan 2013 00:23:05 +0000 (16:23 -0800)]
CHROMIUM: chromeos_laptop: Add MODULE_DEVICE_TABLE
If chromeos_laptop is built as a module, this will register
this driver as handling the various systems by dmi match,
so input devices, light sensors, and keyboard backlight are
still autoloaded on boot.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:38363
TEST=Modify chromeos/config/x86_64/common.config to set
CONFIG_CHROMEOS_LAPTOP=m
build, load this kernel and modules onto Lumpy.
Check that on boot, trackpad works without modprobing
for chromeos_laptop.
Change-Id: Ib0a8f2b1228fc208e17c716d545818ab8b823952
Reviewed-on: https://gerrit.chromium.org/gerrit/42269
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Chung-yih Wang <cywang@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Daniel Kurtz [Wed, 10 Apr 2013 17:43:28 +0000 (01:43 +0800)]
CHROMIUM: drm/exynos: hdmi: remove unused enabled variable
It is set but never checked.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=builds clean
Change-Id: I60c98a41138d5ae5c7d2876abd02b0cb8b3f57b8
Reviewed-on: https://gerrit.chromium.org/gerrit/47754
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Wed, 10 Apr 2013 17:42:06 +0000 (01:42 +0800)]
CHROMIUM: drm/exynos: Always DPMS Off in encoder prepare and train dp link in DPMS On
In drm_crtc_helper_set_mode(), the basic sequence for encoders and crtcs
is:
->prepare()
->mode_set()
->commit()
For other drm drivers, .prepare does dpms(Off), and .commit does dpms(On).
Thus, the intention is for the .mode_set() callback is supposed to operate properly
in the dpms(Off) state.
For some reason, exynos was not doing dpms(Off) in .prepare, but it was
doing the dpms(On) in .commit, before calling an explicit
panel_ops->commit().
However, the dpms(On) in encoder .commit() never actually does anything,
since the .dpms routines call power on/off routines that are smart and
silently ignore requests that don't change the power state.
In particular, this dpms(On) wasn't able to actually commit changes,
such as enabling video and training the DP link. Instead, we were
essentially relying on a explicit call to panel_ops->commit() in
encoder->commit() to do the commit.
Also, this means that when exynos_drm_encoder_mode_set calls
panel_ops->set_mode(), the current dpms/power state is whatever it was
before the call to drm_crtc_helper_set_mode(). This is almost always
DPMS(On).
DP link training uses the AUX channel which is only available when
DPMS(On). A recent change to the dp driver to move link training to the
dp panel_ops->mode_set() seemed to work because, as noted above, we are
almost always in DPMS(On) for DP when we do mode_sets.
There is, however, one exception. It is possible for userspace to explicit
turn DPMS(Off) the DP pipe. To save power, for instance. If this is
followed by a suspend/resume cycle, the resume path, will end up
calling DP mode_set() with dpms(Off). This causes a soft lockup since the
AUX channel is not enabled when we try to do link training.
Instead, we just always do DPMS(Off) in .prepare(), get rid of the
explicit DP mode_set(), and let the encoder .commit call our DPMS(On)
which will train the link.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:189108
TEST=(1) On daisy:
set_short_powerd_timeouts ; echo 1 > /var/lib/power_manager/disable_idle_suspend
wait ~20 seconds for powerd to turn off the LCD
./run_remote_tests.sh --board=daisy --remote=$IP power_Resume/control$
TEST=(2) Same as (1) but with HDMI monitor attached too
=> In this case powerd will switch to "presentation mode", so the turn
LCD off time is ~45 seconds (and it takes two timeouts).
TEST=(3) suspend_stress_test should survive even after LCD powers off
Change-Id: I3cd09d5b9555a9e05efc5a66478ab86f2216fc6b
Reviewed-on: https://gerrit.chromium.org/gerrit/47753
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Mike Frysinger [Thu, 11 Apr 2013 18:03:45 +0000 (14:03 -0400)]
CHROMIUM: config: disable OABI support for exynos platforms
We've never shipped a device with userland code using OABI afaik, so
this is enabling code paths that is purely bloat. Disable it like we
have for all other arm platforms.
BUG=None
TEST=`emerge-daisy chromeos-kernel` works and doesn't have OABI enabled
Change-Id: Ie8a67b3db7faba3ac430e1de678e60b1fba1ffb5
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47911
Reviewed-by: Olof Johansson <olofj@chromium.org>
Stéphane Marchesin [Fri, 12 Apr 2013 00:23:44 +0000 (17:23 -0700)]
CHROMIUM: drm/i915: repin bound framebuffers on resume
During suspend/resume all fences are reset, including their pin
count which is reset to 0. However a framebuffer can be bound across
suspend/resume, which means that after the buffer is unbound on
resume, the pin count for the buffer will be negative. Since the
fence pin count is now negative when available and zero when in use,
the buffer's fence will get recycled when the fence is in use which
is the opposite of what we want. The adverse effect is that since the
fence is recycled the tiling mode goes away while the buffer is being
displayed and we get lines/screens of garbage.
To fix this, we reallocate and repin the fences for all bound fbs on
resume, which ensures the pin count is right.
BUG=chromium:219172,chromium:225056
TEST=by hand, suspend/resume on alex, the artifacts are gone
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Change-Id: I9113078b0eb56e671dcca8dc9557a0c0c37f12e0
Reviewed-on: https://gerrit.chromium.org/gerrit/47933
Sonny Rao [Wed, 10 Apr 2013 22:11:10 +0000 (15:11 -0700)]
CHROMIUM: config: turn off KDS and dma-buf on x86 systems
This is only required for Exynos based systems and makes no sense on
x86. This should save some memory.
BUG=none
TEST=kernel builds, boots on lumpy
Change-Id: I929f4205c2c050dab070311e577b88d8c2e1a7fe
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47784
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Mandeep Singh Baines [Wed, 10 Apr 2013 22:38:31 +0000 (15:38 -0700)]
CHROMIUM: config: disable rfkill
We don't use rfkill in ChromeOS.
The rfkill_poll causes 1 wakeup / 5 seconds / per device.
BUG=chromium:227114
TEST=More details in the bug.
TEST=But I verified that wifi still works and verified that wakeups are reduced.
Change-Id: I92aa7fe4e0dbf806fb63ead7f3ba883f79a1a213
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47808
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Andrew de los Reyes [Tue, 9 Apr 2013 16:21:10 +0000 (09:21 -0700)]
CHROMEOS: HACK: Work around bluetooth kernel panic.
This patch is originally from Doron Keren <doronkeren@ti.com>
http://www.spinics.net/lists/linux-bluetooth/msg15564.html . Original
description:
The patch fixes kernel panic which is due to race condition
between the setup of incomming connection and clean-up of the
dead one. Observed in the following case: attached HID device
disconnects unexpectedly (without performing ACL disconnect ),
the device tries to connect again before the ACL link time-out
fires, this translates to the HCI_DISCONNECT, HCI_CONNECT_REQ
events on the same handle, since HCI_DISCONNECT trigers the clean
up of the HID device and handled in different context, the
linking/unlinking connection object to sysfs, may mess up.
BUG=chromium:228937
TEST=The following used to cause a panic reliably, but now doesn't:
- have Apple Magic Trackpad connected and working
- sleep/wake computer
- immediately click/rub fingers on trackpad
Change-Id: I63e0e37afe572641d7bda593887d2e3269043b5a
Signed-off-by: Ilia Kolominsky <iliak@ti.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47653
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Bernie Thompson [Wed, 10 Apr 2013 18:40:34 +0000 (11:40 -0700)]
Adjust the MIF ASV logic to set the voltage to either ASV group
In the case the U-Boot sets the MIF voltage to 1.05v we need to set the
MIF voltage to the 1.00v if the MIF ASV group allows for it. In this case
we can now handle either MIF ASV voltage setting used by U-Boot.
BUG=chrome-os-partner:16895
TEST=Manual, run new kernel on DUT, verify MIF voltage.
Change-Id: I589844034889f0e9ddd55a62226dd4963a4d0eb4
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47757
Paul Taysom [Wed, 10 Apr 2013 17:03:40 +0000 (10:03 -0700)]
CHROMIUM: md: dm-verity fixed setting error_behavior
Need to be able to set the error behavior from either the device table
or from the linux command line.
The code only handled setting from the linux command line which
broke the platform_DMVetiryCorruption test. This was not noticed
earlier because of another bug in error handling that was just
recently was fixed which exposed this problem.
Now the code defaults to the command line but overrides from
the device table.
BUG=chromium:229621
TEST=platform_DMVerityCorruption
Signed-off-by: Paul Taysom <taysom@chromium.org>
Change-Id: I32a516deb2bd564b599e73177e479cddec789dfb
Reviewed-on: https://gerrit.chromium.org/gerrit/47744
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Queue: Paul Taysom <taysom@chromium.org>
Catalin Marinas [Fri, 5 Apr 2013 16:24:56 +0000 (09:24 -0700)]
BACKPORT: arm: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)
On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:
1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
return code already).
The switch_mm() code includes a DMB operation since the IPI is only sent
to CPUs running the same ASID.
BUG=chromium:226280
TEST=There's unfortunately no simple test to trigger this bug, since it
normally manifests vaguely by random crashes or bad data later during
runtime. General testing to make sure it doesn't add new problems (i.e,
BVT, regression suites) is the best approach, followed by observations
of crash rates from the field.
Change-Id: I8fa68bdac9594a90d29079244efa93750f4319e3
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47427
Reviewed-by: Doug Anderson <dianders@chromium.org>
Olof Johansson [Fri, 5 Apr 2013 17:08:36 +0000 (10:08 -0700)]
Revert "UPSTREAM: ARM: Remove current_mm per-cpu variable"
This originally removed some not-needed code, but the recent A15 errata
workaround actually needs current_mm still around. So for bring this
code back for that reason.
This reverts commit
696cfa01f12ec85ac7122eb57d77c8598f79ff71.
BUG=chromium:226280
TEST=build kernel for daisy
Change-Id: Ie44c6bfea7137ca185eb568f9047bca39f3e1b5c
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47426
Reviewed-by: Doug Anderson <dianders@chromium.org>
Bing Zhao [Tue, 9 Apr 2013 21:23:29 +0000 (14:23 -0700)]
mwifiex: remove redundant initialization for bss_descriptor
Initialization of bss_descriptor is unnecessary as the entire
structure will be overwritten by a memcpy.
BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.
Change-Id: I4e8cecbf862b75f94fa717007111d0d9f9c0a2e3
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47690
Reviewed-by: Doug Anderson <dianders@chromium.org>
Bing Zhao [Tue, 9 Apr 2013 00:55:58 +0000 (17:55 -0700)]
mwifiex: fix use-after-free in beacon_ie processing
beacon_ie buffer is allocated in mwifiex_fill_new_bss_desc()
and the buffer pointer is saved in bss_desc->beacon_buf.
beacon_ie is freed before the function returns. However,
bss_desc->beacon_buf is still being accessed afterwards.
Fix it by allocating and freeing the beacon_ie buffer in
caller's scope.
BUG=chrome-os-partner:18602
TEST=able to associate to AP with and without
slub_debug=FZPUA kernel option.
Change-Id: If6ba90dc3a6d6890a4c891a0c4ab06d46f8cdcc9
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47621
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Paul Stewart <pstew@chromium.org>
Charlie Mooney [Mon, 8 Apr 2013 17:16:36 +0000 (10:16 -0700)]
Add fallback power config values for Atmel T7
On suspend the atmel driver backs up the power configuration (T7) so
that it can restore it later on resume. If the i2c transaction fails
when it's trying to read the current T7 config it sets a flag saying
that it was unable to back up the config, and then won't try to restore
it when the machine resumes.
A problem occurs if the i2c transaction to read the current config to
back it up on suspend fails, but the driver is still able to turn off
the touchpad. Then on resume, it sees that it had failed to backup the
old values and never restores the T7 object. As a result the
touchscreen/pad never wakes up.
Suspend:
1) Read current T7 config and back it up
2) Overwrite current config with suspend config
Resume
3) restore value stored in step 1
So if step 1 fails, but step 2 succedes we run into a dead touch device
on resume. Reboot fixes everything, however.
This patch adds in some default values in the event that a failed backup
config is detected and makes sure the device actually gets turned on no
matter what on resume.
BUG=chrome-os-partner:17621
TEST=manually tested on Link
Change-Id: I325efae0eb2d801d07898ad29a09e3162e5b79e5
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47564
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Chih-Chung Chang [Wed, 3 Apr 2013 08:39:12 +0000 (16:39 +0800)]
CHROMIUM: ALSA: hda/realtek - Check mic jack state when headphone jack state changes.
Usually the mic jack state changes will generate an unsol mic event,
and we can do auto-mic-switching at that time. But if the mic jack state
is gated by the headphone jack state, there may be no unsol mic event,
and we need to do auto-mic-switching in the unsol headphone event handler.
BUG=chromium:221938
TEST=plug/unplug 3.5mm headset and observe the capture source is switched correctly.
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: If057cc20b951fff05af1d6842cbc8e197a93a3f3
Reviewed-on: https://gerrit.chromium.org/gerrit/47231
Paul Taysom [Wed, 27 Mar 2013 17:59:26 +0000 (10:59 -0700)]
CHROMIUM: md: dm-verity: error handling for bad block
In the legacy version of dm-verity, verity_error handled
many different errors. Now it only has to handle bad
hash errors. Simplified to the code to handle only that
case.
BUG=chromium:222545
TEST=./run_remote_tests.sh --board=$B --remote=$IP platform_CorruptRootfs/control
Change-Id: Iaef19a17bd46429cae3589096a8b21ea2d6b70b7
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46652
Paul Taysom [Mon, 25 Mar 2013 02:58:17 +0000 (19:58 -0700)]
CHROMIUM: md: dm-verity: call to verity_error missing
The code path going through verity_work, was not calling
verity_error. This meant invalid block errors were not
being passed to the verity-chromeos error handler.
BUG=chromium:222545
TEST=manually corrupt root file system, reboot
Change-Id: I1f1c81feccc6ca5654dc81de3edfc97f240bea01
Signed-off-by: Paul Taysom <taysom@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46376
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Julius Werner [Thu, 4 Apr 2013 16:50:31 +0000 (09:50 -0700)]
TEMP: uvcvideo: Choose first (not last) of equal-sized alt settings
The LiteOn camera built into Spring boards has a weird bug: it reports
three alternate settings on its USB interface that all have the same
transfer size. Linux arbitrarily chooses the last of them, which seems
to work with EHCI but not with XHCI host controllers for reasons beyond
human understanding. Anyway, the first alternate setting seems to work
with both, so let's change the order for now until the vendor can fix
their firmware.
BUG=chrome-os-partner:18460
TEST=Make sure camera works on Spring EVT.
Change-Id: I7734a43b0383cb1d74f30e99a40cbce9db85c7c2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47319
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Laurent Pinchart [Tue, 17 Jul 2012 11:58:48 +0000 (08:58 -0300)]
UPSTREAM: [media] uvcvideo: Support super speed endpoints
Compute the maximum number of bytes per interval using the burst and
multiplier values for super speed endpoints.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
(cherry picked from commit
6fd90db8df379e215f2d495d0b4f3d2553c00277)
BUG=chrome-os-partner:18460
TEST=None
Change-Id: I0ad74ce6edb7316e51a7f5fb7f1d41b4f6e3880c
Reviewed-on: https://gerrit.chromium.org/gerrit/47318
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Doug Anderson [Tue, 2 Apr 2013 16:21:05 +0000 (09:21 -0700)]
arm: exynos: Don't print out warning about negative ASV group
We have seen CPUs that end up with a calculated ASV group of -1.
According to Samsung these should be assigned group 0 and are no
problem, so we shouldn't warn about them. We'll also stop warning
about other negative ASV groups. If we need to find out the
calculated ASV group we can use the "EXYNOS5250: ORIG: %d MOD: %d
RESULT: %d" message and just to the math ourselves (ORIG-MOD).
BUG=chrome-os-partner:18505
TEST=Boot up a device with ASV group -1 and see the warning go away.
Change-Id: I7c20445b1fb5afc233614faace5f387e5c182a03
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47126
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Stéphane Marchesin [Wed, 3 Apr 2013 20:21:45 +0000 (13:21 -0700)]
Revert "drm/exynos: mixer: support for 800x600 resolution"
This reverts commit
ed244d6a805b3c11a72dbce6307ed752e7c15848.
The 800x600 resolution does not work, so let's not expose it as
it causes black screens, especially with projectors where this mode
is very common (we don't have 1024x768 so it falls back to 800x600).
BUG=chromium:225983
TEST=by hand: the 24 inch Dell monitor now picks 640x480 and works fine
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_hdmi.c
Change-Id: I0337a63767b8ed10f1879f8251f54ac6649b604b
Reviewed-on: https://gerrit.chromium.org/gerrit/47268
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Will Drewry [Thu, 21 Mar 2013 22:00:53 +0000 (17:00 -0500)]
CHROMIUM: Restrict swapon() to "zram" devices / lock down zram
This cl contains three distinct changes collapsed into
one CL as per semenzato's request:
1. Restrict CONFIG_SWAP to ensure that only zram devices
may be used.
2. Restrict zram to disallow open calls, even from root, if
the device is claimed (e.g., by sys_swapon)
3. Add swapoff fallback when filp_open fails to use the path lookup.
I don't believe swapoff needs filp_open() since kern_path()
provides the data needed without a file object.
4. Add an open counter to zram to ensure that it is not opened more
times than swapon(2) will claim it -- twice:
- blkdev_get and filp_open (for swap_file)
Signed-off-by: Will Drewry <wad@chromium.org>
TEST=tested on lumpy; swapon, swapoff, change zram during swapon fails, change withotu swapon succeeds.
BUG=chromium:220974
Change-Id: Ic281a7004a81b2897cf0bf1c5d334351061261f1
Reviewed-on: https://gerrit.chromium.org/gerrit/46168
Tested-by: Will Drewry <wad@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Will Drewry <wad@chromium.org>
Luigi Semenzato [Wed, 27 Mar 2013 23:45:14 +0000 (16:45 -0700)]
CHROMIUM: detect GPU memory mapped at < 1MB physaddr.
We want to check if we ever map GPU memory at < 1MB,
because of problems in Sandy Bridge (and possibly Ivy Bridge).
BUG=chromium:224320
TEST=compiled, booted
BRANCH=none
Change-Id: I731da19f2a4d5230f84b54dbfd3993a5cb8dfe72
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46716
Vincent Palatin [Tue, 2 Apr 2013 18:19:09 +0000 (11:19 -0700)]
CHROMIUM: xhci: Ignore spurious successful event on DWC3 controller
The DesignWare USB3 controller behaves the same as the Panther Point
chipset regarding success on short packets.
Let's define the same quirk (see original explanation below).
As DWC3 IP is the only xhci platform driver so far (both in our tree and
tip of upstream kernel), we can simply define it for all platform XHCI
controller.
This quirk was originally added to xhci-pci driver with the following
message in commit
ad80833:
The xHCI host controller in the Panther Point chipset sometimes produces
spurious events on the event ring. If it receives a short packet, it
first puts a Transfer Event with a short transfer completion code on the
event ring. Then it puts a Transfer Event with a successful completion
code on the ring for the same TD. The xHCI driver correctly processes the
short transfer completion code, gives the URB back to the driver, and then
prints a warning in dmesg about the spurious event. These warning
messages really fill up dmesg when an HD webcam is plugged into xHCI.
This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: I2857226a763613109da767513f350db4081e45e2
Reviewed-on: https://gerrit.chromium.org/gerrit/47152
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vivek Gautam [Thu, 21 Mar 2013 06:36:48 +0000 (12:06 +0530)]
BACKPORT: usb: xhci: Fix TRB transfer length macro used for Event TRB.
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
This patch should be backported to kernels as old as 2.6.31, that
contain the commit
b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
Bulk transfer support". This patch will have issues applying to older
kernels.
Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: Id33eaf62d67edcc5c79a187dd415b914133a58d3
Reviewed-on: https://gerrit.chromium.org/gerrit/47141
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Sarah Sharp [Tue, 8 May 2012 16:22:49 +0000 (09:22 -0700)]
BACKPORT: xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:18460
TEST=on Spring EVT board, use camera preview and get an image.
Change-Id: I5d9ddabd5e8bddd6c2fd2acee2eb8251628f2b9d
Reviewed-on: https://gerrit.chromium.org/gerrit/47140
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Anatol Pomozov [Mon, 1 Apr 2013 16:47:56 +0000 (09:47 -0700)]
UPSTREAM: loop: prevent bdev freeing while device in use
struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
block_device allocated first time we access /dev/loopXX and deallocated on
bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
we want that block_device stay alive until we destroy the loop device
with "losetup -d".
But because we do not hold /dev/loopXX inode its counter goes 0, and
inode/bdev can be destroyed at any moment. Usually it happens at memory
pressure or when user drops inode cache (like in the test below). When later in
loop_clr_fd() we want to use bdev we have use-after-free error with following
stack:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000280
bd_set_size+0x10/0xa0
loop_clr_fd+0x1f8/0x420 [loop]
lo_ioctl+0x200/0x7e0 [loop]
lo_compat_ioctl+0x47/0xe0 [loop]
compat_blkdev_ioctl+0x341/0x1290
do_filp_open+0x42/0xa0
compat_sys_ioctl+0xc1/0xf20
do_sys_open+0x16e/0x1d0
sysenter_dispatch+0x7/0x1a
To prevent use-after-free we need to grab the device in loop_set_fd()
and put it later in loop_clr_fd().
The issue is reprodusible on current Linus head and v3.3. Here is the test:
dd if=/dev/zero of=loop.file bs=1M count=1
while [ true ]; do
losetup /dev/loop0 loop.file
echo 2 > /proc/sys/vm/drop_caches
losetup -d /dev/loop0
done
[ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
time we call loop_set_fd() we check that loop_device->lo_state is
Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
it will get EBUSY. And if we try to loop_clr_fd() on unbound loop
device we'll get ENXIO.
loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
loop_device->lo_ctl_mutex. ]
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium:221466
TEST=link build, manual testing
(cherry picked from upstream commit
c1681bf8a7b1b98edee8b862a42c19c4e53205fd)
Change-Id: Ic728f6f5dc6664bbc06e0265345208a862130bac
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47072
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Nicolas Pitre [Tue, 12 Mar 2013 12:00:42 +0000 (13:00 +0100)]
UPSTREAM: ARM: 7670/1: fix the memset fix
Commit
455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit
418df63adac56841ef6b0f1fcf435bc64d4ed177)
Change-Id: I30ffc36e387901ab33739325ce22b6ee9da52da4
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47028
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ivan Djelic [Wed, 6 Mar 2013 19:09:27 +0000 (20:09 +0100)]
UPSTREAM: ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0:
e92d4008 push {r3, lr}
800554d4:
e1a00001 mov r0, r1
800554d8:
e3a02010 mov r2, #16 ; 0x10
800554dc:
e3a01011 mov r1, #17 ; 0x11
800554e0:
eb04426e bl
80165ea0 <memset>
800554e4:
e1a03000 mov r3, r0
800554e8:
e583000c str r0, [r3, #12]
800554ec:
e5830000 str r0, [r3]
800554f0:
e5830004 str r0, [r3, #4]
800554f4:
e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit
455bd4c430b0c0a361f38e8658a0d6cb469942b5)
Change-Id: Idfbebdd48103e5fa4ae7faeae78dfabace28f0a7
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47027
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Pawel Osciak [Fri, 22 Mar 2013 14:40:25 +0000 (07:40 -0700)]
CHROMIUM: config: Add vivi to base config for testing purposes
vivi is a virtual capture driver that acts like a camera. Add it to the default
build for testing purposes.
Eventually we'd like to have it built for testing images only.
BUG=chromium:223099
TEST=manual build and test
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Change-Id: Ic9b4f95eb10ee609d8e070cb93891164da37f4f4
Reviewed-on: https://gerrit.chromium.org/gerrit/46269
Commit-Queue: Pawel Osciak <posciak@google.com>
Reviewed-by: Pawel Osciak <posciak@google.com>
Tested-by: Pawel Osciak <posciak@google.com>
Joonyoung Shim [Wed, 27 Jun 2012 05:27:06 +0000 (14:27 +0900)]
BACKPORT: drm/exynos: add property for plane zpos
The exynos drm driver used a specific ioctl - DRM_EXYNOS_PLANE_SET_ZPOS
to set zpos of plane. It can be substitute to property of plane. This
patch adds a property for plane zpos and removes
DRM_EXYNOS_PLANE_SET_ZPOS ioctl.
BUG=chromium:222980
TEST=Verified that cursor works when using property to set zpos.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit
00ae67cf26fad3889e71e3bdbec012b1f938dc0e)
Change-Id: I018b6475916f6bbff416d0313fe0c7c3c68217b8
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46957
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Joonyoung Shim [Wed, 27 Jun 2012 05:27:04 +0000 (14:27 +0900)]
BACKPORT: drm/exynos: use private plane for crtc
The crtc can use private plane instead it has overlay struct. It will be
helpful use plane feature from crtc later.
BUG=chromium:222980
TEST=By hand.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
(cherry picked from commit
b5d2eb3bd691c0b6869a2013e719a61c595d73a6)
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I3385e40cac26ebb2d71670f71eb1d3f91638437e
Reviewed-on: https://gerrit.chromium.org/gerrit/46956
Reviewed-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Dylan Reid [Fri, 29 Mar 2013 22:42:06 +0000 (15:42 -0700)]
CHROMIUM: ASoC: max98088 - expose digital mic enable switches.
Add a control for enable right and left digital mic. This control
routes the digital mic input through the ADC. It must be disabled for
analog input to work.
BUG=chrome-os-partner:18454
TEST=toggle switches, see changes with i2cdump.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I8ed493ce9aea4f94f4feda23172e2e3251e27b51
Reviewed-on: https://gerrit.chromium.org/gerrit/46904
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Dylan Reid [Fri, 29 Mar 2013 21:55:52 +0000 (14:55 -0700)]
CHROMIUM: ASoC: daisy - different mic bias for spring.
Spring's mic bias control is "MICBIAS" not "MICBIAS2", set
appropriately.
BUG=chrome-os-partner:18454
TEST=boot; check mic bias register.
Change-Id: Ibd67346dbec153c2635b6a318143766f3f98155a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46932
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tai-Hsu Lin [Thu, 21 Mar 2013 07:54:02 +0000 (15:54 +0800)]
CHROMIUM: input: cyapa - fix power mode switch problems
We have found that some commands may fail if the touchpad is
not running at the full mode. Moreover, setting new power modes
would take the amount of time roughly equal to the old scanrate
to complete. The patch fixes several places where the unsafe
commands might be run before completely returning to the full
mode. Meanwhile, the cyapa_set_power_mode function now returns
early if the mode to set is the same as the current one.
Signed-off-by: Tai-Hsu Lin <sheckylin@chromium.org>
BUG=chromium:196520
TEST=Repeatedly suspend/resume the device with Cypress touchpad for
a few hundred times. One should see errors about reading query data
in the /var/log/messages.
With the fix, one shouldn't see the error.
Change-Id: I95a843a077d5840c57cc24daf85b6549550fa73d
Reviewed-on: https://gerrit.chromium.org/gerrit/46115
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Tai-Hsu Lin <sheckylin@chromium.org>
Tested-by: Tai-Hsu Lin <sheckylin@chromium.org>
Daniel Kurtz [Mon, 25 Mar 2013 13:00:40 +0000 (21:00 +0800)]
CHROMIUM: drm/exynos: Propagate controller's enable_vblank() result
The controller enable_vblank() can fail if, for example, it is requested
while suspended (fimd) or before the mixer is powered on.
In these cases, the error could should be propagated up to the higher
layers so they can deal with it appropriately (i.e., try again later).
In particular, this solves a race at HDMI hotplug where a userspace
WaitVBlank ioctl races with the hdmi/mixer power on sequence.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:223501
TEST=boot w/ HDMI disconnected. Login as guest. Plug HDMI cable.
Should see extended desktop, pointer should move on external monitor.
Change-Id: Id2c54ce8c1c500bc95321a6b00fa147348c29125
Reviewed-on: https://gerrit.chromium.org/gerrit/46399
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Andrew de los Reyes [Sun, 24 Feb 2013 18:45:11 +0000 (10:45 -0800)]
CHROMEOS: HID: Support for Logitech T651 Touchpad
This touchpad is similar to the T650, but has a few notable
differences:
- It connects via Bluetooth as opposed to the Unifying Receiver
- The raw data reports are in a unique format appended to normal mouse
reports. The mouse reports must be ignored. Putting this pad into
raw data mode will work as the T650 does, but Nestor Lopez Casado of
Logitech advises against as that mode as it's not officially
supported.
BUG=chromium:223138
TEST=Manually tested on device. Will add base regression tests.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I9c6e3359f08508c54c47e79bec1bbc0121d0b06c
Reviewed-on: https://gerrit.chromium.org/gerrit/46683
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Rob Clark [Thu, 17 May 2012 08:23:27 +0000 (02:23 -0600)]
UPSTREAM: drm: add plane properties
The omapdrm driver uses this for setting per-overlay rotation. It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
4d93914ae3db4a897ead4b1e33eca7cdfff4c6f7)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: I8f50d93443cc6c51f06d553cd0286fff11de3269
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40516
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Paulo Zanoni [Tue, 15 May 2012 21:09:04 +0000 (18:09 -0300)]
UPSTREAM: drm: add 'count' to struct drm_object_properties
This way, we don't need to count every time, so we're a little bit
faster and code is a little bit smaller.
Change suggested by Ville Syrjälä.
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit
7f88a9bedfb814a2d4d537db8295c524298256cb)
BUG=chrome-os-partner:17074
TEST=Use hardware cursor with kernel v3.8 and v3.4 and no flicker on screen.
Change-Id: Ic184b52fb6d587a69943744e38f8f73bad2cb6e1
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40514
Tested-by: Prathyush Kalashwaram <prathyush@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>