BACKPORT: clocksource: add empty version of clocksource_of_init

Add an empty clocksource_of_init when !CLKSRC_OF. This is needed for builds
where no timer has selected CLKSRC_OF.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit e0c25362384f4be9c755c98560cd4b1cdb2ec79c)

Conflicts:
	include/linux/clocksource.h

Change-Id: I1a4b7710077528ff8ee4a2e065b9780cdff6e24f
Reviewed-on: https://chromium-review.googlesource.com/191596
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: clocksource: pass DT node pointer to init functions

In cases where we have multiple nodes of the same type, we may need the
node pointer to know which node was matched. Passing the node pointer
also keeps the init function from having to match the node a 2nd time.

Update bcm2835, vt8500, and tegra20 init functions for the new function
prototype. Further tegra20 clean-ups are in follow-up commit.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pi

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Prisk <linux@prisktech.co.nz>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit effbfdd7baf7babc73154b87a5ff940969cf6559)

Conflicts:
	drivers/clocksource/bcm2835_timer.c
	drivers/clocksource/vt8500_timer.c

- Remove changes to drivers/clocksource/vt8500_timer.c because the patch
  that moves that file into drivers/clocksource is not in our tree.

Change-Id: Ifaa7b0323a0522e4853d35ef5e104f29d2eb653c
Reviewed-on: https://chromium-review.googlesource.com/191597
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: clocksource: tegra20: use the device_node pointer passed to init

We've already matched the node, so use the node pointer passed in. The rtc
init was intermingled with the timer init, so split this out to a separate
init function.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 1d16cfb3aeba71bc6ecf2d19ccbabed0426e5c22)

Conflicts:
	drivers/clocksource/tegra20_timer.c

Change-Id: Ic201b3c95c3ff1f259a5311c15c2546e2e45cf19
Reviewed-on: https://chromium-review.googlesource.com/191598
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: ARM: smp_twd: convert to use CLKSRC_OF init

Now that we have OF based init with CLKSRC_OF, convert smp_twd init
function to use it and covert all callers of
twd_local_timer_of_register.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-omap@vger.kernel.org
Cc: spear-devel@list.st.com
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit da4a686a2cfb077a8bfc1697f597e7f86235b822)

Conflicts:
	arch/arm/kernel/smp_twd.c
	arch/arm/mach-imx/mach-imx6q.c

Change-Id: I3d4a4ff4908783d0facdd4b6c104df011048f65b
Reviewed-on: https://chromium-review.googlesource.com/191599
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: clocksource: make CLOCKSOURCE_OF_DECLARE type safe

This ensures that a function pointer passed into CLOCKSOURCE_OF_DECLARE
takes the same arguments that we use for calling that function later.

Also fix the extraneous semicolon at end of the CLOCKSOURCE_OF_DECLARE
definition.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 3d5a96582303e28c48699f3faaf920ef7d43e6f2)

Conflicts:
	drivers/clocksource/vt8500_timer.c

- Remove changes to drivers/clocksource/vt8500_timer.c because the patch
  that moves that file into drivers/clocksource is not in our tree.
- Fix build errors in exynos_mct.c

Change-Id: Ic6916cce59d75acc77274d56ae40c797ca55ffcf
Reviewed-on: https://chromium-review.googlesource.com/191600
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: ARM: sched_clock: allow changing to higher frequency counter

Allow multiple calls to setup_sched_clock and switch to the new counter
if it is higher frequency.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit c115739da801ea1ea20c48e2991ce6761496bef1)

Change-Id: Ic1126d4bc038730328756f5b2dbae5ff5b3254da
Reviewed-on: https://chromium-review.googlesource.com/191601
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: ARM: make sched_clock just call a function pointer

This converts sched_clock to simply a call to a function pointer in order
to allow overriding it. This will allow for use with 64-bit counters where
overflow handling is not needed.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 7e48c0b9d9ab07c92cd26f167010cd5a50eb0cec)

Change-Id: I2faf19b368aee3046186d00ddbd8e1c034faad20
Reviewed-on: https://chromium-review.googlesource.com/191602
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: ARM: arch_timer: use full 64-bit counter for sched_clock

Only 32-bits of the arch timer were being used and wrapping was needlessly
being done in s/w. By using the full counter (56-64 bits), we don't need
to deal with wrapping and can simplify the implementation when using
arch timer.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 023796b9be3a77481cd5ee0b64a13a55bb0d5df4)

Change-Id: Iccfb802fa393ef1a0af20e71d0ff7f3de0db7aea
Reviewed-on: https://chromium-review.googlesource.com/191603
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: ARM: make machine_desc->init_time default to clocksource_of_init

Originally from a default machine descriptor patch from Arnd, pull out
just the default call to clocksource_of_init part. This is needed so that
platforms can simply remove .init_time calls as they are converted to use
clocksource_of_init.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit f414f13f2fd0d8bb12a87268a55827cda771d42b)

Change-Id: Ie933d34df6da82ec0f0c40b575215629dd3179c2
Reviewed-on: https://chromium-review.googlesource.com/191604
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.

This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pit

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 0583fe478a7d93be2c814b7e50d6e81c287edfe8)

Conflicts:
	arch/arm/mach-exynos/mach-exynos5-dt.c
	arch/arm/mach-exynos/mct.c
	arch/arm/mach-shmobile/setup-sh73a0.c
	arch/arm/mach-shmobile/timer.c
	arch/arm/mach-virt/virt.c
	drivers/clocksource/Kconfig

- Drop changes to arch/arm/mach-virt/virt.c because it doesn't exist in
  our tree
- arch/arm/mach-exynos/mct.c is now drivers/clocksource/exynos-mct.c so
  apply the changes there instead

Change-Id: I238235893fbb4c8aeb0266eebbfb3c337234d080
Reviewed-on: https://chromium-review.googlesource.com/191605
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: ARM: arch_timer: Silence debug preempt warnings

Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:

  BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
  caller is arch_timer_cpu_notify+0x14/0xc8

This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pi

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <Marc.Zyngier@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit f31c2f1c68aff83277eddc6798adf3438e9c680a)

Change-Id: I76548043164f37d026f533a95cc08e5a88df2634
Reviewed-on: https://chromium-review.googlesource.com/191606
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops

Commit 70264367a243 ("ARM: 7653/2: do not scale loops_per_jiffy when
using a constant delay clock") fixed a problem with our timer-based
delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
by the timer delay ops.

This patch fixes the problem in a more elegant way by keeping a private
ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
and therefore not subject to scaling. The loop-based delay continues to
use loops_per_jiffy directly, as it should.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on pi

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
(cherry picked from commit 6f3d90e55660ba42301b5e9c7eed332cc9f70fd7)

Conflicts:
	arch/arm/kernel/smp.c

Change-Id: Iea0a473b225b3be9debf3ab6694076ec86d4faa4
Reviewed-on: https://chromium-review.googlesource.com/191607
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
UPSTREAM: HID: uhid: make creating devices work on 64/32 systems

Unfortunately UHID interface, as it was introduced, is broken with 32 bit
userspace running on 64 bit kernels as it uses a pointer in its userspace
facing API.

Fix it by checking if we are executing compat task and munge the request
appropriately.

BUG=chromium:345982
TEST=none

Change-Id: Ica866d12cb0f9956903d2a648c35c92d52f74075
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192416
Reviewed-by: Kees Cook <keescook@chromium.org>
UPSTREAM: HID: uhid: use generic hidinput_input_event()

HID core provides the same functionality and can convert the input event
to a raw output report. We can thus drop UHID_OUTPUT_EV and rely on the
mandatory UHID_OUTPUT.

User-space wasn't able to do anything with UHID_OUTPUT_EV, anyway. They
don't have access to the report fields.

BUG=chromium:345982
TEST=BlueZ does not log "Unsupported uHID output event"

Change-Id: I3a84b79b27f01329e479bba22af2d893de331547
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192417
Reviewed-by: Kees Cook <keescook@chromium.org>
UPSTREAM: HID: uhid: fix leak for 64/32 UHID_CREATE

UHID allows short writes so user-space can omit unused fields. We
automatically set them to 0 in the kernel. However, the 64/32 bit
compat-handler didn't do that in the UHID_CREATE fallback. This will
reveal random kernel heap data (of random size, even) to user-space.

Fixes: befde0226a59 ('HID: uhid: make creating devices work on 64/32 systems')

BUG=chromium:345982
TEST=none

Change-Id: Iaaaf5da37802dc5dd2bed1f6fb9b1c5f44fba54d
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192418
Reviewed-by: Kees Cook <keescook@chromium.org>
clk:exynos5250: Add 35xx PLL PMS values

PMS values for GPLL are added as per the recommended settings

BUG=chrome-os-partner:27562
TEST=
1) Boot 30 times till login screen on faulty sample.
See login screen everytime.
2) Run 5 instance WebGL Aquarium on the faulty samples
overnight. See it run without issues.
3) Run Many planets deep, Hopalong WebGL.

Change-Id: Ifca1d993380f78ceea92a618967c7d612372e885
Signed-off-by: Akshu Agrawal <akshu.a@samsung.com>
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/192679
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Abhinav Kochhar <abhinav.k@samsung.com>
Reviewed-by: RAVISHANKAR KN <rash.7015@gmail.com>
Tested-by: RAVISHANKAR KN <rash.7015@gmail.com>
t6xx:chromebook:Exynos5250 Set DVFS rate by setting same value to GPLL

With new GPLL values, DVFS rate and GPLL rate have 1:1 mapping.
The DVFS rate now can be set by directly setting the GPLL rate.

BUG=chrome-os-partner:27562
TEST=
1) Boot 30 times till login screen on faulty sample.
See login screen everytime.
2) Run 5 instance WebGL Aquarium on the faulty samples
overnight. See it run without issues.
3) Run Many planets deep, Hopalong WebGL.

Change-Id: I2af4e8602bb834f21e948e2a1dc541e65e2597d3
Signed-off-by: Akshu Agrawal <akshu.a@samsung.com>
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/192700
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Abhinav Kochhar <abhinav.k@samsung.com>
CHROMIUM: config: enable UHID

UHID provides a mechanism for userspace to implement HID I/O Drivers,
performing the raw data I/O to the low level device and pushing HID
Reports to the kernel for parsing.

It's required for HID over GATT (HID on Bluetooth Low Energy) because,
unlike HID on classic Bluetooth, the GATT protocol is implemented in
userspace whereas the L2CAP protocol on which HID is based is
implemented in the kernel.

BUG=chromium:345982
TEST=`emerge-$BOARD chromeos-kernel-next` and check for /dev/uhid

Change-Id: Id7ae4efdd9045fad2eaac3bf84841ff2e3e02102
Signed-off-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192415
Reviewed-by: Kees Cook <keescook@chromium.org>
ARM: dts: Increase EC/AP communication margins on peach

We have seen occasional checksum failures reported on the SPI bus
that's used for EC/AP communications.  We don't know 100% what's
causing the problems, so we'll take a scattershot approach and hope it
helps.

1. Decrease SPI speed from 4MHz to 3.125MHz.  There appears to be some
   problems on the EC when running SPI at 4.5MHz.  It's entirely
   possible that we _might_ have problems even if we're at 4MHz.
   Let's bump the speed down a bit to give us some margin.

2. Increase the drive strength of the SPI lines.  We've already got
   the chip select line at x4 drive strength.  Move the clock/data
   lines up to x2 from x1.  The slightly higher drive strength should
   just give a little extra integrity to the signal.

3. Adjust our sampling phase offset from 180 degrees to 90 degrees.
   My measurements show that the response from the EC is delayed by
   about 25ns.  At 3.125MHz each phase offset is 62.5ns.  At 4MHz each
   is 50ns.  At 10MHz each is 25ns.  ...so delaying by 90 degrees
   should only increase margin.  Extra confidence is gained by
   observing that 0, 90, and 180 all work OK but when you move to 270
   you start getting failures.

BUG=chrome-os-partner:27445
TEST=Stress ec: "while true; do ectool version > /dev/null; done"
TEST=See sclk_spi2 is 6250000 (3.125 x 2) in /sys/kernel/*/clk/*_summary
TEST=Look on scope and see that signals look good

Change-Id: I3f8dee5bcff31da37379e796192ae72c0b079b79
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192619
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
CHROMIUM: mwifiex: balance dma map/unmap sizes

Depending on the underlying DMA implementation its
not possible to partially unmap DMA buffers. Moreover
its not possible to understand the intent of passing
0 as the size to dma unmap. The intent of this
driver is unmap the entire skb buffer. The only way
to ensure that the size matches on unmap is to store
both the dma address and the size in the skb ca field.

Introduce a mwifiex_dma_mapping structure which tracks
the dma address and the size. Additionally, provide
a mwifiex_unmap_pci_memory() that utilizes the new
structure. This also provide symmetry within the
internal API.

BUG=chrome-os-partner:24817
BUG=chrome-os-partner:24397
BRANCH=None
TEST=Running with instrumented kernel reveals no more
     0-sized DMA unmaps. And the factory Stress test
     can now pass.

Change-Id: Ic2c076c758503d4242db195433eca146c5c7ee11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/193350
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>