Similarly to what we have done with keyboard events, we put touch
events in a FIFO. The AP will need to interpret the timestamp
in the events to be able to process the events correctly tough.
Resume should typically take about 50ms, so a 8-event long FIFO
should be good enough. Also, we bypass the FIFO altogether in most
cases, when the USB interface is not suspended.
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Look at evtest output.
Wait a second, make a swipe, see that events are received in
a very short amount of time after resume (every EP interval/2ms),
but the event timestamps show that some of them are older.
Change-Id: If6ab56396f7d564b19e6c3c528847196ffa4d849
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/612221
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We use the unofficial, Windows 8, Relative Scan time HID usage
(Digitizer page, 0x56) to add timestamps to our HID touchpad
events.
The timestamps is a rolling, unsigned, 16-bit integer, with a
resolution of 100us (so it wraps around every 6.5s).
The host will be able to synchronize to that timestamp, resetting
an offset every time the touchpad is quiet a certain amount of
time (e.g. 1 second).
BRANCH=none
BUG=b:63685117
TEST=Flash hammer, timestamps are reported in HID descriptor.
Change-Id: Ie5d56a9df14e464d2cdcd559f550d6e3cc81961f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/603041
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Put key events in a FIFO. This is especially useful when USB is
suspended, so that we can replay the events on resume. This makes
sure that no key strokes are lost on resume from USB autosuspend.
We coallesce events happening within some interval (18 ms), greater
than EP interval (16 ms) to ensure we cannot have a backlog of keys.
The interval must also be short enough to ensure that the intended
order of key presses is passed to AP, and that we do not coallesce
press and release events (which would result in lost keys).
We also discard key events in the FIFO buffer that are older than
1 second. Note that we do not fully drop them, we still update
the report, but we do not send the events individually anymore
(so an old key press and release will be dropped altogether, but
a single press/release will still be reported correctly).
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Wait a second, type something quickly, verify that no keys are lost.
Change-Id: I64d33c15a39ae33af42039fba62cf4ed3abef462
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/471188
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As suggested in CL:411741, makes the follow-up CL that buffers
key strokes much simpler.
We can revisit later if we can still sneak it that change, but,
all in all, we can guarantee the same key latency by halving the
USB endpoint interval.
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, keyboard works.
Change-Id: I6624fde9bd5561ddceb7ce195470d7af7cca7140
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/471187
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some USB interface handlers need to know when USB has been
successfully resumed after a wake event. For example, this is
useful so that HID keyboard can send the events at the right time.
BRANCH=none
BUG=b:35775048
TEST=Using USB HID keyboard patches to queue keys in a FIFO:
After USB autosuspends, press a single key and hold it. Without
this patch the endpoint data only gets reloaded on the _next_
event.
TEST=On hammer, I2C passthrough still works.
Change-Id: I9b52b9de16767c8a66c702a5ae70369334a3d590
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/569547
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The command "hostcmd" in console isn't very useful and will cause
stack overflow in console task when processing some hash commands.
BUG=chromium:755048
BRANCH=none
TEST=make BOARD=elm -j
make BOARD=elm tests
There should be no hostcmd command in the console of elm.
Change-Id: Ifa721a1731bc1ebfb39e12430b6631338bdccd9f
Signed-off-by: Che-yu Wu <cheyuw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616600
Reviewed-by: Rong Chang <rongchang@chromium.org>
Handle the case of comparing with different kinds of objects.
BUG=none
BRANCH=none
TEST=extra/stack_analyzer/stack_analyzer_unittest.py
Change-Id: I01056cd39e14d75442d4029b6c64d9843c49cf2a
Signed-off-by: Che-yu Wu <cheyuw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616367
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This way, when HOOK_CCD_CHANGE triggers, the debug message is printed
before any of the effects of the change due to other hooks.
No effect on the rest of the code.
BUG=none
BRANCH=cr50
TEST=manual in CR50_DEV=1 image
ccdlock
ccdoops
"CCD change hook called" should be seen before "Enabling I2C" or
"Disabling I2C" messages.
Change-Id: I2e083b70fe8ac3938abc56e14b5e50fe9e237752
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616179
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
When servo_v4 acts as a debug test system (DTS) its expected use
case is for triggering CCD mode and Faft testing. To that end, its
desired default data role is to be a UFP so that the enet and USB
port are accessible by the DUT. However, when servo is acting a
regular SRC port, it makes more sense for the data role pairing to
be consistent with a normal SRC port device which is SRC/DFP.
BUG=b:64720447
BRANCH=servo
TEST=Tested with Eve using twinkie USB PD analyzer. Verified that when
DTS mode is enabled a data role swap request is sent to the DUT and
when DTS mode is disabled that servo_v4 does not send a data role swap
request.
Change-Id: I071f85fc99f1c877d86ef48ec7fa38d6850d5679
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/615813
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
To enable console with DMA, we need to specifically
remap DMA channels for USART1.
ch2/3 and ch6/7 are already used by SPI1/2 modules.
So we have to remap USART1_TX to ch4 and USART1_RX to ch5.
BUG=b:64575809
BRANCH=none
TEST=confirm ec console works on scarlet rev1
Change-Id: Ie2bb141c72252aee98e4cd4a284a01b4d57605f4
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/611147
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Indentation is growing out of control, let's move to a separate
function so that we can return early.
BRANCH=none
BUG=b:35775048
TEST=Flash hammer, usb_wake works.
Change-Id: I9abf99ff55b3977dfc307fc99aac6f1ab7dd1f6a
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/612922
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a shared library to export task information.
Modified the stack analyzer to get information from the shared library.
Show allocated stack sizes of tasks in the stack analyzer.
To get the all task information (including the allocated stack size),
A shared library is added and compiled with the board to export all
configurations of the tasklist.
BUG=chromium:648840
BRANCH=none
TEST=extra/stack_analyzer/stack_analyzer_unittest.py
make BOARD=elm && extra/stack_analyzer/stack_analyzer.py \
--objdump=arm-none-eabi-objdump \
--addr2line=arm-none-eabi-addr2line \
--export_taskinfo=./build/elm/util/export_taskinfo.so \
--section=RW \
./build/elm/RW/ec.RW.elf
make BOARD=${BOARD} SECTION=${SECTION} analyzestack
Change-Id: I72f01424142bb0a99c6776a55735557308e2cab6
Signed-off-by: Che-yu Wu <cheyuw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/611693
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The center supply is fixed to .9V on nefario, it had not the
enable pin for controlling.
Also the Nefario unused the led for battery.
BUG=b:63408169
BRANCH=none
TEST=Tested on nefario, check the gpioget
Change-Id: I339ce2cb2fb530cec393a352d920ea21fd8a8464
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/612969
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Add a static analysis tool for firmware stack usage.
Add an new Makefile rule to analyze the stack usages of firmwares.
Details about the tool can be found in extra/stack_analyzer/README.md.
BUG=chromium:648840
BRANCH=none
TEST=extra/stack_analyzer/stack_analyzer_unittest.py
make BOARD=elm && make BOARD=elm build/elm/RW/ec.RW.taskinfo && \
extra/stack_analyzer/stack_analyzer.py \
--objdump=arm-none-eabi-objdump \
--addr2line=arm-none-eabi-addr2line \
./build/elm/RW/ec.RW.elf ./build/elm/RW/ec.RW.taskinfo
make BOARD=${BOARD} SECTION=${SECTION} analyzestack
Change-Id: Ifb1b5f5ad6be8f8b125b14d6ee03e25cb385895b
Signed-off-by: Che-yu Wu <cheyuw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/576411
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
There isn't enough flash space after 'repo sync',
so disable one more console command.
BRANCH=none
BUG=none
TEST=build reef_it8320 and all.
Change-Id: I370e06d5de211b7de669f35071c680d28efb7c17
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/612001
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the SRC_READY state, we'll only request sink caps if we haven't
received them yet and only if its the first transition to the state.
However, we also don't send any PD traffic in that state if there's an
incoming message in order to prevent a collision. This could create a
scenario where upon entry to the SRC_READY state, a message is incoming.
When this occurs, we never request the sink caps.
This commit simply removes the condition that we may only request sink
caps on the first transition to the SRC_READY state.
BUG=b:64037926
BRANCH=gru
TEST=Flash kevin; Connect to a DR port partner; Verify that sink caps
are requested even after the first transition to the SRC_READY state.
Change-Id: I6bc9ad01d45e6584a7a14b28806ae4872a22d98f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/611320
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT is defined for a board, as
its name implies, the board can source a higher current if there is
only one port acting as a source.
This commit fixes an issue with selecting the right source capability
message to advertise. charge_manager_get_source_pdo() was simply
checking if there was more than one sink connected, instead of checking
if there were any *other* sinks connected. In the event that a sink
was connected to a different port, we would advertise the max source
PDO.
BUG=b:64037926, b:35577509
BRANCH=gru,eve,reef
TEST=Connect sink to port 1. Connect a AMA to port 0 that claims that
VBUS isn't necessary. Start sending source caps, verify that the max
PDO is not being advertised in the source caps.
Change-Id: Ie4145ecaf98d5b9070ad3e8b139e5653685fa801
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/610479
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
As can be seen in <http://crosreview.com/610449> the IDs of PWMs are
directly referenced by the kernel device tree on gru / kevin / nefario
boards (technically also in bob and scarlet-rev0, but neither of those
is supported by mainline EC code). Because of the kernel reference
it's not a great idea to change the IDs.
Let's add a comment so people don't change the ordering / IDs
accidentally.
NOTE: we can have a big argument here about whether it would be OK to
change numbering _and_ change the numbering in the kernel at the same
time. We can talk about whether the device tree is a binary and about
whether this constitutes an ABI since Chromebooks don't ship the
device tree binary separate from the kernel. We can talk about all
those things. ...but we won't. There's no good reason to change the
ID, so just don't do it.
BRANCH=None
BUG=b:63537905
TEST=None
Change-Id: Iacdedc1c91e583183034d15e99735a470d6e0951
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/610933
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Allow TPM to log events in a circular buffer through tpm_log_event().
Logs can be retrieved through a new vendor command
VENDOR_CC_POP_LOG_ENTRY.
BUG=b:63760920
TEST=On eve, store TPM logs through 'logentry' cr50 console command,
verify logs are fetched correctly through 'trunks_send --pop_logentry'.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idbc405728c0ba68078447fb59717d6115830e3d8
Reviewed-on: https://chromium-review.googlesource.com/599352
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In the field, we want to update touchpad FW using the same USB
update protocol as the main EC FW.
To distinguish between EC FW update and touchpad FW update, we
use a virtual address, defined by CONFIG_TOUCHPAD_VIRTUAL_OFF,
that does not map to anything on the EC chip.
Also, this will allow us to verify hashes of each block of the
flashed touchpad firmware, so that we can ensure its integrity
before flashing it into the touchpad. A stub is implemented in
update_fw.c:contents_allowed.
BRANCH=none
BUG=b:63993173
TEST=With follow-up CLs, ./usb_updater2 -p 144.0_2.0.bin
Change-Id: I4de1d7d138fc01fe1552a4173c8ef208ecb834a7
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593373
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Poppy uses 0x00 reg for manufacturer access and shutdown data 0x10
just like Soraka battery. Fix the macros for poppy.
BUG=b:64460667
BRANCH=None
TEST=Verified that battery cutoff by smb command works on poppy.
Change-Id: I5e568a31a575bc0e403362e48e64a753c094dab1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/609553
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Now that we have a custom battery presence function, we do not need
the disconnect behavior as it will recover better by letting the state
machine handle it with precharge directly.
Without this change, EC was stuck in "battery found in disconnect
state" after battery cut-off.
(Reference: https://chromium-review.googlesource.com/c/582538)
BUG=b:64370648,b:64460667
BRANCH=None
TEST=manual testing with cut-off batteries shows more consistent
behavior to boot AP after plugging in adapter.
Change-Id: I8d1072d29c42e5b10b133d880897287882bd698b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607036
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Just checking for battery present gpio is not sufficient to determine
the state of the battery. On the lines of the changes made by Eve, add
a new battery_is_present function which:
1. Checks hardware gpio signal to determine if battery is present
2. If yes, then checks following if its status just changed to present:
a. Battery is not in cut-off state
b. Battery is not in disconnect state (charging and discharging
disabled)
c. Battery initialization is complete
Only if all the above conditions are true, then battery is considered
as present.
BUG=b:64460667,b:64370648
BRANCH=None
TEST=Verified that with this change recovering system from battery
cut-off is more consistent.
Change-Id: I10abdf603e01f404c9b8e2094e36bc068adf5450
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607035
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When battery is cutoff, it might at times require some current to be
applied to it so that it can wake up. Thus, in case where all battery
flags indicate error in charger_profile_override, set
requested_current and requested_voltage to precharge_current and
voltage max. This allows the battery to be woken up.
BUG=b:64370648,b:64460667
BRANCH=None
TEST=Verified that on connecting AC power after battery-cutoff, there
are no "try to wake battery" messages anymore.
Change-Id: Ib88369238b492994d8310655126e19bc7e347a0c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Instead of going to hibernate when the battery is critically low
we should cut off power entirely.
Even with the PMIC shut down the H1 chip consumes more power than
is healthy when the battery is already critically low, depleting it
to dangerously low voltage levels faster than it should.
(Reference: https://chromium-review.googlesource.com/582543)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC cuts off battery when it is
critically low instead of hibernating on soraka.
Change-Id: I3befd583df64c44d43d73cda69a6486219578192
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605015
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
If board selects both CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF and
CONFIG_HIBERNATE, then CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF should
be given higher preference when deciding what action to take in case
of critical battery.
This is necessary on boards where components like H1 chip could be
consuming more power than is healthy when the battery is already
critically low, depleting it to dangeriously low voltage levels faster
than it should.
(Reference: https://chromium-review.googlesource.com/582543)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC cuts off battery when it is
critically low instead of hibernating on soraka.
Change-Id: I6efacd7206199ca19f1073296b113b6cf18ec655
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605014
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With a battery that has 1% charge there may not be enough to boot the
AP, resulting in a brown out. Raise this to 2% to get more consistent
behavior to let the battery charge before booting.
(Reference: https://chromium-review.googlesource.com/582540)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC does not attempt to boot the AP
unless the battery charge is >=2%.
Change-Id: I2c3d0e292470d44ffd8fd33e8a58c59a19548513
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605013
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
These config options change the behavior of charge_prevent_power_on
and ignore the minimum battery percentage for booting. Since we don't
have any AP code to actually handle this state, we don't want it to
always boot the AP or it might brown out with a battery that is
critically low.
(Reference: https://chromium-review.googlesource.com/c/582539)
BUG=b:64460667
BRANCH=None
TEST=manual testing with low battery to ensure it does not attempt to
boot the AP.
Change-Id: I670a2bf7eba4354ae522d1ea2423c90ff07f5ea6
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605012
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The board ID fields are displayed by the Cr50 console command 'bid' as
follows: <board id>:<board id mask>:<board id flags>.
Make sure the user passes them in the same order when invoking the signer
to sign a board locked image.
BRANCH=none
BUG=none
TEST=verified proper order of the fields when generating and using a
prod signed image.
Change-Id: Ia4569c5e9e663b26edaa591bae881c719c4f199c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604218
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device state. It was overkill for managing the battery
present state as forwarded to the write protect pin, and split that
handling between 3 files (board.c, wp.c, device_state.c). Move all of
that logic into wp.c so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in battery (or ground DIOM2)
wp command reports WP enabled
unplug battery (or pull DIOM2 high)
wp command reports WP disabled
Change-Id: I71ab9ce5766ecddae430c63a8b31388935a46180
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604500
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device sstate. It was overkill for managing the CCD cable
(RDD) attach/detach state, and split that handling between 3 files
(board.c, rdd.c, device_state.c). Move all of that logic into rdd.c
so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in CCD cable (or ground DIOM1)
ccd command reports cable connected and AP UART TX+RX
unplug CCD cable (or un-ground DIOM1)
ccd command reports cable disconnected and AP UART disabled
Change-Id: Id8fcd3a51605ae7a4843668ea18dd0ef84aceb2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604499
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This mostly adds a bunch of comments, but does make a few changes to
the code:
1) The devices console command now prints both the current device
state and the last known state.
2) servo_state_unknown() also checks if we're bit-banging the EC UART,
since that could also cause EC_DETECT to go high.
BUG=none
BRANCH=cr50
TEST=make buildall; use 'devices' command
Change-Id: I73e7524545ef49494eb36155b99f4042c1fd466d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/602695
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
There are none cros_ec devices running EC codebase connected to
chromebook, which can be accessed by ectool with
`cros_ec --name=SOME_DEV ...`.
In the case when SOME_DEV is not found, do not fallback to other
communication methods such as LPC or I2C, since ectool will instead get
the reply of real cros_ec device.
BRANCH=none
BUG=b:64468324
TEST=on poppy, `ectool --name=cros_tp version` should show:
`Unable to establish host communication
Couldn't find EC`
Change-Id: I2ac232122e0f928703f7607da365d5c1dc6f7194
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/604977
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
