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
* Changed chip in build.mk
* Renamed the Port H pins
* Switched to 32bit timer
* Remapped UART DMA Channel
BUG=None
TEST=Flash the new chip; UART Debug, SPI HC, I2C Battery should work. Everything
else should work (besides power usage)
BRANCH=None
Change-Id: Ia73f3f6b4e8b7b42af4dfa592b7ff435ee379206
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210522
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
After sending a message, we wait for up to 2.7 ms for reply. If we don't
get one, we retry for up to twice. Therefore, a undelivered message
could take up to >8ms. To prevent starving other tasks, let's yield to
other tasks on retries and rely on interrupt to wake us.
BUG=chrome-os-partner:28341
TEST=Plug in zinger on port 0 and C-to-A dongle on port 1. Check that
port 0 drops connection less frequently.
BRANCH=None
Change-Id: If85a70fd1140fef69d79243b198703ce601f8030
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211281
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When PD state changes, log the state transition. Also, now that we have
the state logged, logging pings doesn't help us anymore, so stop logging
them to make console clean.
BUG=None
TEST=Run on samus_pd. Plug/unplug zinger. Check state is logged and
pings are not.
BRANCH=None
Change-Id: Ib482b3351d9681fbb4bcc2585da58c732428b7af
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211262
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ACPI and thermal throttling are used only by x86 platforms.
Modify the conditional build to avoid building them where they are not
used.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
check the flash size on Ryu and see we are saving about 200 bytes with
this changes.
Change-Id: Ie5e1603fb3bea95eaa5cb1e6cb19f4ddb0e235e8
Reviewed-on: https://chromium-review.googlesource.com/210056
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a preparatory work for USB PD unit test. With this, we won't
need to duplicate these constants in both the implementation and the
test.
BUG=chrome-os-partner:31200
TEST=make buildall
BRANCH=None
Change-Id: Ia814a95450859caaa6d90e4cd866cb671d010b31
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211653
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
I2C reads from the PD happen in two separate transactions, but no stop
condition is set after the first transcation. Therefore, it is necessary
to lock the I2C bus across both transactions to prevent other tasks
from using the bus in between.
BUG=chrome-os-partner:29839
TEST=Manual on Samus. Boot to recovery screen, plug + unplug power
supply, verify that no I2C error messages are printed to console.
Then repeat 100x.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie441637f499980a349022e281379ad2cc825b1aa
Reviewed-on: https://chromium-review.googlesource.com/211649
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Set input current limit based on the max current from the
PD negotiation. For samus, this information is passed to
the EC as a host command. For ryu, the max current is set
directly following a negotiation.
CONFIG_CHARGER_INPUT_CURRENT is now just the default limit,
but after a successful PD negotiation, the limit can be
raised.
Note, for now the input current limit for samus is set to
2/3 of the value negotiated for. This is due to hardware
problems measuring input current on p2b boards.
BUG=chrome-os-partner:28532, chrome-os-partner:24461
BRANCH=none
TEST=tested on a samus. Verified input current limit using
"charger" console command from EC. Input current limit
after a reboot is 512. When zinger is plugged in, it jumps
to the appropriate value (currently 1280mA), and when
the negotiation is changed using the "pd 0 dev 5" command
on the PD console, the input current limit is adjusted to
match (2000mA).
Change-Id: Iab9186a0f9814655e3240217a9baf4a38f15f84d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211023
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change USBC port 1 PD comparator to use window mode, which
uses COMP1's non-inverting input for COMP2's non-inverting
input (pin PA1). This allows us to free up pin PA3 and PA7
for the next build.
BUG=chrome-os-partner:31215
BRANCH=none
TEST=make sure PD communication works on both ports by plugging
in a zinger. Then set gpioset USB_C0_REF_PD_ODL 1, to change
comparator voltage to 1.5 V and verify that neither port works.
Then gpioset USB_C0_REF_PD_ODL 0 and gpioset USB_C1_REF_PD_ODL 1
and make sure that both ports work. This proves that both ports
are using USB_C0_REF_PD_ODL as the comparator value (PA1).
Change-Id: I6e1e5606af43196b04c84417552002b063aa4134
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211416
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
HAS_TASK_HOSTCMD is not a good indicator that we intend to use I2C Host Commands
On platforms such a veyron we use an STM32F0 with SPI HC for example however
i2c-stm32f0.c was very eager to still provide host commands via I2C.
If one wants to use I2C host commands they need to define
CONFIG_HOSTCMD_I2C_SLAVE_ADDR anyway, so the presence of that is a better
indicator.
The boards that want I2C host commands are ryu and samus_pd.
veyron/pinky needs SPI host commands, so this patch makes this case possible.
The rest of the boards that use STM32F0 do not have HAS_TASK_HOSTCMD set.
BUG=None
TEST=make buildall -j
BRANCH=None
Change-Id: Ia5561afdc6e72019c24c5c4b775944b2b88cb950
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211434
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The STM32F0 has a fancier SPI than the L1 series we've been using so far.
Notably it supports 16 bit data packing. This mode is activated automatically
by reading/writing to the SPI_DR register as 16 bits. We do not want this
feature since we only do 8 bit operations. This change prevents a misalignment
of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit
transfers.
Another unwanted feature is the FIFO. We rely on DMA and some buffers instead.
Keeping the FIFO enabled causes extra characters. The way this patch disables
the fifo is by changing the FIFO reception threshold to only 1 byte (which is
the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1
chips should not affect anything as that area of the register is reserved.
BUG=none
BRANCH=none
TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and
STM32F0(new support/veyron)
Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211476
Reviewed-by: Doug Anderson <dianders@chromium.org>
Added a check for if we are in RO and write protect screw is
present which will stop the PD task to prevent PD communication.
By default this check is disabled since the p2 samus units do
not have access to WP screw. This check will need to be enabled
for EVT.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=enabled the check, loaded on a p2 samus, and verified
that in RO, the console prints out "PD not allowed" and there
is no communication with an attached zinger. Then ran "sysjump
RW" and verified that power negotiation with zinger succeeded.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I5007db659d8b057431426157a2150127b97a7b3f
Reviewed-on: https://chromium-review.googlesource.com/211020
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
