Alan Cox [Thu, 15 Nov 2012 13:06:22 +0000 (13:06 +0000)]
UPSTREAM: x86/msr: Add capabilities check
At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.
In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.
Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Horses <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
BUG=chromium-os:38633
TEST=link build, reading MSR correctly fails as uid 0 without caps:
(can't use iotools with minijail because iotools is statically linked)
`minijail0 -c 0 /usr/local/bin/python -c 'from struct import *; \
m = open("/dev/cpu/0/msr"); m.seek(0x3a); \
print "0x%016x" % (unpack("Q", m.read(8)))'`
(cherry picked from upstream commit
c903f0456bc69176912dee6dd25c6a66ee1aed00)
Change-Id: I9d636ff7baac98a4243392428b48c0730600c7bc
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42684
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Mandeep Singh Baines [Wed, 6 Feb 2013 22:22:38 +0000 (14:22 -0800)]
CHROMIUM: config: enable CGROUP_FREEZER
This change is need for work on idle enhancements.
The overhead is negligible. Just calls to cgroup_freezing() in
freezing_slow_path(). cgroup_freezing() is a very low
overhead call.
BUG=chromium-os:38701
TEST=Compile. Boot.
Change-Id: I8df3e19c1bc9a45c7fef0ec014db294c00ab34fc
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42797
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Todd Broch [Wed, 6 Feb 2013 19:57:54 +0000 (11:57 -0800)]
CHROMIUM: spring: dts: Instantiate s5m8767 PMIC.
Note, this will enumerate multiple PMICs for the same design as the
max77686 PMIC is also enumerated via cros5250-common.dtsi. This is
remedied by the firmware (u-boot) at boot time by pruning the
non-existent PMIC.
See: https://gerrit.chromium.org/gerrit/#/c/41993/ for details.
CL also disables ADC node for Spring which is unused.
BUG=chrome-os-partner:16430
TEST=kernel compiles for BOARD=daisy_spring
Change-Id: Ic1070b3001b20b4825582f10bd039051a61c7459
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42798
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Todd Broch [Sat, 26 Jan 2013 02:41:30 +0000 (18:41 -0800)]
CHROMIUM: spring: add DT support for s5m8767.
Add minimal device tree support for mfd/s5m-core and associated
s5m8767 PMIC.
BUG=chrome-os-partner:16430
TEST=kernel compiles
Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: Ieb74abb8ae061b727523c1b3010b354ce6023fe7
Reviewed-on: https://gerrit.chromium.org/gerrit/42202
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Vincent Palatin [Wed, 6 Feb 2013 19:05:28 +0000 (11:05 -0800)]
CHROMIUM: exynos: enable ADCs only if there are used
Check the presence of an ADC node in the device tree before activating
the ADCs and the NTP thermistors connected to them.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16430
TEST=on Spring with SLSI PMIC, boot with adc node de-activated and
doesn't see any ADC related panic.
on Snow, boot and check the thermistor temperatures in sysfs.
Change-Id: I1603d78805a8d0877c137b92bcd2c64cbb32564d
Reviewed-on: https://gerrit.chromium.org/gerrit/42868
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Elly Fong-Jones [Tue, 5 Feb 2013 19:59:07 +0000 (14:59 -0500)]
CHROMIUM: gobi: check for overflow in buffer_new()
The size passed into buffer_new() can overflow. This isn't exploitable, since
all the calling paths check this, but still. Belt and suspenders and all that.
BUG=chromium-os:38211
TEST=adhoc
Change-Id: I3f19ec85db502c9ce56c9bae9e80d393cd5c5972
Signed-off-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42636
John Sheu [Wed, 6 Feb 2013 20:26:40 +0000 (12:26 -0800)]
CHROMIUM: s5p-mfc: enable NV12M/NV21M decoder output.
These two formats work on hardware; there is no need to disable them.
Enable them so we can have linear multiplanar YUV output support.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow
Change-Id: Ic4889ca26555b067e7faadf9027e789633622dee
Reviewed-on: https://gerrit.chromium.org/gerrit/42761
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Yongqiang Yang [Wed, 5 Sep 2012 05:21:50 +0000 (01:21 -0400)]
UPSTREAM: ext4: ignore last group w/o enough space when resizing instead of BUG'ing
If the last group does not have enough space for group tables, ignore
it instead of calling BUG_ON().
Reported-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
BUG=chromium-os:36118
TEST=link build, resize still works
(cherry picked from upstream commit
03c1c29053f678234dbd51bf3d65f3b7529021de)
Change-Id: I3a7274b6bd72346652b9e7f68b53674684764de7
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42679
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
John Sheu [Thu, 31 Jan 2013 02:39:36 +0000 (18:39 -0800)]
CHROMIUM: v4l2: dmabuf: update VIDIOC_EXPBUF interface to upstream
<UPSTREAM MERGE NOT REQUIRED>
Backport the VIDIOC_EXPBUF interface from upstream kernels.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow
Change-Id: Ia5cae1636b85d2c716188ff510a83a04b9cd8bc9
Reviewed-on: https://gerrit.chromium.org/gerrit/42374
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
John Sheu [Wed, 30 Jan 2013 10:04:36 +0000 (02:04 -0800)]
CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow
Change-Id: I868696d5f67235b9ca7d2599eac733438387e82b
Reviewed-on: https://gerrit.chromium.org/gerrit/42295
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Elly Fong-Jones [Mon, 4 Feb 2013 22:13:35 +0000 (17:13 -0500)]
CHROMIUM: gobi: fix integer wraparound bug
All the sizes here are bounded on the wire by 16 bits, to switch to size_t and
check for wraparound more carefully.
BUG=chromium-os:38210
TEST=adhoc
build, boot, see if the gobi still shows up
Change-Id: I492e632722714b1a869929d03c33a4fc12995120
Signed-off-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42559
Reviewed-by: Kees Cook <keescook@chromium.org>
Xi Wang [Thu, 31 May 2012 23:26:04 +0000 (16:26 -0700)]
UPSTREAM: introduce SIZE_MAX
ULONG_MAX is often used to check for integer overflow when calculating
allocation size. While ULONG_MAX happens to work on most systems, there
is no guarantee that `size_t' must be the same size as `long'.
This patch introduces SIZE_MAX, the maximum value of `size_t', to improve
portability and readability for allocation size validation.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Acked-by: Alex Elder <elder@dreamhost.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
a3860c1c5dd1137db23d7786d284939c5761d517)
Change-Id: Ic87ed61f0bbcd4d92ab3c8e898d0519d4d905ffb
BUG=chromium-os:38211
TEST=adhoc
build, boot, test for gobi presence
Signed-off-by: Elly Fong-Jones <ellyjones@chromium.org>
Change-Id: I82b6bf09368b7cc6a1ea1d2813f482cdf4fab424
Reviewed-on: https://gerrit.chromium.org/gerrit/42742
Reviewed-by: Kees Cook <keescook@chromium.org>
Dave Reisner [Wed, 2 Jan 2013 13:54:37 +0000 (08:54 -0500)]
UPSTREAM: debugfs: convert gid= argument from decimal, not octal
This patch technically breaks userspace, but I suspect that anyone who
actually used this flag would have encountered this brokenness, declared
it lunacy, and already sent a patch.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Reviewed-by: Vasiliy Kulikov <segoon@openwall.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BUG=chromium-os:23758
TEST=link build, debugfs mount options work with decimal for gid
Change-Id: I4a37f3bd13da0ced916bde8038de16ebc3504d5e
(cherry picked from upstream commit
f1688e0431d3a395388e70fe21da89ed0de0c323)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42650
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Mandeep Singh Baines [Tue, 5 Feb 2013 22:55:38 +0000 (14:55 -0800)]
CHROMIUM: sysrq-x: killall chrome process not just first one
Currently, sysrq-x just kills the first chrome process it finds.
We've seen in at least one occassion where there may be a stale
chrome process from a previous session. The fix is to kill all
processes we find that meet our criteria.
I also modified the printk to print the pid of the process
that is killed. Previously we were printing the pid of
session_manager which is not as useful.
BUG=chrome-os-partner:17522
TEST=manual (debugging feature):
hold down alt-volup then x - chrome should crash
repeat immediately afterward - session should restart
repeat and machine should reboot
2013-02-05T13:28:37.425355-08:00 localhost crash_reporter[2829]: Received crash notification for chrome[963] sig 6 (ignoring - chrome crash)
2013-02-05T13:28:37.557482-08:00 localhost session_manager: [0205/132837:INFO:session_manager_service.cc(523)] Handling child process exit: 963
2013-02-05T13:28:37.557537-08:00 localhost session_manager: [0205/132837:INFO:session_manager_service.cc(525)] Exited with signal 6
Change-Id: Id039df7386cf7cccf42e0861bc2ab6f653147605
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42658
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Mandeep Singh Baines [Tue, 5 Feb 2013 20:58:55 +0000 (12:58 -0800)]
CHROMIUM: watchdog: don't free perf_event on disable
When offlining a CPU, we currently free the perf_event used for
the hardlockup detector. This sometimes results in an allocation
failure when bringing the CPU back online. The hotplug code to
bring the CPU back online is run while gfp flags are masked by
pm_restrict_gfp_mask.
[10086.691854] [<
ffffffff810a4e80>] warn_alloc_failed+0x10f/0x123
[10086.691864] [<
ffffffff810a6560>] ? drain_local_pages+0x16/0x18
[10086.691872] [<
ffffffff810a75f8>] __alloc_pages_nodemask+0x697/0x752
[10086.691881] [<
ffffffff810a7738>] __get_free_pages+0x17/0x44
[10086.691891] [<
ffffffff810ccca0>] kmalloc_order_trace+0x2b/0x5b
[10086.691898] [<
ffffffff810cf095>] __kmalloc+0x37/0x151
[10086.691908] [<
ffffffff81011a0d>] ? kmalloc_node.isra.0.constprop.3+0xe/0x10
[10086.691917] [<
ffffffff81011a0d>] kmalloc_node.isra.0.constprop.3+0xe/0x10
[10086.691925] [<
ffffffff810120dc>] reserve_ds_buffers+0xaf/0x30e
[10086.691934] [<
ffffffff8100ec2c>] x86_pmu_event_init+0x2d2/0x31c
[10086.691941] [<
ffffffff8109e456>] perf_init_event+0x66/0xac
[10086.691948] [<
ffffffff8109e6fb>] perf_event_alloc+0x25f/0x38f
[10086.691957] [<
ffffffff81076488>] ? touch_nmi_watchdog+0x67/0x67
[10086.691965] [<
ffffffff8109eacd>] perf_event_create_kernel_counter+0x26/0xd9
[10086.691973] [<
ffffffff810762b0>] watchdog_enable+0x7e/0x1ef
[10086.691981] [<
ffffffff81076848>] cpu_callback+0x31/0x3f
[10086.691999] [<
ffffffff810769d4>] lockup_detector_bootcpu_resume+0x2e/0x32
[10086.692009] [<
ffffffff8105beab>] suspend_devices_and_enter+0x1a3/0x26e
[10086.692018] [<
ffffffff8105c075>] pm_suspend+0xff/0x1c2
[10086.692025] [<
ffffffff8105b3a1>] state_store+0x99/0xca
[10086.692034] [<
ffffffff811d6562>] kobj_attr_store+0xf/0x1b
[10086.692042] [<
ffffffff81123280>] sysfs_write_file+0xe9/0x121
[10086.692050] [<
ffffffff810d2fca>] vfs_write+0x98/0xda
[10086.692057] [<
ffffffff810d3199>] sys_write+0x43/0x73
[10086.692066] [<
ffffffff8146ac52>] system_call_fastpath+0x16/0x1b
The end result of the allocation failure is that the watchdog no
longer works sometimes after suspend/resume. The fix is to only
disable the event and not free it. This avoids the failed allocation.
BUG=chrome-os-partner:17522
TEST=Verify that detector still works after suspend/resume.
Change-Id: I78c90b13f718d660bd23884968be2f14c7c61860
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42657
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Vincent Palatin [Tue, 5 Feb 2013 17:12:19 +0000 (09:12 -0800)]
CHROMIUM: exynos: properly manage "regulator" for HSIC reset
We were violating something in the documentation for regulator_put,
namely:
Note: drivers must ensure that all regulator_enable calls made on
this regulator source are balanced by regulator_disable calls prior
to calling this function.
We now keep the regulator around until we've disabled it. That keeps
the regulator in the right state.
At the same time, add some error checking to regulator calls.
BUG=chromium-os:38403
TEST=on Snow with 3G modem, do a suspend/resume cycle and check in
"lsusb" that the modem (VID/PID 1410:a021) and the camera (VID/PID
2232:1037) are still there after resume.
On Spring, check we can still boot from USB.
TEST=Check state of hsichub-reset-l at boot and after resume:
1. cd /sys/kernel/debug/regulator/hsichub-reset-l
2. grep "" *
3. Check open_count of 1 and use_count of 1.
Change-Id: I31012c15e30c43a1259f15ffd3592ee68cb0b772
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42621
Reviewed-by: Todd Broch <tbroch@chromium.org>
Paul Stewart [Tue, 5 Feb 2013 19:53:08 +0000 (11:53 -0800)]
CHROMIUM: nl80211: Reassign NL80211_ATTR_SCAN_FLAGS
Change the NL80211_ATTR_SCAN_FLAGS value to match upstream kernels.
In doing so, fast-forward the contents of the nl80211_attrs enum to
its contents as of the current wireless-testing kernel.
CQ-DEPEND=I315dce8b3c39ae02db2a01401f83666f81b51f63
BUG=chromium-os:38618
TEST="test-flimflam scan" with new supplicant and kernel installed
Change-Id: Ie27c65a6eea1006f34346c51768d797ceadb7951
Signed-off-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42640
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Simon Que [Tue, 5 Feb 2013 01:38:16 +0000 (17:38 -0800)]
CHROMIUM: chromeos: add rts_pstore errors to whitelist
These were added to the kernel build when this CL was pushed:
https://gerrit.chromium.org/gerrit/#/c/41815/
BUG=chromium-os:37418
TEST="FEATURES=test emerge-$BOARD chromeos-kernel" passes
Change-Id: I85426fafa2e022fbf66e09f067e6380957561885
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42591
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 19:06:04 +0000 (11:06 -0800)]
CHROMIUM: exynos: dts: enable G781 thermal sensor on Spring
On Spring, we have a G781 thermal sensor on I2C bus 7.
The sensor is supported by the LM90 driver.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16725
TEST=On spring, on the command-line
"cat /sys/bus/i2c/devices/7-004c/temp[12]_input"
and see board temperature in milli-celsius (e.g. 50750)
Change-Id: I84dfbc03f6b7f9399529f51965fe4dd4aeb04512
Reviewed-on: https://gerrit.chromium.org/gerrit/42380
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 19:06:04 +0000 (11:06 -0800)]
CHROMIUM: config: add LM90 driver on Exynos platforms
On Spring, we have a G781 thermal sensor on I2C bus 7.
The sensor is supported by the LM90 driver.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16725
TEST=On spring, on the command-line
"cat /sys/bus/i2c/devices/7-004c/temp[12]_input"
and see board temperature in milli-celsius (e.g. 50750)
Change-Id: I561df7bdc85cc07221235e85212a42b26598f5a4
Reviewed-on: https://gerrit.chromium.org/gerrit/42335
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 19:06:04 +0000 (11:06 -0800)]
CHROMIUM: i2c: samsung: do not put a default class for the adapter
Avoid adding I2C_CLASS_HWMON and I2C_CLASS_SPD class flags to all
Samsung I2C adapters when the I2C mappings are defined in a device tree.
So the drivers doing an auto-detection by probing busses won't mess-up
sensitive I2C devices or trigger long timeouts on non-functional busses.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:16725
TEST=emerge-daisy_spring chromeos-kernel
On spring, run with LM90 driver compiled and do not see timeout at
startup on non-functional busses
Change-Id: Iacdba3846c59f605224ff61f5b7c605828486db3
Reviewed-on: https://gerrit.chromium.org/gerrit/42480
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Simon Que [Thu, 31 Jan 2013 22:37:32 +0000 (14:37 -0800)]
CHROMIUM: chromeos: add smatch errors for i386 and x86_64 generic builds
Also updates the whitelist update script to reflect changes to ebuild.
BUG=chromium-os:37418
TEST="FEATURES=test USE=smatch emerge-{x86,amd64}-generic" passes
Change-Id: I6db75cc715081a1c719060a3ae69a51ee7a243da
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42416
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Daniel Lezcano [Tue, 15 Jan 2013 13:18:04 +0000 (14:18 +0100)]
UPSTREAM: cpuidle: remove the power_specified field in the driver
We realized that the power usage field is never filled and when it
is filled for tegra, the power_specified flag is not set causing all
of these values to be reset when the driver is initialized with
set_power_state().
However, the power_specified flag can be simply removed under the
assumption that the states are always backward sorted, which is the
case with the current code.
This change allows the menu governor select function and the
cpuidle_play_dead() to be simplified. Moreover, the
set_power_states() function can removed as it does not make sense
any more.
Drop the power_specified flag from struct cpuidle_driver and make
the related changes as described above.
As a consequence, this also fixes the bug where on the dynamic
C-states system, the power fields are not initialized.
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
References: https://lkml.org/lkml/2012/10/16/518
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit
8aef33a7cf40ca9da188e8578b2abe7267a38c52)
BUG=chromium-os:35320
TEST=Boot a ZGB on AC and unplug it afterwards. Run powertop and notice
how the device correctly goes down into C3.
Change-Id: If4f34246ce62d77094bf8f1a1718631a4b8e8030
Reviewed-on: https://gerrit.chromium.org/gerrit/42433
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Julius Werner [Thu, 31 Jan 2013 02:02:45 +0000 (18:02 -0800)]
CHROMIUM: xhci: crude USB resume fix for Stout (temporary)
Stout's USB 3.0 ports show a variety of nasty issues after resume, some
of which are more reproducible than others. They all have in common that
the host controller bails with "Device not responding to set address."
during enumeration. A trace pulled from a USB cable showed that the host
controller just fills the bus with garbage and does not even generate
correct SOF sequences.
This seems like a large and time-consuming problem that could hide
anywhere in the USB software or hardware stack. With Stout being close
to release, we need an interim solution to make it usable while we find
the underlying problem.
This patch sets the XHCI_RESET_ON_RESUME quirk flag on Stout, which
makes device reenumeration after resume work, but it creates a new
issue that makes the host controller hang on the next suspend while
trying to save its state. This looks like an unrelated hardware bug...
but since we don't actually need to save state when we will reset
anyway, we can just add some code to skip that step in xhci_suspend().
This patch is intended to be temporary, and should be reverted as soon
as the root cause for this is found and fixed.
BUG=chrome-os-partner:16781
TEST=Plug a USB device into the yellow port on the right. Run lsusb. Run
powerd_suspend and wake the machine. Run lsusb again and ensure that the
output stayed the same.
Change-Id: Id21ab972c698d02c14937509f699c9bc659b70c0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42394
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Simon Que [Fri, 1 Feb 2013 19:31:04 +0000 (11:31 -0800)]
CHROMIUM: pm-check: s3c_pm_check_init returns int
The proper behavior for a late_initcall() function is to return int.
See include/linux/init.h. Otherwise compiler throws a warning.
BUG=chromium-os:5542
TEST=emerge-daisy chromeos-kernel, make sure there is no warning in this
file.
Change-Id: I47e1f81c622721b06fb715e7c4a876857d9b45b3
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42468
Reviewed-by: Michael Spang <spang@chromium.org>
Simon Que [Fri, 1 Feb 2013 00:35:36 +0000 (16:35 -0800)]
CHROMIUM: chromeos: enable error-on-warning for all configs
BUG=chromium-os:5542
TEST=kernel build passes
Change-Id: I1161ca82de1145066bed22306e49cf73a51d9473
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42428
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 31 Jan 2013 02:16:08 +0000 (18:16 -0800)]
CHROMIUM: arch/arm: do not turn TODO warning into error
If the build treats warnings as errors (CONFIG_ERROR_ON_WARNING=y), then
do not invoke the "#warn 'TODO'" since it unnecessarily fails the build.
BUG=chromium-os:5542
TEST=emerge-daisy chromeos-kernel, make sure this doesn't appear.
Change-Id: I64c1b4d6079980bbea1f808ac038bf5cbe54beb0
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42371
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Wed, 30 Jan 2013 23:51:18 +0000 (15:51 -0800)]
CHROMIUM: net: ipw2x00: #ifdef condtionally used variable
The variable 'dev' is only used by a macro LIBIPW_DEBUG_WX() that is
conditional upon the config option 'CONFIG_LIBIPW_DEBUG'. When this
config option isn't defined, we get this warning:
libipw_wx.c:526:21: error: unused variable 'dev'
The solution is to define 'dev' only if CONFIG_LIBIPW_DEBUG is defined.
BUG=chromium-os:5542
TEST=emerge-x86-generic chromeos-kernel, make sure warning doesn't
appear.
Change-Id: I537c361f363879971ca045687e3dbd98475925fc
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42357
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 31 Jan 2013 00:34:26 +0000 (16:34 -0800)]
CHROMIUM: drm: nouveau: initialize channel pointer
Removes this compiler warning:
nv50_instmem.c:206:27: error: 'chan' may be used uninitialized in
this function
The variable 'chan' is implicitly initialized by passing to
nv50_channel_new()
This is not upstreamable as the structure of the nouveau driver has
changed in 3.8.
BUG=chromium-os:5542
TEST=emerge-x86-generic chromeos-kernel, make sure this warning doesn't
appear.
Change-Id: I753c4f160ecb8068d2bacae904bd2114df687a75
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42359
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 31 Jan 2013 00:26:10 +0000 (16:26 -0800)]
CHROMIUM: drm: nouveau: initialize variables in nv40_pm
These variables are implicitly initialized by being passed as pointers
into nv40_calc_pll(). However, the compile still generates these
warnings:
nv40_pm.c:163:41: warning: 'log2P' may be used uninitialized in this
function
nv40_pm.c:164:38: warning: 'M2' may be used uninitialized in this
function
nv40_pm.c:164:45: warning: 'M1' may be used uninitialized in this
function
nv40_pm.c:164:25: warning: 'N2' may be used uninitialized in this
function
nv40_pm.c:164:51: warning: 'N1' may be used uninitialized in this
function
BUG=chromium-os:5542
TEST=emerge-x86-generic chromeos-kernel, make sure these warnings don't
appear.
Change-Id: Ib51a1744d809a395e2b599461f22f774313512d4
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42358
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Doug Anderson [Tue, 29 Jan 2013 17:59:12 +0000 (09:59 -0800)]
CHROMIUM: pm-check: Don't free memory after each resume
Once you use your device for a significant period of time pm_check
starts failing. This may have gotten worse recently with compressed
RAM. Change pm-check to avoid freeing memory between suspend/resume.
While I'm at it, also over-allocate pm-check memory a little bit to
make sure that normal memory doesn't overlap CRC memory. This ensures
that more in-use memory is actually checked for errors.
BUG=chrome-os-partner:17282
TEST=Run suspend_stress_test on a device with original (90.0)
read-only firmware and see pm_check work.
TEST=Use device with 90.0 read-only firmware for a while and then
suspend/resume. Don't see any warning in system messages.
TEST=Manually change pr_debug() to pr_info() in pm_check_alloc(). See
an allocate at bootup but no more allocates after a
suspend_stress_test
Change-Id: I2399c2d358d548089347aba5163f84adf3262d68
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42242
Reviewed-by: Michael Spang <spang@chromium.org>
viresh kumar [Wed, 31 Oct 2012 09:40:42 +0000 (10:40 +0100)]
BACKPORT: ARM: 7569/1: mm: uninitialized warning corrections
The variables here are really not used uninitialized.
arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: warning: 'offset.un' may be used
uninitialized in this function [-Wmaybe-uninitialized]
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here
BUG=chromium-os:5542
TEST=emerge-daisy chromeos-kernel, make sure warning is gone
Change-Id: I90d41bdc48203f8cc9ef75e6ca1e059b916428cc
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42370
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Simon Que [Sat, 26 Jan 2013 01:29:16 +0000 (17:29 -0800)]
CHROMIUM: Add -Werror build option
Add a config option "ERROR_ON_WARNING" that adds the "-Werror" flag to
gcc, which turns warnings into errors.
BUG=chromium-os:5542
TEST=none
Change-Id: I8d85b8ba443585025a49618c3bca6d9bb7813359
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42075
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Dave Airlie [Tue, 16 Oct 2012 00:28:21 +0000 (10:28 +1000)]
BACKPORT: drm: fix warning on 32-bit.
This cast was causing a warning on 32-bit builds.
BUG=chromium-os:5542
TEST=emerge-x86-generic chromeos-kernel, make sure this warning doesn't
show up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from
7b8505300525d7e802ecf52ae160bc63f4ba28d7)
Change-Id: Ib08213c370525ce23fb0505c7e21439f257a813c
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41562
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 31 Jan 2013 01:52:45 +0000 (17:52 -0800)]
CHROMIUM: usb: dwc: Fix ARM usb_phy init parameter warning
Adding the param "bool ext_clk" to phy_init() results in some warnings:
arch/arm/mach-exynos/mach-exynos5-dt.c:535:2: error: initialization from
incompatible pointer type [-Werror]
arch/arm/mach-exynos/mach-exynos5-dt.c:540:2: error: initialization from
incompatible pointer type [-Werror]
Instead of updating this function pointer to have the extra variable,
add a new function to set "ext_clk" as a static variable in
setup-usb-phy.c
BUG=chromium-os:5542
TEST=emerge-daisy chromeos-kernel, make sure warning is gone
Change-Id: Ic2c38acd945083b0509dafe9dadf12935868991d
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42367
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Bing Zhao [Thu, 31 Jan 2013 05:12:16 +0000 (21:12 -0800)]
UPSTREAM: mwifiex: fix incomplete scan in case of IE parsing error
A scan request is split into multiple scan commands queued in
scan_pending_q. Each scan command will be sent to firmware and
its response is handlded one after another.
If any error is detected while parsing IE in command response
buffer the remaining data will be ignored and error is returned.
We should check if there is any more scan commands pending in
the queue before returning error. This ensures that we will call
cfg80211_scan_done if this is the last scan command, or send
next scan command in scan_pending_q to firmware.
Cc: "3.6+" <stable@vger.kernel.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
BUG=none
TEST=Hacked the driver to simulate an IE parsing error.
Without this patch, "iw mlan0 scan" gets stuck.
With this patch applied, "iw mlan0 scan" returns AP list.
Change-Id: I93cb877650ad9e84e5109f4ea62cf5b5c638e26a
Reviewed-on: https://gerrit.chromium.org/gerrit/42377
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
Julius Werner [Fri, 11 Jan 2013 19:03:44 +0000 (11:03 -0800)]
Revert "CHROMIUM: Log RTM_NEWLINK messages broadcast from the kernel (temporary)"
This reverts commit
0a06f97c7e44bbac8944732d7739ea95b79b2ac5
We have gathered all we need to know from this. The problem was in shill
and we have changed that to properly crash instead of silently fail. The
kernel netlink stack seems to work fine as it is and we don't need this
output anymore.
BUG=chromium-os:35479
TEST=Boot the kernel, make sure it still works fine and does not output
any messages with the string "RTM_NEWLINK" to dmesg anymore.
Change-Id: I9a12e41bb25adaf4ef7a7159d97adebfe2fd14e6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41139
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 18:45:37 +0000 (10:45 -0800)]
CHROMIUM: exynos: dts: ALS configuration is per board
Move the Ambient Light Sensor configuration to board-specific files.
Only Snow has an ISLxxxx light sensor.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17507
TEST=on Snow, boot and check the ambient light sensor is working when
putting the finger on it.
On Spring, boot and observe we no longer have isl driver failure in the kernel log.
Change-Id: I54a3031a4ea211c3a2cd5c56d9188387b329f72a
Reviewed-on: https://gerrit.chromium.org/gerrit/42334
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 18:45:37 +0000 (10:45 -0800)]
CHROMIUM: exynos: dts: TPM configuration is per board
Move the TPM configuration to board-specific files.
On Daisy and Snow, we have a SLB9635TT TPM with software I2C (the max
bus speed is 100kHz).
On Spring, we have a SLB9645TT TPM with hardware I2c (the max bus speed
is 400kHz).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17506
TEST=on Snow and Spring, boot and grep the tpm_tis_i2c messages in the
kernel log.
Change-Id: I3c914c8647fad3f93c5273228c5a18e476efe100
Reviewed-on: https://gerrit.chromium.org/gerrit/42333
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Wed, 30 Jan 2013 00:56:41 +0000 (16:56 -0800)]
BACKPORT: tpm: Add support for new Infineon I2C TPM (SLB 9645 TT 1.2 I2C)
This driver adds support for Infineon's new SLB 9645 TT 1.2 I2C TPMs,
which supports clockstretching, combined reads and a bus speed of
up to 400khz. The device also has a new device id.
The driver works now also fine with device trees, so you can instantiate
your device by adding:
+ tpm {
+ compatible = "infineon,slb9645tt";
+ reg = <0x20>;
+ };
for SLB 9645 devices or
+ tpm {
+ compatible = "infineon,slb9635tt";
+ reg = <0x20>;
+ };
for older SLB 9635 devices to your device tree.
tpm_i2c_infineon is also retained as a compatible id as a fallback to
slb9635 protocol.
The driver was tested on Beaglebone.
Signed-off-by: Peter Huewe <peter.huewe@infineon.com>
BUG=chrome-os-partner:17506
TEST=boot on Snow (with SLB9635) and Spring (with SLB9645)
and check tpm_tis_i2c traces in the kernel log.
Change-Id: I1d229a027dad193e7409261ee1039600cd7fdb01
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42332
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Vincent Palatin [Wed, 23 Jan 2013 00:41:26 +0000 (16:41 -0800)]
CHROMIUM: exynos: dts: configure audio codec master clock pin
On Spring, the I2S0 clock is connected to MCLK2/GPIO3 instead of MCLK1.
Explicitly configure the pin on boards I have tested and let the sane
default value (MCLK1 as before) for others.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17343
TEST=emerge-daisy_spring chromeos-kernel
play sound on Snow with the codec on MCLK1, on Spring proto-1 with the
codec on MCLK2.
Change-Id: I9792dc325bea67e9466cff04576d9a3bbcea4eb1
Reviewed-on: https://gerrit.chromium.org/gerrit/41790
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Wed, 23 Jan 2013 00:41:26 +0000 (16:41 -0800)]
CHROMIUM: ASoC: max98095 - allow to select MCLK source
The codec clock can come from either MCLK1 or MCLK2 pin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17343
TEST=emerge-daisy_spring chromeos-kernel
play sound on Snow with the codec on MCLK1, on Spring proto-1 with the codec
on MCLK2.
Change-Id: Ic82158c63f8fb5c8eb00771e9a1cbf186d561670
Reviewed-on: https://gerrit.chromium.org/gerrit/41876
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
John Sheu [Mon, 28 Jan 2013 23:36:21 +0000 (15:36 -0800)]
CHROMIUM: Fix DMABUF exporting for v4l2-m2m
<UPSTREAM MERGE NOT REQUIRED>
v4l2-mem2mem uses a constant offset to mmap to distinguish between input
and output queues. VIDIOC_EXPBUF should take this into account when
exporting a buffer as a DMABUF.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow, unittests
Change-Id: Id7770666775a78c3e11b3d158052a81f67592c8f
Reviewed-on: https://gerrit.chromium.org/gerrit/42179
Commit-Queue: John Sheu <sheu@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
John Sheu [Wed, 30 Jan 2013 05:27:07 +0000 (21:27 -0800)]
CHROMIUM: v4l2-mem2mem: Implement dmabuf mmap for videobuf2-dma-contig
videobuf2-dma-contig buffers already allow DMABUF exporting; now hook up
the mmap functions for these DMABUFs.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow
Change-Id: Ia415c037b1fe9d1a18a86b1315f6945849940369
Reviewed-on: https://gerrit.chromium.org/gerrit/42296
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Bing Zhao [Mon, 28 Jan 2013 22:27:59 +0000 (14:27 -0800)]
UPSTREAM: mwifiex: do not overwrite error code from lower layer driver
Instead of converting it to a bogus error code -1, we should
return the original error code from lower layer driver. This
error code will be printed so it may give user some clues on
what has happened.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:17015
TEST=tested with the bad unit that fails with error message
"mwifiex_sdio_card_to_host: read iomem failed: -1". Now it says
"mwifiex_sdio_card_to_host: read iomem failed: -84".
Change-Id: I18fa13eb232739a4175e6e37469f3448fb0a58eb
Reviewed-on: https://gerrit.chromium.org/gerrit/42162
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Benson Leung [Fri, 25 Jan 2013 03:49:38 +0000 (19:49 -0800)]
CHROMIUM: Input: cyapa - calibrate command
Add a sysfs property that allows userspace to trigger
a recalibration of the trackpad.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17441
TEST=echo 1 > calibrate
After about a second, the command should return.
Check that the trackpad is responsive.
Change-Id: I17ef8b7960406f9c3230918a18cdf25a0cd84b72
Reviewed-on: https://gerrit.chromium.org/gerrit/41980
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Benson Leung [Mon, 22 Oct 2012 03:53:39 +0000 (20:53 -0700)]
CHROMIUM: Input: cyapa - Read and output max/min baseline vals
Read min and max baseline values back from firmware to check
that the baseline value range is valid for normal usage after
calibration.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17441
TEST=cd /sys/bus/i2c/devices/7-0067/
cat baseline
Check that two numbers are returned :
104 95
The actual values may vary depending depending on condition.
Change-Id: I02f48570f8a0afb78d6587b5a7f6b2cc02cd1b89
Reviewed-on: https://gerrit.chromium.org/gerrit/36213
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Simon Que [Mon, 28 Jan 2013 22:12:33 +0000 (14:12 -0800)]
CHROMIUM: chromeos: update smatch whitelist for x86_64 boards
BUG=chromium-os:37418
TEST="FEATURES=test USE=smatch emerge-$BOARD chromeos-kernel" passes for
BOARD=lumpy and BOARD=stumpy.
Change-Id: I5a8fb067acbe5f4353e56db543c9d1192c67f570
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42157
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Simon Que [Mon, 28 Jan 2013 21:43:52 +0000 (13:43 -0800)]
CHROMIUM: chromeos: Fix bugs in whitelist-update script
- Strip the "kernel/files/" at the beginning of each warning line.
- Strip the double quotation mark at the end of each warning line.
BUG=chromium-os:37418
TEST=run update_smatch_whitelist on new boards, make sure the output
does not contain "kernel/files/" or a terminating double quotation mark.
Change-Id: I3d8caccdf8ad7f849b688313612cb0530626b7e4
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42156
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Stéphane Marchesin [Thu, 24 Jan 2013 03:00:34 +0000 (19:00 -0800)]
CHROMIUM: drm/i915: Improve RC6p stability
When the CPU is loaded and the GPU tries to switch RC6p modes, the GPU
sometimes gets stuck in RC6p mode and doesn't come out of it. I suspect
that our voltage rail is too weak and sometimes falls behind.
This change throttles down the number of RC6p transitions we do to appease it.
The change also disables clock gating which seems to help. Upstream commit
which does that is
0f846f81a154cc1818416918d22939bda73da194
(drm/i915: disable RCBP and VDS unit clock gating on SNB and VL)
I tested this on multiple Link machines for hours. The number of RC6 problems
went down from ~ one every 15 minutes to ~ one every 25 hours. So this is not
a complete solution, but I suspect there might be another, more difficult to
reproduce, problem. In any case it reduces the issue significantly, to the
point where we might be able to forget about it.
I measured the power usage on idle before/after this patch and saw no
difference. Obviously when the GPU load varies, it will consume more power
since it now takes more time to adapt.
Also note that not all machines seem to react equally. Some crash fairly
often, and some less often. So this will improve the situation to different
extents for different people.
BUG=chrome-os-partner:16886,chrome-os-partner:11474
TEST=ran the factory stress test (RunIn.Stress) on multiple Link machines for
TEST=about 100 hours, saw only 4 RC6 crashes.
Change-Id: I1135d90e2a155424388d23c6e0879a210b4a0146
Reviewed-on: https://gerrit.chromium.org/gerrit/42084
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Simon Que [Thu, 17 Jan 2013 00:07:52 +0000 (16:07 -0800)]
CHROMIUM: ata: libata-core: initialize native_sectors in ata_hpa_resize()
Eliminates a compiler warning about uninitialized variable:
"warning: 'native_sectors' may be used uninitialized in this function"
This has been submitted for review upstream, but not yet accepted.
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure the warning doesn't appear
Change-Id: Ic791f8053c468e74445e07a306c76cd9e9e5494b
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41948
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Todd Broch [Fri, 25 Jan 2013 20:56:43 +0000 (12:56 -0800)]
CHROMIUM: config: exynos5: Enable s5m8767.
BUG=chrome-os-partner:16430
TEST=compile kernel successfully see following object files created.
drivers/mfd/s5m-core.o
drivers/mfd/s5m-irq.o
drivers/regulator/s5m8767.o
Change-Id: I29abd49ad7c3cab5370cd5f3f26ec5f7378ae05f
Reviewed-on: https://gerrit.chromium.org/gerrit/42201
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Andrew de los Reyes [Tue, 29 Jan 2013 21:45:16 +0000 (13:45 -0800)]
Revert "HID: magicmouse: Set multi-touch keybits for Magic Mouse"
The issue is this causes Chrome, I think, to consider this device a
touchpad, but since we're using the mouse stack (for the time being)
it breaks scroll.
BUG=chromium-os:38330
TEST=manually tested that Magic Mouse works as expected
This reverts commit
5c1386506de5237373db16f470d54e8a83afe318.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Change-Id: I56f420039252a9c0b4283f5aa9ad68655c305576
Reviewed-on: https://gerrit.chromium.org/gerrit/42252
Reviewed-by: Benson Leung <bleung@chromium.org>
Shawn Nematbakhsh [Mon, 28 Jan 2013 20:12:05 +0000 (12:12 -0800)]
CHROMIUM: usb: add VID/PID of Sierra Wireless Gobi 3000 MC8355 modem.
BUG=chrome-os-partner:17480.
TEST=manual. Verify modem is visible in Chrome OS network manager.
Change-Id: Ie142d8fe2ee67e3cdecaf2e46629680e53e55e1f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42137
Reviewed-by: Ben Chan <benchan@chromium.org>
Sonny Rao [Tue, 29 Jan 2013 21:40:58 +0000 (13:40 -0800)]
CHROMIUM: fix memory leak in request_firmware() error path
request_firmware() will leak memory if it fails to obtain the UMH
lock, fix it.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:17270
TEST=none
Change-Id: Iea9027bb3e53b67418fe70602377c6b1e351d565
Reviewed-on: https://gerrit.chromium.org/gerrit/42249
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Sonny Rao [Tue, 29 Jan 2013 02:14:50 +0000 (18:14 -0800)]
CHROMIUM: remove warning from request_firmware if UMH failed
The UMH failing is a potential consequence of racing with suspend, so
remove the warning but still print the informational message.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:17270
TEST=(needs an autotest test) currently manual:
use the set_short_powerd_timeouts script to all the device to
idle-suspend quickly, wait for an idle suspend with the lid open
(about 30 seconds). Then hit the trackpad and quickly close the lid.
The device should resume and then suspend again within a few seconds
and make sure there's no warning in dmesg from request_firmware()
Change-Id: Iaf46c53e3d5462286130334ca19edc82a0e661dd
Reviewed-on: https://gerrit.chromium.org/gerrit/42247
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Doug Anderson [Fri, 25 Jan 2013 22:27:01 +0000 (14:27 -0800)]
Revert "HACK: arm: exynos: Force 0.8x instead of bypass for VDD_INT"
This reverts commit
466db2af679e46c5ab65c53e38b802a1e4ae3351.
BUG=chrome-os-partner:17442
TEST=With future CL to fix root cause, verify that suspend/resume
work.
Change-Id: Ic48ee710b623d72670db965700c215dfe280d6ea
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42056
Doug Anderson [Sat, 26 Jan 2013 00:01:00 +0000 (16:01 -0800)]
arm: exynos: Fix the ISP Power down sequence
This totally moves the ISP power down configuration to its own
function so we can make sure power sequencing is exactly as the
Samsung HW team suggests. At the moment we're not using the ISP for
anything, so this should be fine.
Following is the suggested power down sequence for ISP:
- 0x10042288 --> 0x10000 (ISP A5 Disable WFE)
- 0x10042280 --> 0x0 (ISP A5 Power Off)
- 0x10041584 --> 0x0 (SYS_PWR_CFG off for CMU_RESET_ISP)
- 0x10044020 --> 0x0 (ISP Block Power Off)
Before this patch our order looks more like:
- 0x10044020 --> 0x0 (ISP Block Power Off)
- 0x10042280 --> 0x0 (ISP A5 Power Off)
- 0x10042288 --> 0x0 (ISP A5 Disable WFI / WFE)
- 0x10041584 --> 0x0 (SYS_PWR_CFG off for CMU_RESET_ISP)
We now match the suggested order except that we actually write
0x10042288 as 0x0 to disable WFE and WFI. This matches what was set
to the register before this patch and has been OKed by the Samsung LSI
hardware team.
BUG=chrome-os-partner:15327
BUG=chrome-os-partner:17442
TEST=Revert 0.8 ABB (see Ic48ee710b623d72670db965700c215dfe280d6ea)
and then use suspend_at_boot.conf script from chrome-os-partner:15327
comment #71 to test on a device that had suspend/resume problems
without this.
Change-Id: Ia3bb141a6c94a6b3656944b6b3a2f1e0645adf8d
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42067
Sonny Rao [Fri, 25 Jan 2013 23:31:17 +0000 (15:31 -0800)]
Revert "PM / Sleep: Mitigate race between the freezer and request_firmware()"
This reverts commit
247bc03742545fec2f79939a3b9f738392a0f7b4.
This patch caused a deadlock between khubd and the suspend process.
This was reliably reproducible when we did a suspend immediately after
a resume, and the khubd kernel thread was busy probing USB devices.
The sequence was that khubd would be running and probing USB devices
when we try to suspend and the freezer would activate, and eventually
khubd would call request_firmware() while holding a device lock, and
request_firmware would call usermodehelper_read_trylock().
Because the UMH is in state UMH_FREEZING, usermode_helper_read_trylock
would end up calling try_to_freeze() and would then be frozen while
holding a device lock. After the freezer finished, it would then try
to suspend each device and would deadlock on the USB hub device that
was being held by khubd.
Reverting this merely results in a WARN_ON from request_firmware() and
no deadlock, and upon the subsequent resume, khubd will successfully
get the firmware and the devices work correctly.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:17270
TEST=(needs an autotest test) currently manual:
use the set_short_powerd_timeouts script to all the device to
idle-suspend quickly, wait for an idle suspend with the lid open
(about 30 seconds). Then hit the trackpad and quickly close the lid.
The device should resume and then suspend again within a few seconds.
Change-Id: Idfc5d40f0f1cc88ca335502454bf675f152df477
Reviewed-on: https://gerrit.chromium.org/gerrit/42190
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Benson Leung [Mon, 28 Jan 2013 23:26:25 +0000 (15:26 -0800)]
CHROMIUM: Input: atmel_mxt_ts - Set T9 in mxt_resume based on lid state
This is an x86 specific change for the short term.
When the lid is closed on resume, make sure T9 is disabled.
to prevent the lid from affecting the touch device and causing
stray touches. If lid is open, restore operational settings for T9.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=Close the lid to suspend in guest mode.
Open the lid slowly, until you see the lights indicating resuming.
Close the lid immediately upon seeing the system resume from
the status light.
The system should stay in S0. Check via ssh:
cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object
Check that T9 is 0x00.
On a normal suspend/resume, where the lid is opened,
check that touch device is functional.
Change-Id: Ibce1c8c000e4bd2a8f360bea2b116051eee35be7
Reviewed-on: https://gerrit.chromium.org/gerrit/42184
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Benson Leung [Mon, 28 Jan 2013 23:31:26 +0000 (15:31 -0800)]
CHROMIUM: Input: atmel_mxt_ts - Disable T9 on mxt_stop
Instead of using 0x81 to keep the object enabled,
disable T9 on mxt_stop by writing 0x00 to it.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=stop powerd (on R25 also stop powerm)
close the lid, or use a magnet to trigger the lid sensor.
cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object
Look for Type: 9, byte 0. Check that this is 0x00
when lid is closed. When opened, this should return
to 0x83.
Change-Id: If794e121d1b61186fee9e5b9f97b922549d7beb8
Reviewed-on: https://gerrit.chromium.org/gerrit/42183
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Benson Leung [Sat, 26 Jan 2013 01:45:56 +0000 (17:45 -0800)]
CHROMIUM: Input: atmel_mxt_ts - mxt_stop on lid close
This is an x86 specific change for the short term.
When the lid is closed, issue an mxt_stop to turn off scanning
to prevent the lid from affecting the touch device and causing
stray touches.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17465
TEST=From test mode, run evtest, and watch the atmel_mxt device.
Close and open the lid. Make sure there are no touch data comes
from the atmel driver when the lid is being closed.
Change-Id: I2163384fc7cbd45c63d05983c50d2a869975a3c9
Reviewed-on: https://gerrit.chromium.org/gerrit/42080
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Simon Que [Thu, 17 Jan 2013 19:24:50 +0000 (11:24 -0800)]
UPSTREAM: net: usb: initialize tmp in dm9601.c to avoid warning
In two places, tmp is initialized implicitly by being passed as a
pointer during a function call. However, this is not obvious to the
compiler, which logs a warning.
Cherry-picked from
15c8bb1284c2e4b0614274602f0d92c4ea3412df in net-next
repo at git.kernel.org.
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure no warnings in dm9601.c
Signed-off-by: Simon Que <sque@chromium.org>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change-Id: Id108c847f9040478e7535eff448958a99ac8700f
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41658
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Wed, 16 Jan 2013 23:23:38 +0000 (15:23 -0800)]
CHROMIUM: media: tuners: init fw and hw ids to 0 in xc4000.c
In xc4000.c's check_firmware() function, these variables are later
initialized by passing them to xc_get_version() as pointers. However,
this results in a compile error that these are not initialized since it
is not explicit.
This patch initializes them to zero. These may or may not be valid
values, but these variables are not used unless xc_get_version() returns
successfully so their initial values aren't important anyway.
I sent this upstream. It may or may not get accepted, but the directory
structure has changed, so this patch won't apply cleanly when we move to
kernel-next.
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure xc4000.c has no warnings.
Change-Id: I66592ecfb09e36a692329e3ee5c3d1cb3394a2ae
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41473
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Kees Cook [Sat, 19 Jan 2013 06:06:50 +0000 (22:06 -0800)]
CHROMIUM: LSM: spinlock the root directory lock
Since module loading routines can be called simultaneously, initialization
of the LSM's root directory lock must be mutexed.
BUG=chrome-os-partner:17321
TEST=link build, manual testing
Change-Id: I8a6e317ea887d535770f5c8617406bf83c06c2e2
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41687
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Sean Paul [Fri, 25 Jan 2013 22:09:04 +0000 (17:09 -0500)]
CHROMIUM: drm/exynos: dp: Add force_connected flag
Add a new flag to the DisplayPort platform data to optionally force
is_connected to return true. This is useful for cases such as ours where
we don't have a proper DP monitor connected, but rather a noisy bridge
that doesn't know when it's actually ready to assert hotplug.
This will also prevent drm from assuming we're disconnected and detaching
our encoder from the connector (thus losing us forever as a result of
the interrupt scheme in the driver, which needs to be fixed).
BUG=chromium-os:38006
TEST=Tested manually using Doug's reproduction instructions in c17 on the bug
Change-Id: If2034458d9de93259e92a0f3eb8f386c340b0d7d
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42042
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Shawn Nematbakhsh [Tue, 15 Jan 2013 17:50:29 +0000 (09:50 -0800)]
Revert "BACKPORT: r8169: enable internal ASPM and clock request settings"
This reverts commit
d6a3750eef2e494e2f78160c5f8b37a7d810bff7.
The original change had the undesired side-effect of delaying link
status detection, and no acceptable solution was found.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
BUG=chrome-os-partner:16247.
TEST=manual. Test ethernet plug/unplug, verify no delay in link status
detect.
Change-Id: I7b7c312a47d065fd25c61949f71436cfe6cbc985
Reviewed-on: https://gerrit.chromium.org/gerrit/41287
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Chih-Chung Chang [Wed, 16 Jan 2013 03:28:56 +0000 (11:28 +0800)]
CHROMIUM: ALSA: hda/ca0132 - Add key-click reduction feature.
This patch is provided by Creative.
BUG=chrome-os-partner:17241
TEST=check there is an additional mixer control in "alsamixer -c 0"
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Change-Id: Ifcb523a234d0d7ee9908911714b90dbcc4783ec1
Reviewed-on: https://gerrit.chromium.org/gerrit/41349
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Kees Cook [Tue, 18 Dec 2012 00:03:14 +0000 (16:03 -0800)]
UPSTREAM: /proc/pid/status: add "Seccomp" field
It is currently impossible to examine the state of seccomp for a given
process. While attaching with gdb and attempting "call
prctl(PR_GET_SECCOMP,...)" will work with some situations, it is not
reliable. If the process is in seccomp mode 1, this query will kill the
process (prctl not allowed), if the process is in mode 2 with prctl not
allowed, it will similarly be killed, and in weird cases, if prctl is
filtered to return errno 0, it can look like seccomp is disabled.
When reviewing the state of running processes, there should be a way to
externally examine the seccomp mode. ("Did this build of Chrome end up
using seccomp?" "Did my distro ship ssh with seccomp enabled?")
This adds the "Seccomp" line to /proc/$pid/status.
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: James Morris <jmorris@namei.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=None
TEST=stout build, "Seccomp" field visible in "status" file
(cherry picked from commit
2f4b3bf6b2318cfaa177ec5a802f4d8d6afbd816)
Change-Id: I9200bf8e7535055e5a849548eb6199812d69b6d8
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41959
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Fri, 25 Jan 2013 00:10:21 +0000 (16:10 -0800)]
chromeos: Clarify comment in smatch script
BUG=chromium-os:37418
TEST=None
Change-Id: I8aa198a95efbe935ec16806383be37bc52318f27
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41973
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Chee Kin Cheong [Wed, 23 Jan 2013 12:44:28 +0000 (04:44 -0800)]
CHROMIUM: ALSA: hda/ca0132 - configure DMIC gain block.
Configure the DMIC input gain block when switching to use DMIC. This
provides 20dB of additional input gain when using the built-in digital
microphone.
This should be changed to export a control to user-space, but keep it
simple for the R25 release.
BUG=chrome-os-partner:16865
TEST=arecord a reference signal and check that there is now 20dB of
gain applied. Hangout and check that the participant on the other
side can hear you.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I2a748f5774e50e513b1107fc3119641aa227453b
Reviewed-on: https://gerrit.chromium.org/gerrit/41816
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Shawn Nematbakhsh [Thu, 24 Jan 2013 05:18:06 +0000 (21:18 -0800)]
UPSTREAM: SCSI & usb-storage: add try_rc_10_first flag
Several bug reports have been received recently for USB mass-storage
devices that don't handle READ CAPACITY(16) commands properly. They
report bogus sizes, in some cases becoming unusable as a result.
The bugs were triggered by commit
09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add
flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
overriding the SCSI level reported by devices. By default, the sd
driver will try READ CAPACITY(16) first for any device whose level is
above SCSI_SPC_2.
It seems likely that any device large enough to require the use of
READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
CAPACITY(10) commands properly. Indeed, I don't know of any devices
that don't handle READ CAPACITY(10) properly.
Therefore this patch (as1559) adds a new flag telling the sd driver
to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
for every USB mass-storage device. If a device really is larger than
2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
This fixes Bugzilla #43391.
BUG=chrome-os-partner:16619
TEST=Manual. Build recovery image on previously failing USB disk, verify
recovery install on generic x86 platform.
Change-Id: I82899c04e2f2b65292a8f55505b347a2b72f8f6e
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Hans de Goede <hdegoede@redhat.com>
CC: "James E.J. Bottomley" <JBottomley@parallels.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41913
Abhilash Kesavan [Fri, 18 Jan 2013 06:47:43 +0000 (12:17 +0530)]
HACK: arm: exynos: Force 0.8x instead of bypass for VDD_INT
Increase the INT voltage margins for all speed groups. According to
the h/w guys at Samsung this is fine except for a power increase. At
the moment this is considered an interrim (but safe) fix while Samsung
looks for a root cause.
Side notes:
* ABB 1.0x appears to work better than bypass (which makes no sense)
but still doesn't work as well as ABB 0.8x (this patch).
* ABB 1.2x also appears to work. It ran 690 cycles of the test below
before I stopped it.
* Leaving ABB off and increasing VDD_INT also appears to work to some
extent, but not as well as this patch.
BUG=chrome-os-partner:15327
TEST=Run the following test on a device that fails 100% without
this patch:
1. Reboot
2. suspend_stress_test -c5 --backup_rtc
3. Goto step 1
With this patch I went through 728 cycles of the above with no
hangs at suspend. Testing was done via an init script that is
attached at comment #71 of the referenced bug.
TEST=Run the above test on several devices that have no problems
without this patch. Confirm that this patch doesn't introduce
additional suspend/resume problems.
TEST=General stability testing should be performed.
Change-Id: I5925ace16e7bc00207f2218c4ccb4cc6453ec44a
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41711
Sean Paul [Wed, 23 Jan 2013 18:55:05 +0000 (13:55 -0500)]
drm/exynos: Reset mixer when we dpms off
Reset the mixer when we power off, this will perform a soft reset on the
IP block and disable IRQs.
BUG=chromium-os:37797
TEST=Tested by hand with DRM_ERROR logging. Made sure IRQ no longer
fires after dpms off.
Change-Id: I35a438b07085173776257bba93ffe603d096f2be
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41835
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Che-Liang Chiou [Wed, 16 Jan 2013 00:06:52 +0000 (16:06 -0800)]
HID: magicmouse: Set multi-touch keybits for Magic Mouse
The driver emits multi-touch events for Magic Trackpad as well as Magic
Mouse, but it does not set keybits that are related to multi-touch event
for Magic Mouse; so set these keybits.
The keybits that are not set cause trouble because user programs often
probe these keybits for self-configuration and thus they cannot operate
properly if the keybits are not set.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chromium-os:36322
TEST=On Snow, connect Magic Mouse and perform 2-finger scroll.
Check /var/log/Xorg.0.log and does not see error message of
"Too many fingers! Max is 1, but I got 2"
Change-Id: Ie7fd4327935555f41577e2c8c6d6d78b52934f1a
Reviewed-on: https://gerrit.chromium.org/gerrit/41322
Commit-Queue: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Benson Leung [Tue, 22 Jan 2013 23:25:44 +0000 (15:25 -0800)]
CHROMIUM: chromeos_laptop : Remove cyapa device on link
The cyapa device is no longer being used on this platform.
Remove from chromeos_laptop so we don't throw a warning
on systems with atmel pads.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17372
TEST=Check that the touchpad works normally.
Check that the following warning doesn't appear in dmesg :
__add_probed_i2c_device failed to register device 1-67
Change-Id: Iac9adb7f42cc5836c2831b4cee8167ab482dae24
Reviewed-on: https://gerrit.chromium.org/gerrit/41782
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Vic Yang [Sat, 19 Jan 2013 06:39:04 +0000 (14:39 +0800)]
CHROMIUM: exynos: dts: Update PS8622 bridge address
The bridge is now at 0x8 instead of 0x48.
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=none
TEST=See display on Spring.
Change-Id: I4903824d401c5ac46cc101ec39b5c6f01809d1db
Reviewed-on: https://gerrit.chromium.org/gerrit/41689
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Sean Paul [Fri, 18 Jan 2013 16:37:00 +0000 (11:37 -0500)]
CHROMIUM: HACK: drm/i915: Don't warn on pin_count < 0
We've had some warnings on resume with an external monitor connected
where the pin_count for the fb's fence register is less than zero. After
some analysis, we're unpinning it twice on resume, once via set_base on
mode_set and then again when we do an rmfb from userspace.
The warning isn't terribly interesting when pin_count is less than zero,
and the relevant code has been refactored upstream such that it's likely
not an issue any longer.
This hack avoids warning when pin count is negative.
BUG=chrome-os-partner:12670
TEST=Tested manually with link connected to DP display. Idle
suspend/resume and check the logs for WARNING.
Change-Id: Idba3e75e48d085faa5bff5f7f165eaef595829be
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41639
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Benson Leung [Sat, 19 Jan 2013 01:35:52 +0000 (17:35 -0800)]
CHROMIUM: Input: atmel_mxt_ts : Set power/wakeup to disabled by default.
Userspace will change it to enabled if needed.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17336
TEST=cat /sys/bus/i2c/devices/2-004a/power/wakeup
Check that it returns "disabled"
Suspend the system using powerd_suspend.
Check that the touch device 2-004a does not wake the system.
Change-Id: If5ac3b30c137d16e5592d4a2ee555fd2533b0caa
Reviewed-on: https://gerrit.chromium.org/gerrit/41679
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Benson Leung [Sat, 19 Jan 2013 01:35:19 +0000 (17:35 -0800)]
CHROMIUM: Input: atmel_mxt_ts : On Tpads, enable T42, disable T19 on suspend
To work around an issue where an idle-suspended system may wake
unnecessarily when the lid is closed because the B panel comes close to
the trackpad, enable touch suppression (t42) when suspending. Also
disable T19, for the button, to allow the button to be pressed if
the case is flexed without the system waking.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17336
TEST=1. Suspend the system with powerd_suspend with lid open.
2. Touch the touchpad. Make sure the system still wakes.
3. Suspend again with powerd_suspend
4. Close the lid. Ensure the system does not wake by observing the system
status light.
Change-Id: I858af27e65ce491c8eb99f5b8db13ea91f789f3e
Reviewed-on: https://gerrit.chromium.org/gerrit/41678
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Simon Que [Fri, 11 Jan 2013 01:14:37 +0000 (17:14 -0800)]
CHROMIUM: chromeos: Add script to update smatch error whitelist
This script can be used to add known smatch errors for new boards to the
smatch error whitelist. It runs the kernel build and check for each new
board and aggregates the new errors into a log file.
BUG=chromium-os:37418
TEST=Run "./update_smatch_whitelist x86-generic amd64-generic daisy"
Make sure there was a log file produced containing new errors.
Change-Id: I6912b6a0d9b9d577af296b15ef1e356e55a9f3ce
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41079
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 17 Jan 2013 02:04:52 +0000 (18:04 -0800)]
BACKPORT: fs: ecryptfs: initialize payload_len in keystore.c
This is meant to remove a compiler warning. It should not make any
functional change.
payload_len should be initialized when it is passed to
write_tag_64_packet() as a pointer. If that call fails, this function
should return early, and payload_len won't be used.
The warning is:
fs/ecryptfs/keystore.c:1168:28: warning: 'payload_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
BUG=chromium-os:5542
TEST=emerge-x86-generic chromeos-kernel, this warning should not appear.
Change-Id: Ia4fb282b3b32eadecc7d2756c6a701864480618b
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41580
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Mandeep Singh Baines [Tue, 18 Dec 2012 18:54:12 +0000 (10:54 -0800)]
CHROMIUM: drm/exynos: use flip_desc queue to track page flips
The data structures and code used to manage page flips are
starting to get hairy and difficult to reason about. Let's
simplify things by using a simple queue of flip descriptors.
BUG=chrome-os-partner:15241
TEST=Multiple VT switch, sign in/out, suspend, idle suspend,
WebGL. Tested with HDMI and without.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I318a13881241406d72045b3b25428d332c63593b
Reviewed-on: https://gerrit.chromium.org/gerrit/39935
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Mandeep Singh Baines [Fri, 7 Dec 2012 19:27:46 +0000 (11:27 -0800)]
CHROMIUM: drm/exynos: fix refcounting in hdmi (mixer) path
Previously, if two fbs were ready to be flipped during the same
vblank, the kds_callback would drop the frame which came earlier
and call apply on the later frame. This worked fine on fimd but
caused problems on hdmi (mixer). The mixer will only accept one
apply call per vblank and ignore calls after that.
Since, we already applied the earlier frame, the mixer would
ignore the later frame. So the mixer flips the earlier fb while
the refcounting code thinks we are flipping the later fb. So the
ref for the earlier fb gets dropped even though its the scanout
fb. This can cause an IOMMU page fault.
The fix is to hold the later fb in an extra slot and then flip
to it on the next vblank.
In order, to allow calling apply from finish_page_flip, I had to
re-structure mixer_irq_handler in order to avoid spinlock
recursion on reg_slock.
BUG=chrome-os-partner:15241
TEST=see below
Before:
$ DISPLAY=:0.0 xrandr --output eDP-1 --off
* crash *
After:
export DISPLAY=:0.0
for i in `seq 20`; do
xrandr --output eDP-1 --off;
sleep 5;
xrandr --output eDP-1 --auto;
sleep 5;
done
* no crash *
Change-Id: I45cdad3dea94c9018e6a5fef9f9807b225130cea
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39386
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Bing Zhao [Fri, 18 Jan 2013 01:58:03 +0000 (17:58 -0800)]
UPSTREAM: mwifiex: correction in status codes used for association failure
When AP responds with appropriate status code, we forward that
code correctly to cfg80211. But sometimes when there is no
response from AP, our firmware uses proprietary status codes.
We will map authentication timeout to WLAN_STATUS_AUTH_TIMEOUT
and other proprietary codes to WLAN_STATUS_UNSPECIFIED_FAILURE.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
BUG=chrome-os-partner:14966
TEST=check driver/wpa_supplicant logs and confirm that status
code 16 is informed for "status code=2 err=0xfffc a_id=0xffff"
authentication timeout and status code 1 is informed for
"status code=1 err=0xfffc a_id=0xffff" association timeout.
Change-Id: I8892b51073e41fe0f2db908a0f60046a806e1338
Reviewed-on: https://gerrit.chromium.org/gerrit/41611
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
Daniel Kurtz [Tue, 8 Jan 2013 17:31:02 +0000 (01:31 +0800)]
CHROMIUM: drm/exynos: fb: Don't take reference when mapping fb's gem objects
The fb itself already takes a reference for all of its gem objects when
it is created, and releases them last when it is destroyed. Taking an
additional reference when the gem objects are mapped into device memory,
which only happens when the fb is created, seems redundant.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium-os:37097
TEST=builds clean; sanity check on device
Change-Id: I63643e974a8cf7d04d32b96bebd5dad4cc281ba8
Reviewed-on: https://gerrit.chromium.org/gerrit/40448
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Simon Que [Thu, 17 Jan 2013 00:19:26 +0000 (16:19 -0800)]
CHROMIUM: bluetooth: initialize rfc struct in l2cap_core.c
Removes warnings:
warning: 'rfc.max_pdu_size' may be used uninitialized in this function
warning: 'rfc.monitor_timeout' may be used uninitialized in this function
warning: 'rfc.retrans_timeout' may be used uninitialized in this function
warning: 'rfc.mode' may be used uninitialized in this function
This is based on (but not compatible with) an upstream patch:
c20f8e35ca8b0583323d310ec63a0f0d17cfdcf5
This patch can be discarded when moving to kernel-next
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure l2cap_core has no warnings
Change-Id: I564eca4421a6c4f8f4dcddfacd56e0d574885596
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41481
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 17 Jan 2013 19:44:47 +0000 (11:44 -0800)]
BACKPORT: hid: Fix uninitialized variable "size" in hid-wiimote-debug
This variable is initialized conditionally, based on whether a wiimote
call succeeds. However, the logic is not obvious to the compiler so it
throws a warning. Eliminate the warning by initializing "size" to 0.
The warning is:
files/drivers/hid/hid-wiimote-debug.c:69:18: warning: 'size' may be used
uninitialized in this function [-Wmaybe-uninitialized]
BUG=chromium-os:5542
TEST=emerge-daisy chromeos-kernel, make sure this warning doesn't appear
Change-Id: I63896a2dd9e08cfd25b25b81d447c7fe9baeae2f
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41558
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Sameer Nanda [Wed, 16 Jan 2013 22:27:37 +0000 (14:27 -0800)]
drm/i915: Honor i915_min_freq post resume
The i915_min_freq setting was not getting honored on the resume path.
Fixed it.
BUG=chrome-os-partner:16439
TEST="cat /sys/kernel/debug/dri/0/i915_min_freq" and remember the value
returned. Do a suspend/resume cycle. cat the i915_min_freq file again,
it must return the same value as read earlier.
Change-Id: Ie3cc8e8794a59c154b511e24e468daef94a44765
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41461
Simon Que [Wed, 16 Jan 2013 23:05:52 +0000 (15:05 -0800)]
BACKPORT: [media] uvcvideo: Fix a "ignoring return value of '__clear_user'" warning
Pulling in commit
57fb4a4831793de9e8dbdfc8dc5eb8796026d47e from
kernel-next/upstream.
Note that the directory structure has changed upstream, so that patch
does not apply to kernel-3.4 anymore.
This removes the warning:
src/third_party/kernel/files/drivers/media/video/uvc/uvc_v4l2.c:1100:14:
warning: ignoring return value of '__clear_user', declared with
attribute warn_unused_result [-Wunused-result]
BUG=chromium-os:5542
TEST=build kernel and make sure uvc_v412.c does not have this warning.
Change-Id: If4d80dcf79a750fd9b812ffe925875be9b809ec7
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41470
Reviewed-by: David James <davidjames@chromium.org>
Simon Que [Wed, 16 Jan 2013 23:55:50 +0000 (15:55 -0800)]
CHROMIUM: sound/pci/hda: fix warnings in patch_ca0132.c
These problems were introduced by us and not by upstream.
In chipio_send():
There should be a space between "KERN_ERR" and the following string.
In dspio_send_scp_message():
int retry is never used, so remove it.
In resume_mic1():
There is no return value. Change to return void.
In ca0132_update_latency():
Do not mix variable declarations and code.
idata_read() is not used, so remove it.
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure there are no warnings in patch_ca0132.c
Change-Id: I40a877605eb38736521b3c6335dc0801b36e883f
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41480
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Oliver Hartkopp [Sun, 25 Mar 2012 06:43:24 +0000 (08:43 +0200)]
BACKPORT: iwlwifi: fix unused variable warning
In the case of disabled CONFIG_IWLWIFI_DEBUGFS option the compiler complains
about the unused variable 'img'. Fix this by moving the 'img' definition.
Taken from kernel-next commit
a855f7ee64fedbe831859d53b20650c2224afecc
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, make sure no warnings in iwl-mac80211.o
Change-Id: I34bcd89a9d96a5baecf064c39ee34bc6e25c9c92
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41487
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Dylan Reid [Thu, 17 Jan 2013 04:29:23 +0000 (20:29 -0800)]
CHROMIUM: ALSA: ASoC: max98095 - disable analog inputs to speaker mux.
ChromeOS only ever uses the DAC1 input, and routing the analog inputs
can be harmful (since they are actually DMIC inputs on Lucas).
BUG=chromium-os:37217
TEST=in dev mode run alsamixer and check available Speaker mux inputs.
Change-Id: I77c5b2a829e8c63035ac8006fa8eca722ed50dd0
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41510
Reviewed-by: Evan Ragsdale <evan.ragsdale@maximintegrated.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Simon Que [Thu, 17 Jan 2013 00:37:55 +0000 (16:37 -0800)]
CHROMIUM: platform/x86: chromeos_acpi: cast sizeof(array) to u32 before use
Removes a compiler warning:
"comparison of distinct pointer types lacks a cast"
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, should not see warnings in chromeos_acpi.o
Change-Id: Ia4779db9d30bd0a1206fe339d682d56411f6105b
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41483
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Simon Que [Thu, 17 Jan 2013 02:25:57 +0000 (18:25 -0800)]
CHROMIUM: cpufreq: explicit typecasts in cpufreq_interactive.c
BUG=chromium-os:5542
TEST=emerge chromeos-kernel, no warnings in cpu_interactive.o
Change-Id: I3d4a0f6dc47edf21108303fabcba59130a05b899
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41499
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Stuart Abercrombie [Thu, 17 Jan 2013 00:52:17 +0000 (16:52 -0800)]
Reiplace HDMI unplug polling with HPD line reading.
It looked as if this didn't work at the HW level, but it actually does.
Polling cost us about 100mW if an HDMI monitor was attached.
This also responds more quickly to unplugging.
Based on upstream change:
http://lists.freedesktop.org/archives/intel-gfx/2012-December/023314.html
BUG=chromium-os:37674
TEST=HDMI hotplug works and responds immediately
Change-Id: I9e88671b1ac0e6204feda2666608f30427c8bb79
Reviewed-on: https://gerrit.chromium.org/gerrit/41474
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stuart Abercrombie <sabercrombie@chromium.org>
Commit-Queue: Stuart Abercrombie <sabercrombie@chromium.org>
Paul Stewart [Wed, 16 Jan 2013 23:00:17 +0000 (15:00 -0800)]
Revert "CHROMIUMOS: mwifiex: Disable transmit aggregation"
New firmware fixes this issue, so this change is no longer necessary.
This reverts commit
6fcfecca9575848120e8c9e35b3ad848b1e85f29
BUG=chrome-os-partner:16279
TEST=Associate with Android AP
Change-Id: Id0542875bc599bf5da23cdeb0da57739cc60c44d
Reviewed-on: https://gerrit.chromium.org/gerrit/41467
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Stéphane Marchesin [Wed, 16 Jan 2013 19:53:04 +0000 (11:53 -0800)]
Revert "Revert "drm/i915: Mark the FB's bo as busy when we pageflip""
This reverts commit
edf0e91c645c10f00f1fb3e5b86bac132d27d9e7.
We previously reverted it because we thought this might cause test
crashes, but it is not the case, so let's reland this change for
good.
BUG=chromium-os:37791
TEST=compiles, works on Alex.
Change-Id: I7dcf708ef5c601e463f10929b802d0682a8be853
Reviewed-on: https://gerrit.chromium.org/gerrit/41460
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Ilja H. Friedel <ihf@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
Tested-by: Ilja H. Friedel <ihf@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Simon Que [Fri, 21 Dec 2012 00:40:48 +0000 (16:40 -0800)]
CHROMIUM: Add file containing known smatch errors
This file contains the known smatch errors in the kernel. Currently it
contains only the errors from i386 boards (i.e. 32-bit x86). In the
future we should add errors from x86_64 and arm boards.
BUG=chromium-os:37418
TEST="FEATURES=test emerge-mario chromeos-kernel" runs successfully
CQ-DEPEND=I9d1f11d00c7852c68d26d0b696bb28e47573e154
Change-Id: If47037fc31960933d18eec5825c996a2035f8f48
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/40056
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Mandeep Singh Baines [Tue, 8 Jan 2013 00:06:09 +0000 (16:06 -0800)]
gpu: vithar: remove unused functions
Fixes the following warnings:
drivers/gpu/arm/t6xx/kbase/src/linux/config/tpip/mali_kbase_config_exynos5.c:180:12: warning: 'pm_callback_runtime_power_on' defined but not used [-Wunused-function]
drivers/gpu/arm/t6xx/kbase/src/linux/config/tpip/mali_kbase_config_exynos5.c:193:13: warning: 'pm_callback_runtime_power_off' defined but not used [-Wunused-function]
drivers/gpu/arm/t6xx/kbase/src/linux/config/tpip/mali_kbase_config_exynos5.c:1213:13: warning: 'kbase_platform_runtime_term' defined but not used [-Wunused-function]
drivers/gpu/arm/t6xx/kbase/src/linux/config/tpip/mali_kbase_config_exynos5.c:1222:19: warning: 'kbase_platform_runtime_init' defined but not used [-Wunused-function]
BUG=chromium-os:5542
TEST=compile,run
Change-Id: Ieb911fe7566ab177eee8c03877ba5753a768cb5f
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/40570
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
projects / cascardo / linux.git / log