summaryrefslogtreecommitdiff
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* usb/mux: Do not connect MUX when PD disconnectedstabilize-12222.BRuibin Chang2019-05-231-10/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When chipset power up to S5->S3 state set PD_EVENT_POWER_STATE_CHANGE, pd task set mux usb mode whether c-port is attached or not. If c-port is nothing attached at the setting moment, then mux detects nothing and goes to low power state. Plug-in type-c usb device, after debounce pass, we set mux usb mode and mux responds i2C NAK (due to in low power mode). This CL changes that do not connect MUX when PD disconnected. For example ps8751 is used for mux case. When power up(S5->S3), we should set mux none mode whether c-port is attached or not. Once type-c usb device plug-in, after cc debounce pass, we will set mux usb mode in X_DEBOUNCE_DISCONNECT state. BRANCH=None BUG=b:133196882 TEST=After console cmd reboot and reboot hard, type-c usb device plug-in on ampton and get type-c port status by "ectool usbpdmuxinfo". Change-Id: Ia538af48c450e12af1438a6aa9a6e4e426e2f616 Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1609262 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* motionsense: Convert in_spoof_mode to a more generic flagsYuval Peress2019-05-231-11/+14
| | | | | | | | | | | | BUG=b:129159505 BRANCH=arcada TEST=I ran `make buildall` since this change isn't used yet it doesn't affect run-time behavior. Change-Id: I01857d679b800f9b53762c659ebd9a018cbf16db Signed-off-by: Yuval Peress <peress@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1612251 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
* flash_log: add vendor command, timestamp base accessorVadim Bendebury2019-05-231-1/+35
| | | | | | | | | | | | | | | | The new vendor command allows to get and increase the flash log timestamp base. BRANCH=cr50, cr50-mp BUG=b:132287488 TEST=verified in the next patch in the series. Change-Id: Idc76012b7e7894b95cd70eeffeb50562a91b9656 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1610720 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Namyoon Woo <namyoon@chromium.org>
* flash_log: add api for setting base timestampVadim Bendebury2019-05-231-6/+47
| | | | | | | | | | | | | | | | | | | | | | | | The Cr50 environment does not have a wall clock, which makes it impossible to associate flash log entries with real time. This patch provides an API which allows to set a base time value and then use it plus current Cr50 uptime to generate more sensible flash log timestamps. Care is taken to ensure that attempts to set timestamp base such that it would cause a log timestamps rollback do not succeed. A unit test is being added to verify this behavior. BRANCH=none BUG=b:132287488 TEST='make buildall -j' (which runs the new tests) succeeds. Change-Id: I7521df1bac5aef67e0cf634c183bf1618655f48d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1610719 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* common: dptf: Guard against wild sensor IDsEvan Green2019-05-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | If developers have not set up TEMP_SENSOR_COUNT correctly, or the caller starts sending wild sensor_id or idx values down, then the EC will do arbitrary reads and writes over its own memory. In one case, the PD log buffer indices are next in memory, so we would see the following spew in the kernel (every 60 seconds, since the kernel only checks that often): [ 138.151937] PDLOG 2019/05/17 22:46:26.913 P0 Disconnected [ 138.158512] PDLOG 2019/05/17 22:46:04.936 P0 Disconnected [ 138.165066] PDLOG 2019/05/17 22:46:04.935 P0 Disconnected [ 138.171643] PDLOG 2019/05/17 22:46:04.935 P0 Disconnected [ 138.178162] PDLOG 2019/05/17 22:46:04.935 P0 Disconnected ... BUG=b:132999028 BRANCH=none TEST=Build and boot hatch, observe no more log spam Change-Id: If2e20972c3268e84bb4cdfa315c6b7f7cb76868f Signed-off-by: Evan Green <evgreen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1623176 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* common: dptf: Fix function name typoEvan Green2019-05-231-2/+2
| | | | | | | | | | | | | | s/dpft_check_temp_threshold/dptf_check_temp_threshold/ BUG=b:132999028 BRANCH=none TEST=make -j BOARD=hatch Change-Id: I453a154ee9e4a58ce88e7d6ffe34f14ae8b08d65 Signed-off-by: Evan Green <evgreen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1623175 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* I2C: Make pass-through debug messages more informativeDaisuke Nojiri2019-05-211-22/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes debug printf messages more informative as follows: - All messages are prefixed with I2C_PTHRU - Don't print pointers for read or write buffers - Print out buffer data With the patch, messages will look as follows: [7.335059 I2C_PTHRU xfer port=1 addr=0x16 rlen=0 flags=0x3] out: 0x03 0x01 0xe0 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=Verify the messages are printed as expected Change-Id: I144b2d1d517070b6cdb492f71baa7f20c27e29b9 Reviewed-on: https://chromium-review.googlesource.com/1604162 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* USB-PD: Consolidate tcpc_config declarations in usb_pd_tcpm.hDaisuke Nojiri2019-05-211-1/+0
| | | | | | | | | | | | | | | | | | Currently, tcpc_config is declared in two places. This patch consolidates declarations in usb_pd_tcpm.h. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=buildall Change-Id: I4f30d06b1eaeb6a83b664de76116d85d65a9fc97 Reviewed-on: https://chromium-review.googlesource.com/1616007 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cr50: Change G2F cert CN to "CrOS"Louis Collard2019-05-211-1/+4
| | | | | | | | | | | | | | BUG=b:132310780 TEST=flash to soraka, retrieve G2F cert, check CN retrieve anonymous U2F cert, check CN unchanged BRANCH=none Change-Id: Id409ac5d534f2ee9e16376d690f58b184f5ac1a6 Signed-off-by: Louis Collard <louiscollard@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1614581 Reviewed-by: Andrey Pronin <apronin@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* tabletmode: ignore lid angle if hall sensor activeJett Rink2019-05-181-15/+27
| | | | | | | | | | | | | | | | | | | | If the 360 degree hall sensor is active, then we should remain in tablet mode even if the lid angle says we are 1 degree since an angle of 360 could wrap around to 1 degree. Also ensure that tablet mode always gets initialized to the correct state at startup (by setting initial value to -1) BRANCH=R75 BUG=b:131785573,b:132178305 TEST=NB_MODE# on arcada does not flutter when the device is at 360 degrees with CL stack. Change-Id: I962a9c23205766080a65d741c6c425452d9de608 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1597189 Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* USB PD: Don't attempt to exit mode on a suspended portDiana Z2019-05-171-11/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Since suspended ports run a very tight while loop which does not include the pd_task's event processing, sysjumping an unlocked system with a suspended port hangs forever. A suspended port cannot be in an alternate mode, so this change skips setting PD_EVENT_SYSJUMP for such ports (which, currently, is only used to trigger the exit mode sequence). In the unlikely event that processing a PD interrupt causes the port to suspend after this check and before PD_EVENT_SYSJUMP is set, the sysjump loop will also send the reply event to the caller. BUG=b:131855159 BRANCH=None TEST=set a phaser port to fail TCPC initialization, verified that "sysjump RW" can still succeed with suspended port Change-Id: I948dd419718d0eb2e5ade58970ed36a8bd51b272 Signed-off-by: Diana Z <dzigterman@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1613640 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* pd_protocol: Add ready_state_holdoff_timer.Aseda Aboagye2019-05-171-17/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently a sink holdoff timer was added to the PD stack which allowed the state machine to prevent initiating any messages for 200ms after entering the SNK_READY state. This was to give time for some chatty sources to send messages to avoid a collision. Apparently, the same thing can happen when we are a source (collision with chatty sink). This commit reuses the holdoff timer for resolution as a source as well, which starts after an explicit contract is established. In order to prevent any potential new collisions, some jitter based off of the system timestamp is added to the holdoff timer. BUG=b:132202148, chromium:925618 BRANCH=firmware-atlas-11827.B TEST=Flash atlas, plug in a fully featured C-C cable between atlas and the LG 27UK850-W, verify that no conflict occurs and external display always works. TEST=Verify that no messages are initiated by the source within 200ms of sending PS_RDY. TEST=Flash nocturne, verify Dell U3818DW still works over C-C cable. TEST=Flash nocturne, verify CableMatters MST DP hub still works with charge through. TEST=Verify with Twinkie that messages are sent at varied timestamps between 200-300ms in the SNK/SRC_READY state. Change-Id: I195199de271950ae09c2b26194ddc5f271b296a0 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1600510 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* i2c: add i2clookup host commandJett Rink2019-05-161-0/+28
| | | | | | | | | | | | | | | Add a new host command that will allow you to lookup a well known device on the EC. This is useful for FAFT tests that want to talk directly with i2c devices but don't know the physical address for each platform. BRANCH=octopus BUG=b:119065537 TEST=Used this with new faft test in CL:1601300 Change-Id: I82c2d5462fcb4edbc92ea60765971190fed7ae81 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1601060 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* charge_manager: Revisit charge supplier priority.stabilize-12206.BYilun Lin2019-05-141-19/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to USB-C spec 1.3 Table 4-17 "Precedence of power source usage", the supplier's priority should be: USB-C 3.0A/1.5A > BC1.2 > USB-C under 1.5A. This CL propose to raise the BC1.2 priority to fix that charge_manager won't choose BC1.2 when the port reports it can supply both TYPEC 500ma and BC1.2 supplier. According to the spec mentioned aboved, we should prefer BC1.2 rather than TYPEC. Besdies, charge_manager is able to pick the supplier which provides the higheste power. The CL simplifies the supplier priority a bit by taking advantage of the feature. TEST=Charge kukui with 5V/2A charger and see it can drain 1.34A (DCP current bound of mt6370 is 1.5A) rather than 0.5A. TEST=Charge kukui with Type-C 5V3A/CDP/DCP/SDP/PD charger randomly and see that the current it drains is reasonable. TEST=Charge soraka with 'A', and plug another port with 'B', and see it can transist the sinking port from A to B. Here (A, B) are: 1. (SDP 5V0.5A, Type-C 5V3A) 2. (CDP 5V1.5A, PD) 3. (SDP 5V0.5A, CDP 5V1.5A) 4. (CDP 5V1.5A, Type-C 5V3A) 5. (Type-C 5V3A, PD) BUG=b:131126720 BRANCH=None Change-Id: I46384e09d764aa926129358657d0593fca4923c2 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1581859 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* retimer: Add driver support for Intel Burnside Bridge retimerVijay Hiremath2019-05-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Burnside Bridge is a Type-C multi-protocol retimer to be used in on-board applications. Burnside Bridge offers the ability to latch protocol signals into on-chip memory before retransmitting them onwards. It can be used to extend the physical length of the system without increasing high frequency jitter. Burnside Bridge supports spec compliant retimer of following protocols: 1. Display Port: four unidirectional DP lanes 2. USB3.1 Gen1/2: one bi-directional USB lane 3. Thunderbolt: two bi-directional CIO lanes 4. Multifunction Display (MFD): two unidirectional lanes of DP and one bi-directional lane of USB3.1 Gen1/2 Note: Only item 1, 2 & 4 are supported in this CL. Item 3 support will be added in follow on CLs. BUG=b:127623438 BRANCH=none TEST=Manually verified on ICLRVP, able to configure the registers Change-Id: I2d60dbcaf8fe7a1503f09a2f16007409f059f54e Signed-off-by: Ayushee <ayushee.shah@intel.com> Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1594170 Commit-Ready: Jett Rink <jettrink@chromium.org> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
* queue.h: Check at compile time if queue size is power of 2Nicolas Boichat2019-05-141-1/+0
| | | | | | | | | | | | | | | | | Replace the runtime assertion with a compile time one, saves a bit of space (~64 bytes on many boards), and warn users earlier of potential issues. BRANCH=none BUG=none TEST=make buildall -j Change-Id: I7df70b7166dd447a8b1dd8e10710c8bc7ab213e3 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1600943 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org>
* Align behavior of strtoi() and strtoul() to match Linux manpage description ↵Jes Klinke2019-05-141-28/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | of strtol(). Behavior changes: 1) Initial '+' character is tolerated. 2) Hexadecimal strings prefixed with "0x" are rejected, if given base parameter is anything other than 16 or 0, rather than parsed as hex, diregarding the given base. 3) If given base is 0, strings starting with leading zero will be parsed as octal, rather than decimal. 4) Initial '-' character allowed before "0x" on hexadecimal numbers. (Note: This is my first time using git or gerrit, please let me know if there is some policy or customs that I am not properly adhering to.) BRANCH=none TEST=make run-utils_str V=1 Bug: 940329 Change-Id: I71654471b77f0df071a58ff6bed7028f00cd46b5 Signed-off-by: Jes Bodi Klinke <jbk@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1577750 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* USB-PD: Fix null-pointer dereference for svdm_rsp.amodeDaisuke Nojiri2019-05-121-2/+4
| | | | | | | | | | | | | | | | | | | This patch fixes null-pointer dereference for svdm_rsp.amode. Some boards set svdm_rsp.amode to NULL. This patch will make TCPM on those boards return NACK instead of crash. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=buildall Change-Id: Ifdeacbe4e164c5f1f7679ed4bb19a91053936ac6 Reviewed-on: https://chromium-review.googlesource.com/1599729 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* common/usb_pd_protocol: Avoid unitialized use of port flagsNicolas Boichat2019-05-121-11/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On reset, when pd_partner_port_reset is called, if, for any reason pd_get_saved_port_flags fails to get the saved port status, we would risk using unitialized flags from the stack. The function logic was a little complicated, and can be simplified quite a bit by returning early if no contract is in place (or if we fail to read flags from BBRAM). This should not be a problem on real boards, as the stored value should be readable from BBRAM. In any case, the first time we used the flag if (explicit_contract_in_place && pd_comm_is_enabled(port)) only applies to unlocked RO images, so this never happens in production (where RO images are locked). The second case is a little tricker, and we may end up (not) applying Rp where we should (not): /* If we just lost power, don't apply Rp. */ if (!explicit_contract_in_place || system_get_reset_flags() & (RESET_FLAG_BROWNOUT | RESET_FLAG_POWER_ON)) return; Presumably, the worst case here is that a charger may not work after a brownout/power on. BRANCH=none BUG=chromium:958510 TEST=setup_board --board=amd64-generic --profile=msan-fuzzer cros_fuzz --board=amd64-generic reproduce --fuzzer \ chromeos_ec_usb_pd_fuzzer --testcase \ ./clusterfuzz-testcase-minimized-ec_usb_pd_fuzzer-5086219896225792 \ --package chromeos-ec --build-type msan => No more MemorySanitizer error. Change-Id: I40fb87b68dbe5244e8a2ae136508b431db7f96a8 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1600935 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* USB-PD: Add hook for PD connect eventDaisuke Nojiri2019-05-082-0/+6
| | | | | | | | | | | | | | | | This patch adds a hook for USB PD connect event. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b/127228934 BRANCH=none TEST=buildall. Verify a hook is called on BC12 charger connection. Change-Id: I88fcd65d1afce07b6275398c5d0b902ecd7a44a3 Reviewed-on: https://chromium-review.googlesource.com/1597794 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* usb_pd_protocol.c: exiting from try.src to attach.srcRuibin Chang2019-05-071-10/+34
| | | | | | | | | | | | | | | | | | | | The port shall transition to Attached.SRC when the SRC.Rd state is detected on exactly "one of the CC1 or CC2 pins" for at least tTryCCDebounce. See TypeC v1.4 spec 4.5.2.2.10.2 Exiting from Try.SRC State. BRANCH=None BUG=b:130615676 TEST=1.Ampton with apple type-c adapter 2.Ellisys USB-PD test Change-Id: I461c53e2b8d9189f290956964754ae5b1a11a950 Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1564499 Commit-Ready: Diana Z <dzigterman@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* pd_protocol: Don't clear PD flags while debouncing.Aseda Aboagye2019-05-041-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PD_FLAGS_TRY_SRC flag was being cleared every time we entered the *_DISCONNECTED state. However, this would lead to a case where if the state machine was debouncing the CC lines and decided to re-enter the SRC_DISCONNECTED state, the Try.Src flag would be cleared and the state machine would not transition to the TryWait.SNK state after timing out. We shouldn't clear any flags when transitioning back to the disconnected state from the debounce state as the two states here are really the same states in the state diagram. This commit simply only clears the PD flags when we're transitioning to the disconnected state but not from a debounce state. This also keeps the Try.Src flag set if the previous state was a debounce as it means the state machine decided it didn't meet the condition to exit and should continue waiting before transitioning to TryWait.SNK. BUG=b:115452695 BRANCH=master TEST=Flash nocturne; boot to S0, plug in Apple 87W USB-C charger with eMarked cable, verify we form an explicit 45W contract. Change-Id: I6d8f5d69b8bd0d25ac7af008bbbe91f2658cdfe2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1286299 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 1f30c7483fa5621e9d67c5977709dce73f31a66d) Reviewed-on: https://chromium-review.googlesource.com/1591483 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
* ish: preserve panic data across resetJack Rosenthal2019-05-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit stores panic data across reset by storing panic data in the last 256 bytes of AON memory (before AON ROM). > crash divzero ========== PANIC ========== Reason: Divide By Zero Error Code = 0xFF00B60C EIP = 0xFF010008 CS = 0x00010202 EFLAGS = 0x00103085 EAX = 0x00000001 EBX = 0xFF01B118 ECX = 0x00000000 EDX = 0x00000000 ESI = 0x00000000 EDI = 0xFF017E0E Resetting system... =========================== ... ISH reset ... > panicinfo Saved panic data: (NEW) Reason: Divide By Zero Error Code = 0xFF00B60C EIP = 0xFF010008 CS = 0x00010202 EFLAGS = 0x00103085 EAX = 0x00000001 EBX = 0xFF01B118 ECX = 0x00000000 EDX = 0x00000000 ESI = 0x00000000 EDI = 0xFF017E0E BUG=b:129425206 BRANCH=none TEST=see console output above (on arcada_ish) Change-Id: I5c9e458b53076eafe7fa50ba851f2c6e863f2247 Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1593418 Reviewed-by: Jett Rink <jettrink@chromium.org>
* 7-seg display: Add config to display port80 msg and power statesAyushee2019-05-031-0/+7
| | | | | | | | | | | | | | | | | Adding this CL to display port80 message and power states of EC & SOC on the 7-segment display. BRANCH=None BUG=b:130738086 TEST=Manually tested on intelrvp, able to verify the power states and port80 message displayed on the 7 segment display Change-Id: I4437cfcd60662c8637e406e425f98fad1a4ba7ed Signed-off-by: Ayushee <ayushee.shah@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1575433 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Ayushee Shah <ayushee.shah@intel.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* cr50: add buffer_units_mask member into struct queueNamyoon Woo2019-05-021-9/+9
| | | | | | | | | | | | | | "q->buffer_units - 1" is performed many times to wrap head and/or tail. It should be calculated once. BUG=None BRANCH=cr50 TEST=None Change-Id: I9714147d5a97afd7aaba00d31a8b10bad50d0942 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1572444 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* usb: add inline helper method for CC linesJett Rink2019-05-023-44/+15
| | | | | | | | | | | | | | | | Expressing logic for CC lines can get very verbose. Add helper inline methods that logical describe the condition we are testing to clean up call sites. BRANCH=none BUG=none TEST=Builds, no functional change. Change-Id: I48c117437bc14f3c55473df7f7c778b55af2706d Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1589906 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Sam Hurst <shurst@google.com>
* pinweaver: fix memory leak introduced when moving to new nevmemVadim Bendebury2019-05-021-4/+3
| | | | | | | | | | | | | | | | | | Not all code paths were covered which results in leaking memory allocated for temporary storage of pinweaver variables. With this patch there memory is returned to the heap in all cases. BRANCH=cr50, cr50-mp BUG=b:69907320 TEST=multiple successive reboots of the Chromebook do not cause Cr50 resets due to memory allocation failures any more. Change-Id: I432bf44e25ce2a99df9ad580b350984f4b133b2c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1588876 Reviewed-by: Andrey Pronin <apronin@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* nvmem: protect flash accesses with a mutexVadim Bendebury2019-05-021-5/+85
| | | | | | | | | | | | | | | | | | | Multiple tasks could be trying to modify NVMEM concurrently. To avoid data corruption add a mutex which guarantees that only one thread of execution has access to the flash storing NVMEM objects. Various paths accessing flash contents are now protected by the same mutex. Mutex control functions are put in wrappers, which makes it easier to add debugging code when needed. BRANCH=cr50, cr50-mp BUG=b:69907320, b:130828517 TEST=attempts to take a device through RMA open do not fail any more. Change-Id: I6424477dced20d00f6165006cd3b3968433be6d0 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1584586 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* kukui_scp: Enable MPU to protect code RAM and data RAM in RW image.Yilun Lin2019-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kukui_scp is loaded into SRAM. We would like to protect the memory from a modified code RAM content and executing injected code in data RAM. BRANCH=None BUG=b:123269246 TEST=Apply MPU test patch https://crrev.com/c/1530265. Test data ram XN: 1. mpu 0 # disable MPU 2. mpu_test # see it prints 3. mpu 1 # enable MPU 4. mpu_test # memory access violation, and reset. 5. mpu_test # memory access violation, and reset # again. (MPU enabled by default) Test code ram RO: 1. rw 0x8 0x5566 # Write to code RAM and see memory # access violation and reset. 2. mpu 0 # disable MPU 3. rw 0x8 0x5566 # Nothing happended 4. rw 0x8 # Read 0x5566 5. mpu 1 # enable MPU 6. rw 0x8 0x5566 # memory access violation. Change-Id: I6af5029d8c55d795543d4759b2c9168a06eb9ff1 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1530264 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org>
* nvmem: populate default tpm objects after wipeoutVadim Bendebury2019-05-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | TPM memory wipe code is removing all TPM objects from the flash, including the reserved objects, which are supposed to be always present. The assumption was that the Cr50 would be reset after the wipe out and the initialization code would populated the reserved objects with default values. But in fact Cr50 reset is not guaranteed after TPM wipeout, so it is better to call the init function explicitly to make sure that all reserved objects are in the flash at all times. BRANCH=cr50, cr50-mp BUG=b:69907320 TEST='dump' command ran on the Cr50 console after RMA open shows all reserved objects present. Change-Id: Id9e227de0995c6491da9f38fc8ca11df3661c71f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1584658 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* battery: Consolidate battery_manufacturer_nameDaisuke Nojiri2019-05-011-0/+11
| | | | | | | | | | | | | | | | | | | | | Currently, the battery_manufacturer_name API is implemented individually by each chip. This patch consolidate the definitions. It also allows a board to return custom manufacturer names. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b/129599895 BRANCH=none TEST=buildall Change-Id: Ib0f60c9be71fea31658ab284a915d73341b9145e Reviewed-on: https://chromium-review.googlesource.com/1590039 Commit-Ready: YH Lin <yueherngl@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: YH Lin <yueherngl@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nvmem: add test of recovery from interrupted savesVadim Bendebury2019-05-011-0/+5
| | | | | | | | | | | | | | Add a test which introduces corrupted objects in the flash and verifies that the initialization function is able to recover. BRANCH=cr50, cr50-mp BUG=b:69907320, b:129710256 TEST='make run-nvmem' succeeds Change-Id: Ibb7d8181dfdeb097b79087cdae824564ec28921f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1590044 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* nvmem: fix delimiter creation during setvar()Vadim Bendebury2019-05-011-16/+54
| | | | | | | | | | | | | | | | | | | | The (key, value) objects should not be treated differently from TPM objects when initializing NVMEM from some inconsistent state. Saving of a modified (key, value) object should include the 'incomplete delimiter' phase when the new value has been already saved, but the old value has not yet been eliminated. Added tests verifying various failure modes. BRANCH=cr50, cr50-mp BUG=b:69907320, b:129710256 TEST='make run-nvmem' succeeds Change-Id: Ia53b6cfa2edd59fef28ace6978d752ca3cfbb2aa Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1590043 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* nvmem: add logging and restart on app_cipher failuresVadim Bendebury2019-05-011-2/+5
| | | | | | | | | | | | | | | Just in case there is a failure when encrypting or decrypting NVMEM objects, add code which detects problems, reports them in the flash log and reboots. BRANCH=cr50, cr50-mp BUG=b:69907320, b:129710256 TEST=none Change-Id: I22e55941f459b5b45bf4b23781b20601a56b40d8 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1590042 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* common: led_pwm: Enable pwm modules for each channels of LEDs.Mulin Chao2019-05-011-1/+21
| | | | | | | | | | | | | | | | | | | | | Since pwm_set_raw_duty() won't enable pwm module when its duty is not zero automatically after CL 1475096 was merged, this CL enables all pwm modules used by LEDs in init_leds_off(). Then we can see pwm output signals when set_led_color() is executed. BRANCH=none BUG=b:123552920 TEST=No build errors for npcx7 series. LED light was observed on grunt when a charger is plugged in. Change-Id: Icd2d19d24dc0354519561f145244f9ae8e9af93b Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1575883 Commit-Ready: Caveh Jalali <caveh@google.com> Tested-by: caveh jalali <caveh@chromium.org> Tested-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com>
* Flapjack: Disable charging from BC 1.2 charger as USB-C chargerDaisuke Nojiri2019-04-301-1/+2
| | | | | | | | | | | | | | | | | | | | | Currently, if a charger shows Rp=USB on USB-C port, the charge manager chooses it and sets the max current to 500 mA even if it can provide higher power as a BC 1.2 charger. This patch introduces CONFIG_USBC_DISABLE_CHARGE_FROM_RP_DEF. When it's defined, a BC 1.2 charger won't be recognized as a USB-C charger. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b/131353444 BRANCH=none TEST=Charge Flapjack from BC 1.2 charger on USB-C port. Change-Id: I50969973026185dd2aecdb768985cd116c1d32f7 Reviewed-on: https://chromium-review.googlesource.com/1586580 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* motion sense: Calculate loop time based on sensor needsMathew King2019-04-271-67/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the motion sense loop bases its sleep time based on the fastest active sensor. This method has several flaws: 1. It does not take into account any task switching overhead 2. With a mix of interrupt driven and forced sensors the sleep time gets recalculated every time there is an interrupt causing the loop to oversleep 3. If multiple sensors do not have rates that are in sync the timing of the slower sensor will be off. For example if there was a sensor running at 50 Hz and one running at 20 Hz the slower sensor would end up being sampled at about 16 Hz instead of 20 Hz This change calculates an ideal read time for every forced mode sensor and calculates the sleep time based on the nearest read time. Every time a sensor is read the next read time is calculated based on the ideal read time not the actual read time so that reading does not drift because of system load or other overhead. BUG=b:129159505 TEST=Ran sensor CTS tests on arcada, without this change the magnetometer was failing 50 Hz tests at about 38 Hz with 30% jitter with this change in place 50 Hz was spot on with about 10% jitter BRANCH=none Change-Id: Ia4fccb083713b490518d45e7398eb3be3b957eae Signed-off-by: Mathew King <mathewk@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1574786 Reviewed-by: Jett Rink <jettrink@chromium.org>
* ccd: delay sleep while opening ccdMary Ruthven2019-04-272-16/+11
| | | | | | | | | | | | | | | | | Cr50 may enter deep sleep while wiping the TPM. This change adds a sleep delay before opening ccd. BUG=b:130646257 BRANCH=cr50 TEST=manual dut-control cold_reset:on run ccd open make sure ccd is open even after entering deep sleep Change-Id: Id44b608702b664621bd2441f62a03ba6428135cf Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1585606 Reviewed-by: Namyoon Woo <namyoon@chromium.org>
* cr50: Support legacy U2F key handlesLouis Collard2019-04-251-5/+48
| | | | | | | | | | | | | | | | | | | | | | The new U2F functions make use of a new key derivation scheme. This adds a flag clients can specify that allows the new functions to also sign requests using a legacy key handle. This will allow continued support of legacy key handles in Chrome OS whilst allowing the legacy code to be removed from cr50. BUG=b:112603199, b:123161715 TEST=with new cr50 and u2fd patched to send new param: - register legacy key handle with Google - restart u2fd with user keys and no fallback - check login fails - restart u2fd with user keys and fallback - check login succeeds Signed-off-by: Louis Collard <louiscollard@chromium.org> Change-Id: Ib3164e9c0856d51b958fa8db181153b5b2227850 Reviewed-on: https://chromium-review.googlesource.com/1580622 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* tasks: convert TASK_EVENT_CUSTOM macro to bitJett Rink2019-04-246-11/+11
| | | | | | | | | | | | | | | | | | | | | We should ensure that all custom task definition are non-zero and fit with the globally defined events. Add compile time check and change semantics to specify bit number (instead of making all callers use the BIT macro). This also fixes an error with TASK_EVENT_PHY_TX_DONE for ITE being 0. The bug that made that happen hasn't landed on any firmware branches that use it though. BRANCH=none BUG=none TEST=builds Cq-Depend:chrome-internal:1178968,chrome-internal:1178952 Change-Id: I5e1d1312382d200280c548e9128e53f4eddd3e61 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570607 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* mkbp: take timestamp closer to hardware interruptJett Rink2019-04-241-15/+2
| | | | | | | | | | | | | | | | | We want to ensure that the timestamp we take for last mkbp is as close to the actual hardware interrupt from EC->AP. BRANCH=none BUG=b:129159505 TEST=passing CTS sensor run (except test 133 nullptr) with this change Change-Id: I94b214f021f0b63ff2883e5fe8e32acc83ce208f Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1560390 Tested-by: Alexandru M Stan <amstan@chromium.org> Reviewed-by: Enrico Granata <egranata@chromium.org> Reviewed-by: Mathew King <mathewk@chromium.org> Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* cleanup: update TASK_EVENT_CUSTOM usageJett Rink2019-04-231-11/+10
| | | | | | | | | | | | | | | | | | The lightbar.c uses the TASK_EVENT_CUSTOM macro in a non-standard way comparing it to the rest of the code base. Update the style in preparation for changing the TASK_EVENT_CUSTOM macro to be a BUILD_CHECK_INLINE macro. Without this cleanup CL, this code breaks. BRANCH=none BUG=none TEST=builds Change-Id: I4fdbb35a2aeeb1f8718b22c017607aee5fa1730a Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570606 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* P9221: Add P9221 driverTony Zou2019-04-222-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds P9221 driver and enable it for Flapjack. The driver originates from https://android.googlesource.com/kernel /msm/+/android-msm-bluecross-4.9-pie-qpr1/drivers/power/supply/qcom /p9221_charger.c CQ-DEPEND=CL:1445133 CL:1551583 BRANCH=none BUG=b:126162615 TEST=Verify charging from PD and WPC as follows: 1. Charge with PD charger. Place DUT on WPC charger. -> PD charger continues to charge. 2. Unplug PD charger. -> WPC starts charging as GPP. 3. Plug PD charger. -> PD charger starts charging at 2A@9V TEST=Verify OTG and WPC functionality as follows: 1. Plug fan to USB port: -> Fan spins 2. Place DUT on WPC charger: -> WPC starts charging as GPP. Fan continues to spin. 3. Remove DUT from WPC charger: -> Fan continues to spin. 4. Do 1 and 2 then unplug USB fan: -> WPC starts charging. TEST=/sys/class/power_supply/CROS_USBPD_CHARGER0/usb_type is BrickID /sys/class/power_supply/sbs-12-000b/status is ok Change-Id: I5fbd0237cedd8095f98582c39973d432e733f2cd Signed-off-by: Tony Zou <zoutao@huaqin.corp-partner.google.com> Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1448193 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* factory_mode: refactor factory_enable_failedMary Ruthven2019-04-221-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor factory_enable_failed, so cr50 always resets if a reset is requested. This change also renames factory_enable_failed to be more specific. It renames ccd_hook_active to wait_for_factory_ccd_change so it's obvious what the variable is doing. It's waiting for the ccd_config change after we enable factory mode. Enabling factory mode can fail in a lot of ways, but by the time we called factory_enable_failed, the failure is specifically about saving the config. This change renames the function, so the failure is a bit more specific. If a reset is required, always reset the system even if saving the factory config failed. ccd_reset_factory_failed is triggered if the ccd changed hook isn't triggered quickly enough or if cr50 fails to save the ccd config. Cr50 has already wiped the TPM and has most likely saved some if not all of the factory mode state. Cr50 should still reset even if the config isn't saved to be safe. enable_ccd_factory_mode isn't used in the process to enable factory mode during init, so this change won't cause a cr50 reboot loop from cr50 trying and failing to enable factory mode during init. This only affects the RMA and factory mode enable vendor commands. BUG=b:129956462 BRANCH=cr50 TEST=Use rma and factory mode vendor commands to enable factory mode. Change-Id: Ib8a502297040296fb0a2250a9e8945af330d4334 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1572450 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org>
* common: led_onoff_states: add new LED state for fully charged in S5Devin Lu2019-04-201-3/+20
| | | | | | | | | | | | | | | | Synchronize with CL:1419477 to common/led_onoff_states. BUG=none BRANCH=none TEST=make buildall -j Change-Id: Ibb5d9150f03cb7a584d7439bc47d5b59de856502 Signed-off-by: Devin Lu <Devin.Lu@quantatw.com> Reviewed-on: https://chromium-review.googlesource.com/1556859 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Marco Chen <marcochen@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* ccd: make ccd open error more meaningfulMary Ruthven2019-04-191-2/+1
| | | | | | | | | | | | | | | | | | | | | Right now if 'ccd open' from the console fails, it pretty much always fails with "nopwd". This error is pretty meaningless, because you can't even set the password until you open ccd. This change suggests removing the battery or sending the open command from the AP in dev mode if ccd open fails. This error should help people remember their device needs to be in dev mode and open needs to be sent from the AP. BUG=b:73170050 BRANCH=cr50 TEST=try 'ccd open' from the console. Verify the error message is changed. Change-Id: I32ca72ed00e03e62d73942961137591dc69bc8fa Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1572156 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Namyoon Woo <namyoon@chromium.org>
* common/usbc_ppc: Fix potential illegal memory access.Tim Wawrzynczak2019-04-191-1/+3
| | | | | | | | | | | | | | | Recent coverity scan indicated a potential illegal memory access in ppc_enter_low_power_mode(). This patch fixes it. BUG=none BRANCH=none TEST=Compiled Change-Id: I0df1ca23340cd4466f8e71349b89ca1ab68aadbf Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1574099 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* CBI: Allow board to compose data from other sourcesDaisuke Nojiri2019-04-191-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the source of CBI data is only EEPROM. This patch allows CBI data to be composed from other sources such as ADC or some chip register. cbi_board_override is called by CBI library when data is being requested. Boards can implement this callback to add additional bits or bytes to the data. A board itself may need to get CBI data first to manipulate data properly. For such a case, a board can return EC_ERROR_BUSY to inform the callers that the data is not fully ready while a board itself can accept EC_ERROR_BUSY as an expected value. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=b/129569858 BRANCH=none TEST=Read LCM_ID properly Change-Id: Ie1f962c64c8d1461a6c171bc6c6d0c855c82e945 Reviewed-on: https://chromium-review.googlesource.com/1572439 Commit-Ready: YH Lin <yueherngl@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Common: move for loop initial declarationDiana Z2019-04-181-2/+6
| | | | | | | | | | | | | | | While builds on cros/master allow variables to be initially declared in for loop statements, builds on firmware branches (ex. octopus) may not. BUG=None BRANCH=octopus TEST=builds on master, builds picked to octopus branch Change-Id: I450d8c564b508a5f51a7784ce67b0664ab97d8ba Signed-off-by: Diana Z <dzigterman@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570609 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* util/ectool, common/system: Share sysmbol reset_flag_desc.Yilun Lin2019-04-181-10/+10
| | | | | | | | | | | | | | | | | There were two symbols reset_flag_desc and reset_flag_strings used in two separated places: host binary ectool and device. This CL combines these two symbols to reduce maintance efforts. TEST=make buildall -j BRANCH=None BUG=None Change-Id: I3b5731ab08804f46629d6e43466dce963bd86a69 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1514395 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
View Lorry Controller Status