Sean Paul [Mon, 25 Feb 2013 20:35:25 +0000 (15:35 -0500)]
drm/bridge: Move ps8622 driver into drm/bridge
Move the ps8622 bridge driver into drm/bridge.
BUG=chrome-os-partner:17557
TEST=Builds
Change-Id: I153539311c5a31aafab9deff1f74384a70bc48c4
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43939
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Mon, 25 Feb 2013 20:26:25 +0000 (15:26 -0500)]
drm/exynos: Convert ptn bridge to drm_bridge
BUG=chrome-os-partner:17557
TEST=Tested on snow
Change-Id: Ie9cc502325953bcb97b69660bebfe4641cda4acd
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43926
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Fri, 22 Feb 2013 20:17:24 +0000 (15:17 -0500)]
drm/i2c: Move ptn3460 from i2c to bridge directory
In preparation of drm_bridge-ifying the ptn3460 driver.
BUG=chrome-os-partner:17557
TEST=Build kernel for daisy
Change-Id: Ia17fe2d4de3c23734e86716b47ee0337c55f518b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43925
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Mon, 25 Feb 2013 19:52:41 +0000 (14:52 -0500)]
drm/exynos: Move dp training into mode_set
Move the DP link training from the interrupt worker to the mode_set
callback.
BUG=chrome-os-partner:17557
TEST=Tested on snow, no regressions noted
Change-Id: I06fecce43500e4a2b64eda4aca18c889a811b1ed
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43924
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
John Sheu [Thu, 7 Feb 2013 01:13:54 +0000 (17:13 -0800)]
ARM: EXYNOS: MFC: Add IOMMU mapping to MFC probe
IOMMU mapping is created for mfc device during probe. This
requires the sysmmu_l and sysmmu_r property be set in the DTS
file. First, the sysmmu device nodes are found and then the
sysmmu platform devices are retrieved. A IOMMU mapping is then created
for mfc_l and mfc_r devices.
Change-Id: I270211bd2583492818d2f2eb2c9bac73ba3956cd
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/42958
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
John Sheu [Thu, 7 Feb 2013 00:23:15 +0000 (16:23 -0800)]
CHROMIUM: s5p-mfc: backport upstream s5p-mfc driver.
<UPSTREAM MERGE NOT REQUIRED>
Backport the upstream driver, for the purpose of enabling s5p-mfc hardware
video encoding.
Backport of changes up to
734d1ece37fbf3d2ddfc71bc6c69e0fe35f02542 from
linuxtv/staging/for_v3.9
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
BUG=chromium:167417
TEST=local build, run on snow
Change-Id: Iae484f49a16a8e753b8951b2db4433bc549a5e97
Reviewed-on: https://gerrit.chromium.org/gerrit/42957
Commit-Queue: John Sheu <sheu@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Steev Klimaszewski [Wed, 20 Feb 2013 20:12:03 +0000 (14:12 -0600)]
CHROMIUM:config:Enable CP210X module
The CP210X is another fairly common serial adapter.
BUG=None
TEST=Compile, boot kernel, plug in cp210x adapter, check that you get a
/dev/ttyUSB0 device.
Change-Id: Ibf79904fef9f93efca135960d48f7200b8c5fef8
Signed-off-by: Steev Klimaszewski <threeway@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/43625
Commit-Queue: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Arjun KV [Wed, 19 Dec 2012 06:54:53 +0000 (12:24 +0530)]
ARM: GPU: MALI: G3D ASV Lock Bit implementation
If G3D ASV lock bit is configured, all voltages in the G3D ASV table
have to be increased by 25mV.
BUG=chrome-os-partner:16615
TEST=Compile and boot kernel, cannot test
the exact changes till we get the new chip.
Change-Id: I8784ed290807ac5db86c706177403260742bbe89
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/39467
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Arjun KV [Wed, 19 Dec 2012 06:10:25 +0000 (11:40 +0530)]
arm: exynos5: INT ASV Lock Bit implementation
If INT ASV lock bit is configured, all voltages in the INT ASV table
have to be increased by 25mV.
BUG=chrome-os-partner:16615
TEST=Compile and boot kernel, cannot test
the exact changes till we get the new chip.
Change-Id: I64ec69874bd4753b61efd46708cdf82046310dd2
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/39466
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Arjun KV [Wed, 19 Dec 2012 05:29:00 +0000 (10:59 +0530)]
arm: exynos5: ARM ASV Lock Bit implementation
If lock bit is configured, voltage for cpu frequency in some
ranges(800-200MHz, 1000-200MHz, 1100-200MHz) should be locked with the
voltage of the locked cpu frequency. e.g. in 800-200MHz range all
frequencies below 800MHz will be configured with same voltage as
800MHz.
BUG=chrome-os-partner:16615
TEST=Compile and boot kernel. Add printouts to
exynos5250_cpufreq_get_asv() to confirm that the min_t() doesn't
actually change the index on existing systems where lock bits are all
0. Check that `dmesg` contains "EXYNOS5250: ASV lock int: 0 g3d: 0
arm: 0" which means that lock bits are all disabled.
[dianders cleaned up patch and CL description]
Change-Id: If5fcfae38af1bd01a5646ae94f7b010e564411cd
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39465
Yufeng Shen [Wed, 27 Feb 2013 23:21:56 +0000 (18:21 -0500)]
CHROMEOS: config: turn on HID_BATTERY_STRENGTH
This option allows external HID device to report its battery info
under /sys/class/power_supply/hid-xxx-battery
Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chromium-os:39317
TEST=Tested on Link with the new kernel, connect an Apple Magic Mouse
to it, and the battery info is shown under
/sys/class/power_supply/hid-xxx-battery
Change-Id: Ia05d8593673d5d1bd0e3f0def643713d8cb81e8e
Reviewed-on: https://gerrit.chromium.org/gerrit/44245
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Jiri Kosina [Tue, 24 Apr 2012 08:51:30 +0000 (10:51 +0200)]
UPSTREAM: HID: add Kconfig text to HID_BATTERY_STRENGTH
HID_BATTERY_STRENGTH is missing both help text and description text.
BUG=chromium-os:39317
TEST=set CONFIG_HID_BATTERY_STRENGTH=y in base.config. build the
kernel, and check that this option is enabled in the built kernel
cherry-picked from upstream commit
692d30d63b80b174d0ed24bbffb7a1ea536d5fee
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Change-Id: I2925c344b918e8b03953679ee5f856860fa09aa7
Reviewed-on: https://gerrit.chromium.org/gerrit/44249
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
Reviewed-by: Yufeng Shen <miletus@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Doug Anderson [Thu, 28 Feb 2013 21:57:05 +0000 (13:57 -0800)]
CHROMIUM: config: Renormalize splitconfig
Just ran: ./chromeos/scripts/kernelconfig oldconfig
...and hit return for everything. AKA: no functional change
here, this just tells us where we are.
BUG=None
TEST=Compiled and booted on one device.
Change-Id: I92d6e364e9c95882e5c8bc10450fe97c79115e76
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44312
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Doug Anderson [Thu, 28 Feb 2013 21:58:11 +0000 (13:58 -0800)]
CHROMIUM: config: Build spidev into the kernel (not a module)
A recovery image needs to be able to access SPI in order to reflash
the firmware, but the recovery image doesn't include any modules.
Make spidev part of the kernel to avoid having yet another weird
config difference for the recovery kernel.
BUG=chrome-os-partner:13068
TEST=Manual:
1. Get an official recovery image (that is marked to do a firmware
flash) that contains this CL plus the modification to
mod_image_for_recovery.sh that enables it.
2. Boot on snow.
3. After reboot confirm that firmware got updated.
4. Also after reboot look in console-ramoops. If you see this:
[ 1157.020235] Chromium OS LSM: init_module locked module=
"/lib/modules/3.4.0/kernel/drivers/spi/spidev.ko" pid=1574
cmdline="modprobe spidev"
...then that's bad and it means that we loaded the spidev module
from the target USB key which isn't what we want to do.
TEST=Manual:
1. Hack up recovery image as described in chrome-os-partner:13068.
2. From first shell prompt in hacked recovery image type:
chroot /usb /usr/sbin/flashrom -r /tmp/foo.bin
3. Confirm that flashrom reports no errors.
4. Type lsmod
5. Confirm that spidev is not listed
Change-Id: Ic156895cb186d04d2c32370d7cf70a3ec4af55bc
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44311
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Kees Cook [Thu, 28 Feb 2013 00:01:13 +0000 (16:01 -0800)]
CHROMIUM: eCryptfs: allow userspace messaging to be disabled
When the userspace messaging (needed for ecryptfsd) is not needed, allow
eCryptfs to build with it removed. This saves on kernel code size and
reduces potential attack surface by removing the /dev/ecryptfs node.
BUG=chromium-os:35732
TEST=link build, /dev/ecryptfs is gone, eCryptfs still works.
[sent upstream for review:
http://marc.info/?l=ecryptfs-users&m=
136204079607329&w=2]
Change-Id: I1b2be61e0a455fc9f6e09a9f4a1b1f6d65d1903a
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44278
Reviewed-by: Will Drewry <wad@chromium.org>
Tyler Hicks [Thu, 13 Sep 2012 19:00:56 +0000 (12:00 -0700)]
UPSTREAM: eCryptfs: Copy up attributes of the lower target inode after rename
After calling into the lower filesystem to do a rename, the lower target
inode's attributes were not copied up to the eCryptfs target inode. This
resulted in the eCryptfs target inode staying around, rather than being
evicted, because i_nlink was not updated for the eCryptfs inode. This
also meant that eCryptfs didn't do the final iput() on the lower target
inode so it stayed around, as well. This would result in a failure to
free up space occupied by the target file in the rename() operation.
Both target inodes would eventually be evicted when the eCryptfs
filesystem was unmounted.
This patch calls fsstack_copy_attr_all() after the lower filesystem
does its ->rename() so that important inode attributes, such as i_nlink,
are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
and eCryptfs can drop its final reference on the lower inode.
http://launchpad.net/bugs/561129
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Tested-by: Colin Ian King <colin.king@canonical.com>
Cc: <stable@vger.kernel.org> [2.6.39+]
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
8335eafc2859e1a26282bef7c3d19f3d68868b8a)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I9d4aa7e91b6f132a1f16d9a8b509681977091907
Reviewed-on: https://gerrit.chromium.org/gerrit/44158
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Thu, 13 Sep 2012 01:38:00 +0000 (18:38 -0700)]
UPSTREAM: eCryptfs: Call lower ->flush() from ecryptfs_flush()
Since eCryptfs only calls fput() on the lower file in
ecryptfs_release(), eCryptfs should call the lower filesystem's
->flush() from ecryptfs_flush().
If the lower filesystem implements ->flush(), then eCryptfs should try
to flush out any dirty pages prior to calling the lower ->flush(). If
the lower filesystem does not implement ->flush(), then eCryptfs has no
need to do anything in ecryptfs_flush() since dirty pages are now
written out to the lower filesystem in ecryptfs_release().
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
64e6651dcc10e9d2cc6230208a8e6c2cfd19ae18)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I44d6ba0eb30b6eebbfbedf3a1d7a8d7eaed28c01
Reviewed-on: https://gerrit.chromium.org/gerrit/44157
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Thu, 13 Sep 2012 01:02:46 +0000 (18:02 -0700)]
UPSTREAM: eCryptfs: Write out all dirty pages just before releasing the lower file
Fixes a regression caused by:
821f749 eCryptfs: Revert to a writethrough cache model
That patch reverted some code (specifically,
32001d6f) that was
necessary to properly handle open() -> mmap() -> close() -> dirty pages
-> munmap(), because the lower file could be closed before the dirty
pages are written out.
Rather than reapplying
32001d6f, this approach is a better way of
ensuring that the lower file is still open in order to handle writing
out the dirty pages. It is called from ecryptfs_release(), while we have
a lock on the lower file pointer, just before the lower file gets the
final fput() and we overwrite the pointer.
https://launchpad.net/bugs/
1047261
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Artemy Tregubenko <me@arty.name>
Tested-by: Artemy Tregubenko <me@arty.name>
Tested-by: Colin Ian King <colin.king@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
7149f2558d5b5b988726662fe58b1c388337805b)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: Ie713a160fb3899869af63fcf4ad0c29a2ab8ea79
Reviewed-on: https://gerrit.chromium.org/gerrit/44156
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tim Sally [Thu, 12 Jul 2012 23:10:24 +0000 (19:10 -0400)]
UPSTREAM: eCryptfs: check for eCryptfs cipher support at mount
The issue occurs when eCryptfs is mounted with a cipher supported by
the crypto subsystem but not by eCryptfs. The mount succeeds and an
error does not occur until a write. This change checks for eCryptfs
cipher support at mount time.
Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
https://bugs.launchpad.net/ecryptfs/+bug/338914
Signed-off-by: Tim Sally <tsally@atomicpeace.com>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
5f5b331d5c21228a6519dcb793fc1629646c51a6)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: If3d6f7f13047e7a9a64c0f79441ca52ebab17979
Reviewed-on: https://gerrit.chromium.org/gerrit/44155
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Tue, 3 Jul 2012 23:50:57 +0000 (16:50 -0700)]
UPSTREAM: eCryptfs: Revert to a writethrough cache model
A change was made about a year ago to get eCryptfs to better utilize its
page cache during writes. The idea was to do the page encryption
operations during page writeback, rather than doing them when initially
writing into the page cache, to reduce the number of page encryption
operations during sequential writes. This meant that the encrypted page
would only be written to the lower filesystem during page writeback,
which was a change from how eCryptfs had previously wrote to the lower
filesystem in ecryptfs_write_end().
The change caused a few eCryptfs-internal bugs that were shook out.
Unfortunately, more grave side effects have been identified that will
force changes outside of eCryptfs. Because the lower filesystem isn't
consulted until page writeback, eCryptfs has no way to pass lower write
errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
that quotas could be bypassed because of the way eCryptfs may sometimes
open the lower filesystem using a privileged kthread.
It would be nice to resolve the latest issues, but it is best if the
eCryptfs commits be reverted to the old behavior in the meantime.
This reverts:
32001d6f "eCryptfs: Flush file in vma close"
5be79de2 "eCryptfs: Flush dirty pages in setattr"
57db4e8d "ecryptfs: modify write path to encrypt page in writepage"
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Tested-by: Colin King <colin.king@canonical.com>
Cc: Colin King <colin.king@canonical.com>
Cc: Thieu Le <thieule@google.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
821f7494a77627fb1ab539591c57b22cdca702d6)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I78b810a47117ddc53f641150a6d097fd95856ae7
Reviewed-on: https://gerrit.chromium.org/gerrit/44154
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Thu, 21 Jun 2012 06:50:59 +0000 (23:50 -0700)]
UPSTREAM: eCryptfs: Initialize empty lower files when opening them
Historically, eCryptfs has only initialized lower files in the
ecryptfs_create() path. Lower file initialization is the act of writing
the cryptographic metadata from the inode's crypt_stat to the header of
the file. The ecryptfs_open() path already expects that metadata to be
in the header of the file.
A number of users have reported empty lower files in beneath their
eCryptfs mounts. Most of the causes for those empty files being left
around have been addressed, but the presence of empty files causes
problems due to the lack of proper cryptographic metadata.
To transparently solve this problem, this patch initializes empty lower
files in the ecryptfs_open() error path. If the metadata is unreadable
due to the lower inode size being 0, plaintext passthrough support is
not in use, and the metadata is stored in the header of the file (as
opposed to the user.ecryptfs extended attribute), the lower file will be
initialized.
The number of nested conditionals in ecryptfs_open() was getting out of
hand, so a helper function was created. To avoid the same nested
conditional problem, the conditional logic was reversed inside of the
helper function.
https://launchpad.net/bugs/911507
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Colin Ian King <colin.king@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
e3ccaa9761200952cc269b1f4b7d7bb77a5e071b)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: Ic6b303d2b8ff2690bc938adce850b2eaedab98a7
Reviewed-on: https://gerrit.chromium.org/gerrit/44153
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Tue, 22 May 2012 20:09:50 +0000 (15:09 -0500)]
UPSTREAM: eCryptfs: Unlink lower inode when ecryptfs_create() fails
ecryptfs_create() creates a lower inode, allocates an eCryptfs inode,
initializes the eCryptfs inode and cryptographic metadata attached to
the inode, and then writes the metadata to the header of the file.
If an error was to occur after the lower inode was created, an empty
lower file would be left in the lower filesystem. This is a problem
because ecryptfs_open() refuses to open any lower files which do not
have the appropriate metadata in the file header.
This patch properly unlinks the lower inode when an error occurs in the
later stages of ecryptfs_create(), reducing the chance that an empty
lower file will be left in the lower filesystem.
https://launchpad.net/bugs/872905
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Colin Ian King <colin.king@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
8bc2d3cf612994a960c2e8eaea37f6676f67082a)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I9ef97db96f1e1e594e5f995ae6c1293d1b3527e0
Reviewed-on: https://gerrit.chromium.org/gerrit/44152
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Mon, 11 Jun 2012 22:42:32 +0000 (15:42 -0700)]
UPSTREAM: eCryptfs: Copy up POSIX ACL and read-only flags from lower mount
When the eCryptfs mount options do not include '-o acl', but the lower
filesystem's mount options do include 'acl', the MS_POSIXACL flag is not
flipped on in the eCryptfs super block flags. This flag is what the VFS
checks in do_last() when deciding if the current umask should be applied
to a newly created inode's mode or not. When a default POSIX ACL mask is
set on a directory, the current umask is incorrectly applied to new
inodes created in the directory. This patch ignores the MS_POSIXACL flag
passed into ecryptfs_mount() and sets the flag on the eCryptfs super
block depending on the flag's presence on the lower super block.
Additionally, it is incorrect to allow a writeable eCryptfs mount on top
of a read-only lower mount. This missing check did not allow writes to
the read-only lower mount because permissions checks are still performed
on the lower filesystem's objects but it is best to simply not allow a
rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw
mount is valid and still allowed.
https://launchpad.net/bugs/
1009207
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Stefan Beller <stefanbeller@googlemail.com>
Cc: John Johansen <john.johansen@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
069ddcda37b2cf5bb4b6031a944c0e9359213262)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I1c087b735bbead871d8420c0346a25468539a6cd
Reviewed-on: https://gerrit.chromium.org/gerrit/44151
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Mon, 11 Jun 2012 16:24:11 +0000 (09:24 -0700)]
UPSTREAM: eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
File operations on /dev/ecryptfs would BUG() when the operations were
performed by processes other than the process that originally opened the
file. This could happen with open files inherited after fork() or file
descriptors passed through IPC mechanisms. Rather than calling BUG(), an
error code can be safely returned in most situations.
In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
release even if the last file reference is being held by a process that
didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
be successful, so a pointer to the daemon is stored in the file's
private_data. The private_data pointer is initialized when the miscdev
file is opened and only used when the file is released.
https://launchpad.net/bugs/994247
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
8dc6780587c99286c0d3de747a2946a76989414a)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I2d877799e3e4c6f4126f28cfacaca4c6e7f729a9
Reviewed-on: https://gerrit.chromium.org/gerrit/44150
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Mon, 11 Jun 2012 17:21:34 +0000 (10:21 -0700)]
UPSTREAM: eCryptfs: Fix lockdep warning in miscdev operations
Don't grab the daemon mutex while holding the message context mutex.
Addresses this lockdep warning:
ecryptfsd/2141 is trying to acquire lock:
(&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<
ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
but task is already holding lock:
(&(*daemon)->mux){+.+...}, at: [<
ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(*daemon)->mux){+.+...}:
[<
ffffffff810a3b8d>] lock_acquire+0x9d/0x220
[<
ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
[<
ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
[<
ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
[<
ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
[<
ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
[<
ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
[<
ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs]
[<
ffffffff811963a4>] vfs_create+0xb4/0x120
[<
ffffffff81197865>] do_last+0x8c5/0xa10
[<
ffffffff811998f9>] path_openat+0xd9/0x460
[<
ffffffff81199da2>] do_filp_open+0x42/0xa0
[<
ffffffff81187998>] do_sys_open+0xf8/0x1d0
[<
ffffffff81187a91>] sys_open+0x21/0x30
[<
ffffffff81527d69>] system_call_fastpath+0x16/0x1b
-> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
[<
ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50
[<
ffffffff810a3b8d>] lock_acquire+0x9d/0x220
[<
ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
[<
ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
[<
ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
[<
ffffffff811887d3>] vfs_read+0xb3/0x180
[<
ffffffff811888ed>] sys_read+0x4d/0x90
[<
ffffffff81527d69>] system_call_fastpath+0x16/0x1b
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from upstream commit
60d65f1f07a7d81d3eb3b91fc13fca80f2fdbb12)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I243163c4ca70dbc74d85a6fa59f5fb4d8b586103
Reviewed-on: https://gerrit.chromium.org/gerrit/44149
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Tyler Hicks [Tue, 12 Jun 2012 18:17:01 +0000 (11:17 -0700)]
UPSTREAM: eCryptfs: Properly check for O_RDONLY flag before doing privileged open
If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.
The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
BUG=chromium-os:35732
TEST=daisy build, ENOSPC bubbles up to userspace
(cherry picked from commit
9fe79d7600497ed8a95c3981cbe5b73ab98222f0)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I748856005c76dd310a5a1d8a053bcba01ddded77
Reviewed-on: https://gerrit.chromium.org/gerrit/44148
Tested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Kees Cook <keescook@chromium.org>
Simon Glass [Sun, 10 Feb 2013 03:48:20 +0000 (19:48 -0800)]
CHROMIUM: charger-manager: Pass IRQ to wakeup check function
Since charger-manager knows the IRQ number it is looking for in the
wake-up check (it gets it from the RTC class), pass it to the platform
function so that this does not need to be hard-coded.
Add a function to exynos which return true if a particular GPIO is known
to be the sole reason for the wakeup event.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Turn on debugging in setup-charger. Try waking up on snow using the
keyboard, the lid and a timer ('rtcwake -s 35 -d /dev/rtc1 -m mem').
See that only the timer causes this function to return true.
Note I did not test simultaneous wakeup. This could perhaps be done by
introducing a long delay in the function, to give me time to cause another
type of wakeup event. However, I did see an EC wakeup event at one point
and this caused the function to return false as required.
Change-Id: I96eb0387e36c097f0df0256c6be4879b3180d259
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43022
Simon Glass [Sun, 10 Feb 2013 04:09:47 +0000 (20:09 -0800)]
CHROMIUM: charger-manager: Tidy up suspend_again() device resume/suspend
The current implementation is pretty-much hard-coded. It doesn't really
provide for different devices to be easy connected or specified via the
device tree.
During suspend_again(), create a list of devices that need to be resumed
by walking up through the parents of the power supply and rtc devices.
Resume the list in reverse order so that parents come first. Then suspend
the list in forward order so that the children are suspended first.
This provides more flexibility for devices to be specified at run-time.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Tested with charger-manager with other changes. See that it can remain
suspended (i.e. returns to suspend automatically after each wake).
Change-Id: I7c9f04330c437b3da32e58dd1e53e0e550b37a71
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43023
Reviewed-by: Benson Leung <bleung@chromium.org>
Bing Zhao [Tue, 26 Feb 2013 23:22:17 +0000 (15:22 -0800)]
Add debugging to trace the loss of hidden ssid
This patch will help to trace if hidden ssid is lost in firmware or driver.
SSID and mac address should be anonymized.
BUG=chrome-os-partner:17989
TEST=trigger a scan and grep for "inform bss" in dmesg/messages. Submit a
feedback report and verify if SSIDs and mac addresses are anonymized. Verified
with the feedback report
718249759.
Change-Id: I0df02a9f8eb1898f6f3af2438c614031bb44f329
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44124
Reviewed-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Bernie Thompson [Wed, 27 Feb 2013 18:56:59 +0000 (10:56 -0800)]
CHROMIUM: mmc: Add in support to expose PRV for v4 MMCs
The JEDEC MMC v4 spec defines a new PRV value in place of the original
fwrev and hwrev specified in v1. We can expose this in the kernel to enable
user space to more easily determine the product revision of a given MMC.
BUG=chrome-os-partner:17640
TEST=emerge-daisy_spring chromeos-kernel
Check for /sys/devices/dw_mmc.0/mmc_host/mmc0/mmc0:0001/prv
Change-Id: Ia241c743e64749909ad18851425a551e04d8cdb3
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44190
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Luigi Semenzato [Wed, 27 Feb 2013 17:41:54 +0000 (09:41 -0800)]
CHROMIUM: TEMPORARY: dump stack to help debug p/17609
This doesn't happen very often, so the dump_stack should
be tolerable. I tried with a WARN_ON, but it made some
of our automated tests fail.
BUG=chrome-os-partner:17609
TEST=none
Change-Id: I3d5a0ebc25d272901e713209dc5d655322804f91
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44178
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Luigi Semenzato [Wed, 27 Feb 2013 16:56:34 +0000 (08:56 -0800)]
Revert "CHROMIUM: TEMPORARY: instrumentation for crosbug.com/p/17609"
This reverts commit
046efd1b7dceabe4cc38c61c355a34c2bf657ca3.
The WARN_ON makes some automated tests fail.
BUG=chrome-os-partner:17609
TEST=none
Change-Id: I07da232e7d2f7456da41ea373dfa00275a8effa0
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44174
Commit-Queue: Grant Grundler <grundler@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Sean Paul [Fri, 22 Feb 2013 19:01:26 +0000 (14:01 -0500)]
drm: Add drm_bridge between encoder and connector
This patch adds the notion of a drm_bridge between the encoder and the
connector. This allows us to handle bridge chips gracefully with dpms
and hotplug.
BUG=chrome-os-partner:17557
TEST=Tested on snow
Change-Id: I66b9f631bb924e443e79419a3dc3af0ef41fb70d
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43912
Luigi Semenzato [Fri, 22 Feb 2013 22:51:39 +0000 (14:51 -0800)]
CHROMIUM: TEMPORARY: instrumentation for crosbug.com/p/17609
We have a hard time reproducing crosbug.com/p/17609. It seems
to be correlated with a reset of the device. We don't understand
why the reset happens and we're hoping that a stack trace will
give us some information.
From the logs we've seen, this doesn't happen very often, so
chances of spewing are low. We get Link feedback reports with
this error almost daily.
BUG=chrome-os-partner:17609
TEST=not tested, or, rather, YOU test it
BRANCH=none
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: If24b4f2490919905d79cdf4e5b8b159cbe8aee6c
Reviewed-on: https://gerrit.chromium.org/gerrit/43832
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 05:26:32 +0000 (21:26 -0800)]
CHROMIUM: dark resume: Make rtc_cmos part of kernel
This change makes the rtc_cmos driver part of the kernel instead of a module.
This allows us to modify sysfs files for it (such as dark_resume_source) as part
of an upstart script. We need to change the owner of the dark_resume_source file
to power so powerd can enable the rtc cmos as a wake source.
BUG=chrome-os-partner:9812
TEST=check that rtc cmos is probed before user space starts.
Change-Id: Ie562fe78ade4f6b46ee1de970401435f52200fa4
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42926
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 05:22:06 +0000 (21:22 -0800)]
CHROMIUM: dark resume: Make usb devices not resume for dark resumes
This change checks if dark resume is activated for the usb device and if there
is a dark resume. If so, it returns immediately rather than resuming the usb
device. This allows us to prevent usb lights from flashing when we do a dark
resume.
BUG=chrome-os-partner:9812
TEST=suspend system, watch dark resumes
Change-Id: Ibbe347c9dbc54b2b5598ac25e846c132a0456b17
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42925
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 04:38:00 +0000 (20:38 -0800)]
CHROMIUM: dark resume: Add rtc-cmos wake source functionality
Add the proper callbacks and structs to rtc cmos such that user space can make
the rtc cmos a wake source for dark resume. The callback function checks a
register of the rtc cmos to see if an interrupt happened. Ideally this should
instead make an ACPI function call that checks what the wake source was and see
if that's the RTC, but we don't have that implemented yet.
BUG=chrome-os-partner:9812
TEST=suspend system, watch dark resumes
Change-Id: I2232b0247e0cf59394da7c530d9e63a6e70bbd17
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42924
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 04:34:20 +0000 (20:34 -0800)]
CHROMIUM: dark resume: Expose dark resume activation
Add a way for userspace to activate dark resume specifically for devices. This
will allow devices to specify to the kernel whether it should do something
different for a device (such as not come up at all) during a dark resume. This
allows drivers that run very different hardware to do something different based
on specific configurations for a machine.
BUG=chrome-os-partner:9812
TEST=suspend system, watch dark resumes happen
Change-Id: If2a6fab5500027d17347552b5a08b24d764aa946
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42923
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 04:27:46 +0000 (20:27 -0800)]
CHROMIUM: dark resume: Expose dark resume status to user space
Add sysfs file, /sys/power/dark_resume_state. This file can be queried to see if
a dark resume happened. If the value is 1, a dark resume happened. If 0, one did
not happen.
BUG=chrome-os-partner:9812
TEST=suspend system, watch dark resumes happen
Change-Id: Ie1b25ed1f5a3fee658e8014a098ba4ae23683f54
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42922
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Derek Basehore [Fri, 8 Feb 2013 04:22:38 +0000 (20:22 -0800)]
CHROMIUM: dark resume: Add dark resume functionality
In drivers/base/power/main.c, create the concept of dark resume. This includes
checking for a dark resume before we resume devices and allowing devices to
query this state. It also adds creating wake sources that indicate if a dark
resume happened. If a device is in this list of devices, we ask it if it woke
the system up. If so, we count the system resume as a dark resume.
BUG=chrome-os-partner:9812
TEST=suspend system, watch dark resumes happen
Change-Id: I0c416c156759728284901f03e98f0c87933c9c9a
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42921
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Sean Paul [Tue, 26 Feb 2013 21:39:55 +0000 (16:39 -0500)]
drm/exynos: Move irq request after drm_dev assignment
There's a race between requesting the irq and dereferencing drm_dev in
the irq handler. Moving the request_irq until after drm_dev has been
assigned eliminates this race.
BUG=chrome-os-partner:17557
TEST=Builds, tested on snow
Change-Id: I8d29aad2c73cb70b24a693e768ffdb2752a48b57
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44087
Chee Kin Cheong [Tue, 26 Feb 2013 18:12:27 +0000 (10:12 -0800)]
CHROMIUM: ALSA: hda/ca0132 - Toggle DAC format when starting a stream.
Sometimes the DAC format would be incorrect after resume even if the
register indicated it was correct. Add a toggle of the format to make
sure the DAC gets audio in the format it expects.
BUG=chrome-os-parnter:17740
TEST=overnight loopback test checking for audio while suspend/resuming
the codec.
Change-Id: Ib27c7cb2489ea1c2c864ed4c6bc4ff98e1142792
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44056
Reviewed-by: Chih-Chung Chang <chihchung@chromium.org>
Simon Glass [Sun, 10 Feb 2013 03:41:11 +0000 (19:41 -0800)]
CHROMIUM: rtc: Implement get_wake_irq for rtc-s3c
Implement this method to provide the interrupt number for the chip.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Tested with charger-manager with other changes. See that it can remain
suspended (i.e. returns to suspend automatically after each wake).
Change-Id: I3be10a73a1b0da5fd47d3b21aae37fb18a78bce4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43021
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 10 Feb 2013 03:39:55 +0000 (19:39 -0800)]
CHROMIUM: rtc: Implement get_wake_irq for rtc-max77686
Implement this method to provide the interrupt number for the chip.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Tested with charger-manager with other changes. See that it can remain
suspended (i.e. returns to suspend automatically after each wake).
Change-Id: Id6512d4110bddd5281e49bfe22e02449991c4507
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43020
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 10 Feb 2013 00:41:29 +0000 (16:41 -0800)]
CHROMIUM: rtc: Add a method to obtain the wake interrupt number
When an rtc wakes the system we need to find this out so that we can decide
whether to immediately suspend again, or to fully wake to user space. This
is required for drivers that want to monitor devices preiodically in suspend,
such as charger-manager.
Add a new rtc method which returns the IRQ used by an RTC. This IRQ number
can then be checked in the suspend_again handler, to see if it caused the
wake.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Tested with charger-manager with other changes. See that it can remain
suspended (i.e. returns to suspend automatically after each wake).
Change-Id: I885aac2dfe15a3fb2c420857382224b98d475416
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43019
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:52:04 +0000 (14:52 -0800)]
CHROMIUM: charger-manager: Add a suspend count
Keep track of the number of times we have checked the battery while
in suspend. This is useful for checking that suspend_again() is doing
its job.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Suspend the device, wait a minute and resume. See from the logs
(dmesg |tail -20) that the charger-manager suspend_again count is now
5 or 6, indicating that it was incrementing in suspend.
Change-Id: Ifcaf459e0acaef5b37b05b9f8d84584010fb0c95
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43018
Reviewed-by: Benson Leung <bleung@chromium.org>
Todd Broch [Fri, 22 Feb 2013 22:24:19 +0000 (14:24 -0800)]
CHROMIUM: dts: spring: Enable TPS65090 regulators in device tree.
BUG=chrome-os-partner:17813
TEST=manual
1. compile, boot & login to system as root
2. See new regulators in sysfs
cat /sys/devices/s3c2440-i2c.4/i2c-4/4-001e/cros_ec-tps65090.*/regulator/regulator.*/name
Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: Icf3e55f78d7d7081e303e91df92e3df25c922a31
Reviewed-on: https://gerrit.chromium.org/gerrit/43945
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Todd Broch [Mon, 25 Feb 2013 22:30:00 +0000 (14:30 -0800)]
CHROMIUM: config: exynos5: Enable cros_ec-tps65090 driver.
BUG=chrome-os-partner:17813
TEST=compile kernel successfully see following object files created.
drivers/regulator/cros_ec-tps65090.o
Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: Iea2b04152d51ca74e81da3a1051281df7b913a91
Reviewed-on: https://gerrit.chromium.org/gerrit/43970
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Todd Broch [Fri, 15 Feb 2013 19:04:32 +0000 (11:04 -0800)]
CHROMIUM: regulator: chromeos_ec: control for TPS65090 FETS.
On spring, the TPS65090 is behind the EC on its host i2c interface.
This CL creates a driver to control those FETS via the EC's MKBP
interface.
BUG=chrome-os-partner:17813
TEST=manual,
1. compile & boot kernel (w/ hacked config)
2. See driver under sysfs
ls /sys/bus/platform/drivers/cros_ec-tps65090
Change-Id: I89082de44e3fa6ccce09b70bf3b191906f858dc1
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43548
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:49:17 +0000 (14:49 -0800)]
CHROMIUM: charger-manager: Make psy_name_buf a pointer
There doesn't seem to be any reason to use a buffer here, when a pointer
can be used. This avoids copying, a buffer, and the size limit.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
See that the battery is still found and accessed correctly by
charger-manager.
Change-Id: Iff78dfc4be112c68b95850ac5687fa335ce103ed
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43017
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:45:00 +0000 (14:45 -0800)]
CHROMIUM: charger-manager: Move temperature thresholds to pdata
Rather than require a function to handle temperature thresholds,
specify the thresholds so that charger-manager can do the right thing
automatically. This is is easier for clients to use, and more
device-tree-friendly
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
See that charger-manager works as before. There is currently no test
for temperature thresholds, so I manually printed them out after a
later change to see that they are correct.
Change-Id: Ide0efff77c3c4e7bd468abf9df3b80884014e28d
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43016
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:32:03 +0000 (14:32 -0800)]
exynos: i2c: Correct suspend/resume GPIO request/free
The gpio_request() is done in the resume handler, but the gpio_free()
is done in the suspend_noirq() handler. These do not match.
Where the system comes up partially from suspend and then goes back to
sleep (via the suspend_again handler), the suspend_noirq() handler
is called but the resume handler is not. This means that we free
the GPIOs but do not request them again, and thus we end up freeing
them again on each suspend_again.
Correct this by putting the gpio_free() into the suspend() handler
instead of suspend_noirq(). The effect is the same, for a full
suspend/resume cycle
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Suspend and resume and see that the i2c bus resumes correctly.
Using charger-manager, take the device through several suspend_again
cycles and see that warnings about multiple gpio_free() calls are
no longer present in the logs.
Change-Id: If11f02675d948959d81fbc5cf05cbb38605b4791
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43015
Reviewed-by: Doug Anderson <dianders@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:19:36 +0000 (14:19 -0800)]
CHROMIUM: power: Allow a power supply to be located by device node
Power supply naming depends on the attached bus and device. For example
an SBS device might have a name like sbs-004-1b, where the characters after
"sbs" come from the i2c bus to which the battery is attached.
This is not really suitable for device tree operation. We want to use a
phandle to point to the power supply, rather than hard-coded knowledge of
what linux might decide to name it.
Add a function to permit a power supply to be located by device node, which
is easy to discover from a phandle.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
See that charger-manager can locate the sbs battery correctly now when
using the device tree.
Change-Id: I0c906469e84406879285669c44f00224eee30136
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43014
Reviewed-by: Benson Leung <bleung@chromium.org>
Simon Glass [Sun, 3 Feb 2013 22:10:34 +0000 (14:10 -0800)]
CHROMIUM: rtc: Allow opening rtc by OF node
This new function allows a device tree phandle to be used to locate an rtc
class device. The name (rtc0, rtc1) depends on the device init order, which
means it cannot be used within the device tree.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Using charger-manager, select either rtc0 or rtc1 as the rtc to use for
the timer alarms, and see that charger-manager wakes up and behaves
correctly in suspend_again() in each case.
Change-Id: Ia6206b26cd74297f16b8e68caf97b6f390f4a7c5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43013
Reviewed-by: Benson Leung <bleung@chromium.org>
Benson Leung [Fri, 15 Feb 2013 23:57:05 +0000 (15:57 -0800)]
CHROMIUM: atkbd: Enable wake events
Init wakeup on the atkbd so that keyboard activity increments
/sys/power/wakeup_count.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:38844
TEST=cat /sys/power/wakeup_count
Press a key on the keyboard
cat /sys/power/wakeup_count
See that the number has incremented in response.
Change-Id: I74869db3a8d88400990433186e0acdb541d58162
Reviewed-on: https://gerrit.chromium.org/gerrit/43938
Reviewed-by: Daniel Erat <derat@chromium.org>
Tested-by: Daniel Erat <derat@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Sean Paul [Thu, 21 Feb 2013 18:36:33 +0000 (13:36 -0500)]
drm/exynos: Split crtc from encoder
This patch removes all calls from exynos_crtc directly into
exynos_encoder and instead relies on drm to do the right thing (which it
does).
BUG=None
TEST=Tested on snow, hotplug/suspend/resume/idle on & off
Change-Id: Iddb907c3a028afe0e9155ef2a0b78aec8612d784
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43518
Sean Paul [Tue, 19 Feb 2013 17:49:43 +0000 (12:49 -0500)]
drm/exynos: Don't reset mixer on win_disable
This patch removes code which resets the mixer on win_disable of the
default overlay. The effect of this code is that it disables interrupts,
and resets all mixer registers to power-on-reset values, then
re-enables interrupts. The code was introduced in the S2R patch, it
probably hacked around a bug, but it's not needed any longer.
BUG=None
TEST=on snow; powerd_suspend/idle off/idle suspend/hotplug/multiple boots
Change-Id: Id65650c7ab7a4cbc508a2087d4354b780acdce1a
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43517
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Mathias Krause [Sat, 23 Feb 2013 18:29:07 +0000 (10:29 -0800)]
CHROMIUM: sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
BUG=chromium-os:39185
TEST=link build, exploit PoC fails
Change-Id: I6f924e8849f60e1a98cdc16cbcb8d4ef5ce611e1
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43867
Reviewed-by: Olof Johansson <olofj@chromium.org>
Vincent Palatin [Wed, 20 Feb 2013 16:33:27 +0000 (08:33 -0800)]
CHROMIUM: i2c: wire the smart battery passthrough
On Spring, the smart battery is behind the EC.
We are connecting the regular SBS I2C driver and translating i2c
messages for the smart battery to the matching EC commands.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17812
TEST=on Spring, read the battery status by using "power-supply-info"
command.
Change-Id: I4d1353d740201935e1bb9566a08f1a81b0262232
Reviewed-on: https://gerrit.chromium.org/gerrit/43610
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Fri, 22 Feb 2013 00:58:44 +0000 (16:58 -0800)]
CHROMIUM: mfd: chromeos_ec: instantiate sub-devices from device tree
If the EC device tree node has sub-nodes, try to instantiate them as MFD
sub-devices.
We can configure the EC features provided by the board.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17812
TEST=on Spring, check that flashrom is working to re-flash the EC
firmware.
Change-Id: Ib1501eb3408cc13acb05073928ee958cd94f9107
Reviewed-on: https://gerrit.chromium.org/gerrit/43783
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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: EC related configuration is per board
Move the Smart Battery configuration to board-specific files.
On Daisy and Snow, the Smart Battery is on the same as the EC,
on Spring, it is behind the EC.
Declare board dependant EC sub-devices as children of the EC node.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17812
TEST=on both Snow and Spring, check that "power-supply-info" returns
acceptable values.
Change-Id: I290e5e8f3591df29a20734e9eff7eb6e03f4a1ec
Reviewed-on: https://gerrit.chromium.org/gerrit/43609
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Tue, 19 Feb 2013 20:47:30 +0000 (12:47 -0800)]
CHROMIUM: drm/exynos: dp: configure GPIO for eDP hotplug detection
the HPD line from the Parade eDP/LVDS bridge is used to trigger the
display controller initialization. Let's configure it as a proper
interrupt line to allow the Exynos display port controller driver to use
it.
The current Exynos needs special hackery to plug an interrupt on a
random GPIO.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17228
TEST=on Spring, boot and see the counter of the HPD interrupt from
the eDP bridge incrementing.
Change-Id: I15c612fe57c0dab98e18c58e1ef092fd8e103a92
Reviewed-on: https://gerrit.chromium.org/gerrit/43535
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Vincent Palatin [Fri, 22 Feb 2013 17:01:33 +0000 (09:01 -0800)]
CHROMIUM: arm: s5p: fix section mismatch for gpioint
The gpioint irq creation might be called from hotpluggable devices,
so it needs to be marked as __devinit (and as nothing in the future).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12625
TEST=emerge-daisy_spring chromeos-kernel with
"CONFIG_DEBUG_SECTION_MISMATCH=y" and do not see any warning.
Change-Id: Ibc0880c90a4002063fd95e752e3fe417455afd22
Reviewed-on: https://gerrit.chromium.org/gerrit/43786
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Thu, 21 Feb 2013 16:08:07 +0000 (08:08 -0800)]
CHROMIUM: arm: s5p: add suspend/resume support to GPIO interrupts
We need to restore the GPIO external interrupt configuration and mask
registers after resume as the hardware has lost those registers content.
We just use the cache maintained by the generic-irq layer.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12625
TEST=manually check the EXTINT registers content before and after a
suspend/resume cycle, and no longer see an interrupt storm after
resuming.
Change-Id: I950362c8d2c7126f5a10502b414cee2d12d2cd4d
Reviewed-on: https://gerrit.chromium.org/gerrit/43726
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Sonny Rao [Thu, 21 Feb 2013 01:45:06 +0000 (17:45 -0800)]
CHROMIUM: bluetooth/usb: hack to cover up dma after free corruption
This is a horrible, gross hack to cover up the fact that we
sometimes get an apparent DMA from the interrupt endpoint on the
bluetooth module after shutting it down. This ends up manifesting as
random kernel crashes, often from other users of kmalloc-16.
Since we don't have root cause (yet?) and can't do much about it, put
in this band-aid which will leak around 64 bytes of memory every time we
suspend/resume a usb bluetooth device. We make no attempt to free
this memory because we don't know when the DMA could come in and it's
a relatively small amount so probably not worth trying to free it
later.
Another issue is that SLUB will mix together objects from different
slabs if they are all the same size. So, in order to get a separate
slab in /proc/slabinfo, we turn on some of the slab debugging options.
The main reason for doing this is to let us track how much memory got
leaked through slabinfo. This will trigger a BUG_ON() in
kmem_cache_create() if the kernel is compiled with
CONFIG_SLAB && !CONFIG_DEBUG_SLAB.
One day, when we have a real fix, we should remove this abomination.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chrome-os-partner:12507
BUG=chrome-os-partner:17614
TEST=repeated suspend resume, should not see a kernel crash
Change-Id: Iebdfe033d178c664a91fce1164b255aa1c322ad0
Reviewed-on: https://gerrit.chromium.org/gerrit/43682
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Vincent Palatin [Sat, 16 Feb 2013 01:11:25 +0000 (17:11 -0800)]
CHROMIUM: gpio: samsung: add support for interrupts on Exynos5 GPIOs
Add support for interrupts on all bank A and B GPIOs on Exynos 5,
in addition of the current XEINT pins.
Re-use the current Exynos4 / s5p code to minizime this CL overhead as we
probably won't use more that a couple of those interrupts but it's not
optimal in term of performance and it requires to do an explicit
5p_register_gpio_interrupt in the platform code for each GPIO used as an
interrupt.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17228 chrome-os-partner:12625
TEST=on Spring, boot and see the counter of the HPD interrupt from the
eDP bridge incrementing.
Change-Id: I60bbe8e96d4028393f82e5717fdfa9ca19eb0773
Reviewed-on: https://gerrit.chromium.org/gerrit/43533
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Thu, 21 Feb 2013 18:35:49 +0000 (13:35 -0500)]
drm/exynos: Remove crtc->disable
Remove the crtc->disable callback since it's not needed and most likely
incorrect anyways. DRM will fall back to dpms if disable is not defined,
and that will simplify the various paths we have. Furthermore, all
disable did was disable the default overlay on the crtc, which is not
the intended result.
BUG=None
TEST=Tested on snow with boot/hotplug/suspend/idle
Change-Id: I2b134662bfa56d35a0de9fbf761d7a8a3708009e
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43725
Sean Paul [Thu, 21 Feb 2013 18:18:03 +0000 (13:18 -0500)]
drm/exynos: Don't win_disable if mixer is off
The win_disable function shouldn't be called when the mixer is off. This
also prevents us from waiting for a vsync that will never happen (occurs
twice on boot, adding 2 seconds to the boot time).
BUG=None
TEST=Tested on snow, verified no regressions
Change-Id: I59e0df06336bbd28440cddf814b233e0027637c2
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43724
Vic Yang [Thu, 21 Feb 2013 07:46:12 +0000 (15:46 +0800)]
CHROMIUM: exynos: dts: enable OHCI controller and EHCI port 0
Now that we have proper hardware to prevent electrical conflict, we can
re-enable OHCI controller and port 0 on EHCI.
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:14319
TEST=boot Spring and verify USB functionality.
Change-Id: Ia0a3e5bb32a5e679b4bfb8158505172b84b57a08
Reviewed-on: https://gerrit.chromium.org/gerrit/43710
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Chung-yih Wang [Tue, 19 Feb 2013 10:47:05 +0000 (18:47 +0800)]
CHROMIUM: Input: synaptics - skip trackpoint reconnect
Since trackpoint properties are probed in the boot time, it should
be safe to skip the reconnect function as we don't need to
probe the properties again to reduce the latency of unresponsiveness.
BUG=chrome-os-partner:15015
TEST=on device; use powerd_suspend and then hit a key to wake it up
see if the trackpoint/trackpoint could be active in 3~4 seconds
after resume instead of 7 seconds long
Change-Id: I7286fe97dfd4a68dbbca0aa411eb15b0d2bcd67d
Signed-off-by: Chung-yih Wang <cywang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43510
Tested-by: Agnes Cheng <agnescheng@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
Ben Chan [Thu, 21 Feb 2013 01:33:43 +0000 (17:33 -0800)]
CHROMIUM: USB: option: don't show error when urb is killed in an expected way
When a device supported by the option driver is suspended, the interrupt
urb is killed and option_instat_callback() is invoked with the urb's
status set to -ENOENT. The patch prevents the option driver from
spamming the log with a message 'option_instat_callback: error -2' under
such scenario.
BUG=chrome-os-partner:17918
TEST=Tested the following on link:
1. Put the system on battery so that USB auto-suspend is turned on for
the Novatel E362 modem.
2. Verify that the option kernel drive no longer prints the following
error to /var/log/messages:
option: option_instat_callback: error -2
Change-Id: Ia2d52c3331499b0713455b65c13e2b34dbc48d16
Signed-off-by: Ben Chan <benchan@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43680
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Abhilash Kesavan [Thu, 21 Feb 2013 03:48:21 +0000 (09:18 +0530)]
arm: exynos: Fix PMU register configuration for local power blocks
For the six local power blocks - MFC, DISP1, GSC, MAU, G3D and ISP
the respective CMU_RESET, CMU_SYSCLK and CMU_CLKSTOP registers need
to be low initially for normal mode. This change has been updated
only in the latest Exynos5250 1.10 user manual. Also fix the AFTR
and LPA configurations even though they are not being used.
There are no known issues fixed by doing this, though had we done this
originally for CMU_RESET_ISP_SYS_PWR_REG I believe we wouldn't have
ever hit the problems that ISP ARM was causing us with suspend/resume
(we wouldn't have had the perfect poweroff sequence for ISP ARM but
wouldn't have hit issues).
BUG=chrome-os-partner:17459
TEST=Boot to login screen on an MP and run suspend_stress_test
Change-Id: I15453224a7f9aed5de477827713e58e8edbe499d
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42097
Vincent Palatin [Tue, 19 Feb 2013 23:09:13 +0000 (15:09 -0800)]
CHROMIUM: mfd: chromeos_ec: update EC<->AP protocol
Update the EC commands header with an up-to-date version including
the new pass-through commands.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17812 chrome-os-partner:17813
TEST=emerge-daisy_spring chromeos-kernel
Change-Id: Ic7f1d06bd2219f1314646ae6d803365b6e008ae6
Reviewed-on: https://gerrit.chromium.org/gerrit/43608
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Benson Leung [Thu, 21 Feb 2013 18:14:07 +0000 (10:14 -0800)]
CHROMIUM: Platform: x86: chromeos_laptop - Change identifiers for Pixel
Change the names of the setup functions for Pixel's atmel
touchscreen and touchpad.
Also, enable the name search for "touchscreen" for the atmel 1664s
irq number in dmi data.
Finally, change some of the Chromebook Pixel related identifiers
in chromeos_laptop_dmi_table.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:17951
TEST=Builds clean. Touchscreen, touchpad, and keyboard backlight all work.
Change-Id: I6945c5d64aea6943ea8468f761a8213eb4d4b498
Reviewed-on: https://gerrit.chromium.org/gerrit/43727
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Yufeng Shen [Mon, 21 Jan 2013 19:45:10 +0000 (14:45 -0500)]
HID: multitouch: Add quirks for Stantum MTP Controller
[NOT FOR UPSTREAM, TEST ONLY]
In each frame, Stantum controller sends back first HID_DG_CONTACTCOUNT
to indicate how many active contacts are in the frame. Then the
controller sends back the state of a fixed number touches, with the
first HID_DG_CONTACTCOUNT touches being valid touches. The generic
hid-multitouch implementation will exam all the sent back touches and
get confused by relying on some other unreliable information like
HID_DG_INRANGE and HID_DG_TIPSWITCH to determine active touches.
This CL adds the quirk for Stantum to only consider the first
HID_DG_CONTACTCOUNT number of touches as active touches.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
BUG=chrome-os-partner:17333
TEST=boot chromebook, plug in the touch device, using mtplot to
make sure it works as expected.
Change-Id: I2a050567c758e3df65aff9cfce1c579f4c98eebb
Reviewed-on: https://gerrit.chromium.org/gerrit/41724
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Queue: Yufeng Shen <miletus@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
Todd Broch [Thu, 21 Feb 2013 15:44:40 +0000 (07:44 -0800)]
CHROMIUM: exynos: dts: Move TPS65090 to per board configs.
Move the TPS65090 specification from the common cros5250 to each
board. This will allow for spring to place TPS65090 behind the EC.
BUG=chrome-os-partner:17813
TEST=manual,
1. Boot kernel, login as root
2a. On Snow see regulators still enumerated in sysfs,
cat /sys/devices/s3c2440-i2c.4/i2c-4/4-0048/tps65090-regulator/regulator/regulator.*/name
2b. On Spring device still functions but devices are NOT in sysfs
Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: I9837062a851b677c3c8844e6b6503450aa4ed555
Reviewed-on: https://gerrit.chromium.org/gerrit/43718
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sean Paul [Wed, 13 Feb 2013 19:52:26 +0000 (14:52 -0500)]
drm/exynos: Untangle dpms a little
This patch strives to simplify the various dpms paths. The overarching
goal is to not get into a situation where connector->dpms is out of
touch with the rest of the driver since that effectively disables
userspace control of the power. The patch also eliminates the duplicate
paths through crtc and encoder.
BUG=chromium-os:37797
TEST=Tested hotplug; idle suspend/resume; idle off/on; lid
suspend/resume; powerd_suspend/resume. No regressions noted
Change-Id: I79376e07500633505eb0159edac9a4ed9054b0e4
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43196
Sean Paul [Tue, 19 Feb 2013 17:25:20 +0000 (12:25 -0500)]
drm/exynos: Remove apply() callback
Remove the apply() callback from the panel and controller ops, it really
doesn't make sense.
BUG=None
TEST=Booted snow, suspend/resume/hotplug no regressions
Change-Id: I1df3a368409aa2bbd0d69866f365d6baa0786025
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43516
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Sean Paul [Wed, 23 Jan 2013 20:16:38 +0000 (15:16 -0500)]
CHROMIUM: drm/exynos: Drop non-essential frames on dpms off
This patch drops all frames except for the last pending one when a crtc
is disabled. It will also wait on the last frame to render before
returning from DPMS off.
BUG=chromium-os:37797
TEST=Tested manually:
- Plug/unplug HDMI with no content on the HDMI monitor
- Plug/unplug HDMI with animation (sad puppy) on HDMI monitor
- Plug/unplug HDMI with animation + cursor movement on monitor
- Suspend/resume with animation on monitor
- Idle suspend/resume
Change-Id: I3e26e8bac9be0d71cf3c0756d1cc3dd92d2612de
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41772
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Sean Paul [Wed, 20 Feb 2013 22:20:35 +0000 (17:20 -0500)]
drm/exynos: Disable fimd interrupts on power off
Disable fimd interrupts on power off.
BUG=None
TEST=Tested on snow with powerd_suspend and idle off
Change-Id: I37734b62b03b79b922b93c821e606a9ba77d26a1
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43640
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Sean Paul [Wed, 20 Feb 2013 21:59:14 +0000 (16:59 -0500)]
drm/exynos: Remove irq_flags kruft
Remove the irq_flags kruft from the enable/disable vblank functions. It
only serves to make things less deterministic and more confusing.
BUG=None
TEST=Tested suspend/resume on snow, no regressions
Change-Id: I3255b55ee5480cf6313de766d35ae84401343312
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43639
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
John Sheu [Wed, 13 Feb 2013 22:03:59 +0000 (14:03 -0800)]
CHROMIUM: s5p-mfc: fix DISPLAY_DELAY
V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE is being
ignored, and the display delay is always being applied. Fix this.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium:175638
BUG=chromium-os:38121
BUG=chromium-os:38376
BUG=chromium-os:38693
TEST=local build, run on snow
Change-Id: I0bfd3cfbb3ec312c073eed5e39bfd2e1637bee3c
Reviewed-on: https://gerrit.chromium.org/gerrit/43677
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
John Sheu [Wed, 13 Feb 2013 21:53:56 +0000 (13:53 -0800)]
CHROMIUM: s5p-mfc: Fix input/output format reporting
The video encode/decode paths have duplicated logic between
VIDIOC_TRY_FMT and VIDIOC_S_FMT that should be de-duped. Also, video
decode reports V4L2_PIX_FMT_NV12MT_16X16 output format, regardless of
what the actual output has been set at. Fix this.
Signed-off-by: John Sheu <sheu@google.com>
BUG=chromium-os:38376
TEST=local build, run on snow
Change-Id: I82272ebe5d46cd78339616795fd96f688fecdabe
Reviewed-on: https://gerrit.chromium.org/gerrit/43676
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
Tested-by: John Sheu <sheu@chromium.org>
Grant Grundler [Wed, 13 Feb 2013 21:52:31 +0000 (13:52 -0800)]
UPSTREAM: exynos: add basic diagnostic output for IOMMU faults
Give some visibility into which devices are hitting problems and
which type of faults they are generating.
Code is roughly what pullip.cho@samsung.com suggested in
http://crosbug.com/37066
Equivalent code is present upstream in exynos-iommu.c:default_fault_handler()
Author: KyongHo Cho <pullip.cho@samsung.com>
Date: Sat May 12 05:56:09 2012 +0900
iommu/exynos: Add iommu driver for EXYNOS Platforms
BUG=chromium-os:37066
TEST=manually injected fault to trigger output.
Change-Id: I06e1d1214578033b72b5aa51c228f13cb4443bcb
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43235
Reviewed-by: Doug Anderson <dianders@chromium.org>
Mandeep Singh Baines [Wed, 13 Feb 2013 03:44:46 +0000 (19:44 -0800)]
CHROMIUM: coredump: prevent crash pipe reader from blocking suspend
Also, prevent hung_task detector from panic()ing the system.
$ # TEST CODE
$ cat pthread_test.c
\#include <pthread.h>
\#include <assert.h>
\#include <unistd.h>
void *task_code(void *argument)
{
pause();
return NULL;
}
int main(int argc, char *argv[])
{
pthread_t thread;
int rc;
rc = pthread_create(&thread, NULL, task_code, NULL);
assert(0 == rc);
rc = pthread_join(thread, NULL);
assert(0 == rc);
return 0;
}
$
$ # TEST PROCESS
$ stop daisydog
$ echo "|/usr/bin/sleep 1d" > /proc/sys/kernel/core_pattern
$ ./pthread_test &
[1] 2872
$ kill -ABRT $!
$ echo mem > /sys/power/state
Sent-upstream: http://thread.gmane.org/gmane.linux.kernel/
1441805
BUG=chrome-os-partner:16961
TEST=See above.
Change-Id: I504c210ec7e65f210240c99892d14e73b482b5da
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43163
Todd Broch [Wed, 20 Feb 2013 16:34:45 +0000 (08:34 -0800)]
CHROMIUM: mfd: s5m-core: Enable low-jitter via DT.
Provide facility via device tree to activate the low-jitter
capababilities of the 32Khz clocks (BT, CP, AP). Note the feature is
enabled for all the clocks or none per the design
Additionally fixed two small nits:
1. added __devinit to declaration of probe function
2. fixed function name of s5m87xx_i2c_parse_dt_pdata for the case when
CONFIG_OF is undefined
BUG=chrome-os-partner:17833 chrome-os-partner:17858
TEST=manual
1. boot kernel, login as root
2. examine CTRL1 (0xa) register and see Low Jitter_EN bit (<3>) is
enabled for the spring design.
i2cget -y -f 0 0x66 0xa
0xf
Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: I80750a3049806692c1c1e214982577f2f39899e1
Reviewed-on: https://gerrit.chromium.org/gerrit/43624
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Oleg Nesterov [Sun, 17 Feb 2013 19:19:05 +0000 (20:19 +0100)]
CHROMIUM: coredump: sanitize the setting of signal->group_exit_code
Now that the coredumping process can be SIGKILL'ed, the setting of
->group_exit_code in do_coredump() can race with complete_signal()
and SIGKILL or 0x80 can be "lost", or wait(status) can report
status == SIGKILL | 0x80.
But the main problem is that it is not clear to me what should we
do if binfmt->core_dump() succeeds but SIGKILL was sent, that is
why this patch comes as a separate change.
This patch adds 0x80 if ->core_dump() succeeds and the process was
not killed. But perhaps we can (should?) re-set ->group_exit_code
changed by SIGKILL back to "siginfo->si_signo |= 0x80" in case when
core_dumped == T.
Under review upstream:
http://thread.gmane.org/gmane.linux.kernel/
1442910
BUG=chrome-os-partner:16961
TEST=See "coredump: prevent crash pipe reader from blocking suspend."
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I96e81bfea6cb5e21e59f2500f502fe1e9c673b43
Reviewed-on: https://gerrit.chromium.org/gerrit/43580
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Oleg Nesterov [Sun, 17 Feb 2013 19:19:02 +0000 (20:19 +0100)]
CHROMIUM: coredump: ensure that SIGKILL always kills the dumping thread
prepare_signal() blesses SIGKILL sent to the dumping process but
this signal can be "lost" anyway. The problems is, complete_signal()
sees SIGNAL_GROUP_EXIT and skips the "kill them all" logic. And even
if the dumping process is single-threaded (so the target is always
"correct"), the group-wide SIGKILL is not recorded in task->pending
and thus __fatal_signal_pending() won't be true. A multi-threaded
case has even more problems.
And even ignoring all technical details, SIGNAL_GROUP_EXIT doesn't
look right to me. This coredumping process is not exiting yet, it can
do a lot of work dumping the core.
With this patch the dumping process doesn't have SIGNAL_GROUP_EXIT,
we set signal->group_exit_task instead. This makes signal_group_exit()
true and thus this should equally close the races with exit/exec/stop
but allows to kill the dumping thread reliably.
Notes:
- It is not clear what should we do with ->group_exit_code
if the dumper was killed, see the next change.
- we need more (hopefully straightforward) changes to ensure
that SIGKILL actually interrupts the coredump. Basically we
need to check __fatal_signal_pending() in dump_write() and
dump_seek().
Under review upstream:
http://thread.gmane.org/gmane.linux.kernel/
1442910
BUG=chrome-os-partner:16961
TEST=See "coredump: prevent crash pipe reader from blocking suspend."
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I92d0458f179bacb816a548c274e2dc83bb6c374d
Reviewed-on: https://gerrit.chromium.org/gerrit/43579
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Oleg Nesterov [Sun, 17 Feb 2013 19:18:49 +0000 (20:18 +0100)]
CHROMIUM: coredump: only SIGKILL should interrupt the coredumping task
There are 2 well known and ancient problems with coredump/signals,
and a lot of related bug reports:
- do_coredump() clears TIF_SIGPENDING but of course this can't help
if, say, SIGCHLD comes after that.
In this case the coredump can fail unexpectedly. See for example
wait_for_dump_helper()->signal_pending() check but there are other
reasons.
- At the same time, dumping a huge core on the slow media can take a
lot of time/resources and there is no way to kill the coredumping
task reliably. In particular this is not oom_kill-friendly.
This patch tries to fix the 1st problem, and makes the preparation
for the next changes.
We add the new SIGNAL_GROUP_COREDUMP flag set by zap_threads() to
indicate that this process dumps the core. prepare_signal() checks
this flag and nacks any signal except SIGKILL.
Note that this check tries to be conservative, in the long term we
should probably treat the SIGNAL_GROUP_EXIT case equally but this
needs more discussion. See marc.info/?l=linux-kernel&m=
120508897917439
Notes:
- recalc_sigpending() doesn't check SIGNAL_GROUP_COREDUMP.
The patch assumes that dump_write/etc paths should never
call it, but we can change it as well.
- There is another source of TIF_SIGPENDING, freezer. This
will be addressed separately.
Under review upstream:
http://thread.gmane.org/gmane.linux.kernel/
1442910
BUG=chrome-os-partner:16961
TEST=See "coredump: prevent crash pipe reader from blocking suspend."
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: I2a660ef2e61d5132dad2aedbcd543d08f1003beb
Reviewed-on: https://gerrit.chromium.org/gerrit/43578
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Mandeep Singh Baines [Thu, 14 Feb 2013 22:49:54 +0000 (14:49 -0800)]
CHROMIUM: lockdep: check that no locks held at freeze time
We shouldn't try_to_freeze if locks are held. Verified that
I get no lockdep warnings after applying this patch and
"vfork: don't freezer_count() for in-kernel users of CLONE_VFORK".
Sent-upstream: http://thread.gmane.org/gmane.linux.kernel/
1441805
BUG=chrome-os-partner:16961
TEST=Verified that there are no lockdep warnings across suspend/resume.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Change-Id: Iba1f22a51aaff4f2cf2c2f95ffa88ad3c7df97ff
Reviewed-on: https://gerrit.chromium.org/gerrit/43347
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Grant Grundler [Wed, 6 Feb 2013 01:51:04 +0000 (17:51 -0800)]
CHROMIUM: watchdog: add WDIOC_GETBOOTSTATUS support to s3c2410_wdt
Exynos5 can report the most recent "reset" (or boot) cause. In particular,
WDIOC_GETBOOTSTATUS ioctl (to /dev/watchdog) can let users know if
the HW watchdog timed out and reset the machine.
BUG=chrome-os-partner:9403
TEST=manual
Change-Id: Iceb63d8404e25200846f75e6ce44da62749246dd
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42759
Reviewed-by: Doug Anderson <dianders@chromium.org>
Grant Grundler [Wed, 6 Feb 2013 02:10:57 +0000 (18:10 -0800)]
CHROMIUM: exynos: log when watchdog timeout triggers a reset
If the HW watchdog timer (WDT) resets the machine, there is no panic.
This patch prints a warning HW WDT timed out (dmesg buffer) and
enables daisydog (or watchdog) daemon to query /dev/watchdog via
WDIOC_GETBOOTSTATUS ioctl.
BUG=chrome-os-partner:9403
TEST=./run_remote_tests.sh --board=daisy --remote=192.168.1.100 platform_HWwatchdog
and check dmesg output for "Watchdog timed out" message.
Change-Id: Ic559244af48773ae7fc35d462620c1ef98f98a4d
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42760
Reviewed-by: Doug Anderson <dianders@chromium.org>
Simon Glass [Sat, 2 Feb 2013 05:52:24 +0000 (21:52 -0800)]
CHROMIUM: power: Allow bus used for power supply to be found
Some power supplies such as batteries are connected via a bus such as i2c.
When we want to resume the battery we must resume the bus also, otherwise
it will not be possible to communicate with it.
Add a function which returns the device that a power supply is connected
on, to permit a caller to resume the bus also.
BUG=chrome-os-partner:10617
TEST=build and boot to kernel prompt on snow
Use charger-manager, with other changes, and see that in the
suspend_again() handler, the battery temperature can be read successfully.
This indicates that the i2c bus is working properly.
Change-Id: I1f19606861e0cb7f86621c2ad22415d7761cb060
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43012
Reviewed-by: Benson Leung <bleung@chromium.org>
Vincent Palatin [Tue, 19 Feb 2013 21:26:58 +0000 (13:26 -0800)]
CHROMIUM: exynos: dts: allow to switch off eDP bridge regulator
We want to control the 1.2v regulator going to the eDP bridge from the
Parade driver.
In order to do this, we don't want to force it on all the time.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17866
TEST=on Spring, suspend with regulator traces and see the vdd_bridge
regulator going off.
Change-Id: I280844b3225cfa0f817a04190ca24779d26fa999
Reviewed-on: https://gerrit.chromium.org/gerrit/43532
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Bing Zhao [Tue, 19 Feb 2013 20:06:20 +0000 (12:06 -0800)]
UPSTREAM: mwifiex: improvement in cfg80211 set_bitrate_mask handler
This patch configures data rates to firmware using bitrate mask
provided by cfg80211.
Earlier we used to only update band information in this handler
which will be used later for ibss network. Due to recent
modifications in ibss join code we don't need to do that.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
BUG=chrome-os-partner:17764
TEST=associate to 5G 11n AP nearby, iw link shows tx bitrate MCS-15.
disconnect and re-connect, association succeeds and iw link still
shows MCS-15.
Change-Id: Iba896d38674517549a162bd7f2627dd00c6f6dd0
Reviewed-on: https://gerrit.chromium.org/gerrit/43523
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Vincent Palatin [Tue, 19 Feb 2013 21:31:23 +0000 (13:31 -0800)]
CHROMIUM: regulator: s5m8767: properly disable regulators
Whatever the default operating mode of a regulator is, we want to ensure
that we are actually putting 0 in the mode to disable it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:17866
TEST=manual
Change-Id: Ic019c92a72b3a97b6ea06657b4f57774337519de
Reviewed-on: https://gerrit.chromium.org/gerrit/43531
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Paul Stewart [Fri, 15 Feb 2013 22:03:48 +0000 (14:03 -0800)]
CHROMEOS: config: Enable addrtype iptables match
This enables the "addrtype" matches to iptables. This will allow
iptables rules to match the type of source and destination addresses
that should be matched. This allows us to classify incoming packets
as "unicast" (intended directly for us) which will allow us to
restrict the types of packets sent to userspace for multicast-reply
classification. See CL
https://gerrit.chromium.org/gerrit/#/c/43447/3/iptables.conf for an
example of how this will be used.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chromium-os:38605
TEST=Compile kernel, ensure iptables works correctly with "-m addrtype" rule
Change-Id: I5cb191453b9458f9014a6494574ccdc151d99d75
Reviewed-on: https://gerrit.chromium.org/gerrit/43426
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Luigi Semenzato [Tue, 4 Dec 2012 18:41:21 +0000 (10:41 -0800)]
CHROMIUM: BACKPORT: mm: better fix for OOM killer hang
This change replaces a previous fix for crosbug.com/32321
(https://gerrit.chromium.org/gerrit/#/c/36953) with a better
fix which David Rentjes applies upstream (this is the equivalent
change). I have studied and tested David's change and it also
avoids the deadlock. In addition, our change has the potential
for unnecessarily killing processes that don't need to be killed.
Furthermore, it's probably better to track upstream more closely.
commit
9ff4868e3051d9128a24dd330bed32011a11421d
Author: David Rientjes <rientjes@google.com>
AuthorDate: Tue Dec 11 16:01:30 2012 -0800
Commit: Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Tue Dec 11 17:22:24 2012 -0800
mm, oom: allow exiting threads to have access to memory reserves
Exiting threads, those with PF_EXITING set, can pagefault and require
memory before they can make forward progress. This happens, for instance,
when a process must fault task->robust_list, a userspace structure, before
detaching its memory.
These threads also aren't guaranteed to get access to memory reserves
unless oom killed or killed from userspace. The oom killer won't grant
memory reserves if other threads are also exiting other than current and
stalling at the same point. This prevents needlessly killing processes
when others are already exiting.
Instead of special casing all the possible situations between PF_EXITING
getting set and a thread detaching its mm where it may allocate memory,
which probably wouldn't get updated when a change is made to the exit
path, the solution is to give all exiting threads access to memory
reserves if they call the oom killer. This allows them to quickly
allocate, detach its mm, and free the memory it represents.
Summary of Luigi's bug report:
: He had an oom condition where threads were faulting on task->robust_list
: and repeatedly called the oom killer but it would defer killing a thread
: because it saw other PF_EXITING threads. This can happen anytime we need
: to allocate memory after setting PF_EXITING and before detaching our mm;
: if there are other threads in the same state then the oom killer won't do
: anything unless one of them happens to be killed from userspace.
:
: So instead of only deferring for PF_EXITING and !task->robust_list, it's
: better to just give them access to memory reserves to prevent a potential
: livelock so that any other faults that may be introduced in the future in
: the exit path don't cause the same problem (and hopefully we don't allow
: too many of those!).
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Tested-by: Luigi Semenzato <semenzato@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium-os:38812
TEST=manually tested in a deadlock situation
Change-Id: If0c52a7009dbc7002d4b26ffe91a1a97989f2215
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39199
Dylan Reid [Fri, 15 Feb 2013 00:00:50 +0000 (16:00 -0800)]
CHROMIUM: ASoC: samsung: Enable daisy platform to support MAX98088.
The Spring board will use the MAX98088 instead of the MAX98095. Add
the ability to use this codec to the daisy platform driver.
BUG=chrome-os-partner:17794
TEST=play audio on snow and spring.
Change-Id: I7beb941d931d198a37d50e970821b8a32786a2e3
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Oleg Nesterov [Mon, 21 Jan 2013 19:48:17 +0000 (20:48 +0100)]
UPSTREAM: wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task
wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
Change it to use TASK_NORMAL and add the WARN_ON().
TASK_ALL has no other users, probably can be killed.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium-os:38610
TEST=link build
Change-Id: I6573a5341e55309f10d3597d2fcf40a0b8e9d73a
(cherry picked from upstream commit
9067ac85d533651b98c2ff903182a20cbb361fcb)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43145
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
projects / cascardo / linux.git / log