Recent changes broke the portability of this header file.
Fix the ACPI guards so it can be used in coreboot.
BUG=b:36024430
BRANCH=none
TEST=make -j buildall (as usual many haven boards fail)
Change-Id: I0d737e7aad7ead90289b43db09352092ef7e3e98
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/539135
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This API checks battery charge level and current power supply
to determine whether the AP has enough power to boot or not.
BUG=b:38462249
BRANCH=none
TEST=make buildall
Change-Id: I489f7ea92f230701b8f18c94d3e698aad90b4a03
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517272
This patch adds wait between DSW_PWROK and PWRBTN assert. It is
required to be 95 msec or longer for Kaby Lake and Sky Lake.
Refer to the timing diagram for G3 to S0 on Sky Lake or Kaby Lake
platform design guide for details.
BUG=b:62584658
BRANCH=none
TEST=On Fizz, measured time between DSW_PWROK high and PWRBTN assert
for 1:AC plug-in, 2:recovery+power press, 3: reboot ec command.
Change-Id: I89a14ac9a49e20a332bd662d90be62f8ea23b003
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/534901
Reject updates for the first 60 seconds after a hard reboot. This should
prevent people from using the reboot at the end of an update to get
around the update rate limiting. Reboots don't happen during normal cr50
operation, so this should not prevent updates. It will just prevent
updating cr50 many times in a row.
This change does not limit updates after deep sleep or POR.
BUG=b:62097097
BRANCH=cr50
TEST=Try to update cr50 two times. Verify that on the second time the
update is rejected. Put cr50 into deep sleep, wake it up and verify it
can be updated immediately. Get cr50 to do a POR and verify it can be
updated immediately.
Change-Id: I828ef210e1c5bcf59d4753b8178ee4e1369d5d36
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/520727
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Until HOOK_INIT has completed, do not allow any tasks other than HOOKS
or IDLE to be scheduled. Programmers often make the assumption that
a HOOK_INIT function is guaranteed to be run before task code that depends
on it, so let's make it so.
BUG=chromium:649398
BRANCH=None
TEST=Manual on kevin, compare boot without patch:
...
[0.004 power state 0 = G3, in 0x0008] <-- from chipset task
RTC: 0x00000000 (0.00 s)
[0.004 power state 4 = G3->S5, in 0x0008]
RTC: 0x00000000 (0.00 s)
[0.005 clear MKBP fifo]
[0.006 clear MKBP fifo]
[0.006 KB init state: ... <-- from keyscan task
[0.012 SW 0x05]
[0.155 hash start 0x00020000 0x00019a38]
[0.158 HOOK_INIT DONE!]
... to boot with patch:
...
RTC: 0x58cc614c (1489789260.00 s)
[0.004 clear MKBP fifo]
[0.005 clear MKBP fifo]
[0.010 SW 0x05]
[0.155 hash start 0x00020000 0x000198e0]
[0.157 HOOK_INIT DONE!]
...
Also, verify kevin boots to OS and is generally functional through
sysjump and basic tasks, and verify elm (stm32f0 / cortex-m0) boots.
Change-Id: If56fab05ce9b9650feb93c5cfc2d084aa281e622
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/456628
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cortex-M4 supports a floating point square root function that takes 14
cycles to execute, which is a speed improvement over the existing binary
search, and saves flash space.
BUG=chromium:687624
BRANCH=None
TEST=On kevin, verify that both sqrtf methods (binary search vs HW
instruction) have identical results for fractional input (eg.
sqrt(15.999999) = 3), except when floating point representation of
square root rounds up to an integer. Verify identical results for all
integers [-100, 16793602). Note that 16793602 is the first integer for
which the floating point representation of sqrt rounds up to an integer.
Also verify basic motion sense functions on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8521c9a28c958b340ca83c37342253e424df0c91
Reviewed-on: https://chromium-review.googlesource.com/537734
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If Cr50 happens to start on a chip where Board ID programmed in INFO1
does not match the contents of the RW header, it means that for some
reason the other RW is not operational and the current image is the
only viable one.
In this case the Cr50 starts but operates in limited mode (only
commands for updating the image and reporting state are handled). In
this case the reason for recovery could be seen on the Recovery
screen, and the update could be done once Chrome OS boots in recovery
mode.
BRANCH=none
BUG=b:35586335
TEST=verified the following:
- if an image with wrong board ID is started, it tries to fall back
(sets the counter to a value above threshold and reboots)
- if the fallback fails, the image keeps running in the limited
capabilities mode but the update is possible, observed that the
new image took over worked after powercycling the device.
- observed proper error message on the recovery screen showing where
the error comes from
Change-Id: I46ba75392f8e891bb8503fb15aea2c56b5805e83
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, read_tty reads characters from tty as long as there
is something to read. This causes read_tty to loop forever if the board
is in reboot loop.
This patch makes cts.py stop reading tty if boot count exceeds
max_boot_count. Reboot is detected by detecting REBOOT_MARKER.
This patch also does:
- Remove debug option: This adds complexity for no real value. Developers
should debug tests using regular tools (make, uart console, etc.).
- Remove html output. Nobody use it. Should be redone when it's needed
using proper libraries.
BUG=chromium:664309
BRANCH=none
TEST=cts.py -m task/gpio/interrupt
Change-Id: I51d1dd51c4097e8115ef04ad46853720295141b4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410281
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch hides expected messages from output to the terminal
and reorganizes log directory as follows:
- All test output goes under /tmp/ects/$dut/$module
- Openocd output is recorded in openocd.log
- uart outputs are recorded in uart_th.log and uart_dut.log
- build output is recorded in build.log
- Check exit code from all subprocess calls
- Dump build log if build fails
- Dump openocd log if openocd fails
BUG=chromium:664309
BRANCH=none
TEST=cts.py --setup and build images in chroot then run cts.py -m meta
outside chroot.
Change-Id: I13294c3bf777ad7ae590459d3cf5aea405d59f96
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/409536
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add support for update related vendor commands in mn50 by relocating
relevant code from board/cr50 to chip/g.
BUG=b:36910757
BRANCH=None
TEST=./extra/usb_updater/usb_updater -d 18d1:502a build/mn50/ec.bin
Change-Id: Iec0fe5585b5b6eb099f9254dfb0e5b02d5106abc
Reviewed-on: https://chromium-review.googlesource.com/537999
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When an external charger is connected, only the LED on the side the
charger is connected should be on, the other side should be off. The
existing LED behavior was incorrect in that only the side that was
charging was being updated and the other side would remain in its
previous state.
This CL adds a fix so that if only one LED is being controlled, the
other side is always turned off. In addition, the logic for double tap
events was changed slightly so that if a double tap event is in
progress and a charger is connected, the new state will be updated as
soon as the charge state is changed instead of waiting for the double
tap event to complete.
BUG=b:62481906
BRANCH=eve
TEST=Manual With battery level < 15% so that both LEDs are red when
the charger isn't connected, connect charger and verified that the LED
on the side the charger is connected turns white and the LED on the
other side turns off.
Change-Id: I7462629409496383adb43445e732dd6ca2f9f589
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/537960
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
The setup time of original i2c setting which i2c freq is 1MHz is closed
to the margin of the spec. This CL improves the setup time with a new
setting. (For example, in npcx evb, measured setup time now is about
480 ns.)
This CL also removes the timing settings of higher i2c source clock
frequencies which are not used so far to save the code size.
BRANCH=none
BUG=b:38217035
TEST=No build error for make buildall; run stress test with i2cxfer and
i2cscan on gru with 400K and 1MHz i2c freq.
Change-Id: I5428a7dab1d935fd428ee9012604813e752cead8
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/527739
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Holding the mutex just around the dcrypto_call is not enough: dcrypto
instruction memory content might change in presence of multiple calling
tasks.
Switching to broad acquire/release pattern instead.
Note to sub-projects: pair your dcrypto_init(_and_lock) w/ matching dcrypto_unlock
BUG=none
BRANCH=cr50
TEST=tcg_tests pass
Change-Id: Idb7f2d79ce533db95cab51d89e3869ecf9f3d499
Reviewed-on: https://chromium-review.googlesource.com/535916
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
When starting up the Cr50 should check if this image is supposed to
run on a chip with the board ID value read from INFO1.
If it is not supposed to run on this chip, and there is no rollback
counter overflow, set the rollback counter to a value which will
trigger a rollback and reboot.
If rollback counter has already exceeded the threshold - set a flag
indicating that the image is running in the "mismatch" mode and
continue.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches applied verified both falling back
to an older image and continuing running with the flag set if
rollback is not possible.
Change-Id: I58d97de61dc446aaf1dd06b6e2b6bb426c14a172
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535977
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
with the board ID match happening in the RW we need to be able to set
the rollback counter to a value which would guarantee a fallback
during the next boot.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches verified the ability to set the
counter to trigger a fallback on the next reboot.
Change-Id: I161f39354e5523121e26e8ad84a791a8b06e5123
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535976
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Until the Board ID check is moved to RO, it is possible to start an RW
with a mismatching Board ID.
Let's add a function to check for mismatch and report the status.
Also eliminating the unnecessary check for empty header Board ID field
- it is going to match any board ID anyways and fixing a CPRINTF
statement in read_board_id().
BRANCH=cr50
BUG=b:35586335
TEST=verified that empty board ID header does not trigger a mismatch
on a board with a non-empty INFO1. With the rest of the patches
applied verified that board ID mismatch is reported properly.
Change-Id: Ie03f8137e494117b7a238e3af72527e0a46369e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535975
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Provide APIs that allow chips to implement their own version of
backing up/restoring panic data to persistent storage.
BUG=b:62076222
BRANCH=None
TEST=make -j buildall
Change-Id: Idda2d55703d4fe7e0a8d6305695fbf4e193b596b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530196
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
rev1 (Soraka) was using proto settings. Instead use the settings described
in fuel gauge specification.
BRANCH=none
BUG=b:62552007
TEST=On soraka, check that the system goes to ship mode and no error
messages appear, using "ectool batterycutoff" from OS or "cutoff"
from EC console.
Change-Id: I04e6b08265d20395d13e28e93cb14c1d49b376df
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/531736
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
In the FIDO U2F Authenticator Transports Extension, the list of
transports will be extended to:
FIDOU2FTransports ::= BIT STRING {
bluetoothRadio(0), -- Bluetooth Classic
bluetoothLowEnergyRadio(1),
uSB(2),
nFC(3),
uSBInternal(4)
}
Given our implementation is internal, update the value from bit(2) uSB
to bit(4) uSBInternal.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate
with an ASN.1 parser.
Change-Id: I62fe72ffed9b7eb34e31164fded46f458e5cbc16
Reviewed-on: https://chromium-review.googlesource.com/536775
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Implement system_get_chip_unique_id() for the g hardware.
It includes the hardware revision, the chip device id and
the read-only key id.
The key-id is included because this unique id is used as serial number
inside certificates and for security reason, we want a different id if
the RO has changed (e.g Node locked firmware).
The id is also 32-byte long for convenience reason when used for
certificates, but the high 16 bytes are currently zeros.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=dump the x.509 individual attestation certificate which includes
the unique id as serial number.
Change-Id: If24597d0de696d2700122d425724f14703fc5256
Reviewed-on: https://chromium-review.googlesource.com/536774
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
x25519 requires quite a bit more stack size (1696/2048), so
increase its size.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer, ./usb_updater2 -c always reports the same
device public key, and authenticator is correct.
Change-Id: I51dff9f10167d654561ef7f199b9b9206511b7e9
Reviewed-on: https://chromium-review.googlesource.com/532476
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Handle UPDATE_EXTRA_CMD_PAIR_CHALLENGE command, where the
lid sends a random x25519 public key, and nonce, and the base
replies with its own (stable) x25519 public key, and computes
a shared secret using its private key to verify its identity.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer, ./usb_updater2 -c always reports the same
device public key, and authenticator is correct.
Change-Id: Ida60ffa7476794ee92669951c740dbe35950fb9c
Reviewed-on: https://chromium-review.googlesource.com/532475
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In CL:503475, SERVO_TYPE is initialized *after* toad cable detection.
This make flash_ec failed to update plankton EC.
This CL adjust the timing of SERVO_TYPE detection, so toad cable
detection can work properly.
BUG=b:35648297
BRANCH=plankton
TEST=utils/flash_ec --board=plankton
Change-Id: I08a11b99109454096949b3ff64ed1c4d5f9891df
Reviewed-on: https://chromium-review.googlesource.com/535381
Commit-Ready: Wei-Han Chen <stimim@chromium.org>
Tested-by: Wei-Han Chen <stimim@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Before this change, the current task id was cached in dcrypto_init() if
it hadn't already been called. This resulted in the task id of the first
caller to dcrypto_init() being cached until reset.
The cached task id was used when generating notifications that hardware
crypto operations were complete. This was fine as long as the task that
invoked dcrypto_init() was also the task that invoked dcrypto_call(). If
this wasn't the case, the task that invoked dcrypto_init() would be
notified of an event it wasn't expecting and the task that invoked
dcrypto_call() would not be notified and would time out.
This change locks a mutex and then caches the current task id in
dcrypto_call() before invoking the hardware operation so that the
correct task will be notified when the operation has completed.
BRANCH=none
BUG=none
TEST=make -j buildall
Change-Id: I30a920d85359cc990d77c88b1607bbe4cf674206
Reviewed-on: https://chromium-review.googlesource.com/522350
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change ensures that the power button pulse setting is saved and
restored across a sysjump. It uses the SYSJUMP_TAG "PB" (0x5042).
BUG=b:62445190
BRANCH=None
TEST=The condition mentioned in the bug could be reproduced using
following steps:
1. reboot on EC console
2. Use Vup/Vdn to select any option other than Power off.
3. Press power button
After step #3 above, device would shut down instead of selecting the
option. Verified that with this change, the device does not power off
anymore at step #3.
Change-Id: Icebe9c17d39a82fc3854dd75cc3a1dea032a234a
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/533921
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The contents of the board ID fields of the Cr50 image headers is an
important piece of information which determines if an image can run on
a particular H1 chip.
This patch adds this information to the output of the 'version'
command, printing both the contents of the fields of the RW images and
if the image would run with the current INFO1 board ID contents (Yes
or NO).
The board_id feature is in fact g chipset specific, this is why
board_id support files are being moved from the cr50 board scope to
the g chip scope.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=observed expected output in the version command:
> bid
Board ID: 000000fa, flags 000000ff
> vers
Chip: g cr50 B2-C
Board: 0
RO_A: * 0.0.10/29d77172
RO_B: 0.0.10/c2a3f8f9
RW_A: * 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
RW_B: 0.0.20/DBG/cr50_v1.1.6543-2c68a2630+
BID A: 00000000:00000000:00000000 Yes
BID B: 000000ea:0000fffc:000000ff No
Build: 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
tpm2:v0.0.289-cb2de5a
cryptoc:v0.0.8-6283eee
2017-06-09 15:34:19 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I5b283abf304a7408ca8f424407044fca238185e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530033
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
By default, read USB serial number from flash, but provide a way
for boards to override the function (e.g., to read serial number
from unique chip id).
BRANCH=none
BUG=b:62280271
TEST=Flash hammer
lsusb -d 18d1:5022 -v -v | grep iSerial
shows different chip IDs on different boards.
Change-Id: I0917752bb8e04c1eff4dffc0b3714f63dcd942b0
Reviewed-on: https://chromium-review.googlesource.com/523045
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Using servo v4 with the captive CCD cable to flash an STM32 requires bit
banging mode to be enabled. This commit adds that support.
BUG=b:35648297
BRANCH=gru
TEST=Add support for rowan and flash rowan with no issues.
Change-Id: I6317d4acdd569888e20a1e298de7c8b620e94bb1
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/503476
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Not every servo has support for the same controls. For example, servo
micro doesn't have the JTAG buf on flex elements. This commit cleans up
the assumptions made and defines some variables which indicate which
controls are supported on a particular servo type. The servo type is
obtained by the "servo_type" control from servod.
BUG=b:35648297
BRANCH=gru
TEST=With some other patches, try and flash rowan with a servo v4.
Change-Id: Ie10f4f73028a01a81638e9114b48c88941b8bf93
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/503475
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Since Reef was the starting point for /board/coral, coral inherited
support for both the BMI150 magnetometer and BMI280 barometer
sensors. Coral does not need to support either of these sensors.
This CL removes support for both of these sensors.
BUG=b:62519010
BRANCH=none
TEST=Manual Run 'make BOARD=coral' and verify it builds. Used
accelinfo EC console command to verify that other sensor readings are
working. My test setup does not have ALS sensor so couldn't confirm
that operation.
Change-Id: I75abe2f10c8f0ff318f4795e6b88c9aff3d8a9ad
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/530448
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
