summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
* cr50: CCD Info indicates whether all CCD capabilities are default.Namyoon Woo2018-10-111-1/+13
| | | | | | | | | | | | | | | | | CR50 provides whether CCD capabilities are default or not. Factory process can utilize this value instead of CCD cap bitmap information. Users can use either 'gsctool -I' or CR50 console command 'ccd'. BRANCH=cr50_tools BUG=b:117200472 TEST=manually set and clear the password using gsctool -a -F and check the result of gsctool -I. Change-Id: Ic6be2ce880476c3a73150fe0e29007dd6a7e328f Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1272190 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* tpcp: update comments for CC status for clarityJett Rink2018-10-111-5/+5
| | | | | | | | | | | BRANCH=none BUG=none TEST=none Change-Id: I5c5c109a8cda96f62bac59a499ca619348e5e922 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1276705 Reviewed-by: Edward Hill <ecgh@chromium.org>
* cr50: minor code revision with macros regarding CCD capabilities.Namyoon Woo2018-10-111-0/+5
| | | | | | | | | | | | | | | | | | | | Defined "Number of bits in CCD cap expression", "Bitmask for a CCD cap expression", and "Number of CCD cap expressions in a Byte," and replaced constant uses with macros in CR50 and gsctool codes. No binary size changes in either CR50 or gsctool. BRANCH=cr50_ccd BUG=none TEST=manually tested with gsctool -I and CR50 console command 'ccd'. Signed-off-by: Namyoon Woo <namyoon@chromium.org> Change-Id: If91305090444395b6a938f920f4e47e2acbba886 Reviewed-on: https://chromium-review.googlesource.com/1274007 Commit-Ready: Namyoon Woo <namyoon@chromium.org> Tested-by: Namyoon Woo <namyoon@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* usb_i2c: extend protocol to allow longer writesVadim Bendebury2018-10-101-11/+19
| | | | | | | | | | | | | | | | | | | | | It is necessary to be able to send longer than 255 byte packets over the USB I2C bridge. This patch introduces a backwards compatible protocol extension to the to allow that. Namely, the top 4 bits of the byte previously used as the port number are now used as the top 4 bits of the 12 bit write counter field. BRANCH=cr50, cr50-mp BUG=b:75976718 TEST=tested along with patches modifying Cr50 and iteflash for operating over CCD. Verified that the ITE EC programming requiring 256 byte write transactions succeeds. Change-Id: I21475c8d87a6a858ff9ad96dae87388604bbbf2d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1256059 Reviewed-by: Matthew Blecker <matthewb@chromium.org>
* usb-pd: allow a task to prevent TCPC LPMJett Rink2018-10-051-0/+12
| | | | | | | | | | | | | | | | | | | If a particularly low priority task (like hooks) wants to access the TCPC, then we do not want the LPM debounce to trigger in the middle of the communication sequence. This is especially a concern if the TCPC access is on debug registers that do not push out the LPM debounce deadline. BRANCH=none BUG=b:111406013 TEST=TCPC communication on meep is much more reliable with this change. TCPC will still go into low power mode after all tasks stop preventing LPM. Change-Id: I58cee8e202ced4085f131ff86dbda9d366e1dcca Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1262107 Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
* usb_i2c: provide a way to communicate non-i2c commandsVadim Bendebury2018-10-051-0/+18
| | | | | | | | | | | | | | | | | | | | | On some occasions there might be a need to request an action from the DUT which is related to i2c operations but can not be performed through an i2c transaction. For instance when one need to generate the sync sequence on the EC i2c interface before the EC can be programmed. This patch introduces a facility which allows to register a handler for commands sent on this special address which is picked at 0x78, which becomes 0xf0 during write transaction address cycle. BRANCH=cr50, cr50-mp BUG=b:75976718 TEST=tested along with the rest of the patches to trigger generating of the ITE EC debugger sync sequence. Change-Id: I269d4b8073b0d02f96ca526f221c02c38a036f3d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1214542 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* FIXUP: mkbp: add support for board-specific host notificationEnrico Granata2018-10-041-2/+28
| | | | | | | | | | | | | | This patch improves naming and documentation for the functionality introduced in crrev.com/c/1247000 TEST=build BRANCH=none BUG=b:112366846, b:112112483, b:112111610 Change-Id: Iedd2fc5492a5d35fa9c2475fe248c5aa41e83bb0 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1258562 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* tcpc: Resume suspended ports after an intervalJonathan Brandmeyer2018-10-042-0/+7
| | | | | | | | | | | | | | | | | | | | | When it appears that the TCPC queue handling logic may be stuck in an infinite loop, the EC will break the loop by disabling the port in order to avoid task starvation. However, nothing attempts to resume the port, and it therefore remains disabled until the next EC reset. Wake back up after a reasonable interval in order to automatically retry. On port suspend, completely drain the TCPM message queue. BUG=chromium:891713 TEST=On Careena hardware, with analogix TCPC firmware v1.5 and an electronically marked cable that sends SOP' messages, verify that the EC auto-retries every second. After removing the offending cable, and PD power supply will work. BRANCH=grunt Change-Id: I563b763501333eb36ee1f76e6f484ebb3245c82a Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1258571 Reviewed-by: Jett Rink <jettrink@chromium.org>
* tcpc: Simplify ANX74XX device selectionJonathan Brandmeyer2018-10-041-0/+7
| | | | | | | | | | | BUG=none BRANCH=none TEST=buildall Change-Id: I8eb4a9027518aa1c7af18e850984a595bd2bbe23 Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1258570 Reviewed-by: Jett Rink <jettrink@chromium.org>
* mag_cal: Support fixed-point calculation.Yilun Lin2018-10-045-25/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Modified from floating point version. This includes changes to vec3, vec4, mat33, mat44, and mag_cal. Now fixed-point type (fp_*) functions is a function wrapper for both fixed-point and floating point version operations: * define CONFIG_FPU to use floating version mag_cal * undef CONFIG_FPU to use fixed-point version mag_cal Also, add tests for both float and fp types operations. TEST=define CONFIG_FPU; flash on reef; See ARC++ magnetmeter app moving. TEST=undef CONFIG_FPU; flash on reef; See ARC++ magnetmeter app moving. TEST=make runtests -j TEST=make buildalltests -j BUG=b:113364863 BRANCH=None Change-Id: Ie695945acb666912babb2a603e09c602a0624d44 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1260704 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* math_util: Support fp_div_dbz which handling division-by-zero error.Yilun Lin2018-10-041-0/+24
| | | | | | | | | | | | | | | | | | | | | | Fixed-point numbers has limited value range. It is very easy to be trapped in a division-by-zero error especially when doing magnetometer calculation. We only use fixed-point operations for motion sensors now, so the precision and correctness for these operations is not the most important point to consider. Here we just let divided-by-zero result becomes INT32_MAX, to prevent the system failure. TEST=undef CONFIG_FPU, build, flash on reef, and test magnetometer, and see the system doesn't crash. BUG=b:113364863 BRANCH=None Change-Id: I0ab657b2132666eefa9f3a04043ce29f0096d238 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1248421 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* rma: when processing 'RMA open' do not reboot the deviceVadim Bendebury2018-10-041-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Once RMA open is processed and CCD state is updated, the AP still might require to perform some operations, even if TPM is not available any more. With this patch enable_ccd_factory_mode() does not trigger device reset, if invoked by the RMA open handler. Another modification is that WP is disabled immediately when factory mode is enabled, there is no need to reset the H1 for WP status to change. BRANCH=cr50, cr50-mp BUG=b:115495431 TEST=verified that running 'gsctool -a -r <authcode>' sets to 'Y' all CCD properties, disables write protection, but does not reboot the device. Change-Id: I834a9e4b5ebbe4aaaf1caafad9c82424087d01f7 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1250037 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* fpsensor: FP_INFO reports the template versionNicolas Norvez2018-10-021-0/+1
| | | | | | | | | | | | | | | | | | | Add a field to the ec_response_fp_info structure to report the version of the template format supported by the hardware. We'd normally uprev the structure version, but given there are only 2 clients of that API (ectool and biod), we'll rather synchronise the submission of the CLs to avoid unnecessary complexity. BRANCH=nocturne BUG=b:116979455 TEST=ectool --name=cros_fp fpinfo TEST=start biod, log shows the format version Change-Id: Ibbf2a3603d4f28c7550523f785aeb7fb740ac9ea Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1252459 Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* pd: prevent incorrect LPM flag useJett Rink2018-10-021-0/+2
| | | | | | | | | | | | | | | | Only define PD_FLAGS_LPM_* with the CONFIG_USB_PD_TCPC_LOW_POWER option is defined. This prevents us from using the flags when we shouldn't. BRANCH=none BUG=b:116269457 TEST=buildall works for all boards. Change-Id: I6837819a7ce5d8216e98c92c95275f297d88f911 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1254922 Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org>
* mkbp: add support for board-specific host notificationEnrico Granata2018-10-021-0/+3
| | | | | | | | | | | | | | | | | | | | On Nocturne, we want to be able to decide whether MKBP events should be notified to the AP via host_set_single_event or gpio_set_level based upon runtime board-version detection instead of a static compile-time flag. Add support for this by marking the function that raises the actual IRQ to the host as weak, so that individual boards can override it with their own version. BRANCH=None BUG=b:112366846, b:112112483, b:112111610 TEST=see CL:1161546 for details Signed-off-by: Enrico Granata <egranata@chromium.org> Change-Id: Ide5ec12fbc6fea3cf23069f376066f225e1887b3 Reviewed-on: https://chromium-review.googlesource.com/1247000 Reviewed-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* fpsensor: Add support for sensor reset commandPrashant Malani2018-10-021-0/+3
| | | | | | | | | | | | | | | | | | | Update the "reset_sensor" option of the FP_MODE EC command to actually reset the FP sensor. A reset_sensor is essentially the same as performing a re-initialization of the sensor, so this amounts to calling fp_sensor_init() again. BUG=b:110805729 BRANCH=nocturne TEST=Run updated biod and inspect cros_fp.log to ensure that the sensor reinitialization code runs after login. Change-Id: Ib639b64089368b38db154da4a99d4def70c48229 Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1239623 Commit-Ready: Nicolas Norvez <norvez@chromium.org> Tested-by: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* bc12: rename bq24392 driver to max14637Scott Collyer2018-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | The MAX14637 BC 1.2 USB charger detection chip is functionally similar to the bq24392 and can use the same driver. Rather than have 2 copies of the same driver, or a generic named driver than can be used for both chips, rename the existing bq24392 driver to max14637 as that's the BC 1.2 chip that our current designs are using. BUG=b:113267982 BRANCH=none TEST=make -j buildall Change-Id: I03cfb4918513d756c2a41341001a8162652a29b6 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1250031 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* pdchipinfo: add min firmware version to pdchipinfoJett Rink2018-09-282-1/+15
| | | | | | | | | | | | | | | | Add a new field to the pdchipinfo host command that exposes the minimum required firmware version that we know about. This will allow factory tests or automated test to compare this version to the current version and fail. BRANCH=none BUG=b:116068318 TEST=with corresponding ectool change, min value is reported correctly Change-Id: Idf338795c3fd6f9f95e51471d0f6a7a422901d52 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1240457 Reviewed-by: Justin TerAvest <teravest@chromium.org>
* led: Board-defined tables for LED statesBen Chen2018-09-272-0/+111
| | | | | | | | | | | | | | | | | Add common code to support GPIO-controlled LEDs for common battery/power states through a board-defined lookup table. BUG=b:113611642 BRANCH=none TEST=Correct charge states shown on Aleena LED Change-Id: Id3ab88965e67d170bdc875112475565ab2dca542 Signed-off-by: Ben Chen <ben.chen2@quanta.corp-partner.google.com> Reviewed-on: https://chromium-review.googlesource.com/1233093 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* math_util: Support fixed-point sqrtf fp_sqrtf.Yilun Lin2018-09-261-0/+5
| | | | | | | | | | | | | TEST=make buildall -j BUG=b:113364863 BRANCH=None Change-Id: I63ee741a08e39cf6f234a2131137144c46ae0bbd Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1235476 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32h7/nocturne_fp: Enable RDP level 1, tie it to flash protection statusNicolas Boichat2018-09-221-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent flash readout, using RDP field in option byte. When RDP is defined, it makes no sense to be able to unlock RO, as that'd allow flashing arbitrary RO that could read back the rest of the flash, so we just tie EC_FLASH_PROTECT_RO_AT_BOOT and RDP protection. This also means we can't unlock the flash after it has been finalized (without removing WP and using BOOT0/stm32mon to mass erase the chip). Also, in flash_mp_mcu, call stm32mon with -U, to unlock flash for read-back first (which disables RDP and triggers a mass erase if RDP was enabled). Finally, load spidev before putting releasing reset, which makes reflashing more reliable. BRANCH=nocturne BUG=b:111330723 TEST=cp flash_mp_mcu read_mp_mcu, replace stm32mon line with: "stm32mon -u -p -s ${SPIDEV} -r rb.bin" dut-control fw_wp_state:force_off => Check that read_mp_mcu works dut-control fw_wp_state:force_on ectool --name=cros_fp flashprotect enable ectool --name=cros_fp reboot_ec => RDP is now on dut-control fw_wp_state:force_off => Check that read_mp_mcu does not work anymore TEST=Add -U to stm32mon line above in read_mp_mcu, check that readback only gets blank data. TEST=In EC console, check that RDP bits are indeed not 0xaa: Before: rw 0x5200201c => 0x07d6aaf0 After: rw 0x5200201c => 0x07d600f0 TEST=flash_mp_mcu still works (does a flash erase that removes RDP protection) Change-Id: Ifbe37ecafbf23f48d4a3cc17933130b7b104b728 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1222094 Commit-Ready: Nicolas Norvez <norvez@chromium.org> Tested-by: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* fpsensor: validate args of EC_CMD_FP* commandsNicolas Norvez2018-09-221-38/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - More thorough validation of the arguments passed to host commands. - Remove obsolete EC_CMD_FP_SENSOR_CONFIG host command. - Some console commands can't be used on locked systems. BRANCH=nocturne BUG=b:116065496 TEST=enroll finger TEST=unlock with finger TEST=Capture ectool --name=cros_fp fpmode capture vendor; ectool --name=cros_fp waitevent 5 10000; ectool --name=cros_fp fpframe raw > /tmp/fp.raw /usr/local/opt/fpc/fputils.py --png /tmp/fp.raw TEST=MQT ectool --name=cros_fp fpmode capture qual; ectool --name=cros_fp waitevent 5 10000; ectool --name=cros_fp fpframe raw > /tmp/fp.raw; /usr/local/opt/fpc/fputils.py --mqt /tmp/fp.raw TEST=Reset_pixel ectool --name=cros_fp fpmode capture test_reset; ectool --name=cros_fp fpframe > /tmp/test_reset.pnm TEST=Checkerboard ectool --name=cros_fp fpmode capture pattern0; ectool --name=cros_fp waitevent 5 500; ectool --name=cros_fp fpframe > /tmp/pattern0.pnm ectool --name=cros_fp fpmode capture pattern1; ectool --name=cros_fp waitevent 5 500; ectool --name=cros_fp fpframe > /tmp/pattern1.pnm Change-Id: I3c9aa4749ffd77c73f8ca52cddbcc0e8ca6ae48c Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1239247 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* fpsensor: add a version to the template formatNicolas Norvez2018-09-211-0/+6
| | | | | | | | | | | | | | The first 2 bytes of the metadata structure contain the version of the format of that structure. BRANCH=nocturne BUG=b:73337313 TEST=enroll/logout/unlock Change-Id: I1838791603df11fdefb373105617f83eec116f89 Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1235413 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* fpsensor: Encrypt the FP templates with HW keyNicolas Norvez2018-09-211-10/+20
| | | | | | | | | | | | | | | | | | | | | We use AES-GCM crypto to encrypt the FP templates between the AP and the MCU. For every single template, we generate a nonce/salt that is updated on every template update (i.e. when the AP requests an encrypted template). We then derive the symmetric key using HMAC-SHA256 and encrypt/decrypt the template. Design doc at go/cros-fp-dd BUG=b:73337313 BRANCH=nocturne TEST=enroll a finger, log out, log back in, unlock the device. TEST=retrieve MQT frame on unlocked system Change-Id: I29c66c6dc660242a423af02066f5aba671613300 Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1194999 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* aes-gcm: Adapt AES-GCM to build for ECNicolas Boichat2018-09-211-0/+3
| | | | | | | | | | | | | | | | | | | | | Update header, C code, trim unnecessary bits. Also add a test with vectors taken from BoringSSL tests. BRANCH=none BUG=b:111160949 TEST=make run-aes -j TEST=make BOARD=nocturne_fp test-aes -j flash_fp_mcu aes.bin runtest => pass (C implementation speed: 909555 us for 1000 iterations) (ASM implementation speed: 596690 us for 1000 iterations) Change-Id: Ief54a8441d26ba44de4c3ac81e203cab7472269f Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1141446 Commit-Ready: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* rollback: Add host command to query rollback informationNicolas Boichat2018-09-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | Rollback id will be useful to check that the secret has actually been wiped. Min rollback version and RW rollback version might be useful in the future. BRANCH=nocturne BUG=b:115733483 TEST=ectool --name=cros_fp rollbackinfo => Rollback block id: X ectool --name=cros_fp reboot_ec; sleep 0.5; \ ectool --name=cros_fp rwsigaction abort && \ ectool --name=cros_fp addentropy reset && \ ectool --name=cros_fp reboot_ec ectool --name=cros_fp rollbackinfo => Rollback block id: X+2 Change-Id: I039d26d302d3a12b0d41acca34aa28d4a2dd096d Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1226126 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org>
* chgmgr: Allow charge_manager_update_charge to accept NULLDaisuke Nojiri2018-09-201-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, charge_manager_update_charge does not handle NULL pointer for struct charge_port_info any differently. It's not sanity-checked either (thus memory access violation can occur). This patch will make charge_manager_update_charge accept NULL pointer and set available current and voltage to zero. This also helps callers' intentions be clear because callers can explicitly specify NULL (instead of passing a pointer to chg = {0}, which is initialized somewhere else). Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=buildall Change-Id: I518662ab6a3a07f93da5d34cf62a6f856884f67d Reviewed-on: https://chromium-review.googlesource.com/1226125 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* aes-gcm: Baseline implementation from BoringSSLNicolas Boichat2018-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Copied over from upstream BoringSSL at commit 859679518d3433cdd0dd6cf534bd7bdb2a32dd60 . cp boringssl/crypto/fipsmodule/modes/gcm.c \ third_party/boringssl/common/gcm.c cp crypto/fipsmodule/modes/internal.h \ third_party/boringssl/include/aes-gcm.h => Remove non-GCM definitions perl boringssl/crypto/fipsmodule/modes/asm/ghash-armv4.pl \ > third_party/boringssl/core/cortex-m/ghash.S BRANCH=none BUG=b:111160949 TEST=none Change-Id: I34702ff315c8c44e6f4868243058700aaf026099 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1141445 Reviewed-by: Adam Langley <agl@chromium.org>
* aes: Adapt AES code to build for ECNicolas Boichat2018-09-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update header, C code, and tweak the assembly for ARMv7-M. Rename aes_now_* functions to AES_* to avoid the need for a separate wrapper. Also add a test with FIPS-197 test vectors, and speed test. BRANCH=none BUG=b:111160949 TEST=make run-aes -j TEST=make BOARD=nocturne_fp test-aes -j flash_fp_mcu aes.bin runtest => pass (C implementation speed: 11977 us for 1000 iterations) (ASM implementation speed: 5815 us for 1000 iterations) Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Change-Id: I2048aae73decccb893bc1724b2617b0b902dd992 Reviewed-on: https://chromium-review.googlesource.com/1120340 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* aes: Baseline implementation from BoringSSLNicolas Boichat2018-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Copied over from upstream BoringSSL at commit 859679518d3433cdd0dd6cf534bd7bdb2a32dd60 . cp boringssl/LICENSE third_party/boringssl/LICENSE cp boringssl/src/crypto/fipsmodule/aes/aes.c \ third_party/boringssl/common/aes.c cp boringssl/include/openssl/aes.h \ third_party/boringssl/include/aes.h perl boringssl/crypto/fipsmodule/aes/asm/aes-armv4.pl \ > third_party/boringssl/core/cortex-m/aes.S BRANCH=none BUG=b:111160949 TEST=none Change-Id: Ia1fbb57b23e039ca5dec3d56984c83c19b7d6cd6 Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1120339 Reviewed-by: Adam Langley <agl@chromium.org>
* ss-mux: remove unused port_addr initializationv2.0.0Jett Rink2018-09-171-2/+5
| | | | | | | | | | | | | | | | | | | We do not need to set the port_addr variable most places because the SS-MUX is also the TCPC and the tcpc_config_t information is used instead. Remove unused variable setting to avoid confusion. BRANCH=none BUG=none TEST=buildall. phaser USB-C communication (and muxs) still work which is a nominal case for all of these changes. Change-Id: I72ee5da251956eb133091974e8dce5ac7f8787c6 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1200064 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Edward Hill <ecgh@chromium.org>
* pd: Ensure TCPC exits low power modeEdward Hill2018-09-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure the TCPC is awake when leaving PD_STATE_DRP_AUTO_TOGGLE and when there is a new PD event to handle. Move the exit_low_power_mode() call from the PD_STATE_DRP_AUTO_TOGGLE case statement into set_state(), to catch all possible paths that exit the state. Add a new exit_low_power_mode() call to the top of the main task loop if there is a new event to handle. This allows the exit_low_power_mode() call to be removed from pd_update_dual_role_config() (since PD_EVENT_UPDATE_DUAL_ROLE is included in PD_EXIT_LOW_POWER_EVENT_MASK). Clear PD_FLAGS_LPM_REQUESTED when PD_FLAGS_LPM_ENGAGED is cleared in handle_device_access() and wake the PD task to ensure we will make another pass through the main task loop (and check the CC lines) before deciding to enter low power mode again. BRANCH=none BUG=b:111663127,b:112039224 TEST=PD and TCPC low power still work on Grunt Change-Id: I99063ce0d02af65de74f4c6f73f7a15600d2eac9 Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1225352 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* pd: Change tcpm_set_drp_toggle() to tcpm_enable_drp_toggle()Edward Hill2018-09-171-2/+1
| | | | | | | | | | | | | | | Change tcpm_set_drp_toggle() to tcpm_enable_drp_toggle(), since enable=0 was unused. BRANCH=none BUG=b:111663127 TEST=PD and TCPC low power still work on Grunt Change-Id: I760a067b11984a579261deac856419d46400497b Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1194353 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* pd: Add PD_FLAGS_LPM_TRANSITIONEdward Hill2018-09-171-1/+4
| | | | | | | | | | | | | | | Add PD_FLAGS_LPM_TRANSITION and use this to allow the PD task to call tcpc_read/tcpc_write from tcpm_enter_low_power_mode() and tcpm_init(). BRANCH=none BUG=b:111663127 TEST=PD and TCPC low power still work on Grunt Change-Id: I12ddb58667c171068e1be6d136f22f2062959c8c Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1194351 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* flash: Add CONFIG_FLASH_READOUT_PROTECTION config optionNicolas Boichat2018-09-141-0/+5
| | | | | | | | | | | | | | Instead of tying together CONFIG_WP_ALWAYS and RDP protection, separate the options. BRANCH=nocturne BUG=b:111330723 TEST=make buildall -j Change-Id: I905b573a900ef4dd0431666c525c951582143e09 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1222093 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* temp_sensor: Add (basic) support for TI TMP468 Temperature SensorMoritz Fischer2018-09-131-0/+1
| | | | | | | | | | | | | | | Add (basic) support for TI TMP468 a 8 Remote + 1 Local channel temperature sensor. BUG=none BRANCH=master TEST=Hook up EVM to I2C port of a STM32F072, read temperatures Change-Id: I6d6644825af04391841847c060f8ffaeff620094 Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Reviewed-on: https://chromium-review.googlesource.com/1213554 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* keyboard: display keycap label in key status debug messagesNamyoon Woo2018-09-131-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current debug message in keyboard_8042.c displays a tuple of row, column, and press status. Additionally, this CL displays a keycap label for better readability. For keycap label mapping table can be adjustable under "CONFIG_KEYBOARD_SCANCODE_MUTABLE" condition as scancode_set2[] is. For coral board, Enabling CONFIG_KEYBOARD_DEBUG (w/o this CL) occupies 652 bytes in flash, and this CL occupies another 312 bytes. BUG=b:111060830 TEST=manually tested by pressing keyboards and check the EC console screen. BRANCH=kblog Signed-off-by: Namyoon Woo <namyoon@chromium.org> Changes to be committed: modified: board/eve/board.c modified: common/keyboard_8042.c modified: common/keyboard_8042_sharedlib.c modified: include/keyboard_8042_sharedlib.h Change-Id: Idd71a5475b1ee313f99e087be9143dcfb6f81550 Reviewed-on: https://chromium-review.googlesource.com/1214543 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Namyoon Woo <namyoon@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* base_detect: Expose console command to force state.RaviChandra Sadineni2018-09-132-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an effort to test wake sources on any given platform, this CL exposes console command to set the base state. This console command can then be invoked by autottests from the uart interface. We have two implementations for managing base status. One is interrupt driven while the other is a polling via a task. Boards current implementations then are: interrupts: lux, soraka, cheza polling task: nocturne, zoombini For forcing base connect and disconnect, interrupts: Disable interrupts and set forced base state. polling task: Stop periodic task and set forced base state. On reset, interrupts: Schedule deferred task immediately and enable interrupts. polling task: Clear forced base state and begin rescheduling periodic task. Signed-off-by: RaviChandra Sadineni <ravisadineni@google.com> BRANCH=poppy,nocturne BUG=chromium:820668, b:37223093 TEST=Tested on lux, soraka and nocturne basestate a : attaches the lid, reflected in ui. basestate d : detaches the lid, reflected in ui. basestate r : resets to the correct state. Wakes the device up on lux and nocturne and soraka. Change-Id: Iab698e103a50b8d22bf216a6f816998cb158e38a Reviewed-on: https://chromium-review.googlesource.com/1184172 Commit-Ready: Ravi Chandra Sadineni <ravisadineni@chromium.org> Tested-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* charge_manager: Use enum for CHARGE_SUPPLIER_NONEDaisuke Nojiri2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | Currently, CHARGE_SUPPLIER_NONE is defined as a macro. This causes the compiler to allocate uint8_t to enum charge_supplier. When -1 passed to or returned from a function, it's cast to 0xff. This patch defines CHARGE_SUPPLIER_NONE in enum charge_supplier. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=Verify ectool usbpdpower 1 return 'Port 1: Disconnected' and 'Port 1: SNK (not charging)' without and with a BJ adapter connected respectively on Fizz. Change-Id: I31bfa33efa91f60c6667f3b0de9cbdf9c6b3e8bf Reviewed-on: https://chromium-review.googlesource.com/1217605 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* ppc: Add support for nx20p3481Scott Collyer2018-09-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL is an incremental change to the nx20p348x driver to add support for the nx20p3481 ppc. Sink/source modes are controlled via the switch control register instead of gpio signals. Another difference is that the values of mode in register 0x1 are slightly different between the 3481 and 3483. The 3481 needs to use the switch status register to verify whether it's in sink or source mode. This register is now checked for both the 3483 and 3481. A delay is required for the switch status register to reflect the control setting just applied. In addition, the nx20p3481 supports Fast Role Swap (FRS). For FRS, only the detection is supported, and it's assumed that it's caused by the removal of an external charger, not an actual FRS event. BUG=b:111281797 BRANCH=none TEST=Verified on DragonEgg that port acts correctly as a sink. Have not been able to verify source operation. Change-Id: I2fb4200a5d9c3ce460e9b913a5b09441e458bb7e Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1178995 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* type: Rename matrix_3x3_t to mat33_fp_tYilun Lin2018-09-133-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I51d88d44252184e4b7b3564236833b0b892edc39 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215449 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename mat44_t to mat44_float_t.Yilun Lin2018-09-132-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I188305fc2f4fcff6ec4343f68e1aa1d2d185f6cf Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215448 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename mat33_t to mat33_float_tYilun Lin2018-09-131-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: Ia601bfc9f9fb311f6ca91bfa2e8fa34259ed6c5b Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215447 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename size3_t to sizev3_tYilun Lin2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I4fea3bb2c1781a91f1c12ad66f25382cc0be3611 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215446 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename size4_t to sizev4_tYilun Lin2018-09-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I3b63b4b1eb4c9ca4166ad207a5646e0c307cd418 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215445 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename vec4_t to floatv4_tYilun Lin2018-09-133-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: Ia61493b9f7303c720fba50d6f481316c6d75cc79 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215444 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename vec3_t to floatv3_t.Yilun Lin2018-09-132-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I8cac6a7c0abe3d462326291b76b1ed44ce6c9a9c Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215443 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* type: Rename vector_3_t to intv3_t.Yilun Lin2018-09-135-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I865aa3ecbab6cb97f8585a081a679adf00febe1d Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215442 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* usb-pd: disconnect USB SS MUX when S5 or lowerJett Rink2018-09-071-2/+2
| | | | | | | | | | | | | | | | | | | Especially for SS MUX that have redrivers in them, we should disable the MUX while the chipset is off because the data line will not be used. This give decent power savings for redriver MUXs (e.g. PS8751) BRANCH=none BUG=b:112136208,b:111196155 TEST=On Phaser the 3300_pd_a drops from 92mW to 32 mW when the charger is plugged into C1 and the SoC is in S5. The rail also says at 32mW after removing and plugging the power back in while the SoC is in S5. Also ensured that power is low upon first insertion and AP does not come on automatically. Change-Id: I0601fbb506ad3eff902cf6562a6408292ef70e3a Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1185485 Reviewed-by: Justin TerAvest <teravest@chromium.org>
* power: add chipset_in_or_transitioning_to_stateJett Rink2018-09-071-0/+12
| | | | | | | | | | | | | | | | | | | | | | | We need a method that we can call from the chipset notify hooks that can clearly distinguish which state you are about to be in. This is made evident by the child CL for putting a MUX into low power mode in S5. Without this method, we have to put chipset state into the PD task variable and use that instead (since chipset_in_state won't work because we are in the S3S5 state) BRANCH=none BUG=b:112136208,b:111196155,chromium:736508 TEST=On Phaser the 3300_pd_a drops from 92mW to 32 mW when the charger is plugged into C1 and the SoC is in S5. The rail also says at 32mW after removing and plugging the power back in while the SoC is in S5. Also ensured that power is low upon first insertion and AP does not come on automatically. Change-Id: I93cce2aa319c9689efce222919e5389471001a00 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1211368 Reviewed-by: Justin TerAvest <teravest@chromium.org>
View Lorry Controller Status