Enable check for protected mode. If we are in RO and we are write
protected, then don't allow PD communication.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=Booted with and without battery, made sure PD communication
works and we can boot (note we are currently not protected).
Then commnented out CONFIG_SYSTEM_UNLOCKED, and ran flashwp enable
from PD console to protect the system. Now when boot with battery,
we don't communicate over PD and just take VBUS 5V. Removed battery
and attempted to boot with just AC, but not enough power to boot
off just 5V. EC goes to S0 and back to G3 after about 100ms.
Change-Id: Ib26f8f0f5e9134d0337ebbd7f087f50fa41842d8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213738
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Some platforms may have active low ILIM_SEL that is per-port
and the output needs to be inverted.
BUG=chrome-os-partner:31549
BRANCH=samus
TEST=emerge-samus chromeos-ec, not used until EVT
Change-Id: I1e164d9aa46df119467113eb175e7deec4fd8a21
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213743
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the power supply voltage is transitioning to a lower value, use the
discharging FET to ensure that the voltage is acceptable before
re-enabling the output.
Note: when discharging, we must disable the fast OCP ADC interrupt, but
that is ok because we still have the slow OCP check in board_checks().
BRANCH=none
BUG=chrome-os-partner:28332
TEST=on Zinger, transition from 20V to 5V using Firefly buttons and
observe that we no longer have an over-voltage event. Also, verified
that fast OCP triggering still works after a discharge.
Change-Id: Ie327645e74819aebd1260f5ce16b2ba46a674a7b
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201577
Reviewed-by: Todd Broch <tbroch@chromium.org>
Software sync on the AP will ask the EC to reboot to RO after the AP
shuts down. This allows the AP to do a clean shutdown before the EC
reboots. The PD chip should be rebooted at the same time the EC
reboots itself, so that in a low-battery case the requested PD reboot
also takes place after AP shutdown.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=From the EC console, 'reboot hard' also reboots the PD chip.
Change-Id: I109a495ca32ad1ac4aac42708935962d3226792e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210570
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Adds a small threshold for sending a host event to battery whenever
the full capacity changes. This helps avoid constant host events
when the battery decides the capacity is going back and forth 1mAh
BUG=none
BRANCH=none
TEST=load on samus. set LFCC_EVENT_THRESHOLD to 1 and see host
events very often. set LFCC_EVENT_THRESHOLD to 5 and see no host
events.
Change-Id: I2dc38f04e1a634539837dfed19b10ccfcfd0a8a3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213668
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds an optional lb_power() function that the lightbar TAP sequence can
use to briefly power up the lightbar rails while the AP is shut down.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
Shut the AP down, then from the EC console run "lightbar seq tap". The
lightbar should light up and briefly indicate the current power levels. You
can manully force the battery status with "lightbar demo on", then use the
arrow keys to change the state.
Note that the Samus that I tested on had trouble recognizing when it was
charging or not. That's a separate bug.
Change-Id: Iad3f08506d9e049e89d0711af00da2f1aa2337e0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213664
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add custom VDM to read last measured output current in mA.
BUG=chrome-os-partner:30850
BRANCH=none
TEST=Run "pd 0 vdm curr" on samus pd console and verify
reasonable current
Change-Id: Ie1f1ab235560eb4e90f399ceac31c5cd93003d80
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212981
Turn off sending pings in SRC_READY by default. Added custom VDM
to turn pings back on, which only zinger supports right now.
Changed the "pd ping" console command to be used to enabled/disable
pings in SRC_READY.
BUG=chrome-os-partner:31409
BRANCH=none
TEST=loaded onto samus and zinger. on samus_pd, enabled highest
level of debug info: "pd 0 debug 2" to allow printing ping received.
Then plugged in zinger. By default, we negotiate to SNK_READY and
receive no pings. Then send "pd 0 vdm ping 1" to send VDM to zinger
to enable pings, and verified we start receiving pings. Sending
"pd 0 vdm ping 0" sends VDM to stop sending pings.
Change-Id: I4f64c6fc59bb734146eeca5e3ea3a24954c786b2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212965
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
This fixes a bug where we were reading the CC line ADC without disabling
the adc watchdog, which caused misreads. Instead, I changed adc_read_channel
so that every ADC read disables and restores the ADC watchdog.
BUG=chrome-os-partner:31454
BRANCH=none
TEST=tested on EVT zinger. Added debug code to print out CC line voltage
after reading it in usb_pd_protocol.c. Before the change the CC voltage is
mostly wrong, unless you read the ADC twice back to back and look at the
second read value. After this change, the CC voltage ADC reading always
matches the real voltage.
Change-Id: I9d3aa02b3d22defb9cf6f5a866de2b846a6b8a35
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213253
Reviewed-by: Todd Broch <tbroch@chromium.org>
Fix zinger and keyborg to use correct event mask when
timing out from task_wait_event(): TASK_EVENT_TIMER.
On zinger, move storing the last event to after enabling
interrupts. This gives an opportunity to interrupt
handler to set the wake event.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load on zinger, and test PD communication with samus.
notably tested sending rw_hash vdm from samus, which is known
to cause zinger to retry the following ping transmit. The
retry on the ping transmit uses task_wait_event(), and without
this fix we were getting false wake events that had been stored
up from the last rx received event. with this fix, the retry
mechanism works.
Change-Id: I9a6902ceaab49a00d3660f9813ca7761cf38f190
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213560
Reviewed-by: Todd Broch <tbroch@chromium.org>
This fixes a bug in the PD transmit retry mechanism. In the retry
mechanism, we were assuming that only a pd rx interrupt will wake
up this event. But, there are other events that could potentially
wake us up, so we need to check to make sure that pd rx started
when we first wake up.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load onto samus and zinger. run "pd 0 flash rw_hash" a bunch of
times manually from the console. Observe that we nearly always fail
the first receive, but succeed on next try, which prevents us from
dropping the negotiation.
Change-Id: I5f7261176c151c3185d76aa374b9b83ac9df9a7d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213369
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Seems like we were always overriding the backlight to be off, preventing the AP
from turning on the backlight.
BRANCH=None
BUG=None
TEST=Boot a kernel that cares about the backlight and see if it turns on.
Change-Id: Ia8f12c5830854e37ffc5d6b41ef5b8fefbab4ed8
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213289
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the power button, volume up, and volume down buttons
are pressed during boot indicate to the AP that recovery mode
is enabled.
BUG=chrome-os-partner:31481
BRANCH=None
TEST=Benson tested this w/ his magic cables.
Change-Id: I2f285d6b8b71708eff53e8b46020e51c96f281a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213299
Reviewed-by: Alec Berg <alecaberg@chromium.org>
It's useful to expose the logic of the power button assertion
according to the CONFIG active level at the hardware input.
Therefore, provide power_button_signal_asserted().
BUG=chrome-os-partner:31481
BRANCH=None
TEST=Benson tested this on ryu since has the button cables.
Change-Id: Ica48bfe981550700a067406cb72908e14dbccba9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213298
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This CL ensures that temporary "one-shot" sequences such as KONAMI, TEST,
TAP, etc. will revert to the previous "normal" sequences even when
interrupted by other one-shot sequences.
This also adds a test for those cases.
BUG=chrome-os-partner:29873
BRANCH=ToT
TEST=manual
make runtests
Change-Id: Ie83908731acdf2f7c9108568a1ba047943175d26
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213230
Host i2c driver in ryu does not allow to snoop the byte
stream to abort the transaction. This make host i2c
driver to be in the dead state if the response message from
ec is shorter than host expected length.
This patch will make ec to send 0xec after end of response
message until get the 'NAK' answer from host to fixed this
issue which occur in these 2 situations.
1. When ec encounters host command error.
2. When response message is a null terminated string.
BUG=chrome-os-partner:31367
TEST='ectool version' runs fine on ryu
BRANCH=none
Change-Id: Icad0f0fde6cca4abd9c833c6d179143e4c5c0561
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213177
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
I readded the code that armed the power_off_deadline. The force power-off should
be controlled fully from the EC now.
BUG=None
TEST=When in S3/S0, hold the power button for 8 seconds; the system should shutdown.
BRANCH=None
Change-Id: I848ce6757e497c15296aa4eae9c05133950b4e45
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213249
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Seems that we were driving GPIO_PMIC_PWRON_H backwards. The only reason it
worked before is because of a stale feature from tegra which pretty much kept it
always disabled(enabled in our case due to _L).
Also removed old power signals and renamed signals so they're more semantic and
respect convention(no _H).
BUG=None
TEST=AP should boot as normal, gpioget will show both PMIC_*PWR* pins 0 when
system off and 1 when system is on. The system will also use 8mA less now
(no more current leak into the PMIC).
BRANCH=None
Change-Id: I81b7596cb39a5c2b45d53e05478396b91040cacf
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213246
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
The original version of the script worked but as the USB PD protocol
SM has been enhanced to handle more complicated scenarios the
occurrence of collisions on the baseband comm has grown and script
needs to account for that.
Script now checks status of ACK from zinger 'DONE 0' and retries two
additional times for commands that failed. If those three attempts
are unsuccessful script raises exception and quits.
Also added some more logging around retries and progress of chunk
writes.
BRANCH=none
BUG=chrome-os-partner:30135
TEST=manual, util/flash_pd.py build/zinger/ec.RW.flat succeeds in
programming zinger even in light of some retries.
Change-Id: Iaa8a22c2510ea5f4ebd92e1715be5fe062e13c61
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213131
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This just brings the competely unsupported but occasionally useful lightbar
simulation tool up to date with the rest of the source tree so it will
compile and run again.
BUG=none
BRANCH=ToT
TEST=manual
cd extra
make
./lightbar
Change-Id: Iafeaaa5ac56a4b711c63d2c64d8c51ab4b324104
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213206
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously our accel / gyro drivers assumed that we had exactly two of
each identical part in the system. Some systems may have different
configurations, so allow this to be specified at the board-level.
Note that our motion_sense algorithm currently assumes that we have one
accelerometer in the lid and one in the base -- we'll need to fix that
in another CL.
BUG=chrome-os-partner:27320
TEST=Compile-only. Tested in future Samus commit.
BRANCH=None.
Change-Id: I1fae1f6c578fedebe78b473a5d66a5794ccaae00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212321
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We use window mode to share the non-inverting input of the two
comparators. If COMP1 is not enabled, it causes problem on the operation
of COMP2. Fix this by enabling both comparator at the same time.
BUG=chrome-os-partner:31400
TEST=Reboot PD MCU, and plug into port 1. See SNK_READY state.
BRANCH=None
Change-Id: Icb7e7acdb8a09e094c24839c1d7b398b2c3fb9c0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212921
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When long power press is canceled, we need to cancel the current running
timer. Otherwise, if the power button is pressed again before the
current running timer expires, the next deadline won't be set. This
causes the chipset task to wake up too early and miss the subsequent
long power press shutdown.
BUG=chrome-os-partner:31372
TEST=On Ryu, long press following a short press shuts down the system.
BRANCH=None
Change-Id: I9855b146d430e5babda727fcb429c516ca91e48e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212560
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Passing the "--usb" argument will now utilized case-closed
debugging for flashing the EC. Currently this is only supported
for the samus LM4-based board.
BRANCH=none
BUG=none
TEST=verify that when the case-closed debugging flag is set, the
alternate openocd config file is used for samus, and an error is
thrown for all other boards
Change-Id: I0642bc2e9c2657cd8dbd83ee6e282365275d665a
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
implement USB mass storage class using the bulk-only transport
protocol with the transparent SCSI command set.
BRANCH=none
BUG=none
TEST=verify that usb mass storage functions on windows xp, 7, 8, mac os x, goobuntu precise
Change-Id: Ideecad55bd275df7b30aa4a3ed263304a3a109cd
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206303
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During flash erase operation, read is stalled and thus interrupt might
be serviced later. This can cause PD communication to fail and thus the
board reboots if there is no battery. Print a warning message in this
case.
BUG=chrome-os-partner:31127,chrome-os-partner:31207,chrome-os-partner:31362
TEST=Boot Ryu, on software sync, see warning message before board
reboots.
BRANCH=None
Change-Id: If327a4f533fd2dfa83f92531148bd52ace927e03
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212264
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We're printing more and more log and this sometimes causes timing issue.
Let's guard the PD log with a log level. Currently there are three
different levels:
- 0: Log state transition
- 1: Level 0, plus packet info
- 2: Level 1, plus packet dump on error
The default value is 0.
BUG=None
TEST=On Ryu, enable USB PD console channel and set different log levels.
Observe different amount of log message.
BRANCH=None
Change-Id: I49613d406bcb1ec20d3f242f724dc1c054478c7d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212351
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Certain i2c host drivers don't allow one to snoop the byte
stream to abort a transaction. Allow those devices to make
forward progress by sending out the '0xec' byte for any
requests coming through after an EC host command error.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Ran on ryu. Allowed passthru probing which normally hung
the system because of there not being a passthrue device
on ryu -- error returned. Instead the command returns
successfully by returning 0xec for the unfilled bytes.
Change-Id: Ibcab5ade1f727f3852995437105eb9fa693caadf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212165
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c_packet structure wasn't always being initialized
in the error path. It's possible to crash the EC if the first
command processed hit this error path. Instead, unconditionally
set all the i2c_packet fields.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: Ic6d7c63f61d59c4449fbb20f656c1bfb835db8be
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212164
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The wrong define was being used when checking the I2C ISR status.
The wrong define just so happened to be the correct bit.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: I6c7aad34f5e7c7ace4db4442147023346b6285bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212163
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On sysjump, we are losing all of our PD states. Instead of trying to
remember all the states and deal with on-going transmission, let's just
issue a soft reset so that the communication starts over.
BUG=chrome-os-partner:31207
TEST=With Ryu/Zinger, do 'sysjump rw' and check EC doesn't reboot.
BRANCH=None
Change-Id: I8779b74491a402434931b3455fa93ff2e178cb1f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212123
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Seems like STM32_SPI_CR2_FRXTH from 5d208b99(STM32F0 SPI Fixes) was not enough
to "disable" RX FIFO from the F0 series. There were still a few bytes stuck in
the FIFO just after a command with a long sequence of 00 bytes.
This increases the dummy bytes read just before a DMA transfer to 4(size of the
FIFO).
BUG=none
BRANCH=none
TEST=Veyron with the new EC should survive the AP booting. ectool version will
work right away after boot. This change should not affect other STM32 chips
because reading dummy bytes from an empty register is essentially a NOP.
Change-Id: I812208622a75ecce82433eb6c12595fee3c1428b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212297
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, when we receive soft reset request, we only reset message ID.
According to the spec, we should also reset the state machine without
cutting power. This CL implements this, along with a console command to
issue soft reset request.
BUG=chrome-os-partner:31296
TEST=Issue soft reset from Ryu to Zinger. Check that we go back to
discovery state and re-negociate a contract.
BRANCH=None
Change-Id: Ib00b0d9dddaf6ac2a1ec5c46dbc2824d6d7814ed
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212122
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently charge state machine resets input current limit to default
every time AC is connected. Problem is by the time charge state machine
gets around to setting input current, it could have already been set
by successful PD negotiation, and this ends up overriding that value.
This fix has the state machine store desired input current limit, as
determined from PD negotation or any other place, and send last desired
input current limit on AC connect.
BUG=chrome-os-partner:24461
BRANCH=none
TEST=load on samus, test toggling between "pd 0 dev 5" and "pd 0 dev 20",
and test plugging and unplugging zinger numerous times, and verify charger
command always gives the expected input current limit based on PD
negotiation.
Change-Id: I18d8acc9e2085739e783c9c70c682d46bcce7fdb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211639
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Change default to request 20V.
BUG=none
BRANCH=none
TEST=Load onto a firefly. Plug in a zinger, make sure 20V LED
lights up. Press other buttons to make sure we can change the
requested voltage to 5V and 12V.
Change-Id: I3a3e63a6d0e4f01b9fe7c730468da75ad6783f41
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211872
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change the VDM implementation in the PD task to allow for VDMs
at any time when connected without disrupting any regular PD
communications.
BUG=none
BRANCH=none
TEST=load on a samus and on a zinger and test sending VDMs:
pd 0 flash version
pd 0 flash reboot
Also, test using the flash_pd.py script to write zinger RW using
VDMs.
Change-Id: I48352978d8c45f78e8a5a7735d65b013a853f3e2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210746
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As per the PD spec, give up on sending source cap packets
after nCapsCount number of attempts.
BUG=chrome-os-partner:28341
BRANCH=none
TEST=Connect samus to an unplugged zinger. Samus recognizes
a device has been plugged in and sends source cap for 5
seconds (50 attempts at 100ms retry period), then stops
sending source cap but remains in discovery state providing
VBUS.
Change-Id: I0aa25263f200299a0eb8d219883f825ae655129c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211335
