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>
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.
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.
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>
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.
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
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>
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()
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.
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.
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.
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.
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.
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.
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>
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>
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.
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
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.
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.
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"
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
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.
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.
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>
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>
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.
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 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.
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>
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>
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>
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>
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.
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]
As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:
if ((all_iftypes & used_iftypes) != used_iftypes)
goto cont;
However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
when we bring up a ADHOC wlan with commands similar to:
# iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up
In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below fixes the issue:
if (total == 1)
return 0;
But it also introduces other dependencies for stable. For example,
a full cherry pick of 8e8b41f9d8c8e would introduce additional
regressions unless we also start cherry picking driver specific
fixes like the following:
9b4760e ath5k: add possible wiphy interface combinations 1ae2fc2 mac80211_hwsim: advertise interface combinations 20c8e8d ath9k: add possible wiphy interface combinations
And the purpose of the 'if (total == 1)' is to cover the specific
use case (IBSS, adhoc) that was mentioned above. So we just pick
the specific part out from 8e8b41f9d8c8e here.
Doing so gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.
Cc: stable@vger.kernel.org Signed-off-by: Liang Li <liang.li@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Change-Id: Ib81e4382f283752acbd7be03f9c49d5d92511400
BUG=chrome-os-partner:16305
TEST=Boot, login as user, join an IBSS network, run suspend-resume test or
close the lid for few seconds and then open the lid. Check dmesg for WARNINGS. Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org> Tested-by: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41294 Reviewed-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: ath9k: Fix a WARNING on suspend/resume with IBSS
this patch is dependent on the patch "cfg80211: fix interface
combinations"
In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC. we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.
The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.
ath: phy0: Cannot create ADHOC interface when other
interfaces already exist.
WARNING: at net/mac80211/driver-ops.h:12
ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
Hardware name: 2842RK1
wlan2: Failed check-sdata-in-driver check, flags: 0x0
Cc: stable@vger.kernel.org Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Change-Id: I7edce69980a59b83f67c24cbf2b02e62ce5525c3
BUG=chrome-os-partner:16305
TEST=Boot, login as user, join an IBSS network, run suspend-resume test or
close the lid for few seconds and then open the lid. Check dmesg for WARNINGS. Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org> Tested-by: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41293 Reviewed-by: Paul Stewart <pstew@chromium.org>
If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.
Cc: stable@kernel.org Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Change-Id: I46925dac512f669f5431861a8e5153e24c9afb08
BUG=chrome-os-partner:16305
TEST=Boot, login as user, join an IBSS network, run suspend-resume test or
close the lid for few seconds and then open the lid. Check dmesg for WARNINGS. Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org> Tested-by: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41292 Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: drm/exynos: drop fb reference in page_flip error path
Commit "CHROMIUM: drm/exynos: Fix fb refcounting", moved the
exynos_drm_fb_get before the kds failure check. To avoid a leak,
we need to drop the reference if kds fails.
Kees Cook [Wed, 2 Jan 2013 21:36:02 +0000 (13:36 -0800)]
CHROMIUM: test_nx: make test_nx work again
This makes test_nx work again (has been broken 2.6.28). Can't upstream at
the moment, since upstream (after 3.6) changed module exception handlers
to be relative, which makes it impossible to represent stack and heap
exceptions on 64-bit. For now, though, we are able to use it for
autotest to evaluate our x86 kernels.
Make sure to always call get before put on the fb. Before this
patch, there is a window where we can put before get if the
callback triggers right away (or if the interrupt triggers quickly
enough). We fix this by taking the reference on the fb before we
setup the async waiting.
BUG=chrome-os-partner:16069
TEST=by hand, compiles and runs (but I was never able to repro the issue)
Change-Id: Iedde277c8f9cfebf6c4f6b0675e4d3bace52f637
Reviewed-on: https://gerrit.chromium.org/gerrit/41238 Tested-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
We are trying to nail down the cause for a recent series of test
crashes in Chrome. Since this is basically the only graphics
change in that time frame, let's try to revert this for a couple
of days and see if our tests heal.
BUG=chromium-os:37791
TEST=compiles, works on Alex.
Change-Id: I5a1086389be56ca2603371b4f89d7a1e3d2d74ee
Reviewed-on: https://gerrit.chromium.org/gerrit/41263 Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Ilja H. Friedel <ihf@chromium.org> Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
John Sheu [Thu, 13 Dec 2012 01:35:08 +0000 (17:35 -0800)]
CHROMIUM: v4l2-m2m: drop rdy_queue on STREAMOFF
When a v4l2-m2m context gets a STREAMOFF call on either its CAPTURE or
OUTPUT queues, we should:
* Drop the corresponding rdy_queue, since a subsequent STREAMON expects
an empty queue.
* Deschedule the context, as it now has at least one empty queue and
cannot run.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chrome-os-partner:10057
TEST=build, run on exynos
Change-Id: Id3994907ccb6a6ee7af187e0a5d3e55cda94c76b
Reviewed-on: https://gerrit.chromium.org/gerrit/39643 Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org> Tested-by: John Sheu <sheu@chromium.org>
Daniel Kurtz [Thu, 3 Jan 2013 03:14:21 +0000 (11:14 +0800)]
CHROMIUM: drm/exynos: fbdev: Don't recompute fb size in fbdev_update
The size variable in fbdev_update is used to set the amount of mapped RAM
needed for the framebuffer. Thus, it is not just the number of pixels
times the bpp; it could be significantly more due to line length cache
alignment and other padding.
Thus, get the size from the gem object itself instead of computing it.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=splash screen displays correctly w/ no HDMI
TEST=splash screen displays correctly w/ HDMI
Change-Id: I7df74770d49931f98ebd62d71178755a83d6db57
Reviewed-on: https://gerrit.chromium.org/gerrit/40445 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz [Thu, 3 Jan 2013 03:09:19 +0000 (11:09 +0800)]
CHROMIUM: drm/exynos: fbdev: Pass gem object to fbdev_update
Simplify fbdev creation by just passing the just created gem object to
fbdev_update. The gem object's buffer is always valid (or else the gem
object creation itself would have failed).
This cleans up fbdev creation by removing some unneccessary error
handling.
UPSTREAM: mwifiex: use correct htcapinfo for HT20 ibss network
It is observed that same htcapinfo ie is included in beacon for
HT20, HT40+ and HT40- ibss networks. This patch makes sure that
we will not advertise 40Mhz flags while creating/joining ibss
network in HT20 mode.
Change-Id: I1e144840a4258f4d5ecf8bf32f30ce78646753e6
Reviewed-on: https://gerrit.chromium.org/gerrit/40553 Reviewed-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org> Tested-by: Paul Stewart <pstew@chromium.org>
Vincent Palatin [Fri, 26 Oct 2012 16:24:51 +0000 (09:24 -0700)]
CHROMIUM: exynos: reset external HSIC hub
The former code was only ensuring that the reset line was released but
neither doing an actual reset pulse if it was already before nor
ensuring we had proper reset timings.
If the HSIC hub was used before booting (e.g on Spring, the external
USB2 port is connected the HSIC hub, so the bootloader is using it to
boot from USB), we need to do a proper 100us low reset pulse, then wait
for 4 ms for the hub to finish initialization (as per SMSC 3503
datasheet).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14490
TEST=boot on Spring from a USB key connected to the external USB2 port
(which is connected to the HSIC hub
boot on Snow, do a "lsusb" and see the internal USB peripherals
connected the HSIC hub are there (e.g."ID 1410:a021 Novatel wireless"
and "ID 2232:1037" which is webcam).
Change-Id: Idb15188aa1b1d502387a5e67b3598d016eeb6ab7
Reviewed-on: https://gerrit.chromium.org/gerrit/36693 Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
Theodore Ts'o [Thu, 27 Dec 2012 06:42:50 +0000 (01:42 -0500)]
UPSTREAM: ext4: avoid hang when mounting non-journal filesystems with orphan list
When trying to mount a file system which does not contain a journal,
but which does have a orphan list containing an inode which needs to
be truncated, the mount call with hang forever in
ext4_orphan_cleanup() because ext4_orphan_del() will return
immediately without removing the inode from the orphan list, leading
to an uninterruptible loop in kernel code which will busy out one of
the CPU's on the system.
This can be trivially reproduced by trying to mount the file system
found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
source tree. If a malicious user were to put this on a USB stick, and
mount it on a Linux desktop which has automatic mounts enabled, this
could be considered a potential denial of service attack. (Not a big
deal in practice, but professional paranoids worry about such things,
and have even been known to allocate CVE numbers for such problems.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reviewed-by: Zheng Liu <wenqing.lz@taobao.com> Cc: stable@vger.kernel.org
BUG=chromium-os:37768
TEST=link build, manual test with corrupted filesystem image
(cherry picked from commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca)
Change-Id: I5e985a85e94f3b38f0dd5d8c1517c0bccc93eb04 Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41038 Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ext4: make orphan functions be no-op in no-journal mode
Instead of checking whether the handle is valid, we check if journal
is enabled. This avoids taking the s_orphan_lock mutex in all cases
when there is no journal in use, including the error paths where
ext4_orphan_del() is called with a handle set to NULL.
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
BUG=chromium-os:37768
TEST=link build, manual test with corrupted filesystem image
(cherry picked from commit c9b92530a723ac5ef8e352885a1862b18f31b2f5)
Change-Id: I408cdaaa8872435f530a063bc84c3ca602e01b18 Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41037 Reviewed-by: Olof Johansson <olofj@chromium.org>
Yufeng Shen [Thu, 10 Jan 2013 20:00:42 +0000 (15:00 -0500)]
CHROMIUM: Input: atmel_mxt_ts: Use correct max touch_major in mxt_release_all_fingers()
We hard-coded the maximal touch_major value to be 255 in mxt_release_all_fingers().
Fixing this by using the queried actual maximal touch_major value.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chrome-os-partner:17176
TEST=1. Run evtest on the touch device
2. Keep touching the device while closing the lid.
3. Release the touch after the system suspends.
4. Open the lid to resume the system
5. Check evtest result and see that there is release events with correct
touch major value.
MyungJoo Ham [Thu, 23 Jun 2011 02:27:17 +0000 (11:27 +0900)]
CHERRY-PICK: ARM: EXYNOS4: Support Charger Manager
The configuration is supposed to support Exynos4-NURI. However, we
expect that the configuration is mostly compatible with other Exynos4
platforms.
v2
- Remove undefined field of struct charger_desc (measure_ambient_temp)
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Change-Id: Ib568676b0af5fb22ca8bae29dcc8f7fb61e492e4
(cherry picked from commits 914a452e6ef714492bbbfafcec389313a044e760
and 27be8be090694878b8ff05a0611a46af0a8fb598
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Reviewed-on: https://gerrit.chromium.org/gerrit/40163 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Change-Id: Id40ac31fe388bf266a013003e056d9dfe23d7404 Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
(cherry picked from commit c7284202121b663559e615e87ad447ea3f6177fb
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Reviewed-on: https://gerrit.chromium.org/gerrit/40162 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
MyungJoo Ham [Tue, 27 Mar 2012 07:18:43 +0000 (16:18 +0900)]
CHERRY-PICK: Samsung SoC: support Charger Manager.
Change-Id: I9b01982d5ab01185517a6b948fb660a50a7fafd0 Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
(cherry picked from commit 914a452e6ef714492bbbfafcec389313a044e760
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Reviewed-on: https://gerrit.chromium.org/gerrit/40161
Commit-Queue: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Abhilash Kesavan [Fri, 21 Dec 2012 04:14:39 +0000 (09:44 +0530)]
exynos5: asv: Call the core ASV code early
Change the priority of ASV code initialization. The core ASV code
finds the speed group, lot id and exposes it to various consumer
drivers like busfreq, G3D and CPUfreq. Among these, the G3D driver
is getting called before the core code and thus is always getting
the ASV speed group as 0. Fix this by calling the core ASV early.
BUG=chrome-os-partner:16796
TEST=Checked that G3D, ARM and INT drivers are all getting the same
ASV group on 2 different boards (1 MP and 1 PVT). Also, verified that
the voltages match that speed group.
Change-Id: I1ca234a770bbd8b2d590a83377ee44527327066b Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/40076 Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
Chanwoo Choi [Tue, 8 May 2012 04:43:59 +0000 (13:43 +0900)]
CHERRY-PICK: charger-manager: Workaround for checking state of charger before initializaing cm
Change-Id: I071ec6bb9d9a9e3b749572cecbfdcef5f7f8be3d Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
(cherry picked from commit eaef7ab292ec455123d425a519abc399e68048af
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Reviewed-on: https://gerrit.chromium.org/gerrit/40159 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Chanwoo Choi [Sat, 5 May 2012 13:26:47 +0000 (06:26 -0700)]
CHERRY-PICK: charger-manager: Provide cm_notify_event function for in-kernel use
By using cm_notify_event function, charger driver can report several
charger events (e.g. battery full and external power in/out, etc) to
Charger-Manager. Charger-Manager can properly and immediately control
chargers by the reported event.
Change-Id: Id791abfc9ab014cba7446f2467830a1af99eff0a Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
(cherry picked from commit d1c35d11cd03167d1479bfbe09998d9dfe361b32
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Reviewed-on: https://gerrit.chromium.org/gerrit/40158 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Chanwoo Choi [Sat, 5 May 2012 13:24:10 +0000 (06:24 -0700)]
CHERRY-PICK: charger-manager: Poll battery health in normal state
Charger-Manager needs to check battery health in normal state
as well as suspend-to-RAM state. When the battery is fully charged,
Charger-Manager needs to determine when the chargers restart charging.
This patch allows Charger-Manager to monitor battery health in normal
state and handle operation for chargers after battery is fully charged.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
(cherry picked from commit 6d193b13aee372996e45c34865aa37c3c603b228
in branch charger-manager-for-next of
git://git.infradead.org/users/kmpark/linux-2.6-samsung)
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Change-Id: Iab84dc96254dae448cd18d3ba4458c48203b3d13
Reviewed-on: https://gerrit.chromium.org/gerrit/40157 Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Abhilash Kesavan [Fri, 14 Dec 2012 06:02:19 +0000 (11:32 +0530)]
arm: exynos: Enable CHIP ID clock
The bootloader may gate the CLK_CHIPID_APBIF which will cause
an invalid value to be read for the Package ID in ASV. Explicitly
enable the clock in the ASV driver.
BUG=chrome-os-partner:16796
TEST=Boot 5 different snows to the login screen. Verify that the clock
is enabled and the appropriate speed group is being selected. Do a few
suspend/resume cycles with reboots.
Doug Anderson [Fri, 14 Dec 2012 19:21:12 +0000 (11:21 -0800)]
arm: exynos: Use MIF ASV group
The original code doesn't use the MIF ASV group. Add code to read it.
There are 2 ASV groups for the fused chips ASV0 at 1.05V and ASV1 at
1V. For the non-fused chips the MIF voltage remains at 1V.
BUG=chrome-os-partner:16820
TEST=Verified that we never change MIF voltage, so this doesn't affect
us right now.
TEST=Saw printout about MIF ASV group at bootup.
Vic Yang [Thu, 13 Dec 2012 02:09:51 +0000 (18:09 -0800)]
CHROMIUM: drm/exynos: dp: Handle bad hotplug IRQ
If the hotplug detect pin cannot be mapped to an IRQ number, we should
still be able to detect the display with polling loop. This CL prevents
driver initialization from failing in this case, and adds a call to
hotplug handling function in power on sequence.
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:16280
TEST=on Snow and Spring, boot and see display.
Change-Id: Idaa908ac38e85b8dd10c367a4c1f8ec47a4432b9
Reviewed-on: https://gerrit.chromium.org/gerrit/40363 Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The fw variable is initialized in request_ihex_firmware in the
non-failure case but the compiler is not smart enough to pick
this up so fixing this way.
Fixes the following warning:
drivers/usb/serial/keyspan.c:1298:18: warning: 'fw' may be used uninitialized in this function [-Wmaybe-uninitialized]
The bootcache header has 12-character fields for date and time.
However, the __DATE__ string is only 9 characters long incl. null
terminator. When comparing __DATE__ and __TIME__ to the header's
fields, we should use the lengths of __DATE__ and __TIME__, because they
are <= 12 (size of the header fields).
e.g.
strncmp(hdr->date, __DATE__, sizeof(hdr->date))
--> sizeof(hdr->date) is 12 but __DATE__ is only 9 characters long,
so will throw a smatch error.
strncmp(hdr->date, __DATE__, strlen(__DATE__) + 1)
--> strlen(__DATE__) + 1 == 9, so this will not result in comparing
a string that is shorter than the required length.
BUG=chromium-os:37656
TEST=Build kernel with USE=test, after this CL has been merged:
https://gerrit.chromium.org/gerrit/#/c/40054/
dm-bootcache.c should not throw any smatch errors about strncmp().
Change-Id: I88c7cbb96dc4da611b96609ef21b3787483c25db Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/40549 Reviewed-by: Paul Taysom <taysom@chromium.org>
BUG=chromium-os:37579
TEST=hciconfig shows device and hcitool scan works
Change-Id: I365fd3c8c7863fc634613ae6ad18a01e600572e2 Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/40338 Reviewed-by: Paul Stewart <pstew@chromium.org>
Bing Zhao [Thu, 3 Jan 2013 01:45:19 +0000 (17:45 -0800)]
UPSTREAM: mwifiex: check wait_event_interruptible return value
wait_event_interruptible function returns -ERESTARTSYS if it's
interrupted by a signal. Driver should check the return value
and handle this case properly.
In mwifiex_wait_queue_complete() routine, as we are now checking
wait_event_interruptible return value, the condition check is not
required. Also, we have removed mwifiex_cancel_pending_ioctl()
call to avoid a chance of sending second command to FW by other path
as soon as we clear current command node. FW can not handle two
commands simultaneously.
Cc: "3.6+" <stable@vger.kernel.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
BUG=chrome-os-partner:16031,17015
TEST=Boot, associate, and run "rtcwake -s 10 -mmem" in a
"while/do/done" loop
Change-Id: I54deddb71864a5b638a559b9e51942bf1d46162d
Reviewed-on: https://gerrit.chromium.org/gerrit/40359 Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com> Tested-by: Bing Zhao <bzhao@marvell.com>
Daniel Kurtz [Thu, 3 Jan 2013 02:37:06 +0000 (10:37 +0800)]
CHROMIUM: drm/exynos: fbdev: Set visible dimensions correctly
When probing the fbdev, the drm_fb_helper may specify a visible area
(fb_width x fb_height) than is smaller than the total requested
framebuffer area (surface_width x surface_height).
Use these fb dimensions when setting the visible area in the "variable"
portion of the fb info. This is consistent with other drm fbdev drivers
(i915, radeon, nouveau).
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=none
TEST=splash screen displayed properly at boot w/ no HDMI
TEST=splash screen displayed properly at boot w/ HDMI
Change-Id: Id209ea395a7e5eb993632ae4cfe4263b5af18138
Reviewed-on: https://gerrit.chromium.org/gerrit/40443 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org>
projects / people / aperard / linux-chromebook.git / log