Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Chromeos 2.6.38 #2

Merged
merged 170 commits into from Aug 22, 2011

Conversation

Projects
None yet
Contributor

muromec commented Aug 22, 2011

апстрим замержил, драйвер своей батарейки додал, регуляторов въебал. посмотри, или тебе поможет с x11perf

Jason Glasgow and others added some commits Jul 22, 2011

Jason Glasgow CHROMIUM: gobi: set needs_remote_wakeup to fix problems with autosuspend
set needs_remote_wakeup to 1 when probing the device.  Otherwise the
device does not seem to wake up properly when autosuspend occurs.
This can cause problems when connecting and the connect does not
finish before autosuspend, or when an SMS arrives but the module is suspended.

BUG=chrome-os-partner:4832
TEST=run without AC power, connect and disconnect many times

Signed-off-by: Jason Glasgow <jglasgow@chromium.org>

Change-Id: I48f11ffea6cd894c143acda5cac4017641bf80d5
Reviewed-on: http://gerrit.chromium.org/gerrit/4609
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: Jason Glasgow <jglasgow@chromium.org>
485be11
@vpalatin Joseph Lo CHROMIUM: arm: tegra: fix L2 been disabled after LP2
This is caused by the LP2 save the L2 control registers after the L2
been disabled. When the LP2 been resumed back, the L2 been restore to
disable state. Using the same procedure in LP0/LP1. when system resume
back, call a c code L2 restart func.

BUG=chrome-os-partner:5075
TEST=check the L2 control register been enabled after LP2 on T20/T25, it's OK

Change-Id: I3010872c8d133055fd66052f3e949b36723b4073
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4566
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
6046aaa
@vpalatin vpalatin CHROMIUM: USB: cdc-acm: fix possible null pointer in acm_tty_hangup
Sometimes, acm_tty_hangup and acm_tty_close are called concurrently.
This results in acm pointer being null in acm_tty_hangup and aborts when
it is dereferenced.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:5053
TEST=on Alex with YT3300 modem, connect to 3G network, then open/close
the lid to suspend/resume the machine and observe there is no kernel
panic.

Change-Id: Ied0ff4448ef1f7a48ef34a3a1fffb1b6568e25fe
Reviewed-on: http://gerrit.chromium.org/gerrit/4672
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
df05a65
@atseanpaul atseanpaul CHROMIUM: ARM: tegra: asymptote: Insert the correct LCD timing values.
Replace the currently incorrect LCD timings with the correct LCD timings.

BUG=None
TEST=Booted Asymptote, verified LCD worked

Change-Id: I6e2691a273e5530f4783a12ac46bcabf8b892c6b
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4545
Reviewed-by: Doug Anderson <dianders@chromium.org>
dd46b50
Thieu Le Revert "ecryptfs: modify write path to encrypt page in writepage"
This reverts commit 92fad83.

Signed-off-by: Thieu Le <thieule@chromium.org>

BUG=chromium-os:17459
TEST=Build, boot, login, surf

Change-Id: I6498acbfdc73392d687734b7553b1575203abe5b
Reviewed-on: http://gerrit.chromium.org/gerrit/4688
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Thieu Le <thieule@chromium.org>
4d4ca2e
Mandeep Singh Baines CHROMIUM: verity: use alloc_page instead of mempool_alloc
I ran a quick test and verified that mempool_alloc we are never
hitting the remove_element path of mempool_alloc so the 8MB of
mempool memory is never actually used.

Since dm-verity is read-only, its not part of memory reclaim. So a
memory pool is not neccesary. Since we alloc with GFP_KERNEL, an
allocation failure is highly unlikely. If an allocation does fail,
we already have code to handle the failure.

By removing the memory pool, we save 8 MB of RAM and save 1 ms on boot:

[    0.974280] before mempool_create_page_pool
[    0.975345] after mempool_create_page_pool

BUG=chromium-os:9752
TEST=Ran dm-verity.git unit tests. Ran platform_DMVerityCorruption on H/W.

Also ran platform_BootPerfServer:

Before:

  seconds_power_on_to_login                                       8.81
  seconds_power_on_to_login{1}                                    8.76
  seconds_power_on_to_login{2}                                    9.24
  seconds_power_on_to_login{3}                                    8.83
  seconds_power_on_to_login{4}                                    8.76
  seconds_power_on_to_login{5}                                    8.84
  seconds_power_on_to_login{6}                                    8.86
  seconds_power_on_to_login{7}                                    8.86
  seconds_power_on_to_login{8}                                    8.86
  seconds_power_on_to_login{9}                                    8.97

  Mean:  8.87
  Stdev: 0.14

After:

  seconds_power_on_to_login                                       8.92
  seconds_power_on_to_login{1}                                    9.06
  seconds_power_on_to_login{2}                                    8.96
  seconds_power_on_to_login{3}                                    8.71
  seconds_power_on_to_login{4}                                    8.99
  seconds_power_on_to_login{5}                                    8.89
  seconds_power_on_to_login{6}                                    8.77
  seconds_power_on_to_login{7}                                    8.96
  seconds_power_on_to_login{8}                                    8.95
  seconds_power_on_to_login{9}                                    8.95

  Mean: 8.91
  Stdev 0.10

The difference between the two runs is within stdev.

Change-Id: I9eddf2f01e6d3f09a010622d09485fac0924a8db
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4584
557e8ba
@yufengshen Iiro Valkonen UPSTREAM: Input: atmel_mxt_ts - handle objects with multiple instance…
…s correctly

Handle the objects with multiple instances correctly when the configuration
data is loaded.

Signed-off-by: Iiro Valkonen <iiro.valkonen@atmel.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit a93d4f2d023ea5e84c0104d4e479243c6ac77d17)

Signed-off-by: Yufeng Shen <miletus@chromium.org>

BUG=None
TEST=Manually deployed. Touchscreen driver loads and works properly.

Change-Id: Ia3fc026e90223c03b9b7b0c34e7659d4cd769d74
Reviewed-on: http://gerrit.chromium.org/gerrit/4066
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Tested-by: Yufeng Shen <miletus@chromium.org>
4d348b8
@yufengshen yufengshen CHROMIUM: ARM: Tegra: Seaboard: Set correct touchscreen config data f…
…or seaboard

Adjust the seaboard atmel touchscreen config data to have 2 instances of key
array config data, in corresponding with driver change

a93d4f2 Input: atmel_mxt_ts - handle objects with multiple instances

of drivers/input/touchscreen/atmel_mxt_ts.c

BUG=None
TEST=Tested with patched driver and the driver is loaded and working properly.

Change-Id: I28f97aa6ff532e8a312a5ce285b6328179a75eba
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4067
1e2b1c5
Sonny Rao UPSTREAM: perf: Robustify proc and debugfs file recording
While attempting to create a timechart of boot up I found perf didn't
tolerate modules being loaded/unloaded.  This patch fixes this by
reading the file once and then writing the size read at the correct
point in the file.  It also simplifies the code somewhat.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Link: http://lkml.kernel.org/r/10011.1310614483@neuling.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
(cherry picked from commit 259032bfe379281bf7cba512b7705bdb4ce41db5) from tip

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

BUG=chromium-os:16856
TEST=add timechart calls to chromeos_startup and boot up, verify valid perf.data file is generated

Change-Id: I248cafb4f8305683c723063684c8386693462a4e
Reviewed-on: http://gerrit.chromium.org/gerrit/4704
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
e955543
@rmorell @vpalatin rmorell CHROMIUM: video: tegra: Implement EDID query
This change implements the TEGRA_DC_EXT_CONTROL_GET_OUTPUT_EDID ioctl in
the dc_ext interface.

It first adds a way for the tegra dc EDID module to export EDID data
safely, without the risk of reading an incomplete or corrupted EDID in
the presence of hotplug, by moving the actual data to a substructure
with a lifetime maintained by a kref.  Then, that support is plumbed
through the hdmi block (which is currently the only way to get at the
EDID) and out to userspace.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Read the EDID for an HDMI monitor, both through the XRandR
interface and through the debugfs file /sys/kernel/debug/edid1

Change-Id: Icb32a2b08c40340afb9ad6d2d817ac3440265596
Reviewed-on: http://gerrit.chromium.org/gerrit/4632
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mark Hayter <mdhayter@chromium.org>
03e4d8d
@bopiy @dianders bopiy CHROMIUM: arm: tegra: seaboard: power gate PCIE partition
Power gate PCIE partition since seaboard doesn't use it

BUG=none
TEST=built kernel and boot.

Change-Id: I21651c7a1b558583ad6a7dc5bf1f858ecf74bd72
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/3784
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
2fbde90
@vpalatin Wei Ni CHROMIUM: media: tegra: avp: Fix avp_svc_thread shutdown
Avoid exiting from avp_svc_thread in error case.
Add nicer messages.
Fix the race condition between kthread_stop() and wait.
Without this fix, the following message was printed.
"avp_svc_thread: couldn't receive msg"

BUB=None
TEST=Play video with omxplayer, the debug message:
"avp_svc_thread: couldn't receive msg" will be gone.
AVP teardown log goes as follows:
avp_svc_thread: AVP seems to be down; wait for kthread_stop
avp_svc_thread: exiting
avp_uninit: avp teardown done

Change-Id: I4b78234e9e9efa00726ff85f0924d110f1be321f
Signed-off-by: Kaz Fukuoka <kfukuoka@nvidia.com>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4084
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
bb2e712
@vpalatin Jordan Nien CHROMIUM: arm: tegra: correct 3D power gate WAR.
3D power gate should be always enabled to keep the power.

BUG=chrome-os-partner:none
TEST=Power on system and check 3D power gate setting.

Change-Id: I4dd23f7057a7b4a12364cc263501ced8eb50afd2
Signed-off-by: Jordan Nien <jnien@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
620f472
Elly Jones CHROMIUM: dm: Add support for devices by PARTUUID/PARTNROFF.
This is a special hack for the chromium-os bootloader, which knows its own
partition UUID easily but not that of its targets.

BUG=chromium-os:17184
TEST=Adhoc
Booted a kaen with dm-verity, and 'dmesg | grep verity'. Look in particular for
verity finding a root device, and for 'adding target' with a PARTUUID line in
it.

Change-Id: Idc2791db1b9cc376090c188062c675c8dd173fd4
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3900
7b1d54b
ttuttle CHROMIUM: gobi: Don't leak urb data buffers
We make a copy of the data in each skb we send, and pass it off to the usb
subsystem.  Unfortunately, we weren't setting the "please free the buffer
when you don't need it anymore" flag, and we weren't freeing it ourselves,
so we leaked all of the urb data buffers.

Now we set the flag, and we don't leak the buffers.

BUG=None
TEST=None

Change-Id: I8df45fea2185d51b02269d331734e70fb312731b
Signed-off-by: ttuttle <ttuttle@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4813
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
a7201f2
Vasanthakumar Thiagarajan ath9k_hw: Configure chain switch table and attenuation control only f…
…or active chains

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat for regression

Change-Id: I2e2c0ad4f8a4fd62f9bf21d6cbae2789dca56b66
Reviewed-on: http://gerrit.chromium.org/gerrit/4592
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
5d881c7
Vasanthakumar Thiagarajan ath9k_hw: Read iq calibration data only for active chains
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat for regression

Change-Id: Ica879b93518ce8bd75977908f6900d5e222d62f9
Reviewed-on: http://gerrit.chromium.org/gerrit/4593
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
a1d3193
Vasanthakumar Thiagarajan ath9k_hw: Read noise floor only for available chains for AR9003
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat for regression

Change-Id: I57dd427e8b1b46685a2b7e47d7216848fa46014a
Reviewed-on: http://gerrit.chromium.org/gerrit/4594
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
4a9ceba
Rajkumar Manoharan ath9k: Fix suspend/resume when no interface is UP
When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=roaming for regression

Change-Id: I598505c21b7a893eb3b088252c5c35a6d312ff2c
Reviewed-on: http://gerrit.chromium.org/gerrit/4421
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
7e430eb
Senthil Balasubramanian ath9k_hw: Fix incorrect key_miss handling
Decryping frames on key_miss handling shouldn't be done for Michael
MIC failed frames as h/w would have already decrypted such frames
successfully anyway.

Also leaving CRC and PHY error(where the frame is going to be dropped
anyway), we are left to prcoess Decrypt error for which s/w decrypt is
selected anway and so having key_miss as a separate check doesn't serve
anything. So making key_miss handling mutually exlusive with other RX
status handling makes much more sense.

This patch addresses an issue with STA not reporting MIC failure events
resulting in STA being disconnected immediately.

Cc: stable@kernel.org
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat+perf for regression

Change-Id: I8c6fa567396a31acb1b43a25d81e8f0697742f7a
Reviewed-on: http://gerrit.chromium.org/gerrit/4422
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
e71b404
Rajkumar Manoharan ath9k: Fix tx throughput drops for AR9003 chips with AES encryption
While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat+perf for regression

Change-Id: Ib7bd0ddd76207b5d01bf09ef1ed9727aa1071f7c
Reviewed-on: http://gerrit.chromium.org/gerrit/4423
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
e311381
Rajkumar Manoharan ath9k: Reset chip on baseband hang
Resetting hardware helps to recover from baseband
hang/panic for AR9003 based chips.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chromium-os:13832, chrome-os-partner:3095, chromium-os:15945
TEST=matfunc+secmat for regression

Change-Id: I5b92fe5103246ad84d78038c8447aecbe2c6e3a6
Reviewed-on: http://gerrit.chromium.org/gerrit/4415
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
e7ff685
Rajkumar Manoharan ath9k: set 40 Mhz rate only if hw is configured in ht40
Whenever there is a channel width change from 40 Mhz to 20 Mhz,
the hardware is reconfigured to ht20. Meantime before doing
the rate control updation, the packets are being transmitted are
selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.

While transmitting ht40 rate packets in ht20 mode is causing
baseband panic with AR9003 based chips.

==== BB update: BB status=0x02001109 ====
ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
src=0 **
ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
ath: ** BB mode: BB_gen_controls=0x000033c0 **
ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
ath: ==== BB update: done ====

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chromium-os:13832, chromium-os:15945
TEST=matfunc+secmat+perf for regression

Change-Id: I5c46bb4ab4b1f6bc1fe236c5adc6f64cc9d54f86
Reviewed-on: http://gerrit.chromium.org/gerrit/4417
Reviewed-by: Gary Morain <gmorain@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
2c89a8b
rochberg Revert "CHROMIUM: gobi: Don't leak urb data buffers"
This reverts commit 1b3ad6f2cd6de8aaa9bf686ce2ec426d4d620eec

Change-Id: I69accd23d7b031c404ac11c844c41ba9035225ae
Reviewed-on: http://gerrit.chromium.org/gerrit/4834
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: <rochberg@google.com>
0948df4
Rajkumar Manoharan ath9k: Fix locking issue during tx completion
The received tx status of aggregated frame without BlockAck may
cause deaf state in AR5416 cards. So the driver does a reset to
recover. When this happens, we release the pcu_lock before doing
a reset as ath_rest acquires pcu_lock. This is ugly and also not
atomic. Fixing this addresses the TX DMA failure also.

ath_tx_complete_aggr can be called from different paths which
takes different variants of spin_lock. This patch also addresses
the following warning.

WARNING: at kernel/timer.c:1011 del_timer_sync+0x4e/0x50()
Call Trace:
 <IRQ>  [<ffffffff8104be3a>] warn_slowpath_common+0x7a/0xb0
 [<ffffffff8104be85>] warn_slowpath_null+0x15/0x20
 [<ffffffff8105915e>] del_timer_sync+0x4e/0x50
 [<ffffffffa03726be>] ath_reset+0x3e/0x210 [ath9k]
 [<ffffffff8135cdaf>] ? _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa037760a>] ath_tx_complete_aggr.isra.26+0x54a/0xa40 [ath9k]

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=none
TEST=matfunc+secmat+perf for regression

Change-Id: I4ac92d801c1e3d4046ac5f4a37c9b20fb5c8e0e3
Reviewed-on: http://gerrit.chromium.org/gerrit/4420
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
e015979
Felix Fietkau ath9k: fix stopping tx dma on reset
In some situations, stopping Tx DMA frequently fails, leading to messages
like this:

ath: Failed to stop TX DMA in 100 msec after killing last frame
ath: Failed to stop TX DMA!

This patch uses a few MAC features to abort DMA globally instead of iterating
over all hardware queues and attempting to stop them individually.
Not only is that faster and works with a shorter timeout, it also makes the
process much more reliable.

With this change, I can no longer trigger these messages on AR9380,
and on AR9280 they become much more rare.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:3095, chromium-os:13832, chromium-os:15945
TEST=matfunc+secmat for regression

Change-Id: I9b6722cc509892d4d99eb1c4b0f4cf16e059ad86
Reviewed-on: http://gerrit.chromium.org/gerrit/4591
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
6e9ef33
Rajkumar Manoharan ath9k_hw: Fix false tx hung detection in AR9003 chips
The edma based (AR9003 family) chips update tx status
descriptors in a common ring buffer for all transmitted
frames. Whenever tx interrupt is raised, the descriptors
are processed and tx status index is moved.

The complete tx stauts ring are updated with beacons tx status
when there are no data frames to be sent for a period of time.
In this state, transmitting data frames causes the driver to
wait for the tx status on an incorrect tx status index though
the status was updated by hw properly. The driver detects this
condition as a h/w hang and does unnecessary chip resets.

This issue was orginally reported in adhoc mode while sending
frames after an idle time.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:4297
TEST=matfunc+secmat+perf for regression

Change-Id: Id59d7b3b95fa2f66188ec64bc2e71057b75eae06
Reviewed-on: http://gerrit.chromium.org/gerrit/4418
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
672555a
Rajkumar Manoharan ath9k_hw: disable phy restart on baseband panic caused by RXSM
While receiving unsupported rate frame rx state machine
gets into a state 0xb and if phy_restart happens in that
state, BB would go hang. If RXSM is in 0xb state after
first bb panic, ensure to disable the phy_restart.

Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chromium-os:13832, chrome-os-partner:3095
TEST=matfunc+secmat+perf for regression

Change-Id: I661a8b8da1eca4547c9d794fbbca7b1ab9a7b96c
Reviewed-on: http://gerrit.chromium.org/gerrit/4416
Reviewed-by: Sam Leffler <sleffler@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
30d6bf8
ttuttle CHROMIUM: gobi: Don't leak urb data buffers
We make a copy of the data in each skb we send, and pass it off to the usb
subsystem.  Unfortunately, we weren't setting the "please free the buffer
when you don't need it anymore" flag, and we weren't freeing it ourselves,
so we leaked all of the urb data buffers.

Now we set the flag, and we don't leak the buffers.

BUG=None
TEST=network_3GSmokeTest

Signed-off-by: ttuttle <ttuttle@chromium.org>

Change-Id: Ie624dcc074485e374ebdd82d15396a5741cecb4e
Reviewed-on: http://gerrit.chromium.org/gerrit/4838
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: ttuttle <ttuttle@chromium.org>
d176f1f
@dianders Olof Johansson CHROMIUM: arm: tegra: seaboard: purge static clock table
The clock table on seaboard was bloated with quite a few clocks that were
blindly added during initial bringup of a u-boot based environment, where
they were just set to whatever fastboot set them to. Later on, some have been
adjusted as needed.

The right thing to do here is to use the minimal table. Audio is still needed since
the driver assumes that firmware or kernel sets up the needed clocks for the platform.
Most others can be handled through clock control from the drivers instead.

BUG=chromium-os:17120
TEST=BVT on labtest/seaboard. Also, run diffs on /sys/kernel/debug/clock/clock_tree and check for valid differences

Change-Id: Icbd3c054adc2a96fd0859c99046ffa9b30be5e1b
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3390
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
b386bdc
ttuttle CHROMIUMOS: gobi: Reuse skb buffer in urb instead of copying
We are needlessly making a copy of each sk_buff we transmit to put into
the bulk urb.  We can instead reuse the copy in the sk_buff, and hold
on to our reference until the urb has completed.

BUG=chromium-os:17703
TEST=network_3GSmokeTest passed

Signed-off-by: ttuttle <ttuttle@chromium.org>

Change-Id: Id9305b46d10bd42f837d85ec423dcdf368e7824e
Reviewed-on: http://gerrit.chromium.org/gerrit/4826
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: ttuttle <ttuttle@chromium.org>
f49eb72
@bleungatchromium Allen Martin CHROMIUM: arm: tegra: fix cpu clock transition latency
On tegra2, cpu clock transition latency is a little over 300us.  Set
cpufreq hint to 400us to give a little safety net.

BUG=chrome-os-partner:5189,chrome-os-partner:1895
TEST=scrolling test
https://bug442291.bugzilla.mozilla.org/attachment.cgi?id=327454, before this
change scrolling is jerky at first as cpu ramps up, after this change it's
much smoother

Change-Id: Ie456fa318d2a7982d732a2dbd8ce567860f923da
Signed-off-by: Allen Martin <amartin@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4933
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
6a4debe
@bleungatchromium Bill Huang CHROMIUM: arm: tegra: restore cpufreq to cpufreq governor target
Restore cpufreq to its governor target after resume. So CPU will
not stay at frequency lower than governor's maximum frequency,
this will be a problem when governor is set to Performance.

BUG=chrome-os-partner:5190
TEST=1. set scaling_governor of cpu0 and cpu1 to performance
     2. cat scaling_cur_freq
     3. suspend/resume the system
     4. cat scaling_cur_freq to see if it's correct.

Change-Id: I90fd5734cc478c941c1226cae77efe17c2de12a9
Signed-off-by: Bill Huang <bilhuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4913
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
bc1a357
Todd Broch CHROMIUM: alsa: hda: Don't force mute on built-in speakers when hdmi …
…detected

If external display doesn't support audio ( deterimed via reading EDID ) we
should allow audio policy manager to use built-in speakers.  This change
decouples the gpio sensing of external display from automuting the built-in
speakers.

BUG=chrome-os-partner:3719
TEST=manual, connect to hdmi display and built-in's should still be audible if
headphone's aren't present

Signed-off-by: Todd Broch <tbroch@chromium.org>

Change-Id: Ic8fdc9df56b561d6f5ab70a42281eb7f9360b7a1
Reviewed-on: http://gerrit.chromium.org/gerrit/4786
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
c7534aa
@rmorell @dianders rmorell CHROMIUM: video: tegra: fb: Remove yres_virtual hack
This hack was added for Android to be able to perform panning.  However,
not all clients want this, and for those that don't, it generally
doubles the amount of memory required.

Instead, the client specifying the mode should be the one doubling
yres_virtual if it is desired.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Verify that fbconsole VTs still work, X11 still works, and VT
switching between the two still works

Change-Id: I723abb07d92a7588566f73266678176a7d1a01ab
Reviewed-on: http://gerrit.chromium.org/gerrit/4862
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
6d2c750
@dianders Joseph Lo CHROMIUM: media: tegra: set the clock rate of avp.sclk for T20/T25
According to the HW spec, the request frequency of avp.sckl is 240MHz
for T20 and 300MHz for T25. Setting it to the request value.

BUG=none
TEST=using a video player that will enable avp.sclk and check the clock by
     looking at /sys/kernel/debug/clock/clock_tree

Change-Id: I639a2cc64d119f3b3c8ffd54f3948abafdecf58e
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4571
3d1e18f
@dianders Joseph Lo CHROMIUM: media: tegra: set the clock rate of VDE for T20/T25
According to the HW spec, the request frequency of VDE is 240MHz for
T20 and 300MHz for T25. Setting it to the request value.

BUG=none
TEST=using the video player that will enable VDE and check the clock by
     looking at /sys/kernel/debug/clock/clock_tree

Change-Id: I5fa8964317f631f98f65f3241fa0be579e8eceb0
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4569
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
31af14c
@bleungatchromium Du, Dudley Input: cyapa: Convert some variables to bool type and tune some logic
Use type bool instead of int for some variables that only take two states.

BUG=chrome-os-partner:4790
TEST=test on Kaen board

Change-Id: I61f9bed4527140ca83d2a2120ab6404333065f2a
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4384
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
ee6d651
@bleungatchromium Du, Dudley input: cyapa: modify polling mode name and support polling mode when …
…request irq failed

1. modify polling mode variable name down_to_polling_mode to polling_mode_enabled.
2. using polling mode to read finger contact data from trackpad device
   when request system irq failed.

BUG=chrome-os-partner:4709
TEST=test trackpad on Kaen with irq disbaled

Change-Id: Ic7e1014ced84277979d78f7729e0ee88f5885da1
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4649
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
b01dbcd
@bleungatchromium Du, Dudley Input: cyapa: configure trackpad interrupt to wake up system
Currently, the trackpad cannot wake the system from sleep
because its interrupt line is not configured as a system wake up source.

This patch configures the configure trackpad interrupt to wake
the system up during interrupt initialization.

BUG=chrome-os-partner:4816
TEST=test trackpad on Kaen board with S3 mode

Change-Id: I536bba614a8143eadee182af035445bc066ea20e
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4385
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
57019a9
@bleungatchromium Du, Dudley Input: cyapa: Shorten delay when no trackpad device is connected
When running a bare board without trackpad device connected,
Cyapa driver adds a big delay in system booting,
because cyapa driver doesn't detect trackpad device is connected
or not, so it always tries to read data from trackpad device
until timeout.

So this solution moves trackpad device detect function to
a single thread workqueue to avoid affecting system booting
and system resuming.

BUG=chrome-os-partner:4790
TEST=test on Kaen board without any trackpad device connected

Change-Id: I61a2542d0d2e6e67a93fb5156e4de7e4c7d94189
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4386
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
ca9dd80
@bleungatchromium Du, Dudley input: cyapa: add I2C bus acquire/release pair functions
Add function pair for acquiring and releasing I2C bus.

BUG=chrome-os-partner:3299,3300
TEST=test I2C bus IO with Cypress trackpad on Kaen board

Change-Id: I6b821762719a37071ef2168f5b5eab12c716abec
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4650
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
34bc489
@bleungatchromium Du, Dudley Input: cyapa: Support trackpad sleep and wake up function.
Trackpad device light sleep and wake up function is added and supported.

BUG=chrome-os-partner:3299,3300
TEST=test on Kaen board with S3 sleep and wake up, cold boot up and
     shutdown with CYTRA-014001-00 V20 firmware

Change-Id: I57452ab461476815b6c90990c613f88ee296e787
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4387
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
4a2e778
@bleungatchromium Du, Dudley Input: cyapa: update cyapa driver version
cyapa driver version is updated to v1.1.0.

BUG=chrome-os-partner:
TEST=test trackpad on Kaen though cyapa driver_version interface.

Change-Id: I62a5194576f525361e00bb7f6d3395368d47433f
Signed-off-by: Du, Dudley <dudl@cypress.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4388
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
bf6ccdd
@bleungatchromium Sameer Nanda CHROMIUM: config: tegra: enable cpuidle
Enable cpuidle support.

BUG=chrome-os-partner:3674
TEST=run powertop and ensure that LP2 and LP3 states are visible
under "Idle stats" tab.

Change-Id: Ibc17e308ef35ac60feb2d7799865d1aa4925710f
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/2410
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
033f713
@bopiy @bleungatchromium bopiy CHROMIUM: config: tegra: enable memory frequency scaling
Enable kernel option CONFIG_TEGRA_EMC_SCALING_ENABLE

BUG=none
TEST=built kernel and boot. It passed over-night dvfs stress test.

Change-Id: I258c826fd571a920386c65b9dc06a59fb925e46e
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/2596
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
3ff167b
@bleungatchromium Sameer Nanda CHROMIUM: config: tegra: enable core DVFS
Enable core DVFS kernel config option.

BUG=chrome-os-partner:3253
TEST=run this command: "grep ^vdd_core /sys/kernel/debug/clock/dvfs".
If core DVFS is disabled, you should see: "vdd_core 1300 mV disabled:".
If it is enabled, you should see: "vdd_core 1300 mV:"

Change-Id: I000d6f318c06ff8c2856032875aba4b947e99e2a
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/2534
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
87bb60d
@dianders Joseph Lo CHROMIUM: media: tegra: set the clock rate of MPE for T20/T25
According to the HW spec, the request frequency of MPE is 240MHz for
T20 and 300MHz for T25. Setting it to the request value.

BUG=none
TEST=open the device node by "cat /dev/nvhost-mpe" and check the clock
     by looking at /sys/kernel/debug/clock/clock_tree

Change-Id: Id40e9abbb0e570d19b5b6684db9bd416368279a0
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4910
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
6f705e0
@dianders Rakesh Iyer Input: tegra-kbc - enable key autorepeat
To support key repeats, keyboard needs to be setup as an autorepeating
device.

Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 5599d2e60b1191520778def7c0658fbc6de6d8c1)

BUG=chrome-os-partner:4735
TEST=Verify that keys repeat are working in VT2 terminal.

Change-Id: I0887af3de38b5f61ead4175bea82ac95508640d1
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5023
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
d09ac0b
Elly Jones CHROMIUM: dm-verity: use key-val args
BUG=chromium-os:15772
TEST=Adhoc
1. Install verity for the host (sudo emerge verity) (you need 2926 for this)
2. Rebuild the kernel with this change present.
3. Build an image with rootfs verification enabled.
4. Boot it.
5. Mod your image for recovery.
6. Boot that image in recovery mode.
7. Build another image with rootfs verification enabled.
8. Run the devserver in delta mode (--src_image=<image from step 3>,
   --image=<image from step 7>).
9. Run 'update_engine_client -check_for_update' on the target to do a delta
   update.
10. Reboot. If the machine boots, you win!

This change has a circular dependency on the CLs listed below; this CL introduces
a new (non-backward-compatible) argument format and the CLs below use it.

Depends-on: http://gerrit.chromium.org/gerrit/2926
Depends-on: http://gerrit.chromium.org/gerrit/5002
Depends-on: http://gerrit.chromium.org/gerrit/5069
Change-Id: If12abd96b7a439f1c299e124f2f96284bed90c3a
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3037
Reviewed-by: Will Drewry <wad@chromium.org>
f1613ae
Elly Jones Revert "CHROMIUM: dm-verity: use key-val args"
This reverts commit ea7d1e7a0ef8061c9910734cdd90c53c5f8a24f2

Change-Id: I07170b695de0447f72502a4dff5f89a13b276460
Reviewed-on: http://gerrit.chromium.org/gerrit/5097
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Elly Jones <ellyjones@chromium.org>
0974dd5
Todd Broch CHROMIUM: enabled CONFIG_PM_DEBUG on ARM
This config option is enabled by default on x86.  CL to bring ARM to
same level of PM debug.

BUG=none
TEST=manual, tried the following on ARM device and saw transistions
in dmesg output:

for c in freezer devices platform processors core ; do
  echo "Trying $c"
  echo $c > /sys/power/pm_test
  echo mem > /sys/power/state
done

Signed-off-by: Todd Broch <tbroch@chromium.org>
Change-Id: Ic0f4667cbd7cb1868b4adb776e02f1b0030d210a
Reviewed-on: http://gerrit.chromium.org/gerrit/5108
Reviewed-by: Sameer Nanda <snanda@chromium.org>
4797a06
ttuttle CHROMIUMOS: gobi: Eliminate urbreq from qcusbnet
Instead of using urbreq to chain urbs together, use the built-in
urb_list.  Note that we lose ownership of this list_head when we
submit the urb, so we can't use it in qmidevice, which currently
keeps urbs in a list even after they've been submitted.

BUG=chromium-os:16294
TEST=network_3GSmokeTest passes

Signed-off-by: ttuttle <ttuttle@chromium.org>

Change-Id: Ieb3ce4663752d0608c521905beebf012ba60dbc5
Reviewed-on: http://gerrit.chromium.org/gerrit/5088
Reviewed-by: Jason Glasgow <jglasgow@chromium.org>
Tested-by: ttuttle <ttuttle@chromium.org>
67fe5f4
@bopiy @dianders bopiy CHROMIUM: arm: tegra: seaboard: Enable uart clock only when needed
Enable uartb and uartd clock only when needed instead of enable both
of them in the seaboard_clk_init_table

BUG=none
TEST=Built kernel and boot. uart console is working correctly.

Change-Id: I572bb6cb418a2a89c5b52918bec5b6059972a93e
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/3783
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
24e1ee7
@dianders Andrew Chew CHROMIUM: configs: Renormalize splitconfigs
Some config options have changed (likely as a result of CONFIG_PM_DEBUG).
Reran chromeos/scripts/kernelconfig oldconfig and answer the prompts with
their default values, to prevent the prompts from coming up during a build.

BUG=none
TEST=none

Change-Id: Ie067de1eb73d46a335361d03233ad0998a69e222
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5128
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
f27b1c1
Noah Richards Allow v4l2 framerate get/set on ov9740.
BUG=None
TEST=Built/ran gtalk, confirmed framerates for 30/15/10.

Change-Id: I6f876b2a0a14ef8bf59c3335cb30b0e2dc5b43e5
Signed-off-by: Noah Richards <noahric@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5177
Reviewed-by: Andrew Chew <achew@nvidia.com>
a565969
@rhklein @dianders rhklein CHROMIUM: video: tegra: nvmap: catch null pointer
Adding a check to verify the pointer for carveout is not NULL before
accessing it.

BUG=None
TEST=None

Change-Id: I964f6fb9e91a8091321d6dded490581048c4e4a6
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4701
Reviewed-by: Doug Anderson <dianders@chromium.org>
e860575
@bopiy @dianders bopiy CHROMIUM: arm: tegra: seaboard: set blink clock rate
Set blink clock rate to 32768Hz for WLAN

BUG=chrome-os-partner:5278
TEST=Built kernel and boot. Wifi is working properly

Change-Id: Ibd1d84035100f6ddd82c850d9bad40b2a18a0d0e
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5067
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
6a4b795
Elly Jones CHROMIUM: dm-verity: optionally support key-val args
BUG=chromium-os:15772
TEST=Adhoc
Build a normal image (I built for Kaen) and boot it. Nothing generates the new
argument format yet, so this code is not exercised, but the system still boots.
Build a recovery image (I also built this for Kaen), boot it, and do the
recovery procedure. Ensure the machine boots afterwards. This exercises the
optional error behavior argument.

Change-Id: Icfee3e85cc7fa18054cc3d9ce71281afd3233888
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5141
Reviewed-by: Will Drewry <wad@chromium.org>
d5b110e
Taylor Hutt CHROMIUM: sound: codecs: MAX98095: Connect max98095 for Arthur board
This change finally finishes the configuration of the  Max98095 sound codec.

NOTE: Initial arthur boards have the sound codec connected to the
camera GPIO; unless the camera is powered-up, the sound codec will not
work.  The camera is not powered in this change.

Testing

  tegra2_arthur     : boots, camera not powered on, no sound will play.
  tegra2_seaboard   : boots, played WAV through speaker & headphones.
  tegra2_kaen       : boots, played WAV through headphones.
  tegra2_aebl       : boots, played WAV through speaker & headphones.
  x86-mario         : boots, played WAV through speaker & headphones.

Signed-off-by: Taylor Hutt <thutt@chromium.org>

TEST=See above
BUG=chrome-os-partner:3577

Change-Id: I7ed73d8f742a063ab50348d7dad88fc37b13b2fe
Signed-off-by: Taylor Hutt <thutt@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4658
5ec62b2
@dianders Wei Ni CHROMIUM: mfd: tps6586x: add api to power off tps6586x
Add an api to put tps6586x in sleep mode by resetting EXITSLREQ and
setting SLEEP_MODE in SUPPLYENE register. It will power off ldos.

BUG=None
TEST=Call this api in board-seaboard-power.c to power off system.
It run ok.

Change-Id: I2e60215cbc8c3668df31fbfdfa9ce6216699ee2c
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4800
Reviewed-by: Jordan Nien <jnien@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
7cfab60
@dianders Wei Ni CHROMIUM: tegra: seaboard: set pm_power_off to seaboard specific routine
For Seaboard, implement pm_power_off with tps6586x's power off routine.

BUG=None
TEST=Test on seaboard and kaen, turn off the system, it run ok.

Change-Id: Idbbcf23d53fae5566a2c9f5054a7e076dec82348
Signed-off-by: Nitin Kumbhar <nkumbhar@nvidia.com>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4801
Reviewed-by: Jordan Nien <jnien@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
9df0f60
@dianders Wei Ni CHROMIUM: tegra: harmony: set pm_power_off to harmony specific routine
For harmony, implement pm_power_off with tps6586x's power off routine.

BUG=None
TEST=Test on harmony, power off the system, it runs ok.

Change-Id: I4f627fd3be38d669d56570e16f90a94076d58121
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4802
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
c60cb74
@nvjmayo nvjmayo CHROMIUM: video: tegra: dc: remove hard coded modes for HDMI
Removed hard coded mode list from HDMI driver.
Use modes from monitor's EDID data.
Return mode set errors on unsupported clock tolerances.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Switch modes on HDMI

Change-Id: Ifa460866d87fd26d3df8054a12619b6c7a0578d8
Reviewed-on: http://gerrit.chromium.org/gerrit/4863
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
9926ded
@rmorell rmorell CHROMIUM: video: tegra: Actually validate modes in check_var
The fbdev framework expects validation of possible modes against
hardware capabilities to be done in the fb_check_var hook.  See the
comment above xxxfb_check_var in skeletonfb.c for how this works.

Among other things, this allows userspace to check if a given mode is
possible or not using the FB_ACTIVATE_TEST option without actually
attempting to set the mode.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Using a suitable X11 driver on Tegra, validate that `xrandr -q`
output contains modes suitable for connected HDMI sink.

Change-Id: I2ea77bea3fce28ec17a61f1137ba079822f75550
Reviewed-on: http://gerrit.chromium.org/gerrit/4864
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
6fbe1b6
@rmorell rmorell CHROMIUM: video: tegra: Use fb_var_screeninfo properly
The fbdev infrastructure depends on certain values being set proprerly
in certain structures.  This is necessary so that things like the ioctl
FBIOGET_VSCREENINFO return proper results.

This change tracks the current mode in struct fb_info::struct
fb_var_screeninfo, and removes the code to force requested modes to
always use a mode from the mode list.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Verify that FBIOPUT_VSCREENINFO/FBIOGET_VSCREENINFO work properly

Change-Id: I771fa54f8d792775e85d3d044c79bdffc52bb673
Reviewed-on: http://gerrit.chromium.org/gerrit/4865
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
4dcb61b
@rmorell rmorell CHROMIUM: video: tegra: Add pixel clock maximum for HDMI
The HDMI specification states that the maximum supported pixel clock is
165MHz.  Driving modes beyond this may cause monitors to fail to
display.  This change adds an explicit maximum pixel clock and validates
that modes do not go beyond the maximum.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Verify that modes beyond 165MHz are rejected.

Change-Id: I2f3377166600926a209ad2dbb557730f0d7b5acd
Reviewed-on: http://gerrit.chromium.org/gerrit/4982
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
341cee5
@rmorell rmorell CHROMIUM: arm: tegra: Limit HDMI output to 148.5MHz
The DVFS table for Tegra2 is currently only populated for up to 148.5
MHz.  This change limits the pixel clock on HDMI outputs to 148.5 MHz
until that can be fixed.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Verify that modes beyond 148.5MHz are rejected, but modes up to
1080p@60Hz (exactly 148.5 MHz) still work.

Change-Id: Id176e19f5d38ef1d15eb29bde1a6cf190eec2d44
Reviewed-on: http://gerrit.chromium.org/gerrit/4983
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
6e7153a
@rmorell rmorell CHROMIUM: video: tegra: Determine best PLL, divider for HDMI
This code iterates through the available values for the PLL driving
display over HDMI and determines the best rate and divider, if any, for
the desired mode.

Signed-off-by: Robert Morell <rmorell@nvidia.com>

BUG=chrome-os-partner:4249
TEST=Verify that xrandr shows a variety of modes for HDMI monitors and
that setting those modes is successful.

Change-Id: I712b62914ce631f383ce7d9945780c86bda0fcf9
Reviewed-on: http://gerrit.chromium.org/gerrit/4984
Tested-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
846fc5d
@redpig redpig CHROMIUM: seccomp_filter: new mode with configurable syscall filters
This change adds a new seccomp mode which specifies the allowed system
calls dynamically.  When in the new mode (13), all system calls are
checked against process-defined filters - first by system call number,
then by a filter string.  If an entry exists for a given system call and
all filter predicates evaluate to true, then the task may proceed.
Otherwise, the task is killed.

Filter string parsing and evaluation is handled by the ftrace filter
engine.  Related patches tweak to the perf filter trace and free
allowing the calls to be shared. Filters inherit their understanding of
types and arguments for each system call from the CONFIG_FTRACE_SYSCALLS
subsystem which already populates this information in syscall_metadata
associated enter_event (and exit_event) structures. If
CONFIG_FTRACE_SYSCALLS is not compiled in, only filter strings of "1"
will be allowed.

The net result is a process may have its system calls filtered using the
ftrace filter engine's inherent understanding of systems calls.  The set
of filters is specified through the PR_SET_SECCOMP_FILTER argument in
prctl(). For example, a filterset for a process, like pdftotext, that
should only process read-only input could (roughly) look like:
  sprintf(rdonly, "flags == %u", O_RDONLY|O_LARGEFILE);
  type = PR_SECCOMP_FILTER_SYSCALL;
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_open, rdonly);
  prctl(PR_SET_SECCOMP_FILTER, type, __NR__llseek, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_brk, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_close, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_exit_group, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_fstat64, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_mmap2, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_munmap, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_read, "1");
  prctl(PR_SET_SECCOMP_FILTER, type, __NR_write, "fd == 1 || fd == 2");
  prctl(PR_SET_SECCOMP, 13);

Subsequent calls to PR_SET_SECCOMP_FILTER for the same system call will
be &&'d together to ensure that attack surface may only be reduced:
  prctl(PR_SET_SECCOMP_FILTER, __NR_write, "fd != 2");

With the earlier example, the active filter becomes:
  "(fd == 1 || fd == 2) && (fd != 2)"

The patch also adds PR_CLEAR_SECCOMP_FILTER and PR_GET_SECCOMP_FILTER.
The latter returns the current filter for a system call to userspace:

  prctl(PR_GET_SECCOMP_FILTER, type, __NR_write, buf, bufsize);

while the former clears any filters for a given system call changing it
back to a defaulty deny:

  prctl(PR_CLEAR_SECCOMP_FILTER, type, __NR_write);

Note, type may be either PR_SECCOMP_FILTER_EVENT or
PR_SECCOMP_FILTER_SYSCALL.  This allows for ftrace event ids to be used
in lieu of system call numbers.  At present, only syscalls:sys_enter_*
event id are supported, but this allows for potential future extension
of the backend.

v11: - Use mode "13" to avoid future overlap; with comment update
     - Use kref; extra memset; other clean up from msb@chromium.org
     - Cleaned up Makefile object merging since locally shared symbols are gone
v10: - Note that PERF_EVENTS are also needed for ftrace filter engine support.
     - Removed dependency on ftrace code changes for event_filters
       (wrapping with perf_events and violating opaqueness for the filter str)
     - pulled in all the hacks to get access to syscall_metadata and build
       call objects for filter evaluation.
v9: - rebase on to de505e7
    - disallow PR_SECCOMP_FILTER_EVENT when a compat task is calling
      as ftrace has no compat_syscalls awareness yet.
    - return -ENOSYS when filter engine strings are used on a compat call
      as there are no compat_syscalls events to reference yet.
v8: - expand parenthical use during SET_SECCOMP_FILTER to avoid operator
      precedence undermining attack surface reduction (caught by
      segoon@openwall.com).  Opted to waste bytes on () than reparse to
      avoid OP_OR precedence overriding extend_filter's intentions.
    - remove more lingering references to @state
    - fix incorrect compat mismatch check (anyone up for a Tested-By?)
v7: - disallow seccomp_filter inheritance across fork except when seccomp
      is active.  This avoids filters leaking across processes when they
      are not actively in use but ensure an allowed fork/clone doesn't drop
      filters.
    - remove the Mode: print from show as it reflected current and not the
      filters holder.
v6: - clean up minor unnecessary changes (empty lines, ordering, etc)
    - fix one overly long line
    - add refcount overflow BUG_ON
v5: - drop mutex usage when the task_struct is safe to access directly
v4: - move off of RCU to a read/write guarding mutex after
      paulmck@linux.vnet.ibm.com's feedback (mem leak, rcu fail)
    - stopped inc/dec refcounts in mutex guard sections
    - added required changes to init the mutex in INIT_TASK and safely
      lock around fork inheritance.
    - added id_type support to the prctl interface to support using
      ftrace event ids as an alternative to syscall numbers.  Behavior
      is identical otherwise (as per discussion with mingo@elte.hu)
v3: - always block execve calls (as per torvalds@linux-foundation.org)
    - add __NR_seccomp_execve(_32) to seccomp-supporting arches
    - ensure compat tasks can't reach ftrace:syscalls
    - dropped new defines for seccomp modes.
    - two level array instead of hlists (sugg. by olofj@chromium.org)
    - added generic Kconfig entry that is not connected.
    - dropped internal seccomp.h
    - move prctl helpers to seccomp_filter
    - killed seccomp_t typedef (as per checkpatch)
v2: - changed to use the existing syscall number ABI.
    - prctl changes to minimize parsing in the kernel:
      prctl(PR_SET_SECCOMP, {0 | 1 | 2 }, { 0 | ON_EXEC });
      prctl(PR_SET_SECCOMP_FILTER, __NR_read, "fd == 5");
      prctl(PR_CLEAR_SECCOMP_FILTER, __NR_read);
      prctl(PR_GET_SECCOMP_FILTER, __NR_read, buf, bufsize);
    - defined PR_SECCOMP_MODE_STRICT and ..._FILTER
    - added flags
    - provide a default fail syscall_nr_to_meta in ftrace
    - provides fallback for unhooked system calls
    - use -ENOSYS and ERR_PTR(-ENOSYS) for stubbed functionality
    - added kernel/seccomp.h to share seccomp.c/seccomp_filter.c
    - moved to a hlist and 4 bit hash of linked lists
    - added support to operate without CONFIG_FTRACE_SYSCALLS
    - moved Kconfig support next to SECCOMP
    - made Kconfig entries dependent on EXPERIMENTAL
    - added macros to avoid ifdefs from kernel/fork.c
    - added compat task/filter matching
    - drop seccomp.h inclusion in sched.h and drop seccomp_t
    - added Filtering to "show" output
    - added on_exec state dup'ing when enabling after a fast-path accept.

Signed-off-by: Will Drewry <wad@chromium.org>

BUG=chromium-os:14496
TEST=built in x86-alex.  Out of tree commandline helper test confirms functionality works.  Will check in a test into the minijail repo which can be used from autotest.

Change-Id: I901595e3399914783739d113a058d83550ddf8e2
Reviewed-on: http://gerrit.chromium.org/gerrit/4814
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
75a37d0
@redpig redpig CHROMIUM: seccomp_filter: add process state reporting
Adds seccomp and seccomp_filter status reporting to proc.
/proc/<pid>/seccomp_filter provides the current seccomp mode
and the list of allowed or dynamically filtered system calls.

v9: rebase on to bccaeaf
v8: -
v7: emit seccomp mode directly
v6: -
v5: fix typos when mailing the wrong patch series
v4: move from rcu guard to mutex guard
v3: changed to using filters directly.
v2: removed status entry, added seccomp file.
    (requested by kosaki.motohiro@jp.fujitsu.com)
    allowed S_IRUGO reading of entries
    (requested by viro@zeniv.linux.org.uk)
    added flags
    got rid of the seccomp_t type
    dropped seccomp file

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:14496
TEST=see others in series

Change-Id: I86515e56d2da3b3c22ac90856a6ffa71a045c253
Reviewed-on: http://gerrit.chromium.org/gerrit/3242
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
cccf240
@redpig redpig CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it …
…works.

Adds a text file covering what CONFIG_SECCOMP_FILTER is, how it is
implemented presently, and what it may be used for.  In addition,
the limitations and caveats of the proposed implementation are
included.

v10: fix to reflect mode==13 now.
v9: rebase on to bccaeaf
v8: -
v7: Add a caveat around fork behavior and execve
v6: -
v5: -
v4: rewording (courtesy kees.cook@canonical.com)
    reflect support for event ids
    add a small section on adding per-arch support
v3: a little more cleanup
v2: moved to prctl/
    updated for the v2 syntax.
    adds a note about compat behavior

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:14496
TEST=I can readz.

Change-Id: I10945ea369757756b08834650e59d148b3e08aa2
Reviewed-on: http://gerrit.chromium.org/gerrit/3243
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
f7c2679
@redpig redpig CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve
Adds support to the x86 architecture by providing a compatibility
mode wrapper for sys_execve's number and selecting HAVE_SECCOMP_FILTER

v9: rebase on to bccaeaf

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:14496
TEST=see others ref'd in bug

Change-Id: Id0e8440181e98f7edb12ef702f2f6bdca54d15a6
Reviewed-on: http://gerrit.chromium.org/gerrit/3244
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
cefd5fb
@redpig redpig CHROMIUM: arm: select HAVE_SECCOMP_FILTER
Enable support for CONFIG_SECCOMP_FILTER by selecting HAVE_SECCOMP_FILTER by
default.

v9: rebase on to bccaeaf

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:14496
TEST=builds on arm, testsuite works.

Change-Id: I4eada815f792c9eff64438e1a6dbe55ad44bc2c7
Reviewed-on: http://gerrit.chromium.org/gerrit/3245
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
d88c988
@redpig redpig CHROMIUM: enable SECCOMP_FILTER=y
Done with chromeos/scripts/kernelconfig oldconfig
And enabled CONFIG_FTRACE_SYSCALLS

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:14496
TEST=boots and out-of-tree testsuite pass

Change-Id: I4c20996ccc9dfcdf003c0f37e50c3a6173c26bc8
Reviewed-on: http://gerrit.chromium.org/gerrit/3246
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
1b39732
Joe Thornber UPSTREAM: dm-devel: add persistent-data.
The persistent-data library offers a re-usable framework for the storage
and management of on-disk metadata in device-mapper targets.

It's used by the thin-provisioning target in the next patch and in an
upcoming hierarchical storage target.

For further information, please read
Documentation/device-mapper/persistent-data.txt

Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
(cherry picked from commit 29a226094ff6e242f706ed6beb7afe2184bae3e8)

Cherry-picked from linux-next
<git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git>.

Change-Id: I337946d3d041e924b0831312100725bed0750374
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5165
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
8c8bdaa
Joe Thornber UPSTREAM: dm-devel: add dm-thin.
Initial EXPERIMENTAL implementation of device-mapper thin provisioning
with snapshot support.  The 'thin' target is used to create instances of
the virtual devices that are hosted in the 'thin-pool' target.  The
thin-pool target provides data sharing among devices.  This sharing is
made possible using the persistent-data library in the previous patch.

The main highlight of this implementation, compared to the previous
implementation of snapshots, is that it allows many virtual devices to
be stored on the same data volume, simplifying administration and
allowing sharing of data between volumes (thus reducing disk usage).

Another big feature is support for arbitrary depth of recursive
snapshots (snapshots of snapshots of snapshots ...).  The previous
implementation of snapshots did this by chaining together lookup tables,
and so performance was O(depth).  This new implementation uses a single
data structure so we don't get this degradation with depth.

For further information and examples of how to use this, please read
Documentation/device-mapper/thin-provisioning.txt

Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
(cherry picked from commit 7ea3c63442cad18d0636fc9881f5f6c7b47e076f)

Cherry-picked from linux-next
<git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git>.

Change-Id: I0e3284bea9cb350f62eea429f0fd418a405cbff6
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5166
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
6a04e44
Roy Hashimoto Revert "CHROMIUM: enable SECCOMP_FILTER=y"
This reverts commit 4cf3a73098bd9dae2c949eadcbfaeb1453b59c24

Change-Id: Ia47e02f519b940ee75b40babe2af9c902deae11a
Reviewed-on: http://gerrit.chromium.org/gerrit/5255
Tested-by: Roy Hashimoto <rhashimoto@chromium.org>
Reviewed-by: Roy Hashimoto <rhashimoto@chromium.org>
d31dcb1
Bryan Freed CHROMIUM: tpm: tpm_tis_i2c: Lock the I2C adapter for a sequence of re…
…quests.

Submitted upstream at https://lkml.org/lkml/2011/8/3/327.
This is derived from Peter Huewe's hacked tpm_tis_i2c.c driver:

On some ChromeOS systems, a TPM sharing the I2C bus with another device
gets confused when it sees I2C requests to that other device.
This change locks the I2C adapter for the duration of the full sequence
of I2C requests the TPM needs to complete.

smbus_xfer is not supported, but SMBUS is not supported by the original
driver, either.

BUG=chrome-os-partner:4775
TEST='while tpmc getf > /dev/null; do echo -n .;done' runs a loooong time.

Change-Id: Ia9cb23aa5722e46aaebc1e96fb5bc3da2c134c7f
Signed-off-by: Bryan Freed <bfreed@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5186
Reviewed-by: Grant Grundler <grundler@chromium.org>
11a94db
@yufengshen yufengshen CHROMIUM: ARM: tegra: asymptote: Add asymptote specific mxt config data
Asymptote has a different version of atmel controller than the seaboard one.
This patch adds the asymptote specific atmel mxt config data.

BUG=None
TEST=Built and deployed the kernel on asymptote, ensured that touch
controller module atmel_mxt_ts is loaded correctly.

Change-Id: Iac91e0eaf14b1242abe9b3f4438387e089ef4f60
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5284
db2d5ec
@yufengshen yufengshen CHROMIUM: arm: tegra: Expose control gpios for LCD and Backlight
Exposing gpio after board init through /sys/class/gpio/export
always return device busy errors for gpio 10 (LCD) and gpio 28 (
Backlight). It is very useful for development to have these 2
gpios exposed to user space. This patch exports these 2 gpios at
the board init stage.

BUG=None
TEST=Confirmed that gpio 10 and 28 are exposed and
/sys/class/gpio/gpio10 and /sys/class/gpio/gpio28

Change-Id: I24b51bfaf18394aa9d7fc549c176ea3fed9b4382
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5288
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
217fa49
@kvalo kvalo ath6kl: don't force foreground scan when connected
In my setup data transfer stalls when there's data transmission during
scan. After some testing I found out that using background scan
when connected to makes the problem go away. This is more like
a workaround than a proper fix, but as the stall is so severe the
workaround is justified.

With a dual band card this increases scan time when connected from
1.9s to 5.4s. When not connected the scan time is not affected and
is the same 1.9s.

This is a backport of a patch with the same name from ath6kl-cleanup tree.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

BUG=chrome-os-partner:4458
TEST=manual:test normal use on various platforms

Change-Id: Ie51f3f04333c07290c15b949900670c6df81869f
Reviewed-on: http://gerrit.chromium.org/gerrit/5283
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
731eed9
@dianders Andrew Chew CHROMIUM: configs: Renormalize splitconfigs
The seccomp_filter commit (75a37d0)
and DM_THIN_PROVISIONING commit (6a04e44)
introduced some kernel options that we don't have in our splitconfigs.

Renormalize so that we don't get prompted on build.

BUG=none
TEST=Regenerated splitconfigs, and made sure nothing happens.

Change-Id: I26a51e152593cc1462261ea981239ef1d188f971
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5366
Reviewed-by: Doug Anderson <dianders@chromium.org>
19081d0
@dianders Dilan Lee CHROMIUM: arm: tegra: I2C driver uses the suspend_noirq/resume_noirq
We found the register settings of wm8903(an audio codec) can't be modified
in snd_soc_suspend since I2C bus has been suspended before snd_soc_suspend.

Pop noise will occur when system resume from LP0 if the register settings of wm8903
haven't be modified correctly in snd_soc_suspend.

So, we use the suspend_noirq/resume_noirq callbacks to make sure I2C bus still
operates while running snd_soc_suspend.

BUG=chrome-os-partner:4858
TEST=I can't hear the pop noise when system resume from LP0.

Change-Id: Ifc243d63a2df2ffe78cbce9015593132f1515535
Signed-off-by: Dilan Lee <dilee@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5135
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
e982f5f
@dianders Rakesh Iyer Input: tegra-kbc - fix computation of polling time
Fix a constant definition and computation of polling time.

[dtor@mail.ru: switched to using DIV_ROUND_UP as was suggested by
 Thierry Reding <thierry.reding@avionic-design.de>]

Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 3f27757a1182f5e3feff7425b1c3e43f3e466724)

BUG=None.
TEST=Keyboard works fine with the fix.

Change-Id: I05b7026c75526c09d19f4f1f5d625ef4713da63a
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5403
Reviewed-by: Doug Anderson <dianders@chromium.org>
05e4ab7
@yufengshen @dianders yufengshen CHROMIUM: ARM: tegra: asymptote: Tune mxt config data on asymptote
Atmel touch controller on asymptote is currently not useable due to
electrical noise from other components and keeps reporting false
detection. This patch tunes the configuration data to suppress
false detection, at the expense of desensitize the touchscreen.
Further tuning of the configuration parameters will follow.

Parameters changed in the patch:
1. TCHTHR: Touch Threshold : increased from 0x28 to 0x50
2. TCHDI:  Touch Detect Integration : increased from 0x02 to 0x07
3. CTRL in Noise Suppression Object T22: changed from 0x05 to 0x03
   to disable frequence hopping

BUG=None
TEST=Manually tested on Asymptote and confirmed false detection is
significantly suppressed.

Change-Id: Ic1229c35ec0043387641eb1163150e955e974098
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5364
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
6d58ea3
@rhklein @dianders rhklein CHROMIUM: arm: tegra: powergate: remove warning
Remove compiler warning about struct being initialized in parameter list.

TEST=compiler no longer throws the warning.
BUG=None

Change-Id: I46a39da2100645c7d115b3d9c527c1c1728ae767
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5408
Reviewed-by: Doug Anderson <dianders@chromium.org>
fb9dbb9
Dave Parker CHROMIUM: ARM: tegra: aebl: Fix type-o in EMC table name.
BUG=None
TEST=Boot Aebl with Micron DDR2. Verify comment in /var/log/messages

Change-Id: Ie86babf8f342f88abdb674fb8412cad3fdd9132f
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5434
Reviewed-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
a47e50e
Sonny Rao CHROMIUM: tegra: print out usec timer just before timekeeping starts
The tegra usec timer corresponds to what u-boot uses to
measure time prior to kernel execution. We need this to
accurately measure how much time was spent in firmware
and the time before the kernel starts keeping track
of time.

BUG=chromium-os:4900
TEST=boot on a tegra platform, verify a line saying
"Initial usec timer"

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: I1ed23390f1389d914b49b51074310e4a37f5294c
Reviewed-on: http://gerrit.chromium.org/gerrit/5420
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
41d389d
@rhklein @dianders rhklein CHROMIUM: arm: tegra: cpu-tegra: remove warning
Removing compiler warning about incorrect type in pr_info.

TEST=compiling doesn't throw this warning any more
BUG=None

Change-Id: Id750dd03e9dcc34e01feb8c608fe8437e4db03dd
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5406
Reviewed-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
a08f044
@rhklein @dianders rhklein CHROMIUM: arm: tegra: cpuidle: remove warning
Remove compiler warning that this function doesn't have a return statement.

TEST=compiler no longer shows this warning
BUG=None

Change-Id: Ibba78952e8451b34b486b9ff1706e014d2e41590
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5407
Reviewed-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
0785147
Mandeep Singh Baines UPSTREAM: lib/sha1: use the git implementation of SHA-1
For ChromiumOS, we use SHA-1 to verify the integrity of the root
filesystem.  The speed of the kernel sha-1 implementation has a major
impact on our boot performance.

To improve boot performance, we investigated using the heavily optimized
sha-1 implementation used in git.  With the git sha-1 implementation, we
see a 11.7% improvement in boot time.

10 reboots, remove slowest/fastest.

Before:

  Mean: 6.58 seconds Stdev: 0.14

After (with git sha-1, this patch):

  Mean: 5.89 seconds Stdev: 0.07

The other cool thing about the git SHA-1 implementation is that it only
needs 64 bytes of stack for the workspace while the original kernel
implementation needed 320 bytes.

Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Nicolas Pitre <nico@cam.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1eb19a12bd2214cdcad5273d472b062a4ba97fa1)

Change-Id: I4abc14594c53989bec8badd5691e2023b70d8f13
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5477
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
1ceffbf
@torvalds torvalds UPSTREAM: arm: remove "optimized" SHA1 routines
Since commit 1eb19a12bd22 ("lib/sha1: use the git implementation of
SHA-1"), the ARM SHA1 routines no longer work.  The reason? They
depended on the larger 320-byte workspace, and now the sha1 workspace is
just 16 words (64 bytes).  So the assembly version would overwrite the
stack randomly.

The optimized asm version is also probably slower than the new improved
C version, so there's no reason to keep it around.  At least that was
the case in git, where what appears to be the same assembly language
version was removed two years ago because the optimized C BLK_SHA1 code
was faster.

Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4d4487140d34c1b9b321889d2d209321b0da6643)

Change-Id: I5e98535224284ef5d30351e9039df725fcd26097
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5478
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
10b827e
@torvalds torvalds UPSTREAM: arm: remove stale export of 'sha_transform'
The generic library code already exports the generic function, this was
left-over from the ARM-specific version that just got removed.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f23c126bfabef88c201c8cc56bd3ccd9d59c51e0)

Change-Id: I7ea9023f72cc33fbcfb9d8c62699a9e98ca81fac
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5479
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
18ba9ac
Grant Grundler CHROMIUM:staging:iio:light: fix ISL29018 sensor operation after a bro…
…wnout

After a voltage brownout, sensor will now operate correctly.

Page 10 of ISL29018 data sheet and the Intersil Application Note 1534
describe the required initialization sequence:
1. Write 0x00 to register 0x08 (TEST)
2. Write 0x00 to register 0x00 (CMD1)
3. msleep(1)
4. program remaining registers as before

BUG=chrome-os-partner:5351,chrome-os-partner:4752
TEST=manual (boots and light sensor responds after 5 seconds)

Change-Id: I09738e3680cacfa9f71e2173cdd02aae82e26dd5
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5474
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
3d084e2
@swarren @dianders swarren CHROMIUM: video: tegra: Modify tegra_dc_hdmi_setup_audio prototype
A future change will modify tegra_dc_hdmi_setup_audio() to dynamically
calculate CTS and N values. This will be simpler if the function simply
returns those individual values directly through "out parameters" rather
than having to return a pointer to a structure containing those values.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
BUG=chrome-os-partner:4249
TEST=Compile the kernel for Tegra

Change-Id: If9eba4cf1edbd82e32a3b0a5351c3ac87c40ae14
Reviewed-on: http://gerrit.chromium.org/gerrit/5264
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Taylor Hutt <thutt@chromium.org>
33191f6
@vpalatin vpalatin CHROMIUM: config: tune RCU config
When starting the tegra2 kernel, we are waiting several hundred
milliseconds on each synchronize_rcu() because the second CPU is idle.

We save 1420ms on kernel boot time.
(measured on Kaen doing 12 runs with and 12 runs without the patch)

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=none
TEST=run "./lab_test.py --board=tegra2_kaen -i BootPerfServer" with and
without the change

Change-Id: Idceec5ea48064d44070594bb0adbfb0e6eb7737a
Reviewed-on: http://gerrit.chromium.org/gerrit/5557
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
5a71c19
@swarren @dianders swarren CHROMIUM: video: tegra: Calculate HDMI audio CTS/N values
The current table-drive approach for determining the CTS and N values
required for HDMI audio limits audio availability to a small set of pixel
clock frequencies. Allow audio in other cases by calculating the CTS and N
value dynamically where the tables don't contain pre-calculated values.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
BUG=chrome-os-partner:4249
TEST=Boot ChromeOS
  Plug in HDMI monitor
  Boot ChromeOS
  Log in to ChromeOS UI
  Log in over serial console as user chronos
  export DISPLAY=:0
  export XAUTHORITY=/home/chronos/.Xauthority
  # Without the following, one/both of them reset the display back to
  # 1080p after each xrandr command of yours
  sudo stop powerd
  sudo stop powerm
  # Just to keep things simple
  xrandr --output LVDS-1 --off
  # Use a long 44.1KHz audio file here
  aplay -D hw:0,1 /foo.wav &
  # Alternatively, use speaker-test:
  speaker-test -D hw:0,1 -c 2 -r 44100 -t sine &
  # List supported modes, hopefully the list includes entries that weren't
  # supported before Robert's changes to support abitrary HDMI modes
  xrandr -q
  # For each mode $mode:
    xrandr --output HDMI-1 --mode $mode --refresh $refresh
    # Observe audio still playing

Change-Id: I30d3f63278a85673a722c17b437fba33d956f7e7
Reviewed-on: http://gerrit.chromium.org/gerrit/5265
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
02d4ea6
@swarren @dianders swarren CHROMIUM: video: tegra: Preserve sample rate across DPMS off
When the display mode is changed, or the display turned off then on,
tegra_dc_hdmi_enable() would re-initialize the HDMI audio programming for
a hard-coded 44100Hz sample rate. If audio was actually playing at a
different rate, this would end up causing audio noise or dropouts.
Instead, remember the most recently used audio frequency, and use that.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
BUG=chrome-os-partner:4249
TEST=Same steps as for previous commit,
  "CHROMIUM: video: tegra: Calculate HDMI audio CTS/N values",
  but using an audio file that isn't at 44.1KHz

Change-Id: Ib580e35871ae4a6b05c98124f4cdfdc0cb90b663
Reviewed-on: http://gerrit.chromium.org/gerrit/5266
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
0bed2ad
@bopiy @dianders bopiy CHROMIUM: arm: tegra: Remove pll_x from common_clk_init_table
The CPU clock source switches from pll_x to pll_p when CPU fequency goes
to 216MHz and pll_x should be disabled.
Kernel can disable pll_x by removing the entry in the common_clk_init_table

BUG=none
TEST=Built kernel and boot. pll_x can be disabled when CPU frequency goes
     to 216MHz

Change-Id: I533b2971ad7b4842b9de67d9b11875107be67775
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5213
Reviewed-by: Allen Martin <amartin@nvidia.com>
Reviewed-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
d6aca21
Elly Jones CHROMIUM: init: don't dm_substitute_devices().
With uuid+offset support in dm_get_device(), we don't need to substitute at all
here, and this code was kind of a wart.

BUG=chromium-os:17184
TEST=Adhoc
Booted. dmesg | grep device-mapper
Built a normal image for kaen, booted it successfully.

Change-Id: I690cd60433925ee419796497ec922442f04e53af
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3970
Reviewed-by: Will Drewry <wad@chromium.org>
668d417
Elly Jones TBR Revert "CHROMIUM: init: don't dm_substitute_devices()."
This reverts commit 2eb0de2ca3050279f00f0170309cca7002ee145c

Probably caused http://build.chromium.org/p/chromiumos/builders/x86%20generic%20PFQ/builds/152

Change-Id: Ib893569ba3285b587e60be356fbb7d9e28adc3a6
Reviewed-on: http://gerrit.chromium.org/gerrit/5579
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Tested-by: Elly Jones <ellyjones@chromium.org>
9dcf92d
@sglass68 Da Zheng CHROMIUM: config: the kernel for ARM support sqashfs.
BUG=none
TEST=adhoc

Change-Id: I1d6f4ac50122032c338e052c4ab0bfeccdfb111b
Signed-off-by: Da Zheng <zhengda@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4898
Reviewed-by: Simon Glass <sjg@chromium.org>
6e90260
@bleungatchromium bleungatchromium Revert "CHROMIUM: config: tune RCU config"
This reverts commit 5a71c19.

Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chromium-os:18948
TEST=Boot system. powerd_suspend.
Ensure that no mmcblk errors occur on resume.

Change-Id: I2bd1dcec10d2387fbe631fd2aa388c74231b6176
Reviewed-on: http://gerrit.chromium.org/gerrit/5624
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
b4f6002
@colincross @bleungatchromium colincross ARM: tegra: timer: Add suspend and resume support
Signed-off-by: Colin Cross <ccross@android.com>
(cherry picked from commit 488708cafb8ad65fa3cf75ccc1d21d1f0d33154a)

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chrome-os-partner:5308
TEST=powerd_suspend
dmesg
Ensure that timestamps before and after suspend
resume are consistent.

Change-Id: I182210d10b91456be43c2d1042cafa6564762aa7
Reviewed-on: http://gerrit.chromium.org/gerrit/5620
Tested-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
e07362a
@muromec muromec bq2045 battery driver for TF101 3b0bd4e
Sameer Nanda CHROMIUM: audio: cirrus: add support for CS421x
This update includes the changes necessary for supporting the CS421x
family of codecs. Previously this file only supported the CS420x
family of codecs.

This file also contains initialization verbs to correct several issues
in both the CS420x and CS421x hardware.

NOTE: a version of this patch has been uploaded upstream to ALSA.
However, in order to use the upstreamed patch we need to be at ALSO version
1.0.25. We are currently at version 1.0.24 and therefore taking this out
of tree patch for now.

TEST=plug in headphones. Go to an audio site such as zombo.com and make
sure audio is heard.
BUG=chrome-os-partner:5290

Change-Id: I370a19ce0b84534f33e18e5fe1f5f6fa799394ae
Signed-off-by: Tim Howe <tim.howe@cirrus.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5663
Tested-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
3e0d8af
@bleungatchromium Dilan Lee CHROMIUM: arm: tegra: Add a callback 'notify_after' for backlight con…
…trol

We need a callback to do some things after pwm_enable, pwm_disable
and pwm_config.

This should have been done at the same time as these kernel CLs:
 * http://gerrit.chromium.org/gerrit/#change,4906
    CHROMIUM: arm: tegra: kaen/aebl: implement panel power sequence

BUG=chrome-os-partner:1957
TEST=passed signal measurement on kane and aebl, all timings meet
     customer's request.

Change-Id: I9968273f7b2c3a42fad611639694cb3ec4e21a98
Signed-off-by: Dilan Lee <dilee@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5455
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
da61fee
@dianders Mursalin Akon CHROMIUM: tegra: harmony: wifi: add board support for WiFi
The SDIO WiFi module requires power from external PMU and 1.2V regulator.
The module gets powered on if - (1) all power sources are enabled, and
(2) power (down) and reset (down) pins are enabled as per spec.

To enable mmc/SDIO driver to detect the WiFi hardware, the WiFi chip has
to be powered-up before mmc driver does probing. So, steps should be as
following: (1) required regulators are on, (2) power/reset of WiFi are
enabled, (3) mmc does probing. Later time, when WiFi driver module is
loaded and registers with SDIO, the SDIO driver knows which H/W the driver
has to be associated with.

BUG=none
TEST=WiFi module is properly powered up and mmc detects it. Sample kernel log:

[    3.202617] mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
[    3.211251] mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
[    3.215018] mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
[    3.215810] mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
[    3.220636] mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
[    3.220894] mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
[    3.221150] mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
[    3.221283] mmc0: new SDIO card at address 0001

Change-Id: I6ff46924913efbeff0a332bd195300a58d2eb8d8
Signed-off-by: Mursalin Akon <makon@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4550
Reviewed-by: Allen Martin <amartin@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
d781b64
Nick Sanders CHROMIUM: arm: tegra2: Add keys for JP, UK kbd
Fill in scancode matrix for extra JP, UK keys.

BUG=chrome-os-partner:5212
TEST=(By partner) Using evtest on a system with JP, verify that each key produces the matching code.
Signed-off-by: Nick Sanders <nsanders@google.com>
Change-Id: Ia3f2dd19cd86c16b3972cf962e409988755eabae
Reviewed-on: http://gerrit.chromium.org/gerrit/5630
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
6286dfe
@pieleric @djkurtz pieleric BACKPORT: Input: elantech - describe further the protocol
For some Dell laptops, Ubuntu had a special version of the elantech
driver with more knowledge on the devices. It can be found there:
http://zinc.ubuntu.com/git?p=mid-team/hardy-netbook.git;a=blob;f=drivers/input/mouse/elantech.c;h=d0e2cafed162428f72e3654f4dda85e08ea486b3;hb=refs/heads/abi-22

By inspecting the source code, and doing some test on a real hardware, I
have completed the protocol specification (especially for the 6 bytes
protocol). It also adds information about the mapping between the
version reported by the device and the protocol to use.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 71c6d18)

Change-Id: Ia7627a400b881b714a7fc898ea13469d97c8e53f
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5654
Tested-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: JJ Ding <jj_ding@emc.com.tw>
Tested-by: TomLin <tom_lin@emc.com.tw>
Reviewed-by: TomLin <tom_lin@emc.com.tw>
6906674
@pieleric @djkurtz pieleric BACKPORT: Input: elantech - export pressure and width when supported
Using the info of the Dell/Ubuntu driver, described in the protocol
document, report both width and pressure when pressing 1 and 3
fingers, for the versions of the touchpad which support it.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit f941c70)

Change-Id: I4d52ecc7fb27d34080f81a24adf68fc69e00dff3
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5655
Tested-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: JJ Ding <jj_ding@emc.com.tw>
Tested-by: TomLin <tom_lin@emc.com.tw>
Reviewed-by: TomLin <tom_lin@emc.com.tw>
579e458
@pieleric @djkurtz pieleric BACKPORT: Input: elantech - report multitouch with proper ABS_MT mess…
…ages

Multitouch info was reported only via a old protocol used by the
proprietary X driver from elantech. Let's report the multitouch info
also following the official MT protocol. It's semi-mt because the device
only reports the lowest/highest coordinates.

This was done following the multi-touch-protocol.txt documentation, and
inspired by the bcm5974 and elantech implementations. Testing was light
as there is not many applications using this protocol yet, but the X
synaptics driver didn't complain and the X multitouch driver behaved
correctly.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 89eec4d)

Change-Id: If864a5f814f75d3543f14bba132118007bfd1920
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5656
Tested-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: JJ Ding <jj_ding@emc.com.tw>
Tested-by: TomLin <tom_lin@emc.com.tw>
Reviewed-by: TomLin <tom_lin@emc.com.tw>
9721118
@pieleric @djkurtz pieleric BACKPORT: Input: elantech - remove support for proprietary X driver
Apparently somewhere someone had a proprietary X driver. To get the
multitouch info, it uses some hack on the normal API instead of using
the multitouch protocol. Now that the multitouch info is transmitted
correctly it makes not much sense to keep it. Especially because it's
impossible to find this proprietary X driver anywhere, so the number of
users must be very low.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 9cb6cfa)

Change-Id: I8bfdc12b2ce8259f32efc0bd1cb3813ef58ef6c3
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5657
Tested-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: TomLin <tom_lin@emc.com.tw>
Tested-by: TomLin <tom_lin@emc.com.tw>
64c4577
Sameer Nanda CHROMIUM: nm10_gpio: support additional LPC IDs
Adding more LPC device IDs of the Intel 6 Series and C200 Series
chipsets.

This has been tested and works on HM65 and HM67 variants.

BUG=none
TEST=run crossystem and ensure that the current values of recovery and
dev switches are correct

Change-Id: I895fca9bd5c23caeb2b4a3b06bbb20bc46d8691a
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5682
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
6857fb8
@dianders dianders CHROMIUM: config: tegra: Switch early printk to UARTB.
This will BREAK earlyprintk for seaboard but fix it for many
seaboard variants (which all use UARTB).  If we want to do something
better, we'd need to do something clever like store the printk UART
in a scratch register.

BUG=chromium-os:18486
TEST=On kaen, added earlyprintk to the cmdline and saw early printouts.
Note that you also see some garbage printed out before the early
printouts.  That seems fairly harmless, but should probably be fixed
eventually.

Change-Id: I9db422a3f3bd7122b6c9fcfafb55b66f97084544
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5769
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
7726ce0
Dave Parker CHROMIUM: arm: tegra: Fully populate EMC scaling table entries for aebl
This is to support aebl boards that use straps to select either of the
remaining two BCT entries. Separate timing tables may be added later
if required by these boards.

BUG=chrome-os-partner:5435
TEST=Boot aebl boards strapped for ram_ids 2 and 3

Change-Id: I2de9c58a1aa6b7640e475005fa37a0e168f5ec20
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5786
0d22fcb
@dianders dianders CHROMIUM: i2c: tegra: fix possible race condition after tx
In tegra_i2c_fill_tx_fifo, once we have finished pushing all the bytes
to the I2C hardware controller, the interrupt might happen before we
have updated i2c_dev->msg_buf_remaining at the end of the function.
Then, in tegra_i2c_isr, we will call again tegra_i2c_fill_tx_fifo
triggering weird behaviour. This has been shown to happen under
real conditions.

Submitted upstream at: https://lkml.org/lkml/2011/8/11/424

BUG=chromium-os:18841
TEST=System appears to behave normally while under DVFS and
exercising various i2c peripherals.

Change-Id: I91b0ea715ffd3384f0a332e821cca6760d597a68
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5684
c37a91c
@vpalatin Bill Huang CHROMIUM: USB: tegra: turn off usb1/usb3 vbus in suspend
Turn off usb1/usb3 vbus in system suspend if the flag
power_down_on_bus_suspend is set, this save ~2mW in suspend.

BUG=chrome-os-partner:4856
TEST=Plug in USB optical mouse in suspend to see if the light
is off, or compare the total power difference in suspend,
it saves ~2mW.

Change-Id: I25cf33e728781a73b68e187bb3adf041708846ff
Signed-off-by: Bill Huang <bilhuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4718
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
ad2c6fe
@dianders Xin Xie CHROMIUM: regulator: tps6586x: add SMx slew rate setting
Add output vlotage slew rate setting for SM0/SM1

LKML thread (acked by Mark Brown): https://lkml.org/lkml/2011/8/9/89
Expected to show up in:
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6.git

BUG=none
TEST=built kernel and boot.

Change-Id: I9663343cfa4572495a4fec0a697a1129eaa36333
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4920
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
0151769
@bopiy @dianders bopiy CHROMIUM: arm: tegra: seaboard: set regulator output voltage slew rate
The default slew rate is 7.04mV/us. Set the rate to 3.52mV/us in order
to prevent voltage undershoot when changing from high level to low level

From: Xin Xie <xxie@nvidia.com>

BUG=chrome-os-partner:5415
TEST=built kernel and boot. Kernel can change voltage correctly.

Change-Id: I2ebc83a8b19e132fe7af53c6d8fc3d6e24c6db7d
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4921
Reviewed-by: Doug Anderson <dianders@chromium.org>
1f81003
@kvalo kvalo ieee80211: add few wmm tspec values
These are needed by ath6kl for parsing tspec status from an IE.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit 856799d58274bfa6a57bc80051ee1cefdb6b041f)

BUG=chrome-os-partner:1770
TEST=build kernel

Change-Id: Ibfed904233605151c8d0777050d9b87e45712bb4
Reviewed-on: http://gerrit.chromium.org/gerrit/5881
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
d2f1292
Jouni Malinen cfg80211: Add nl80211 event for deletion of a station entry
Indicate an NL80211_CMD_DEL_STATION event when a station entry in
mac80211 is deleted to match with the NL80211_CMD_NEW_STATION event
that is used when the entry was added. This is needed, e.g., to allow
user space to remove a peer from RSN IBSS Authenticator state machine
to avoid re-authentication and re-keying delays when the peer is not
reachable anymore.

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
(cherry picked from commit ec15e68)

BUG=chrome-os-partner:1770:
TEST=build kernel

Change-Id: I91a37692fc6ccb2abea2cb220a3324a169323467
Reviewed-on: http://gerrit.chromium.org/gerrit/5880
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Sam Leffler <sleffler@chromium.org>
802048c
@kvalo kvalo ieee80211: add few wmm tspec values
These are needed by ath6kl for parsing tspec status from an IE.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Change-Id: Iad3a6cda19032058b747e448a5bd3585caf31661
Reviewed-on: http://gerrit.chromium.org/gerrit/5567
Tested-by: Sam Leffler <sleffler@chromium.org>
Reviewed-by: Sam Leffler <sleffler@chromium.org>
f4d8a36
@vpalatin vpalatin CHROMIUM: config: enable large block devices on ARM
This change allows to mount USB key formatted with ext4 filesystem on
ARM based configuration (this is already working on x86).

CONFIG_LBDAF normally enables the support for 2TB+ block devices,
but when an ext4 filesystem has the "huge_file" feature enabled (which is
the default in mkfs.ext4), it requires this option to be mounted
read-write.

The GFS2_FS configuration symbol is now common to all our configuration file,
so it moves automatically to config.common.chromeos.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chromium-os:19106
TEST=mount an EXT4 formatted USB key from the command line

Change-Id: If97eac4f880cc413e42c40ac71a6e48c92019737
Reviewed-on: http://gerrit.chromium.org/gerrit/5900
Reviewed-by: Will Drewry <wad@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
789c688
Marco Stornelli UPSTREAM: ramoops: use module parameters instead of platform data if …
…not available

Use generic module parameters instead of platform data, if platform data
are not available.  This limitation has been introduced with commit
c3b92ce ("ramoops: use the platform data structure instead of module
params").

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Américo Wang <xiyou.wangcong@gmail.com>
Reported-by: Stevie Trujillo <stevie.trujillo@gmail.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 13aefd7293e7a697bbf452fca65e69cc1fa8a31c)

Change-Id: If4f30cd3275789a332a095ba5620240765f4742d
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5342
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
8282666
Marco Stornelli UPSTREAM: ramoops: add new line to each print
Add new line to each print.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Reported-by: Stevie Trujillo <stevie.trujillo@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Américo Wang <xiyou.wangcong@gmail.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0169256e4bbf29e507cdd1df5812c093d610f1d5)

Change-Id: I959fd11eacca229e2277a36fc2ff7e58d3cbad92
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5343
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
fd9d564
Sergiu Iordache UPSTREAM: ramoops: move dump_oops into platform data
The platform driver currently allows setting the mem_size and
mem_address.

Since dump_oops is also a module parameter it would be more consistent if
it could be set through platform data as well.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6b4d2a2733b9a17112f746d498c9f9a0427dcdd8)

Change-Id: I97fb254f27584b49be617350eef80922f30ce5ea
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5344
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
87756ad
Sergiu Iordache UPSTREAM: ramoops: make record_size a module parameter
The size of the dump is currently set using the RECORD_SIZE macro which
is set to a page size.  This patch makes the record size a module
parameter and allows it to be set through platform data as well to allow
larger dumps if needed.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3e5c4fadb9943c7539364d0c8425db071a2020e4)

Change-Id: I273274cc37e9d8c9cdee95d82f2cad96cdc2cbef
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5345
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
d44d8bc
James Bottomley UPSTREAM: ramoops: fix compile failure on parisc
Fixes this:

  drivers/char/ramoops.c: In function 'ramoops_init':
  drivers/char/ramoops.c:221: error: implicit declaration of function 'IS_ERR'
  drivers/char/ramoops.c:222: error: implicit declaration of function 'PTR_ERR'

If it actually builds on other platforms, it's probably getting
linux/err.h via some other #include.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 83c1b31794a9e3cb30edabef7e57fbdbe129c5ce)

Change-Id: I94edeaeb9d9bb4c2a9914e5de34f5a66f8a1d9cb
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5346
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
5c09c43
Sergiu Iordache UPSTREAM: ramoops: update module parameters
Update the module parameters when platform data is used.  This means
that they can be read from /sys/module/ramoops/parameters in order to
parse the memory area.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Cc: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f7b9fcbbc3b8593ff7dc587f90c2fe90a2fd1e6f)

Change-Id: I79c8a3663060800978ba894b10f69f0955a835ba
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5347
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
b0b25d2
Sergiu Iordache CHROMIUM: Add platform data for ramoops
Adds and sets the platform data so that ramoops works on Chromium OS.

Needs the ramoops upstream patches in the series to work properly.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Change-Id: I6b1f0a26a82bfdda111945ab497e69d1c11dc137
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5426
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
7342219
Sergiu Iordache CHROMIUM: config: Adds kconfig entries for ramoops
In order to easily maintain the cross-platform settings we decided to
use Kconfig entries to set the Ramoops parameters. The patch adds the
required entries for ramoops.

BUG=chromium-os:12059
TEST=Tested manually, run autotests on both Mario and Alex

Change-Id: I780c80bc07b8ee8113ffa4267e55daddc23103ff
Signed-off-by: Sergiu Iordache <sergiu@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5427
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
dc51d09
Mandeep Singh Baines Revert "CHROMIUM: Add platform data for ramoops"
This reverts commit 14fba818763304b41151b41f7e4946788f499de2

Change-Id: I4c614767e02beec68ccd42aaa96ffe4d8f3adce5
Reviewed-on: http://gerrit.chromium.org/gerrit/6002
Tested-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Sergiu Iordache <sergiu@chromium.org>
e4cfda0
@dianders dianders CHROMIUM: tegra: harmony: wifi: Fix harmony_wifi_init() return val.
The previous patch to harmony added harmony_wifi_init(), but
didn't realize that function installed with subsys_initcall_sync()
should return a value.  This caused a warning in the kernel compile.

BUG=None
TEST=No more compile-time warning.

Change-Id: Ic115a6d25f8c33e43957a00af240a67ac3552c64
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5792
Tested-by: Mursalin Akon <makon@nvidia.com>
Reviewed-by: Mursalin Akon <makon@nvidia.com>
6348aef
@yufengshen yufengshen CHROMIUM: tegra: asymptote: Optimize mxt config on asymptote
    Atmel touch controller on asymptote is currently very unsensitive
due to high TCHTHR/TCHDI values. Experiments show that by turning off
Noise Suppression Object (T22), TCHDI can be decreased to 0x02 and
the false detection rate can still remain very low. In this patch, we
turn off Noise Suppression Object (T22) and decrease TCHDI to 0x02 so
that we can have usable asymptote device for now.

BUG=None
TEST=Manually tested on Asymptote and confirmed false detection rate
remains low and touch sensitivity is increased.

Change-Id: Id14a7df4b51120744e0d2c4ef4bfd5125f39e4de
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6040
Tested-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
2d0aac4
@rhklein @dianders rhklein CHROMIUM: video: tegra: nvmap: fix possible sleep while atomic
Fix possible sleep in atomic context in iovmm code
(semaphore inside spinlock) by replacing spinlock
with mutex.

This is mostly a theoretical case and a test to exercise it explicitly
hasn't been found that is reliable.

Split off from change: http://gerrit.chromium.org/gerrit/#change,5485

TEST=Verified kernel boots and seems stable with this change while doing
gles tests that exercise memory allocations from nvmap.
BUG=None

Change-Id: I84a132e8b4019db298e848b189fee090a6af19c1
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5750
Reviewed-by: Doug Anderson <dianders@chromium.org>
b98c088
@dtor @djkurtz dtor UPSTREAM: Input: synaptics - set minimum coordinates as reported by f…
…irmware

Newer Synaptics firmware allows to query minimum coordinates reported by
the device, let's use this data.

Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit a66413fbc37994710d638aec3314f735a7ac0df5)

BUG=chromium-os:19209
TEST=builds

Change-Id: I7b7f87bd02007c774f93e9083b1fd5cdb5b4192b
Reviewed-on: http://gerrit.chromium.org/gerrit/5064
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
9765515
@dtor @djkurtz dtor UPSTREAM: Input: synaptics - fix reporting of min coordinates
We were testing wrong bit in the extended capability query.

Reported-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
(cherry picked from commit 3c6b50141ef9f0a8844bf1357b80c0cdf518bf05)

BUG=chromium-os:19209
TEST=builds

Change-Id: I0387e2d50231f1e1d10f799551f8a7d4306046e2
Reviewed-on: http://gerrit.chromium.org/gerrit/5065
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
c149199
@dianders Mursalin Akon CHROMIUM: tegra: harmony: wifi: Make the init harmony specific
The Atheros wifi init function should be harmony specific. The
previous change added an init function that is invoked for all
board platforms.

BUG=none
TEST=Tested with extra kernel log that the init function is not
invoked on other board platform (i.e., Ventana).

Change-Id: I8d5893149aa992f033824a6fced9a05ed7811e16
Signed-off-by: Mursalin Akon <makon@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/6083
Reviewed-by: Doug Anderson <dianders@chromium.org>
cda14e3
Mandeep Singh Baines CHROMIUM: verity: use one shared queue per processer
Move from creating workqueues per instance of a verity target to sharing
workqueues across all targets.

BUG=chromium-os:9752
TEST=Ran platform_DMVerityCorruption and platform_DMVerityBitCorruption.
TESTED_ON=Alex

Change-Id: I8b07c456f8d475d4fb56a9ec8b73536e1c115470
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5672
Reviewed-by: Will Drewry <wad@chromium.org>
62e85a2
Mandeep Singh Baines CHROMIUM: verity: embed hash_desc instead of allocating it
This simplifies the code and saves a level of indirection.

I also discovered a leak in one of the dm_bht_create error paths
which is also fixed by this change.

BUG=chromium-os:9752
TEST=Ran unit tests from dm-verity.git.
     Ran platform_DMVerityCorruption and platform_DMVerityBitCorruption.
TESTED_ON=Alex

Change-Id: I243e8ffeb7ecf19d9a6a6386fc81fce646b0a6f6
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5673
e9fe879
Elly Jones CHROMIUM: init: don't dm_substitute_devices().
With uuid+offset support in dm_get_device(), we don't need to substitute at all
here, and this code was kind of a wart.

BUG=chromium-os:17184
TEST=Adhoc
Booted. dmesg | grep device-mapper
Built a normal image for kaen, booted it successfully. This tests u-boot.
Build a normal image for any x86 board (I used x86-alex). Boot it. This tests
chromeos-firmware boot.
Modify your x86 image for vm using image_to_vm.sh (this doesn't work for Arm
yet). Make sure it boots in the VM. This tests legacy (syslinux) boot.
As for testing grub boot, you're on your own :)

Change-Id: I6c7f048a7ec8b6949a29c86aaa5b9ebec6545404
Reviewed-on: http://gerrit.chromium.org/gerrit/3970
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6063
Reviewed-by: Will Drewry <wad@chromium.org>
854430a
@yufengshen yufengshen CHROMIUM: tegra: asymptote: Decrease touch threshold for asymptote
	Currently atmel touch controller threshold TCHTHR is set too high
that dragging is reported as continues press/release pair events instead
of press/move(s)/release events. This patch decreases THCTHR from 0x50
to 0x3c so that dragging is correctly interpreted. TCHDI is increased
from 0x02 to 0x03 to suppress noise.

BUG=None
TEST=Manually tested on Asymptote and confirmed that scrolling on webpage
is working as expected.

Change-Id: I60daffa232f85001794f22bd32f99d0d40ba86e5
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6117
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
91e40cc
Dilan Lee CHROMIUM: arm: tegra: kaen/aebl: implement panel power sequence
the sequence of panel power on:
GPIO_EN_VDD_PNL up
delay 4ms
GPIO_LVDS_SHUTDOWN up
delay 203ms
GPIO_BACKLIGHT_VDD up
delay 20ms
BACKLIGHT_PWM(GPIO_PU5) up
delay 20ms
GPIO_BACKLIGHT up

the sequence of panel power off:
GPIO_BACKLIGHT down
delay 203ms
GPIO_LVDS_SHUTDOWN down
delay 4ms
GPIO_EN_VDD_PNL down and BACKLIGHT_PWM(GPIO_PU5) down
delay 20ms
GPIO_BACKLIGHT_VDD down

This should have been done at the same time as these kernel CLs:
 * http://gerrit.chromium.org/gerrit/#change,5455
    CHROMIUM: arm: tegra: Added a callback 'notify_after' for backlight control

BUG=chrome-os-partner:1957
TEST=passed signal measurement on kane and aebl, all timings meet
     customer's request.

Change-Id: I2faada7d40aba61d36379f27242d557bcb8b19f0
Signed-off-by: Dilan Lee <dilee@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/4906
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
dc94fa2
Bryan Freed CHROMIUM: ARM: tegra: kaen: Set the panel backlight to just over 200Hz.
This is requested (along with a hardware rework) to reduce an audible hum
from the LCD panel.

BUG=chrome-os-partner:1957
TEST=Probe the backlight signal to confirm the frequency.

Change-Id: I8470f4fa1c89985345eabab4a2b60a05d1e8f99c
Signed-off-by: Bryan Freed <bfreed@chromium.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/6112
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Tested-by: Bryan Freed <bfreed@chromium.org>
56b2ab1
@djkurtz djkurtz CHROMIUM: config: enable elantech driver for i386 and x86_64
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium-os:19264
TEST=rebuild kernel;
test on x86-* machine with installed elantech touchpad
confirm kernel detects elan touchpad in /var/log/messages:
   elantech: assuming hardware version 4 (with firmware version 0x361f00)
   elantech: Synaptics capabilities query result 0x11, 0x14, 0x0e.
   input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio4/input/input5

Change-Id: I44b23ebc2d1813e8e82413d1e8649d5b3e82f4a6
Reviewed-on: http://gerrit.chromium.org/gerrit/6158
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
2a9b8c8
@yufengshen yufengshen Input: atmel_mxt_ts.c - clean divergence with upstream
Clean a minor formatting divergence with upstream so later upstream
patch can be applied cleanly.

BUG=None
TEST=Applying the patch and atmel_mxt_ts.c compiles.

Change-Id: Ic3de767e85b94a0c5c11e60add6ead45779152c1
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6084
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
942201c
@djkurtz djkurtz CHROMIUM: Input: synaptics - refactor y inversion
Synaptics touchpads report increasing y from bottom to top.
This is inverted from normal userspace "top of screen is 0" coordinates.
Thus, the kernel driver reports inverted y coordinates to userspace.

This patch refactors this inversion.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: Ib8dfb543f5b6017609eb133fdc7be325189ccbfa
BUG=chromium-os:19094
TEST=builds clean; cursor still moves up and down correctly
Reviewed-on: http://gerrit.chromium.org/gerrit/4254
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
7f6fd4f
@djkurtz djkurtz CHROMIUM: Input: synaptics - refactor agm packet parsing
When a Synaptics touchpad is in "AGM" mode, and multiple fingers are
detected, the touchpad sends alternating "Advanced Gesture Mode" (AGM) and
"Simple Gesture Mode" (SGM) packets.
  The AGM packets have w=2, and contain reduced resolution finger data.
  The SGM packets have w={0,1} and contain full resolution finger data.

Refactor the parsing of agm packets to its own function, and rename the
synaptics_data.mt field to .agm to indicate that it contains the contents of
the last agm packet.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I5b3104855f55d561a35f13bea0b61b2460dcd48e
BUG=chromium-os:19094
TEST=builds clean; check sgm and agm packets with evtest
Reviewed-on: http://gerrit.chromium.org/gerrit/4255
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
8de8f45
@djkurtz djkurtz CHROMIUM: Input: synaptics - refactor initialization of abs position …
…axes

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I567772e653cd94176eda899e7a06986d83474574
BUG=chromium-os:19094
TEST=builds clean; confirm absinfo ranges using evtest
Reviewed-on: http://gerrit.chromium.org/gerrit/4398
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
e90e234
@djkurtz djkurtz CHROMIUM: Input: synaptics - add image sensor support
Synaptics makes (at least) two kinds of touchpad sensors:
 * Older pads use a profile sensor that could only infer the location
   of individual fingers based on the projection of their profiles
   onto row and column sensors.
 * Newer pads use an image sensor that can track true finger position
   using a two-dimensional sensor grid.

Both sensor types support an "Advanced Gesture Mode":
 When multiple fingers are detected, the touchpad sends alternating
 "Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
 packets.
 The AGM packets have w=2, and contain reduced resolution finger data
 The SGM packets have w={0,1} and contain full resolution finger data

Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other.  Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.

Image sensors can report the actual coordinates of two of the fingers
present.  This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.

NOTE: This patch only adds partial support for 2-finger gestures.
      The proper interpretation of the slot contents when more than
      two fingers are present is left to later patches.  Also,
      handling of 'number of fingers' transitions is incomplete.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: Ie271205829ae317833a4c4ed6a453ce83260c171
BUG=chromium-os:19094
TEST=builds clean; confirm using evtest
Reviewed-on: http://gerrit.chromium.org/gerrit/4256
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
d5471ae
@djkurtz djkurtz CHROMIUM: Input: synaptics - decode AGM packet types
A Synaptics image sensor tracks 5 fingers, but can only report 2.

The algorithm for choosing which 2 fingers to report and in which packet:
  Touchpad maintains 5 slots, numbered 0 to 4
  Initially all slots are empty
  As new fingers are detected, assign them to the lowest available slots
  The touchpad always reports:
    SGM: lowest numbered non-empty slot
    AGM: highest numbered non-empty slot, if there is one

In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots.  Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked.  When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: Ibd52fda9f516afe4e0ee6635af377b212b59580f
BUG=chromium-os:19094
TEST=builds clean; confirm with evtest
Reviewed-on: http://gerrit.chromium.org/gerrit/4257
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
fcae158
@djkurtz djkurtz CHROMIUM: Input: mt - document devices reporting more touches than slots
Some devices are capable of identifying and/or tracking more contacts than
they can report to the driver.  Document how a driver should handle this,
and what userspace should expect.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I92d92b0235b47000afba0f6f7c7b1ba11550720f
BUG=chromium-os:19094
TEST=read the doc
Reviewed-on: http://gerrit.chromium.org/gerrit/6217
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
ccb1f01
@djkurtz djkurtz CHROMIUM: Input: synaptics - process finger (<=3) transitions
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:

 * When there are 3 or more fingers, only two are reported.
 * The touchpad tracks the 5 fingers in slot[0] through slot[4].
 * It always reports the lowest and highest valid slots in SGM and AGM
   packets, respectively.
 * The number of fingers is only reported in the SGM packet.  However,
   the number of fingers can change either before or after an AGM
   packet.
 * Thus, if an SGM reports a different number of fingers than the last
   SGM, it is impossible to tell whether the intervening AGM corresponds
   to the old number of fingers or the new number of fingers.
 * For example, when going from 2->3 fingers, it is not possible to tell
   whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
   3rd finger).
 * When fingers are added one at at time, from 1->2->3, it is possible to
   track which slots are contained in the SGM and AGM packets:
     1 finger:  SGM = slot[0], no AGM
     2 fingers: SGM = slot[0], AGM = slot[1]
     3 fingers: SGM = slot[0], AGM = slot[2]
 * It is also possible to track which slot is contained in the SGM when 1
   of 2 fingers is removed.  This is because the touchpad sends a special
   (0,0,0) AGM packet whenever all fingers are removed except slot[0]:
     Last AGM == (0,0,0): SGM contains slot[1]
     Else: SGM contains slot[0]
 * However, once there are 3 fingers, if exactly 1 finger is removed, it
   is impossible to tell which 2 slots are contained in SGM and AGM.
   The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
 * Similarly, if two fingers are simultaneously removed (3->1), then it
   is only possible to know if SGM still contains slot[0].
 * Since it is not possible to reliably track which slot is being
   reported, we invalidate the tracking_id every time the number of
   fingers changes until this ambiguity is resolved when:
     a) All fingers are removed.
     b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
     c) All fingers are removed except slot[0].  In this special case, the
        ambiguity is resolved since by the (0,0,0) AGM packet.

Behavior of the driver:

When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad.  If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.

The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
 a) There are more than 2 fingers on the pad.
 b) During ambiguous number-of-fingers transitions, the correct track_id
    for one or both of the slots cannot be determined, so the slots are
    invalidated.

Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I26021fbb30a93e9713ac68be96194364c81c909d
BUG=chromium-os:19094
TEST=builds clean; evtest to confirm raw events
     confirm motion, 2f-tap, 2f-scroll, using xf86-input-cmt
Reviewed-on: http://gerrit.chromium.org/gerrit/4258
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
d9be2fa
@djkurtz djkurtz CHROMIUM: Input: add BTN_TOOL_QUINTTAP for reporting 5 fingers on tou…
…chpad

"4-finger scroll" is a gesture supported by some applications and
operating systems.

"Resting thumb" is when a clickpad user rests a finger (e.g., a
thumb), in a "click zone" (typically the bottom of the touchpad) in
anticipation of click+move=select gestures.

Thus, "4-finger scroll + resting thumb" is a 5-finger gesture.
To allow userspace to detect this gesture, we send BTN_TOOL_QUINTTAP.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I7ac13ea6a0d9440760b0b9d02700216c2223f1a0
BUG=chromium-os:19094
TEST=builds clean;
     Use evtest to confirm QUINTTAP is sent for 5-finger tap
Reviewed-on: http://gerrit.chromium.org/gerrit/4253
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
3defe34
@djkurtz djkurtz CHROMIUM: Input: synaptics - process finger (<=5) transitions
Synaptics image sensor touchpads track up to 5 fingers, but only report 2.
They use a special "TYPE=2" (AGM-CONTACT) packet type that reports
the number of tracked fingers and which finger is reported in the SGM
and AGM packets.

With this new packet type, it is possible to tell userspace when 4 or 5
fingers are touching.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>

Change-Id: I58f39a14e808ba865e5c39dfdf72e7b6da112395
BUG=chromium-os:19094
TEST=builds clean; evtest to confirm raw events
     confirm motion, 2f-tap, 2f-scroll, using xf86-input-cmt
Reviewed-on: http://gerrit.chromium.org/gerrit/4259
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
e5c9a6c
@redpig redpig CHROMIUM: mmap, sysctl: add sysctl for controlling VM_MAYEXEC taint
This patch proposes a sysctl knob that allows a privileged user to
disable ~VM_MAYEXEC tainting when mapping in a vma from a MNT_NOEXEC
mountpoint.  It does not alter the normal behavior resulting from
attempting to directly mmap(PROT_EXEC) a vma (-EPERM) nor the behavior
of any other subsystems checking MNT_NOEXEC.

It is motivated by a common /dev/shm, /tmp usecase. There are few
facilities for creating a shared memory segment that can be remapped in
the same process address space with different permissions.  Often, a
file in /tmp provides this functionality.  However, on distributions
that are more restrictive/paranoid, world-writeable directories are
often mounted "noexec".  The only workaround to support software that
needs this behavior is to either not use that software or remount /tmp
exec.  (E.g., https://bugs.gentoo.org/350336?id=350336)  Given that
the only recourse is using SysV IPC, the application programmer loses
many of the useful ABI features that they get using a mmap'd file.

With this patch, it would be possible to change the sysctl variable
such that mprotect(PROT_EXEC) would succeed.  In cases like the example
above, an additional userspace mmap-wrapper would be needed, but in
other cases, like how code.google.com/p/nativeclient mmap()s then
mprotect()s, the behavior would be unaffected.

The tradeoff is a loss of defense in depth, but it seems reasonable when
the alternative is frequently to disable the defense entirely.

(There are many other ways to approach this problem, but this seemed to
 be the most practical and feel the least like a hack or a major change.)

Signed-off-by: Will Drewry <wad@chromium.org>

BUG=chromium-os:19221,native-client:1883
TEST=built x86, booted,
     ran sysctl -w vm.mmap_noexec_taint=0
     run mmap_tester.c from issue such that it uses mprotect.

Change-Id: I1e13adc0d9e8fdb1a0027a2e715557f4aff1b283
Reviewed-on: http://gerrit.chromium.org/gerrit/6007
Reviewed-by: <krasin@google.com>
Reviewed-by: Roland McGrath <mcgrathr@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
a3dc5f4
@redpig redpig CHROMIUM: Disable VM_MAYEXEC tainting for noexec mounts
With our userland, VM_MAYEXEC tainting does not provide much
additional benefit beyond protecting against LD_PRELOAD or
dlopen()ing files dropped in a noexec mountpoint.  This sets
the sysctl default to 0 such that VM_MAYEXEC is not masked off
of /dev/shm and other mountpoints when a file is mmap'd.

Signed-off-by: Will Drewry <wad@chromium.org>
BUG=chromium-os:19221,native-client:1883
TEST=booted, ran mmap_tester.c from the nacl bug.

Change-Id: If3c84f7c000b22328e8980fdf3cbcdb155a82a4b
Reviewed-on: http://gerrit.chromium.org/gerrit/6081
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Tested-by: Will Drewry <wad@chromium.org>
6e4b466
Jason Glasgow gobi: drop locks when code path might sleep
drop locks while submitting urbs, and reset interupt context when
notifying clients.  In general, ensure that might_sleep is never
called when a spinlock is held.

Signed-off-by: Jason Glasgow <jglasgow@chromium.org>

BUG=chrome-os-partner:5222
TEST=run kernel with CONFIG_DEBUG_SPINLOCK_SLEEP=y

Change-Id: I730644d9bd97590ef896da8e1876c6f739360c03
Reviewed-on: http://gerrit.chromium.org/gerrit/6110
Tested-by: Jason Glasgow <jglasgow@chromium.org>
Reviewed-by: Elly Jones <ellyjones@chromium.org>
4398200
@yufengshen yufengshen CHROMIUM: tegra: asymptote: Suppress touch noise when on battery
Currently the atmel touch controller on asymptote will generate
a lot of touch noise when the AC supply is removed and on battery.
This patch tunes the parameter IDLEGCAFDEPTH and ACTVGCAFDEPTH of
the touch controller object T28 to suppress these noise.

BUG=None
TEST=Manually tested on Asymptote and confirmed false detection is
suppressed when AC supply is disconnected.

Change-Id: Ia2e3e8e52eab1073bd2fa026575e5d070e9dadb6
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6234
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
b5c8a05
Rakesh Iyer ARM: smp_twd: Preserve prescaler on shutdown event
Preserve timer prescaler through timer shutdown. This is needed
because timer shutdown is invoked on low power CPU transitions when the kernel
switches to using the broadcast timer, and a governor may not update the
prescaler after CPU powers back up.

BUG=chrome-os-partner:5483
TEST=V8 benchmark regression is fixed.

Change-Id: I35901b3fc606da3f90967d8591c9d015b2872015
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/6233
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
b08158c
@muromec muromec ec cleanup, charge fix 88aa666
@muromec muromec panel freq fix. 37dc017
@muromec muromec Merge branch 'chromeos-2.6.38' of http://git.chromium.org/chromiumos/…
…third_party/kernel into chromeos-2.6.38

Conflicts:
	arch/arm/mach-tegra/board-seaboard-panel.c
	arch/arm/mach-tegra/common.c
b9881a6
@muromec muromec Merge branch 'chromeos-2.6.38' of https://github.com/astarasikov/icon…
…ia-gnu-kernel into chromeos-2.6.38
a207026
@muromec muromec drop regulator values 776a0c3
@muromec muromec fix last merge 49878e8
@marvintwentyfour @muromec marvintwentyfour paz00: fix possible typo in cpu-tegra.c
Latency is measured in nano-secs, not mu-secs. Found by juliank
on IRC.
1cfa2be
@muromec muromec update defconfig 9a3ad8e

@astarasikov astarasikov added a commit that referenced this pull request Aug 22, 2011

@astarasikov astarasikov Merge pull request #2 from muromec/chromeos-2.6.38
Chromeos 2.6.38
f16434e

@astarasikov astarasikov merged commit f16434e into astarasikov:chromeos-2.6.38 Aug 22, 2011

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@mfuzzey @gregkh mfuzzey + gregkh USB: usbtest - Add tests to ensure HCDs can accept byte aligned buffers.
Add a set of new tests similar to the existing ones but using
transfer buffers at an "odd" address [ie offset of +1 from
the buffer obtained by kmalloc() or usb_alloc_coherent()]

The new tests are:
#17 : bulk out (like #1) using kmalloc and DMA mapping by USB core.
#18 : bulk in (like #2) using kmalloc and DMA mapping by USB core.
#19 : bulk out (like #1) using usb_alloc_coherent()
#20 : bulk in (like #2) using usb_alloc_coherent()
#21 : control write (like #14)
#22 : isochonous out (like #15)
#23 : isochonous in (like #16)

Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
084fb20

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@abogani @linvjw abogani + linvjw rtlwifi: Add the missing rcu_read_lock/unlock
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/mac80211/sta_info.c:125 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by wpa_supplicant/468:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c1465d84>] rtnl_lock+0x14/0x20
 #1:  (&rdev->mtx){+.+.+.}, at: [<f84b8c2b>] cfg80211_mgd_wext_siwfreq+0x6b/0x170 [cfg80211]
 #2:  (&rdev->devlist_mtx){+.+.+.}, at: [<f84b8c37>] cfg80211_mgd_wext_siwfreq+0x77/0x170 [cfg80211]
 #3:  (&wdev->mtx){+.+.+.}, at: [<f84b8c44>] cfg80211_mgd_wext_siwfreq+0x84/0x170 [cfg80211]
 #4:  (&rtlpriv->locks.conf_mutex){+.+.+.}, at: [<f8506476>] rtl_op_bss_info_changed+0x26/0xc10 [rtlwifi]

stack backtrace:
Pid: 468, comm: wpa_supplicant Not tainted 2.6.38-rc6+ #79
Call Trace:
 [<c108806a>] ? lockdep_rcu_dereference+0xaa/0xb0
 [<f8523d2c>] ? sta_info_get_bss+0x19c/0x1b0 [mac80211]
 [<f8523d62>] ? ieee80211_find_sta+0x22/0x40 [mac80211]
 [<f850661c>] ? rtl_op_bss_info_changed+0x1cc/0xc10 [rtlwifi]
 [<c153671c>] ? __mutex_unlock_slowpath+0x14c/0x160
 [<c153673d>] ? mutex_unlock+0xd/0x10
 [<f8507180>] ? rtl_op_config+0x120/0x310 [rtlwifi]
 [<c10896db>] ? trace_hardirqs_on+0xb/0x10
 [<f8522169>] ? ieee80211_bss_info_change_notify+0xf9/0x1f0 [mac80211]
 [<f8506450>] ? rtl_op_bss_info_changed+0x0/0xc10 [rtlwifi]
 [<f853646f>] ? ieee80211_set_channel+0xbf/0xd0 [mac80211]
 [<f84b5f41>] ? cfg80211_set_freq+0x121/0x180 [cfg80211]
 [<f85363b0>] ? ieee80211_set_channel+0x0/0xd0 [mac80211]
 [<f84b8ceb>] ? cfg80211_mgd_wext_siwfreq+0x12b/0x170 [cfg80211]
 [<f84b87eb>] ? cfg80211_wext_siwfreq+0x9b/0x100 [cfg80211]
 [<c153b98b>] ? sub_preempt_count+0x7b/0xb0
 [<c150f874>] ? ioctl_standard_call+0x74/0x3b0
 [<c1465d84>] ? rtnl_lock+0x14/0x20
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c14568bd>] ? __dev_get_by_name+0x8d/0xb0
 [<c150fddb>] ? wext_handle_ioctl+0x16b/0x180
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c145bc7a>] ? dev_ioctl+0x5ba/0x720
 [<c108a947>] ? __lock_acquire+0x3e7/0x19b0
 [<c1443b0b>] ? sock_ioctl+0x1eb/0x290
 [<c108bfa5>] ? lock_release_non_nested+0x95/0x2f0
 [<c1443920>] ? sock_ioctl+0x0/0x290
 [<c114d74d>] ? do_vfs_ioctl+0x7d/0x5c0
 [<c1112232>] ? might_fault+0x62/0xb0
 [<c113e3c6>] ? fget_light+0x226/0x390
 [<c1112278>] ? might_fault+0xa8/0xb0
 [<c114dd17>] ? sys_ioctl+0x87/0x90
 [<c1002f9f>] ? sysenter_do_call+0x12/0x38

This work was supported by a hardware donation from the CE Linux Forum.

Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
701c2be

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@lge lge + Philipp Reisner drbd: fix potential access of on-stack wait_queue_head_t after return
I run into something declaring itself as "spinlock deadlock",
 BUG: spinlock lockup on CPU#1, kjournald/27816, ffff88000ad6bca0
 Pid: 27816, comm: kjournald Tainted: G        W 2.6.34.6 #2
 Call Trace:
  <IRQ>  [<ffffffff811ba0aa>] do_raw_spin_lock+0x11e/0x14d
  [<ffffffff81340fde>] _raw_spin_lock_irqsave+0x6a/0x81
  [<ffffffff8103b694>] ? __wake_up+0x22/0x50
  [<ffffffff8103b694>] __wake_up+0x22/0x50
  [<ffffffffa07ff661>] bm_async_io_complete+0x258/0x299 [drbd]
but the call traces do not fit at all,
all other cpus are cpu_idle.

I think it may be this race:

drbd_bm_write_page
 wait_queue_head_t io_wait;
 atomic_t in_flight;
 bm_async_io
  submit_bio
					bm_async_io_complete
					  if (atomic_dec_and_test(in_flight))
 wait_event(io_wait,
	atomic_read(in_flight) == 0)
 return
					    wake_up(io_wait)

The wake_up now accesses the wait_queue_head_t spinlock, which is no
longer valid, since the stack frame of drbd_bm_write_page has been
clobbered now.

Fix this by using struct completion, which does both the condition test
as well as the wake_up inside its spinlock, so this race cannot happen.

Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
725a97e

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@glikely Thomas Gleixner + glikely gpio/langwell: Fix broken irq_eoi change.
commit 0766d20 (langwell_gpio: modify EOI handling following change
of kernel irq subsystem)  changes

 -   desc->chip->eoi(irq);
 +
 +   if (desc->chip->irq_eoi)
 +           desc->chip->irq_eoi(irq_get_irq_data(irq));
 +   else
 +           dev_warn(pg->chip.dev, "missing EOI handler for irq %d\n", irq);

With the following explanation:

 "Latest kernel has many changes in IRQ subsystem and its interfaces,
  like adding irq_eoi" for struct irq_chip, this patch will make it
  support both the new and old interface."

This is completely bogus.

 #1) The changelog does not match the patch at all

 #2) This driver relies on the assumption that it sits behind an eoi
     capable interrupt line. If the implementation of the underlying
     chip changes from eoi to irq_eoi then this driver has to follow
     that change and not add a total bogosity.

 #3) Just mechanically changing eoi to irq_eoi without checking the
     background of that change is sloppy at best.

Remove the sillyness and retrieve the interrupt data from irq_desc
directly. No need to go through a sparse irq lookup.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
20e2aa9

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

Thomas Gleixner arm: Ns9xxx: Remove private irq flow handler
handle_prio_irq is almost identical with handle_fasteoi_irq. The
subtle differences are

1) The handler checks for IRQ_DISABLED after the device handler has
   been called. In case it's set it masks the interrupt.

2) When the handler sees IRQ_DISABLED on entry it masks the interupt
   in the same way as handle_fastoei_irq, but does not set the
   IRQ_PENDING flag.

3) Instead of gracefully handling a recursive interrupt it crashes the
   kernel.

#1 is just relevant when a device handler calls disable_irq_nosync()
   and it does not matter whether we mask the interrupt right away or
   not. We handle lazy masking for disable_irq anyway, so there is no
   real reason to have this extra mask in place.

#2 will prevent the resend of a pending interrupt, which can result in
   lost interrupts for edge type interrupts. For level type interrupts
   the resend is a noop in the generic code. According to the
   datasheet all interrupts are level type, so marking them as such
   will result in the exact same behaviour as the private
   handle_prio_irq implementation.

#3 is just stupid. Crashing the kernel instead of handling a problem
   gracefully is just wrong. With the current semantics- all handlers
   run with interrupts disabled - this is even more wrong.

Rename ack to eoi, remove the unused mask_ack, switch to
handle_fasteoi_irq and remove the private function.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
LKML-Reference: <20110202212552.299898447@linutronix.de>
6829310

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@kumargala kumargala edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set or
clear this register bit on them.  Otherwise we get crashes like:

NIP: c0579f84 LR: c006d550 CTR: c0579f84
REGS: ef857ec0 TRAP: 0700   Not tainted  (2.6.38.2-00072-gf15ba3c)
MSR: 00021002 <ME,CE>  CR: 22044022  XER: 00000000
TASK = ef8559c0[1] 'swapper' THREAD: ef856000 CPU: 0
GPR00: c006d538 ef857f70 ef8559c0 00000000 00000004 00000000 00000000 00000000
GPR08: c0590000 c30170a8 00000000 c30170a8 00000001 0fffe000 00000000 00000000
GPR16: 00000000 7ffa0e60 00000000 00000000 7ffb0bd8 7ff3b844 c05be000 00000000
GPR24: 00000000 00000000 c05c28b0 c0579fac 00000000 00029002 00000000 c0579f84
NIP [c0579f84] mpc85xx_mc_clear_rfxe+0x0/0x28
LR [c006d550] on_each_cpu+0x34/0x50
Call Trace:
[ef857f70] [c006d538] on_each_cpu+0x1c/0x50 (unreliable)
[ef857f90] [c057a070] mpc85xx_mc_init+0xc4/0xdc
[ef857fa0] [c0001cd4] do_one_initcall+0x34/0x1a8
[ef857fd0] [c055d9d8] kernel_init+0x17c/0x218
[ef857ff0] [c000cda4] kernel_thread+0x4c/0x68
Instruction dump:
40be0018 3c60c052 3863c70c 4be9baad 3be0ffed 4bd7c99d 80010014 7fe3fb78
83e1000c 38210010 7c0803a6 4e800020 <7c11faa6> 54290024 81290008
3d60c06e
Oops: Exception in kernel mode, sig: 4 [#2]
---[ end trace 49ff3b8f93efde1a ]---

Also use the HID1_RFXE define rather than a magic number.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
a94d7b3

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@jtlayton jtlayton + Steve French cifs: clean up various nits in unicode routines (try #2)
Minor revision to the original patch. Don't abuse the __le16 variable
on the stack by casting it to wchar_t and handing it off to char2uni.
Declare an actual wchar_t on the stack instead. This fixes a valid
sparse warning.

Fix the spelling of UNI_ASTERISK. Eliminate the unneeded len_remaining
variable in cifsConvertToUCS.

Also, as David Howells points out. We were better off making
cifsConvertToUCS *not* use put_unaligned_le16 since it means that we
can't optimize the mapped characters at compile time. Switch them
instead to use cpu_to_le16, and simply use put_unaligned to set them
in the string.

Reported-and-acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
581ade4

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@torvalds torvalds Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
  cifs: don't allow mmap'ed pages to be dirtied while under writeback (try #3)
  [CIFS] Warn on requesting default security (ntlm) on mount
  [CIFS] cifs: clarify the meaning of tcpStatus == CifsGood
  cifs: wrap received signature check in srv_mutex
  cifs: clean up various nits in unicode routines (try #2)
  cifs: clean up length checks in check2ndT2
  cifs: set ra_pages in backing_dev_info
  cifs: fix broken BCC check in is_valid_oplock_break
  cifs: always do is_path_accessible check in cifs_mount
  various endian fixes to cifs
  Elminate sparse __CHECK_ENDIAN__ warnings on port conversion
  Max share size is too small
  Allow user names longer than 32 bytes
  cifs: replace /proc/fs/cifs/Experimental with a module parm
  cifs: check for private_data before trying to put it
6faf9a5

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@rolandd @davem330 rolandd + davem330 vmxnet3: Consistently disable irqs when taking adapter->cmd_lock
Using the vmxnet3 driver produces a lockdep warning because
vmxnet3_set_mc(), which is called with mc->mca_lock held, takes
adapter->cmd_lock.  However, there are a couple of places where
adapter->cmd_lock is taken with softirqs enabled, lockdep warns that a
softirq that tries to take mc->mca_lock could happen while
adapter->cmd_lock is held, leading to an AB-BA deadlock.

I'm not sure if this is a real potential deadlock or not, but the
simplest and best fix seems to be simply to make sure we take cmd_lock
with spin_lock_irqsave() everywhere -- the places with plain spin_lock
just look like oversights.

The full enormous lockdep warning is:

 =========================================================
 [ INFO: possible irq lock inversion dependency detected ]
 2.6.39-rc6+ #1
 ---------------------------------------------------------
 ifconfig/567 just changed the state of lock:
  (&(&mc->mca_lock)->rlock){+.-...}, at: [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
 but this lock took another, SOFTIRQ-unsafe lock in the past:
  (&(&adapter->cmd_lock)->rlock){+.+...}

 and interrupts could create inverse lock ordering between them.

 other info that might help us debug this:
 4 locks held by ifconfig/567:
  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff8147d547>] rtnl_lock+0x17/0x20
  #1:  ((inetaddr_chain).rwsem){.+.+.+}, at: [<ffffffff810896cf>] __blocking_notifier_call_chain+0x5f/0xb0
  #2:  (&idev->mc_ifc_timer){+.-...}, at: [<ffffffff8106f21b>] run_timer_softirq+0xeb/0x3f0
  #3:  (&ndev->lock){++.-..}, at: [<ffffffff81531dd2>] mld_ifc_timer_expire+0x32/0x280

 the shortest dependencies between 2nd lock and 1st lock:
   -> (&(&adapter->cmd_lock)->rlock){+.+...} ops: 11 {
      HARDIRQ-ON-W at:
                                            [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
                                            [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                            [<ffffffff81571156>] _raw_spin_lock+0x36/0x70
                                            [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
                                            [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
                                            [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
                                            [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
                                            [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
                                            [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
                                            [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
                                            [<ffffffff81373a2e>] driver_attach+0x1e/0x20
                                            [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
                                            [<ffffffff813745b6>] driver_register+0x76/0x140
                                            [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
                                            [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
                                            [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                            [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
                                            [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
      SOFTIRQ-ON-W at:
                                            [<ffffffff8109adb7>] __lock_acquire+0x827/0x1e10
                                            [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                            [<ffffffff81571156>] _raw_spin_lock+0x36/0x70
                                            [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
                                            [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
                                            [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
                                            [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
                                            [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
                                            [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
                                            [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
                                            [<ffffffff81373a2e>] driver_attach+0x1e/0x20
                                            [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
                                            [<ffffffff813745b6>] driver_register+0x76/0x140
                                            [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
                                            [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
                                            [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                            [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
                                            [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
      INITIAL USE at:
                                           [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
                                           [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                           [<ffffffff81571156>] _raw_spin_lock+0x36/0x70
                                           [<ffffffffa000d212>] vmxnet3_alloc_intr_resources+0x22/0x230 [vmxnet3]
                                           [<ffffffffa0014031>] vmxnet3_probe_device+0x5f6/0x15c5 [vmxnet3]
                                           [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
                                           [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
                                           [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
                                           [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
                                           [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
                                           [<ffffffff81373a2e>] driver_attach+0x1e/0x20
                                           [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
                                           [<ffffffff813745b6>] driver_register+0x76/0x140
                                           [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
                                           [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
                                           [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                           [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
                                           [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
    }
    ... key      at: [<ffffffffa0017590>] __key.42516+0x0/0xffffffffffffda70 [vmxnet3]
    ... acquired at:
    [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
    [<ffffffff81571bb5>] _raw_spin_lock_irqsave+0x55/0xa0
    [<ffffffffa000de27>] vmxnet3_set_mc+0x97/0x1a0 [vmxnet3]
    [<ffffffff8146ffa0>] __dev_set_rx_mode+0x40/0xb0
    [<ffffffff81470040>] dev_set_rx_mode+0x30/0x50
    [<ffffffff81470127>] __dev_open+0xc7/0x100
    [<ffffffff814703c1>] __dev_change_flags+0xa1/0x180
    [<ffffffff81470568>] dev_change_flags+0x28/0x70
    [<ffffffff814da960>] devinet_ioctl+0x730/0x800
    [<ffffffff814db508>] inet_ioctl+0x88/0xa0
    [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70
    [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0
    [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570
    [<ffffffff81188d01>] sys_ioctl+0x91/0xa0
    [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b

  -> (_xmit_ETHER){+.....} ops: 6 {
     HARDIRQ-ON-W at:
                                          [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
                                          [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                          [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
                                          [<ffffffff81475618>] __dev_mc_add+0x38/0x90
                                          [<ffffffff814756a0>] dev_mc_add+0x10/0x20
                                          [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
                                          [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
                                          [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450
                                          [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
                                          [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
                                          [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
                                          [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
                                          [<ffffffff8146a944>] register_netdevice+0x244/0x2d0
                                          [<ffffffff8146aa0f>] register_netdev+0x3f/0x60
                                          [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
                                          [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
                                          [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
                                          [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
                                          [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
                                          [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
                                          [<ffffffff81373a2e>] driver_attach+0x1e/0x20
                                          [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
                                          [<ffffffff813745b6>] driver_register+0x76/0x140
                                          [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
                                          [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
                                          [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                          [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
                                          [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
     INITIAL USE at:
                                         [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
                                         [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                         [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
                                         [<ffffffff81475618>] __dev_mc_add+0x38/0x90
                                         [<ffffffff814756a0>] dev_mc_add+0x10/0x20
                                         [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
                                         [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
                                         [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450
                                         [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
                                         [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
                                         [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
                                         [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
                                         [<ffffffff8146a944>] register_netdevice+0x244/0x2d0
                                         [<ffffffff8146aa0f>] register_netdev+0x3f/0x60
                                         [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
                                         [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
                                         [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
                                         [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
                                         [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
                                         [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
                                         [<ffffffff81373a2e>] driver_attach+0x1e/0x20
                                         [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
                                         [<ffffffff813745b6>] driver_register+0x76/0x140
                                         [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
                                         [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
                                         [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                         [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
                                         [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
   }
   ... key      at: [<ffffffff827fd868>] netdev_addr_lock_key+0x8/0x1e0
   ... acquired at:
    [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
    [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
    [<ffffffff81475618>] __dev_mc_add+0x38/0x90
    [<ffffffff814756a0>] dev_mc_add+0x10/0x20
    [<ffffffff81532c9e>] igmp6_group_added+0x10e/0x1b0
    [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
    [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450
    [<ffffffff81519f27>] addrconf_notify+0x2f7/0xb10
    [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
    [<ffffffff81089586>] raw_notifier_call_chain+0x16/0x20
    [<ffffffff814689b7>] call_netdevice_notifiers+0x37/0x70
    [<ffffffff8146a944>] register_netdevice+0x244/0x2d0
    [<ffffffff8146aa0f>] register_netdev+0x3f/0x60
    [<ffffffffa001419b>] vmxnet3_probe_device+0x760/0x15c5 [vmxnet3]
    [<ffffffff812df67f>] local_pci_probe+0x5f/0xd0
    [<ffffffff812dfde9>] pci_device_probe+0x119/0x120
    [<ffffffff81373df6>] driver_probe_device+0x96/0x1c0
    [<ffffffff81373fcb>] __driver_attach+0xab/0xb0
    [<ffffffff81372a1e>] bus_for_each_dev+0x5e/0x90
    [<ffffffff81373a2e>] driver_attach+0x1e/0x20
    [<ffffffff813735b8>] bus_add_driver+0xc8/0x290
    [<ffffffff813745b6>] driver_register+0x76/0x140
    [<ffffffff812e0046>] __pci_register_driver+0x66/0xe0
    [<ffffffffa001b03a>] serio_raw_poll+0x3a/0x60 [serio_raw]
    [<ffffffff81002165>] do_one_initcall+0x45/0x190
    [<ffffffff810aa76b>] sys_init_module+0xfb/0x250
    [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b

 -> (&(&mc->mca_lock)->rlock){+.-...} ops: 6 {
    HARDIRQ-ON-W at:
                                        [<ffffffff8109ad86>] __lock_acquire+0x7f6/0x1e10
                                        [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                        [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
                                        [<ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0
                                        [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
                                        [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450
                                        [<ffffffff81ce0d16>] addrconf_init+0x4e/0x183
                                        [<ffffffff81ce0ba1>] inet6_init+0x191/0x2a6
                                        [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                        [<ffffffff81ca4d3f>] kernel_init+0xe3/0x168
                                        [<ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10
    IN-SOFTIRQ-W at:
                                        [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
                                        [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                        [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
                                        [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
                                        [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
                                        [<ffffffff810666d0>] __do_softirq+0xc0/0x210
                                        [<ffffffff8157b3dc>] call_softirq+0x1c/0x30
                                        [<ffffffff8100d42d>] do_softirq+0xad/0xe0
                                        [<ffffffff81066afe>] irq_exit+0x9e/0xb0
                                        [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
                                        [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
                                        [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0
                                        [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60
                                        [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60
                                        [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
                                        [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
                                        [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
                                        [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
                                        [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
                                        [<ffffffff814d8223>] inet_del_ifa+0x13/0x20
                                        [<ffffffff814da731>] devinet_ioctl+0x501/0x800
                                        [<ffffffff814db508>] inet_ioctl+0x88/0xa0
                                        [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70
                                        [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0
                                        [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570
                                        [<ffffffff81188d01>] sys_ioctl+0x91/0xa0
                                        [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b
    INITIAL USE at:
                                       [<ffffffff8109a9e9>] __lock_acquire+0x459/0x1e10
                                       [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
                                       [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
                                       [<ffffffff81532bd5>] igmp6_group_added+0x45/0x1b0
                                       [<ffffffff81533f2d>] ipv6_dev_mc_inc+0x2cd/0x430
                                       [<ffffffff81515e17>] ipv6_add_dev+0x357/0x450
                                       [<ffffffff81ce0d16>] addrconf_init+0x4e/0x183
                                       [<ffffffff81ce0ba1>] inet6_init+0x191/0x2a6
                                       [<ffffffff81002165>] do_one_initcall+0x45/0x190
                                       [<ffffffff81ca4d3f>] kernel_init+0xe3/0x168
                                       [<ffffffff8157b2e4>] kernel_thread_helper+0x4/0x10
  }
  ... key      at: [<ffffffff82801be2>] __key.40877+0x0/0x8
  ... acquired at:
    [<ffffffff810997bc>] check_usage_forwards+0x9c/0x110
    [<ffffffff8109a32c>] mark_lock+0x19c/0x400
    [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
    [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
    [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
    [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
    [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
    [<ffffffff810666d0>] __do_softirq+0xc0/0x210
    [<ffffffff8157b3dc>] call_softirq+0x1c/0x30
    [<ffffffff8100d42d>] do_softirq+0xad/0xe0
    [<ffffffff81066afe>] irq_exit+0x9e/0xb0
    [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
    [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
    [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0
    [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60
    [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60
    [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
    [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
    [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
    [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
    [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
    [<ffffffff814d8223>] inet_del_ifa+0x13/0x20
    [<ffffffff814da731>] devinet_ioctl+0x501/0x800
    [<ffffffff814db508>] inet_ioctl+0x88/0xa0
    [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70
    [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0
    [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570
    [<ffffffff81188d01>] sys_ioctl+0x91/0xa0
    [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b

 stack backtrace:
 Pid: 567, comm: ifconfig Not tainted 2.6.39-rc6+ #1
 Call Trace:
  <IRQ>  [<ffffffff810996f6>] print_irq_inversion_bug+0x146/0x170
  [<ffffffff81099720>] ? print_irq_inversion_bug+0x170/0x170
  [<ffffffff810997bc>] check_usage_forwards+0x9c/0x110
  [<ffffffff8109a32c>] mark_lock+0x19c/0x400
  [<ffffffff8109ad5e>] __lock_acquire+0x7ce/0x1e10
  [<ffffffff8109a383>] ? mark_lock+0x1f3/0x400
  [<ffffffff8109b497>] ? __lock_acquire+0xf07/0x1e10
  [<ffffffff81012255>] ? native_sched_clock+0x15/0x70
  [<ffffffff8109ca4d>] lock_acquire+0x9d/0x130
  [<ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280
  [<ffffffff8109759d>] ? lock_release_holdtime+0x3d/0x1a0
  [<ffffffff8157124b>] _raw_spin_lock_bh+0x3b/0x70
  [<ffffffff81531e9f>] ? mld_ifc_timer_expire+0xff/0x280
  [<ffffffff8157170b>] ? _raw_spin_unlock+0x2b/0x40
  [<ffffffff81531e9f>] mld_ifc_timer_expire+0xff/0x280
  [<ffffffff8106f2a9>] run_timer_softirq+0x179/0x3f0
  [<ffffffff8106f21b>] ? run_timer_softirq+0xeb/0x3f0
  [<ffffffff810122b9>] ? sched_clock+0x9/0x10
  [<ffffffff81531da0>] ? mld_gq_timer_expire+0x30/0x30
  [<ffffffff810666d0>] __do_softirq+0xc0/0x210
  [<ffffffff8109455f>] ? tick_program_event+0x1f/0x30
  [<ffffffff8157b3dc>] call_softirq+0x1c/0x30
  [<ffffffff8100d42d>] do_softirq+0xad/0xe0
  [<ffffffff81066afe>] irq_exit+0x9e/0xb0
  [<ffffffff8157bd40>] smp_apic_timer_interrupt+0x70/0x9b
  [<ffffffff8157ab93>] apic_timer_interrupt+0x13/0x20
  <EOI>  [<ffffffff81571f14>] ? retint_restore_args+0x13/0x13
  [<ffffffff810974a7>] ? lock_is_held+0x17/0xd0
  [<ffffffff8149d857>] rt_do_flush+0x87/0x2a0
  [<ffffffff814a16b6>] rt_cache_flush+0x46/0x60
  [<ffffffff814e36e0>] fib_disable_ip+0x40/0x60
  [<ffffffff814e5447>] fib_inetaddr_event+0xd7/0xe0
  [<ffffffff81575c1c>] notifier_call_chain+0x8c/0xc0
  [<ffffffff810896e8>] __blocking_notifier_call_chain+0x78/0xb0
  [<ffffffff81089736>] blocking_notifier_call_chain+0x16/0x20
  [<ffffffff814d8021>] __inet_del_ifa+0xf1/0x2e0
  [<ffffffff814d8223>] inet_del_ifa+0x13/0x20
  [<ffffffff814da731>] devinet_ioctl+0x501/0x800
  [<ffffffff8108a3af>] ? local_clock+0x6f/0x80
  [<ffffffff81575898>] ? do_page_fault+0x268/0x560
  [<ffffffff814db508>] inet_ioctl+0x88/0xa0
  [<ffffffff814541f0>] sock_do_ioctl+0x30/0x70
  [<ffffffff814542a9>] sock_ioctl+0x79/0x2f0
  [<ffffffff810dfe87>] ? __call_rcu+0xa7/0x190
  [<ffffffff81188798>] do_vfs_ioctl+0x98/0x570
  [<ffffffff8117737e>] ? fget_light+0x33e/0x430
  [<ffffffff81571ef9>] ? retint_swapgs+0x13/0x1b
  [<ffffffff81188d01>] sys_ioctl+0x91/0xa0
  [<ffffffff8157a142>] system_call_fastpath+0x16/0x1b

Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
e328d41

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@michael-holzheu michael-holzheu + Martin Schwidefsky [S390] kernel: Initialize register 14 when starting new CPU
When starting a new CPU we currently jump to start_secondary() without
setting register 14 (the return address) correctly. Therefore on the stack
frame for start_secondary an invalid return address is stored. This leads
to wrong stack back traces in kernel dumps.

Example:

 #00 [1f33fe48] cpu_idle at 10614a
 #1 [1f33fe90] start_secondary at 54fa88
 #2 [1f33feb8] (null) at 0                 <--- invalid

To fix this start_secondary() is called now with basr/brasl that sets
register 14 correctly. The output of the stack backtrace looks then
like the following:

 #00 [1f33fe48] cpu_idle at 10614a
 #1 [1f33fe90] start_secondary at 54fa88
 #2 [1f33feb8] restart_base at 54f41e      <--- correct

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
8eb4bd6

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@jtlayton jtlayton + Steve French cifs: fix cifsConvertToUCS() for the mapchars case
As Metze pointed out, commit 84cdf74 broke mapchars option:

    Commit "cifs: fix unaligned accesses in cifsConvertToUCS"
    (84cdf74) does multiple steps
    in just one commit (moving the function and changing it without
    testing).

    put_unaligned_le16(temp, &target[j]); is never called for any
    codepoint the goes via the 'default' switch statement. As a result
    we put just zero (or maybe uninitialized) bytes into the target
    buffer.

His proposed patch looks correct, but doesn't apply to the current head
of the tree. This patch should also fix it.

Cc: <stable@kernel.org> # .38.x: 581ade4: cifs: clean up various nits in unicode routines (try #2)
Reported-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
11379b5

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

Steve French [CIFS] Allow to set extended attribute cifs_acl (try #2)
Allow setting cifs_acl on the server.
Pass on to the server the ACL blob generated by an application.
cifs is just a pass-through, it does not monitor or inspect the contents
of the blob, server decides whether to enforce/apply the ACL blob composed
by an application.
If setting of ACL is succeessful, mark the inode for revalidation.

Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
b73b9a4

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@gregkh Arvid Brodin + gregkh usb/isp1760: Move function isp1760_endpoint_disable() within file.
Preparation for patch #2. The function isp1760_endpoint_disable() does almost
the same thing as urb_dequeue(). In patch #2 I change these to use a common
helper function instead of calling each other - for clarity but also to
avoid releasing the spinlock while in a "questionable" state. It seemed
proper to have these functions close to each other in the code.

Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
079cdb0

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

@jarodwilson jarodwilson + Mauro Carvalho Chehab [media] rc: add locking to fix register/show race
When device_add is called in rc_register_device, the rc sysfs nodes show
up, and there's a window in which ir-keytable can be launched via udev
and trigger a show_protocols call, which runs without various rc_dev
fields filled in yet. Add some locking around registration and
store/show_protocols to prevent that from happening.

The problem manifests thusly:

[64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
[64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core]
[64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0
[64692.957894] Oops: 0000 [#1] SMP
[64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols
[64692.957902] CPU 3
[64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec
_decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi
di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp
kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai
d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
[last unloaded: redrat3]
[64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G   M    W   2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892
[64692.957957] RIP: 0010:[<ffffffffa036a4c1>]  [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core]
[64692.957962] RSP: 0018:ffff880194509e38  EFLAGS: 00010202
[64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a
[64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0
[64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000
[64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000
[64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190
[64692.957976] FS:  00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
[64692.957979] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0
[64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720)
[64692.957991] Stack:
[64692.957992]  0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000
[64692.957997]  ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b
[64692.958001]  ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18
[64692.958005] Call Trace:
[64692.958014]  [<ffffffff8131484b>] dev_attr_show+0x27/0x4e
[64692.958014]  [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172
[64692.958014]  [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52
[64692.958014]  [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172
[64692.958014]  [<ffffffff8113205e>] vfs_read+0xac/0xf3
[64692.958014]  [<ffffffff8113347b>] ? fget_light+0x3a/0xa1
[64692.958014]  [<ffffffff811320f2>] sys_read+0x4d/0x74
[64692.958014]  [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b

Its a bit difficult to reproduce, but I'm fairly confident this has
fixed the problem.

Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
08aeb7c

@muromec muromec pushed a commit to muromec/iconia-gnu-kernel that referenced this pull request Dec 15, 2011

Paul E. McKenney + Ingo Molnar rcu: Avoid acquiring rcu_node locks in timer functions
This commit switches manipulations of the rcu_node ->wakemask field
to atomic operations, which allows rcu_cpu_kthread_timer() to avoid
acquiring the rcu_node lock.  This should avoid the following lockdep
splat reported by Valdis Kletnieks:

[   12.872150] usb 1-4: new high speed USB device number 3 using ehci_hcd
[   12.986667] usb 1-4: New USB device found, idVendor=413c, idProduct=2513
[   12.986679] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   12.987691] hub 1-4:1.0: USB hub found
[   12.987877] hub 1-4:1.0: 3 ports detected
[   12.996372] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input10
[   13.071471] udevadm used greatest stack depth: 3984 bytes left
[   13.172129]
[   13.172130] =======================================================
[   13.172425] [ INFO: possible circular locking dependency detected ]
[   13.172650] 2.6.39-rc6-mmotm0506 #1
[   13.172773] -------------------------------------------------------
[   13.172997] blkid/267 is trying to acquire lock:
[   13.173009]  (&p->pi_lock){-.-.-.}, at: [<ffffffff81032d8f>] try_to_wake_up+0x29/0x1aa
[   13.173009]
[   13.173009] but task is already holding lock:
[   13.173009]  (rcu_node_level_0){..-...}, at: [<ffffffff810901cc>] rcu_cpu_kthread_timer+0x27/0x58
[   13.173009]
[   13.173009] which lock already depends on the new lock.
[   13.173009]
[   13.173009]
[   13.173009] the existing dependency chain (in reverse order) is:
[   13.173009]
[   13.173009] -> #2 (rcu_node_level_0){..-...}:
[   13.173009]        [<ffffffff810679b9>] check_prevs_add+0x8b/0x104
[   13.173009]        [<ffffffff81067da1>] validate_chain+0x36f/0x3ab
[   13.173009]        [<ffffffff8106846b>] __lock_acquire+0x369/0x3e2
[   13.173009]        [<ffffffff81068a0f>] lock_acquire+0xfc/0x14c
[   13.173009]        [<ffffffff815697f1>] _raw_spin_lock+0x36/0x45
[   13.173009]        [<ffffffff81090794>] rcu_read_unlock_special+0x8c/0x1d5
[   13.173009]        [<ffffffff8109092c>] __rcu_read_unlock+0x4f/0xd7
[   13.173009]        [<ffffffff81027bd3>] rcu_read_unlock+0x21/0x23
[   13.173009]        [<ffffffff8102cc34>] cpuacct_charge+0x6c/0x75
[   13.173009]        [<ffffffff81030cc6>] update_curr+0x101/0x12e
[   13.173009]        [<ffffffff810311d0>] check_preempt_wakeup+0xf7/0x23b
[   13.173009]        [<ffffffff8102acb3>] check_preempt_curr+0x2b/0x68
[   13.173009]        [<ffffffff81031d40>] ttwu_do_wakeup+0x76/0x128
[   13.173009]        [<ffffffff81031e49>] ttwu_do_activate.constprop.63+0x57/0x5c
[   13.173009]        [<ffffffff81031e96>] scheduler_ipi+0x48/0x5d
[   13.173009]        [<ffffffff810177d5>] smp_reschedule_interrupt+0x16/0x18
[   13.173009]        [<ffffffff815710f3>] reschedule_interrupt+0x13/0x20
[   13.173009]        [<ffffffff810b66d1>] rcu_read_unlock+0x21/0x23
[   13.173009]        [<ffffffff810b739c>] find_get_page+0xa9/0xb9
[   13.173009]        [<ffffffff810b8b48>] filemap_fault+0x6a/0x34d
[   13.173009]        [<ffffffff810d1a25>] __do_fault+0x54/0x3e6
[   13.173009]        [<ffffffff810d447a>] handle_pte_fault+0x12c/0x1ed
[   13.173009]        [<ffffffff810d48f7>] handle_mm_fault+0x1cd/0x1e0
[   13.173009]        [<ffffffff8156cfee>] do_page_fault+0x42d/0x5de
[   13.173009]        [<ffffffff8156a75f>] page_fault+0x1f/0x30
[   13.173009]
[   13.173009] -> #1 (&rq->lock){-.-.-.}:
[   13.173009]        [<ffffffff810679b9>] check_prevs_add+0x8b/0x104
[   13.173009]        [<ffffffff81067da1>] validate_chain+0x36f/0x3ab
[   13.173009]        [<ffffffff8106846b>] __lock_acquire+0x369/0x3e2
[   13.173009]        [<ffffffff81068a0f>] lock_acquire+0xfc/0x14c
[   13.173009]        [<ffffffff815697f1>] _raw_spin_lock+0x36/0x45
[   13.173009]        [<ffffffff81027e19>] __task_rq_lock+0x8b/0xd3
[   13.173009]        [<ffffffff81032f7f>] wake_up_new_task+0x41/0x108
[   13.173009]        [<ffffffff810376c3>] do_fork+0x265/0x33f
[   13.173009]        [<ffffffff81007d02>] kernel_thread+0x6b/0x6d
[   13.173009]        [<ffffffff8153a9dd>] rest_init+0x21/0xd2
[   13.173009]        [<ffffffff81b1db4f>] start_kernel+0x3bb/0x3c6
[   13.173009]        [<ffffffff81b1d29f>] x86_64_start_reservations+0xaf/0xb3
[   13.173009]        [<ffffffff81b1d393>] x86_64_start_kernel+0xf0/0xf7
[   13.173009]
[   13.173009] -> #0 (&p->pi_lock){-.-.-.}:
[   13.173009]        [<ffffffff81067788>] check_prev_add+0x68/0x20e
[   13.173009]        [<ffffffff810679b9>] check_prevs_add+0x8b/0x104
[   13.173009]        [<ffffffff81067da1>] validate_chain+0x36f/0x3ab
[   13.173009]        [<ffffffff8106846b>] __lock_acquire+0x369/0x3e2
[   13.173009]        [<ffffffff81068a0f>] lock_acquire+0xfc/0x14c
[   13.173009]        [<ffffffff815698ea>] _raw_spin_lock_irqsave+0x44/0x57
[   13.173009]        [<ffffffff81032d8f>] try_to_wake_up+0x29/0x1aa
[   13.173009]        [<ffffffff81032f3c>] wake_up_process+0x10/0x12
[   13.173009]        [<ffffffff810901e9>] rcu_cpu_kthread_timer+0x44/0x58
[   13.173009]        [<ffffffff81045286>] call_timer_fn+0xac/0x1e9
[   13.173009]        [<ffffffff8104556d>] run_timer_softirq+0x1aa/0x1f2
[   13.173009]        [<ffffffff8103e487>] __do_softirq+0x109/0x26a
[   13.173009]        [<ffffffff8157144c>] call_softirq+0x1c/0x30
[   13.173009]        [<ffffffff81003207>] do_softirq+0x44/0xf1
[   13.173009]        [<ffffffff8103e8b9>] irq_exit+0x58/0xc8
[   13.173009]        [<ffffffff81017f5a>] smp_apic_timer_interrupt+0x79/0x87
[   13.173009]        [<ffffffff81570fd3>] apic_timer_interrupt+0x13/0x20
[   13.173009]        [<ffffffff810bd51a>] get_page_from_freelist+0x2aa/0x310
[   13.173009]        [<ffffffff810bdf03>] __alloc_pages_nodemask+0x178/0x243
[   13.173009]        [<ffffffff8101fe2f>] pte_alloc_one+0x1e/0x3a
[   13.173009]        [<ffffffff810d27fe>] __pte_alloc+0x22/0x14b
[   13.173009]        [<ffffffff810d48a8>] handle_mm_fault+0x17e/0x1e0
[   13.173009]        [<ffffffff8156cfee>] do_page_fault+0x42d/0x5de
[   13.173009]        [<ffffffff8156a75f>] page_fault+0x1f/0x30
[   13.173009]
[   13.173009] other info that might help us debug this:
[   13.173009]
[   13.173009] Chain exists of:
[   13.173009]   &p->pi_lock --> &rq->lock --> rcu_node_level_0
[   13.173009]
[   13.173009]  Possible unsafe locking scenario:
[   13.173009]
[   13.173009]        CPU0                    CPU1
[   13.173009]        ----                    ----
[   13.173009]   lock(rcu_node_level_0);
[   13.173009]                                lock(&rq->lock);
[   13.173009]                                lock(rcu_node_level_0);
[   13.173009]   lock(&p->pi_lock);
[   13.173009]
[   13.173009]  *** DEADLOCK ***
[   13.173009]
[   13.173009] 3 locks held by blkid/267:
[   13.173009]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8156cdb4>] do_page_fault+0x1f3/0x5de
[   13.173009]  #1:  (&yield_timer){+.-...}, at: [<ffffffff810451da>] call_timer_fn+0x0/0x1e9
[   13.173009]  #2:  (rcu_node_level_0){..-...}, at: [<ffffffff810901cc>] rcu_cpu_kthread_timer+0x27/0x58
[   13.173009]
[   13.173009] stack backtrace:
[   13.173009] Pid: 267, comm: blkid Not tainted 2.6.39-rc6-mmotm0506 #1
[   13.173009] Call Trace:
[   13.173009]  <IRQ>  [<ffffffff8154a529>] print_circular_bug+0xc8/0xd9
[   13.173009]  [<ffffffff81067788>] check_prev_add+0x68/0x20e
[   13.173009]  [<ffffffff8100c861>] ? save_stack_trace+0x28/0x46
[   13.173009]  [<ffffffff810679b9>] check_prevs_add+0x8b/0x104
[   13.173009]  [<ffffffff81067da1>] validate_chain+0x36f/0x3ab
[   13.173009]  [<ffffffff8106846b>] __lock_acquire+0x369/0x3e2
[   13.173009]  [<ffffffff81032d8f>] ? try_to_wake_up+0x29/0x1aa
[   13.173009]  [<ffffffff81068a0f>] lock_acquire+0xfc/0x14c
[   13.173009]  [<ffffffff81032d8f>] ? try_to_wake_up+0x29/0x1aa
[   13.173009]  [<ffffffff810901a5>] ? rcu_check_quiescent_state+0x82/0x82
[   13.173009]  [<ffffffff815698ea>] _raw_spin_lock_irqsave+0x44/0x57
[   13.173009]  [<ffffffff81032d8f>] ? try_to_wake_up+0x29/0x1aa
[   13.173009]  [<ffffffff81032d8f>] try_to_wake_up+0x29/0x1aa
[   13.173009]  [<ffffffff810901a5>] ? rcu_check_quiescent_state+0x82/0x82
[   13.173009]  [<ffffffff81032f3c>] wake_up_process+0x10/0x12
[   13.173009]  [<ffffffff810901e9>] rcu_cpu_kthread_timer+0x44/0x58
[   13.173009]  [<ffffffff810901a5>] ? rcu_check_quiescent_state+0x82/0x82
[   13.173009]  [<ffffffff81045286>] call_timer_fn+0xac/0x1e9
[   13.173009]  [<ffffffff810451da>] ? del_timer+0x75/0x75
[   13.173009]  [<ffffffff810901a5>] ? rcu_check_quiescent_state+0x82/0x82
[   13.173009]  [<ffffffff8104556d>] run_timer_softirq+0x1aa/0x1f2
[   13.173009]  [<ffffffff8103e487>] __do_softirq+0x109/0x26a
[   13.173009]  [<ffffffff8106365f>] ? tick_dev_program_event+0x37/0xf6
[   13.173009]  [<ffffffff810a0e4a>] ? time_hardirqs_off+0x1b/0x2f
[   13.173009]  [<ffffffff8157144c>] call_softirq+0x1c/0x30
[   13.173009]  [<ffffffff81003207>] do_softirq+0x44/0xf1
[   13.173009]  [<ffffffff8103e8b9>] irq_exit+0x58/0xc8
[   13.173009]  [<ffffffff81017f5a>] smp_apic_timer_interrupt+0x79/0x87
[   13.173009]  [<ffffffff81570fd3>] apic_timer_interrupt+0x13/0x20
[   13.173009]  <EOI>  [<ffffffff810bd384>] ? get_page_from_freelist+0x114/0x310
[   13.173009]  [<ffffffff810bd51a>] ? get_page_from_freelist+0x2aa/0x310
[   13.173009]  [<ffffffff812220e7>] ? clear_page_c+0x7/0x10
[   13.173009]  [<ffffffff810bd1ef>] ? prep_new_page+0x14c/0x1cd
[   13.173009]  [<ffffffff810bd51a>] get_page_from_freelist+0x2aa/0x310
[   13.173009]  [<ffffffff810bdf03>] __alloc_pages_nodemask+0x178/0x243
[   13.173009]  [<ffffffff810d46b9>] ? __pmd_alloc+0x87/0x99
[   13.173009]  [<ffffffff8101fe2f>] pte_alloc_one+0x1e/0x3a
[   13.173009]  [<ffffffff810d46b9>] ? __pmd_alloc+0x87/0x99
[   13.173009]  [<ffffffff810d27fe>] __pte_alloc+0x22/0x14b
[   13.173009]  [<ffffffff810d48a8>] handle_mm_fault+0x17e/0x1e0
[   13.173009]  [<ffffffff8156cfee>] do_page_fault+0x42d/0x5de
[   13.173009]  [<ffffffff810d915f>] ? sys_brk+0x32/0x10c
[   13.173009]  [<ffffffff810a0e4a>] ? time_hardirqs_off+0x1b/0x2f
[   13.173009]  [<ffffffff81065c4f>] ? trace_hardirqs_off_caller+0x3f/0x9c
[   13.173009]  [<ffffffff812235dd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[   13.173009]  [<ffffffff8156a75f>] page_fault+0x1f/0x30
[   14.010075] usb 5-1: new full speed USB device number 2 using uhci_hcd

Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
8826f3b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment