This commit adds support for a common framework for PWM controlled LEDs.
If there are multiple LEDs, they will all follow the same pattern. The
pattern is such that it follows the Chrome OS LED behaviour
specification, essentially a similar version of led_policy_std.c but for
PWM controlled LEDs.
To use this framework, a board must do the following:
- First, define the number of logical PWM LEDs which will be controlled
by this common policy, CONFIG_LED_PWM_COUNT.
- Then declare those logical LEDs and define the PWM channels that
comprise those LEDs. (struct pwm_led pwm_leds[]).
- Next, define what each color should look like (struct pwm_led
led_color_map[]).
By default, the colors follow the recommended colors in the LED
behaviour spec, which assume an LED with a red and green channel. If a
board differs or wishes to change the colors in general, they can
redefine the colors (CONFIG_LED_PWM_*_COLOR) as they see fit. The
colors must be one in enum ec_led_colors. These colors are the ones
that can represent the charging state, SoC state, etc.
BUG=b:69138917,chromium:752553
BRANCH=None
TEST=make -j buildall
TEST=Enable led_pwm for meowth, and verify that LEDs behave as expected.
Change-Id: I945b86a7f8ed30df58d7da835d83577192548bea
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/888220
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
GCC 6.3 can't tell that we enforce the variable 'size' being set,
so initialize it to 0 to make the warning go away. The code does
actually verify that size is set, but not by checking the size
variable itself.
util/cbi-util.c: In function 'main':
util/cbi-util.c:139:8: error: 'size' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
buf = malloc(size);
^~~~~~~~~~~~
util/cbi-util.c:233:11: note: 'size' was declared here
uint32_t size;
^~~~
BUG=b:72609872
BRANCH=None
TEST=Build with coreboot toolchain.
Change-Id: Ide41a0fce40254f2fa3a8626dec75840a728d967
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/890703
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
The HPD pins for meowth and zoombini go from the EC to the AP. This
commit drives the HPD correctly.
BUG=b:72413020
BRANCH=None
TEST=Flash meowth; Use a couple charge-through hubs, unplug HDMI cable,
replug, verify AP sees new DP sink.
Change-Id: Ie1f86378c59fc4a717edc537ff8afe01b21d9b68
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/888226
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
touchpad can be powered off when the USB interface is disabled
without setting the remote wake feature
(USB_REQ_FEATURE_DEVICE_REMOTE_WAKEUP), as events would be ignored
anyway.
BRANCH=none
BUG=b:72683995
TEST=touchpad is disabled when lid is closed.
Change-Id: I688fce16ab8c75330e588ec130fb2aa499fc0ed1
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897069
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Keyboard matrix scanning can be disabled when the USB interface is
disabled without setting the remote wake feature
(USB_REQ_FEATURE_DEVICE_REMOTE_WAKEUP), as events would be
ignored anyway.
BRANCH=none
BUG=b:72683995
TEST=keyboard matrix scanning is disabled when lid is closed.
Change-Id: I0b2346cc3426b9ef51127424f9953fd5c20ecd49
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897068
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch makes EC enable PD communication if it's running in
manual recovery mode. This is required to show recovery screen
on a type-c monitor.
This patch also makes EC-EFS ignore power availability. It will
make EC verify & jump to RW even if power is sourced by a barrel
jack adapter. This should allow depthcharge to show screens
(e.g. broken, warning) on a type-c monitor.
BUG=b:72387533
BRANCH=none
TEST=On Fizz with type-c monitor, verify
- Recovery screen is displayed in manual recovery mode.
- Critical update screen is displayed in normal mode.
- Warning screen is displayed in developer mode.
Monitors tested: Dingdong, Dell S2718D
Change-Id: Ib53e02d1e5c0f5b2d96d9a02fd33022f92e52b04
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/898346
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Host command handler prints every single host command except when
commands are repeated back-to-back. Some commands do not provide
useful info when studying feedback reports or what is worse they
may hide critical info by flooding the EC log.
BUG=chromium:803955
BRANCH=none
TEST=Observe 'HC 0x115' is not printed.
Change-Id: I4901b27bbfedd54dc0d364b16c49d4ed0dea0fc4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/896694
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Because H1 monitor tx/rx signals to detect servo board,
so we can't pull-up tx/rx or the DETECT_SERVO of H1 will
be always high even the servo board isn't connected.
BUG=none
BRANCH=none
TEST=H1 detect servo board correctly.
Change-Id: I2f2dfa220ed77478e6e622a0ed1189f559044aa3
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/897315
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To avoid issues where adapter would drive against OTG of lid or
base, and to make sure that we do not over-current the adapter,
we disconnect the base/lid power transfer whenever a new
adapter is connected.
We reenable power transfer as needed.
We also separate out base current control as a new function,
that allows us to record the previous base current only when
the base charge control command is successful, and ignore
errors until the base is responsive for the first time.
Finally, we make sure that
charge_allocate_input_current_limit is only called from a
single location in charger_task.
BRANCH=none
BUG=b:71881017
TEST=Plug/unplug base, reset lux EC, connect charger.
Base is detected, power allocation works as expected.
Change-Id: I8b206d5b0fbcf0fe868b56a0336745aebe2a6dc2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/880021
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change creates a state machine to handle ap uart detection. It
removes all of the ap_uart stuff from ap_state.c and moves it to
ap_uart_state.c. All boards will now use ap_uart to enable/disable ap
uart and tpm_rst_l to detect the ap state.
Separate ap uart detection from ap detection, so we can disable the ap
uart without enabling deep sleep. If the ap is in S3 on ARM devices,
Cr50 wont be in deep sleep, but the AP UART RX signal wont be pulled up.
In this case we need cr50 ap rx to be disabled and deep sleep to be
disabled.
BUG=b:35647982
BRANCH=cr50
TEST=run firmware_Cr50DeviceState on scalet and electro
Change-Id: I81336a9e232df8d44b325eef59327a1c06a80cba
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/884307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If during PMIC initialization, it is identified that there was a VR
fault, then dump fault registers 0x16 and 0x17 to EC console. This
information is very useful during debugging sudden power losses in
field and so it is printed out to EC console.
Additionally, add panic reason with these register values as panic
data so that OS can provide this information in cros ec
panicinfo. This helps in retaining the information even if EC console
logs overflow.
BUG=b:65026806
BRANCH=eve
TEST=Verified that on a VCCIO shutdown, PMIC VR fault is
reported: "PMIC VRFAULT: PWRSTAT1=0x80 PWRSTAT2=0x00"
Change-Id: I583e513f865aeefc7dfc9860ce0ce9789808dea2
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/896163
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
In particular, this will allow touchpad driver and keyboard matrix
scanning to be powered off/disabled when the USB interface is
disabled without setting the remote wake feature
(USB_REQ_FEATURE_DEVICE_REMOTE_WAKEUP), as events would be
ignored anyway.
BRANCH=none
BUG=b:72683995
TEST=With next CLs, touchpad and keyboard matrix scanning are disabled
when lid is closed.
Change-Id: I3750bfaf8c31cde075adf9da4fef39753b8981c5
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897067
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change the EC to drive the Hotplug Detect (HPD) GPIOs.
Grunt HW has these driven from EC to SOC, unlike coral which had
the TCPCs drive the HPD signals to SOC.
BUG=b:71810897
BRANCH=none
TEST=external display works using USB-C to DP adapter on both ports
Change-Id: I22ec9eecc5bdf9c6463dd3ce208d051faf15c57a
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/892099
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
This patch makes EC_CMD_SET_CROS_BOARD_INFO return
EC_RES_ACCESS_DENIED if the command fails due to write-protect
switch.
BUG=b:70294260
BRANCH=none
TEST=Verify 'ectool cbi set 2 4' prints 'WP enabled?' when WP
is enabled.
Change-Id: I7c27ee748caf32e57f22ab79edcbff96e42c44ad
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897683
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Automated code scanner highlighted a few problems in the recent ode
additions. This patch fixes the problems.
BRANCH=cr50
BUG=none
TEST=none
Change-Id: I1f199eb5d2af992384ab04f3010b4b646464a70f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/897993
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
CONFIG_USB_PD_DISCHARGE is now defined automatically if you specify one of
the specified options such as CONFIG_USB_PD_DISCHARGE_TCPC
BRANCH=none
BUG=none
TEST=grunt still discharges using PPC
Change-Id: I94086cfc58bebce9c62ad6aa52b7740b25276d89
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894676
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Based on measurements, Soraka can pull more current than desired.
Decrease the programmed current limit by an additional factor,
determined by taking the worst-case power measurements across several
different Soraka devices, to ensure that Soraka never pulls more
current than desired.
BRANCH=None
BUG=b:67944740
TEST=Verify with `charger` that input current limit becomes 472mA when a
5V / 500mA charger is plugged, and 2896mA when a 5V / 3000mA charger is
plugged.
Change-Id: I2b2cb6f445533476d173cd7f5fb825d8b11d1405
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/890102
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Benson Leung <bleung@google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Prevents a null pointer dereference when the AP asks the EC
for nonexistent settings of a sensor.
BUG=chromium:761758
TEST="ectool motionsense offset ${ID of baro_bmp280 sensor}"
And see no null pointer dereference, but an invalid command error
BRANCH=master
Change-Id: I3050feaa3c9752abebc30237dac1befa4e5775cc
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/850639
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The ISL923x init function would initialize the charger's input current
to the board's defined default. For some boards like meowth and
zoombini, the default input current was set quite low, 128mA. When
sysjumping, all HOOK_INITs are called again and therefore the input
current limit would be reset even thought it would have been set
correctly prior to jumping. Setting the current limit so low, without a
battery, would cause a power failure and the PMIC would drop its power
OK signal and go into emergency shutdown.
This commit simply adds a check to whether the EC jumped to this image.
If it has, the charger input current limit is left unchanged. It will
be updated to the correct value by charge manager later on after
determine the attached charge supplier.
BUG=b:72129338
BRANCH=None
TEST=Flash meowth; Boot to S0 without a battery; Verify that PMIC_DPWROK
remains high.
TEST=Repeat above test for zoombini.
Change-Id: I7e5bbbbf3ec604c876cc4fa0163f8bb7feff4cc9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/896960
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
If the sn5s330 PPC is being used to detect VBUS presence
(CONFIG_USB_PD_VBUS_DETECT_PPC), then enable interrupts and call
usb_charger_vbus_change when VBUS_GOOD changes.
BUG=b:72007153,b:72007492
BRANCH=none
TEST=Connect 3A and 1A USB-A chargers to each of Grunt's USB-C ports,
check that BC1.2 detection is working:
With 1A:
> chgsup
port=0/1, type=7, cur=500mA, vtg=5000mV, lsm=1
With 3A:
> chgsup
port=0/1, type=7, cur=2400mA, vtg=5000mV, lsm=1
TEST=Boot Grunt to OS, then connect USB2 mouse or USB3 flash drive to each
of Grunt's USB-C ports. Devices do not work due to b:71772180, but gpioget
shows EC is setting USB_C0/1_BC12_VBUS_ON_L correctly.
Change-Id: Iffc352105a321997adb364b9fbb8bafef248c224
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/887938
Reviewed-by: Jett Rink <jettrink@chromium.org>
Meowth also seems to take enough power when flashing without a battery.
Zoombini has a similar issue, and the fix is to wait 1s to let the
voltage level stabilize before flashing.
This commit just waits 1 second before flashing.
BUG=b:65694390
BRANCH=None
TEST=./util/flash_ec --board meowth; Verify it succeeds without a battery.
Change-Id: Ida34a7eb923187940afe05a32d200b48e71aaa9f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/894370
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
Flash operations in do_flash_op() involve waiting polling for the chip
to complete the operation. If a concurrent operation is started while
another operation is in progress, flash gets confused and locks up.
Let's add a mutex to ensure that flash operation runs to completion
before another operation starts.
BRANCH=cr50
BUG=b:67651754
TEST=multiple times ran firmware update while the device was coming up
and saving TPM status in NVMEM. Observed no failures.
Change-Id: I777a38f8a63cf17d60edb11cc3f916a4ea904741
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894180
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
- Add a vendor command that provides alert counter. Userspace can use
it e.g. for user metric analysis.
- Add 'alerts' debug console command. It provides information about
chip alerts: supported alerts, fuse status, interrupt status, alert
counter.
- Add 'alerts fire [INT]' command to fire a software defined alert
(globalsec/fwN where N is 0,1,2,3).
Signed-off-by: Anatol Pomazau <anatol@google.com>
BUG=b:63523947
TEST=ran the FW at Pyro and checked alerts data sent to host
Change-Id: I7cec0c451ed71076b44dad14a151b147ff1337e8
Reviewed-on: https://chromium-review.googlesource.com/817639
Commit-Ready: Anatol Pomazau <anatol@google.com>
Tested-by: Anatol Pomazau <anatol@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Boards with a PPC will use the PPC to discharge the VBUS line instead
of the TCPC or GPIO discharge path.
BRANCH=none
BUG=b:72179253
TEST=Fall time after device removal on grunt within spec now
Change-Id: I822923a1cedb32a20efc3610cce4437ade3387f0
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/886563
Reviewed-by: Edward Hill <ecgh@chromium.org>
Templates for USB isochronous implementation. Current implementation
only supports TX transmit. Example of usage can be found in CL:803414.
Basically, declare an USB isochronous interface by
USB_ISOCHRONOUS_CONFIG_FULL(<NAME>,
<INTERFACE_NUM>,
<USB_CLASS>,
<USB_SUBCLASS>,
<SUB_PROTOCOL>,
<USB_STR_FOR_INTERFACE_NAME>,
<USB_EP_NUM>,
<PACKET_SIZE>,
<TX_CALLBACK>,
<SET_INTERFACE>)
where <PACKET_SIZE> is size of each USB packet, <TX_CALLBACK> is called
when USB hardware has completed a packet. The buffer that USB is not
currently using will be passed to <TX_CALLBACK>, allow applications to
write next packet to it.
When a SET_INTERFACE packet is received, <SET_INTERFACE> will be called
with bAlternateSetting and bInterfaceNumber.
We will declare interface descriptor with bAlternateSetting = 0 and 1
for you, if you need more alternate settings, you need to declare by
yourself.
BUG=b:70482333
TEST=manually on reworked staff board
Signed-off-by: Wei-Han Chen <stimim@google.com>
Change-Id: Ic6d41da6ddd7945edf0bdfff55ede38a97661783
Reviewed-on: https://chromium-review.googlesource.com/818853
Commit-Ready: Wei-Han Chen <stimim@chromium.org>
Tested-by: Wei-Han Chen <stimim@chromium.org>
Reviewed-by: Wei-Han Chen <stimim@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
On VM-based builders, the nvmem unittest was sometimes missing the
10-second deadline, likely being stuck in slow I/Os.
Try to move the persistent storage files used for flash 'emulation' on
host from the build directory to a RAM-backed filesystem in /dev/shm
in order to mitigate this bottleneck.
Store the new backing files in a path like:
/dev/shm/EC_persist__mnt_host_source_src_platform_ec_build_host_nvmem_nvmem.exe_flash
in order to keep the properties of the old system:
subsequent runs of the same build will use the same persistent storage
but 2 different trees won't mix up.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:715011
TEST=make runtests
TEST=run the following command with and without this change:
'for i in 0 1 2 3 4 5 6 7 8 9 ; do time make run-nvmem ; done'
and see the average test time around 500 ms without the change
and around 320 ms with it on an idle and beefy workstation.
Change-Id: Ic2ff6511b81869171efc484ca805f8c0d6008595
Reviewed-on: https://chromium-review.googlesource.com/893380
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This allows the acpi_light sysfs entry to be populated with the actual
ALS data.
BUG=b:70290036
BRANCH=None
TEST=Flash meowth; read both illuminance values for the ALS devices
under iio and verify that they are both operational.
Change-Id: Ia22633629195d5bdeedc70a908ceca1411110b7d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/888218
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In the system, RT946x is always powered by the battery.
So even in battery cutoff mode, the reg values on RT946X are not reset.
We don't want RT946x to supply VBUS when DUT boots, which could mess up
PD state. So we need to disable VBUS output when RT946x initializes.
BUG=b:72228350
BRANCH=none
TEST=Confirm OPA_MODE (bit0 in reg 0x01) is clear after RT946x
finishes initialization
Change-Id: I32795b3bea64860b164c14b06aa1cd2551ebd8a0
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/890028
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
rt946x_block_read() is not implemented right.
It not only makes rt946x_init_irq() fail but also put
RT946x i2c module in an erroneous state temporarily.
BUG=b:72228350
BRANCH=none
TEST=manually on scarlet rev3:
1)Insert Plugable USB-C hub w/o AC
2)Run cutoff command on ec console
3)Hold Pwr button for a few seconds to wake up DUT
4)Repeat 2 - 3 for 10 times without seeing PD loops
Change-Id: I9304617f924e44288483afca5ab1b2923eb68ff0
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/890027
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
It's no longer necessary to call board_tcpc_init() from PD tasks, since
HOOK_INIT completion is guaranteed before the task starts. Also, calling
board_tcpc_init() for each PD task without a port arg is a bad idea.
BUG=b:72229154
BRANCH=none
TEST=`make buildall -j`
Change-Id: I6fba07771693b8343568041960a263e02775a8fc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/881538
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
stm32f0 has 20 bytes (not 20 words) of VBAT-backed RAM. Make more
efficient use of our limited storage to prevent trying to use storage
that doesn't exist.
BUG=b:71333840
BRANCH=None
TEST=Negotiate PD, run "reboot" on scarlet EC console, verify reset path
is taken in pd_partner_port_reset().
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie4c303b74a1b82b84ec971cdcc19c2b21a0032e7
Reviewed-on: https://chromium-review.googlesource.com/885461
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
