summaryrefslogtreecommitdiff
path: root/chip
Commit message (Collapse)AuthorAgeFilesLines
* chip/stm32: Support for I2C4 instance on STM32L4/5Jes B. Klinke2023-05-174-7/+42
| | | | | | | | | | | | | | | | | | | The L4/L5 families have four I2C controllers. The fourth has its registers in a separate region, and enable bits are not contiguous with the first three. This CL adds a few if-statements in i2c driver code, in order to support all four controllers. BUG=b:282999020 TEST=Observe I2C activity on HyperDebug I2C4 Change-Id: If27eda73b3da32190bad7df5db8c6bb6c78b4c5c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4537011 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* NPCX9: Allow boards to customize MIWU interrupt priorityDaisuke Nojiri2023-05-152-16/+67
| | | | | | | | | | | | | | | | This CL will add macros used to set MIWU interrupt priorities. These macro can be set by each board to adjust priorities as needed. BUG=b:279918234 TEST=build agah Change-Id: Ide840e4ab8cc9aa8deb83b6ad76fa64bc0d83972 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4518230 Auto-Submit: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Tarun Tuli <taruntuli@google.com> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Mulin Chao <mlchao@nuvoton.com> Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
* chip: add support for npcx trngDavid Cross2023-05-152-0/+252
| | | | | | | | | BUG=b:280889889 TEST=add CONFIG_RNG to NPCX based board.h file (e.g. npcx9_evb) Change-Id: I93b3a7742c3b7d614cc1218104cd642b3339f8b3 Signed-off-by: David Cross <davidmcross@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4507895 Reviewed-by: Bobby Casey <bobbycasey@google.com>
* common: move chip agnostic trng code from stm32 to commonDavid Cross2023-05-122-70/+6
| | | | | | | | | | | | | | | | | | | | | Making this change causes common trng functions to move memory locations. This change only affects fingerprint (FPMCU) boards BUG=b:280889889 TEST=make BOARD=bloonchipper, CONFIG_CMD_RAND enabled in board.h ALLOW_CONFIG=1 ./util/compare_build.sh -b all => All boards match, except the following Fingerprint boards: bloonchipper dartmonkey hatch_fp nami_fp nocturne_fp nucleo-dartmonkey Change-Id: I4dbb5e255be0f61eb7b446af4565bea487c08e52 Signed-off-by: David Cross <davidmcross@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4507892 Reviewed-by: Bobby Casey <bobbycasey@google.com>
* chip/stm32: Support dynamic I2C speed on L4/L5 seriesJes B. Klinke2023-05-051-5/+10
| | | | | | | | | | | | | | | The file i2c-stm32l4.c practically already had support for changing I2C speed. This CL renames and exports the function for setting speed, such that i2c_controller.c can call it. BUG=none TEST=Observe HyperDebug I2C still working, and now able to change speed Change-Id: I2fbe674795f9e8ed0b8d324cc1ff68f4df4174a4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4506619 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* it83xx/adc: Use 64-bit int for voltage calculationReka Norman2023-05-041-1/+1
| | | | | | | | | | | | | | | | For some voltage dividers, factor_mul is large enough that the intermediate value can overflow, so use a 64-bit int. BRANCH=None BUG=b:271941405 TEST=VBUS ADC calculation doesn't overflow on dibbi Change-Id: I993e62e7c0ae31c70f962303e7a618841f2bc772 Signed-off-by: Reka Norman <rekanorman@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4506010 Commit-Queue: Reka Norman <rekanorman@chromium.org> Tested-by: Reka Norman <rekanorman@chromium.org> Reviewed-by: Sam McNally <sammc@chromium.org>
* chip/stm32: Simplify usb_spi.c macro useJes B. Klinke2023-05-032-200/+163
| | | | | | | | | | | | | | | Moving the body of the USB_SPI_CONFIG() macro into usb_spi.c allows eliminating the "trampoline functions", for a slight performance improvement, and simplification of the code. BUG=b:273601311 TEST=HyperDebug still able to forward SPI requests Change-Id: Id64c0a30c791962dbe4360c92dc512e6c2adc2f6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4370998 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Brian Nemec <bnemec@google.com> Commit-Queue: Jes Klinke <jbk@chromium.org>
* npcx: SPI: add asynchronious transaction APIsJun Lin2023-05-031-23/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | As the finger printer sensor needs multiple SPI transactions in the same command state without de-asserting the CS pin, this commit implements: - spi_transaction_async() - does the same thing as the original spi_transaction does but keeps asserting the CS pin. - spi_transaction_flush() - de-assert the CS pin. - spi_transaction_wait() - a noop function as we don't support SPI DMA. The original spi_transaction() is hence changed to call spi_transaction_async() and spi_transaction_flush() to prevent code duplication. BRANCH=none BUG=b:266703380, b:269695617 TEST=Test console commands spi_flashinfo/spi_flashread/spi_flashwrite/spi_flasherase. TEST=write a test console command to read the unique ID from flash with multiple spi_transaction_async() calls + 1 spi_transaction_flush() call. Change-Id: I3aacef0063a7cf2c1f70dfe2683b67110cdd9f5f Signed-off-by: Jun Lin <CHLin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4305803 Reviewed-by: Bobby Casey <bobbycasey@google.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: David Cross <davidmcross@google.com> Commit-Queue: David Cross <davidmcross@google.com>
* npcx: driver: SPI: extend driver to support concurrent modeJun Lin2023-05-021-2/+14
| | | | | | | | | | | | | | | | | | | | | | | This CL extends the SPI controller driver to support the concurrent transaction: - if the parameter "rxlen" is set to SPI_READBACK_ALL when spi_transaction() is called, the received data during the transmission phase should be stored in the "rxdata" buffer. BRANCH=none BUG=b:268286582 TEST=Loopback test on the npcx9 EVB, make sure the received data in the rxdata buffer is the same as that in the txdata buffer. Change-Id: Ia5ae17fefb69ce18709ded87693b34ed861f4997 Signed-off-by: Jun Lin <CHLin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4259466 Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: David Cross <davidmcross@google.com> Commit-Queue: David Cross <davidmcross@google.com> Reviewed-by: Bobby Casey <bobbycasey@google.com>
* npcx: watchdog: support the longer watchdog timeoutJun Lin2023-04-271-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | In the current pre-scalar setting (fixed to 0), the max watchdog timeout that the user can set is ~8 seconds. It is not enough for some application requirements such as FPMCU. This commit extends the max timeout by adjusting the pre-scalar dynamically. BRANCH=none BUG=b:273577369 TEST=pass "make buildall -j" TEST=Change the CONFIG_WATCHDOG_PERIOD_MS > 8 seconds; type console command "watims ${timeout}"; make sure watchdog panic occurs as expected. TEST=Set the CONFIG_WATCHDOG_PERIOD_MS to the default (1600); make sure WDCNT and WDCP are the same before/after applying this commit. Change-Id: I11b764811f65f0956593ab6725a619a1a44464c4 Signed-off-by: Jun Lin <CHLin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4444452 Reviewed-by: David Cross <davidmcross@google.com> Tested-by: David Cross <davidmcross@google.com> Commit-Queue: David Cross <davidmcross@google.com> Reviewed-by: Bobby Casey <bobbycasey@google.com>
* ec: add support for npcx9m8sDavid Cross2023-04-262-0/+28
| | | | | | | | | | | BUG=none TEST=`make BOARD=helipilot` BRANCH=none Signed-off-by: David Cross <davidmcross@google.com> Change-Id: Ib6e0ccc2eac31f47326e27459c9ee8c32585a7ec Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4007183 Reviewed-by: Bobby Casey <bobbycasey@google.com> Reviewed-by: CH Lin <chlin56@nuvoton.com>
* clock: Add mock for clock_enable_moduleYi Chou2023-04-2517-19/+20
| | | | | | | | | | | | BUG=b:248508087 TEST=make buildall -j BRANCH=none Force-Relevant-Builds: all Change-Id: If691bd1400b65c5595b833293578e16208c49849 Signed-off-by: Yi Chou <yich@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4376399 Reviewed-by: Tom Hughes <tomhughes@chromium.org>
* chip/stm32: Add extensions for flash programmingJes B. Klinke2023-04-182-36/+368
| | | | | | | | | | | | | | | | | | | | | | | Add support to usb_spi.c for processing a new "Flash Command Start" packet, as an alternative to the existing "Command Start" packet. The new serial flash version carries additional flags, among others, to request a one-byte "Write enable" transaction to take place before the main transaction, and to request repeated polling of the "busy bit" after the main transaction. These allow the number of USB round trips to be reduced when using Servo Micro or C2D2 for flash programming. Also, flags of the new request allow the caller to ask for dual or quad lane communication, which can be supported by board-specific SPI drivers. This is intended for use on the HyperDebug debugger board. BUG=b:273601311 TEST=c2d2 flashing gets slight performance boost Change-Id: Id4d1ec9f37387b4e083a397ca15300455f7a0ada Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4346952 Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* chip/stm32: Remove unwanted protool extensionJes B. Klinke2023-04-181-85/+0
| | | | | | | | | | | | | | | This first attempt turned out to be too closely coupled to the capabilities of the STM32L5xx OctoSPI, allowing odd combiations that is never used by actual SPI flash chips. BUG=b:273601311 TEST=make BOARD=c2d2 Change-Id: I3fd5b1356d1c2c3a7d63dbdf8e1a5fd45ddfe0a1 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4432090 Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* clock: Remove the weak definition clock_enable_moduleYi Chou2023-04-1810-0/+47
| | | | | | | | | | | | | | | | | BUG=b:248508087 TEST=make buildall -j200 TEST=./util/compare_build.sh -b all => Most of the compare result match except for adlrvpm_ite, adlrvpp_ite, adlrvpp_mchp1727, cozmo, icarus, it8xxx2_pdevb, mchpevb1, npcx_evb, npcx_evb_arm pico. And differ the change is the address of clock_enable_module. BRANCH=none Change-Id: I5750c5d5037f303f6cf55a73a1cd5a9501b49aa1 Signed-off-by: Yi Chou <yich@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4369174 Reviewed-by: Tom Hughes <tomhughes@chromium.org>
* trng: Drop trng_rand() functionPatryk Duda2023-04-131-1/+1
| | | | | | | | | | | | | | | | | | | The function is not used anywhere except test/rng_benchmark.cc, so we will have a problem with code coverage when implementing the function using Zephyr API. The RNG benchmark was modified to use trng_rand_bytes() function. BUG=b:277029648 BRANCH=none TEST=./test/run_device_tests.py --board bloonchipper -t rng_benchmark Change-Id: Ic6cf7e511b2e8fe88a08e9e1c4354f7afa9ae425 Signed-off-by: Patryk Duda <pdk@semihalf.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4423151 Tested-by: Patryk Duda <patrykd@google.com> Commit-Queue: Patryk Duda <patrykd@google.com> Reviewed-by: Keith Short <keithshort@chromium.org>
* ish: increase HECI response buffer sizeLi Feng2023-04-041-2/+14
| | | | | | | | | | | | | | | | | | | | | HC version v1 response has 132 bytes, but ISH response buffer is smaller than this. We will get error as below: localhost ~ # ectool version --name=cros_ish EC result 14 (RESPONSE_TOO_BIG) Hence increase ISH response buffer size to 260 bytes. BUG=b:271502099 BRANCH=none TEST=on Rex platform with ISH enabled, "ectool version --name=cros_ish" will print firmware version, no error. Change-Id: I81cbea19a2b4719b88b232bfea02803b0a244b89 Signed-off-by: Li Feng <li1.feng@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4302834 Reviewed-by: Yuval Peress <peress@google.com> Reviewed-by: Tanu Malhotra <tanu.malhotra@intel.com>
* chip/stm32: Eliminate run-time flags to usb_spi.cJes B. Klinke2023-03-282-18/+3
| | | | | | | | | | | | | | | | | | | | | The USB_SPI_CONFIG() macro allowed a set of "run-time" flags to be given by board.c. However, these flags have to be known at compile time, and always are. They can more conveniently be given through a CONFIG_ define. With the above, and a little tweak in hammer/board.h (mimicking what was already done for I2C), then every invocation of the USB_SPI_CONFIG() across the codebase is identical, setting the stage for moving the declarations into usb_spi.c, and eliminating the macro altogether. BUG=b:273601311 TEST=none Change-Id: Id565338238a7c21f7e2c6c24b7c4e3d7648482f6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4368551 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Brian Nemec <bnemec@google.com> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Eliminate support for multiple USB->SPI instancesJes B. Klinke2023-03-282-197/+175
| | | | | | | | | | | | | | | | | | | | For some reason, all methods in usb_spi.c pass along pointers to config and state, as if prepared to have multiple USB interfaces each implementing their own instance of the SPI->USB bridge protocol. Doing so would make little sense, as a single instance is already able to manipulate multiple SPI busses. This CL eliminates the pointer parameters, for a tiny performance improvement, and code simplification. BUG=b:273601311 TEST=none Change-Id: Ifbfdb18b4a2ba656732e4eb143de9f678416067a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4352128 Reviewed-by: Brian Nemec <bnemec@google.com> Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* ite83xx: Remove false-alarm EC panic reportsAaron Massey2023-03-231-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pre-watchdog warning interrupt handler currently invokes get_panic_data_write() to retrieve a pointer to panic data. This has a side-effect of initializing the panic data with PANIC_MAGIC and a panic data size without other pertient fields set. As a result, the EC reports malformed panic to the AP causing an unparsable EC crash to be reported. Revert the ITE watchdog warning interrupt usage of get_panic_data_write() to using the global PANIC_DATA_PTR pointer to panic data. BRANCH=none BUG=b:247100203 TEST=On drawcia, dead battery boot, invoke waitms 1100 (pre-wdt warning), invoke ectool panicinfo to check for well-formed panic data TEST=On drawcia, invoke crash watchdog, invoke ectool panicinfo to check for well-formed panic data. Change-Id: I5a75bec0efa79d00c358edc0645a0a0d39a879d2 Signed-off-by: Aaron Massey <aaronmassey@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4358752 Reviewed-by: Boris Mittelberg <bmbm@google.com> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* chip/stm32: Interface extensions for serial flashJes B. Klinke2023-03-172-17/+114
| | | | | | | | | | | | | | | Enhance the interface to board-specific SPI driver such that it can take flags for advanced serial flash chip protocols (dual/quad lanes, dummy cycles, double transfer rate). BUG=b:273601311 TEST=c2d2 can still flash (using single-lane) Change-Id: Iee6a17077ea8c382c7d59bd404bf5d033bd9b517 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4336273 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* NPCX9: Enable SHA256 acceleratorDaisuke Nojiri2023-03-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | This patch enables SHA256 accelerator for all boards using NPCX9. Before: [0.007394 hash start 0x00040000 0x0002f97c] [0.291092 hash done e7faf382c6bd60c892cb4af...] After: [0.038571 hash start 0x00040000 0x0002f97c] [0.095532 hash done e7faf382c6bd60c892cb4af...] BUG=b:272132276 BRANCH=None TEST=Agah Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: I10660e423ee16b2a6bcb3dd147593b6c7e4cf952 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4348896 Reviewed-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Enable asynchronous write-only SPI transactionsJes B. Klinke2023-03-161-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During my investigation into performance of SPI flashing with servo-like devices, I stumbled upon an odd behavior. It seems that asynchronous execution of write-only SPI transactions does not quite work on STM chips. For transactions that consist of writing a few bytes followed by reading a block of data, the current spi_transaction_async() works well, in that it first performs the write part, then waits for the DMA to finish, before setting up the larger read part, and returning without waiting for it to finish. Later, spi_transaction_flush() will call spi_dma_wait() to know when the transfer has completed. For write-only transactions, however, spi_transaction_async() blocks in its "intermediate" spi_dma_wait(), before realizing that there is nothing to read, meaning spi_transaction_async() in effect blocks until the transaction is complete, and the subsequent spi_dma_wait() in spi_transaction_flush() is superfluous. I have found that with this very small change, spi_transaction_async() will return soon after a write-only transaction has been initiated, and spi_transaction_flush() will wait for its completion. BUG=b:273601311 TEST=Flash using c2d2 and HyperDebug Change-Id: I015f2870b1f0e561050b75618545dee6bcf04690 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4336269 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* Replace CONFIG_DMA with CONFIG_DMA_CROS in EC codebasePatryk Duda2023-03-014-4/+4
| | | | | | | | | | | | | | | | The config from EC collides with the same config from Zephyr. BUG=b:239712345 BRANCH=none TEST=make runhosttests buildall Change-Id: Ic6e63ea6dd9e745e82feb2af04b77069c2d78af1 Signed-off-by: Patryk Duda <pdk@semihalf.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4295699 Reviewed-by: Keith Short <keithshort@chromium.org> Reviewed-by: Tom Hughes <tomhughes@chromium.org> Commit-Queue: Patryk Duda <patrykd@google.com> Tested-by: Patryk Duda <patrykd@google.com>
* chip/stm32: ADC fixesJes B. Klinke2023-02-212-29/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ADC drivers for STM32L4 (and L5) seems to have significant flaws. The chip has the ability to continuously perform ADC conversions according to a set sequence of channels and bit depths. In addition to that, the chip can perform a one-off "injected" sequence of up to four channels, in response to a hardware or software trigger. The driver uses only a software triggered "injected" sequence to convert two pre-set channels. The code of `adc_read_channel()` has some odd properties, though. On first invocation, it sets up the injected sequence to consist of the two configured ADC channels. Each invocation takes one particular ADC channel number as input, but the code simply kicks of the sequence of two channels to read, and then returns the relevant of the two, discarding the other reading. The has the needless limitation that it cannot be used with more than two ADC channels. Since it is permitted to modify the list of channels in the injected sequence as long as no conversion is in progress, it would be more straightforward, if each invocation of `adc_read_channel()` would reconfigure the injected sequence to consist of a single channel, the one requested. This CL makes that change. BUG=b:269621551 TEST=Read and of a dozen ADC channels on HyperDebug Change-Id: I62387979faf494cfefc3b6e7dd1d9a1954017ae6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265223 Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Eric Yilun Lin <yllin@google.com> Auto-Submit: Jes Klinke <jbk@chromium.org> Reviewed-by: Eric Yilun Lin <yllin@google.com>
* chip/stm32: Sample time off-by-oneJes B. Klinke2023-02-183-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The STM32L4/5 ADCs use three bits to configure the time to sample the input voltage, that is the time during which an analog MUX conducts, allowing the internal holding capacitor to settle. The enums declared in adc_chip.h has eight usable values, plus an additional value called DEFAULT. It makes sense to have the DEFAULT be represented by a zero value, such that if a board.c file does not mention the sample_time field in its adc_t, then due to the C convention of data being zero-initialized, the code can detect it and apply a sensible default. However, the body of adc_configure() has no such logic, but takes the raw enum value and attempts to stuff it into a 3-bit field, which will be off by one, and overrun for the largest enum value of 8. Also, I find the term "sample rate" misleading, as it implies a continuous process. This sample time setting applies equally to one-off injected conversions, as it refers to the duration of the sampling of the input signal, before conversion begins, not a rate of conversions happening. BUG=b:269621551 TEST=Made measurements with the longest same time setting Change-Id: Id8d297fcec883565dea1e09d6bbbfa1ab564778d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265222 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Add warnings in stm32l4 files also used by L5Jes B. Klinke2023-02-172-0/+4
| | | | | | | | | | | | | | | | | | In several cases, the L4 and L5 series can use the same driver, which is different from other STM32Lx chips. This CL introduce a warning at the top of such files, alerting readers to the fact that they are also used by L5 despite this not being apparent from the file name. BUG=b:269621551 TEST=none Change-Id: I6edff6c0aea57ea9679729db20a292d75b4b8df0 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4264176 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* chip/stm32: ADC status register "write 1 to clear"Jes B. Klinke2023-02-171-2/+9
| | | | | | | | | | | | | | | | The convention of the STM32_ADC1_ISR register is that writing a 1 to any bit clears that one latched interrupt status bit. Existing code wrongly uses |= on this register, effectively clearing every latched bit in the register, not merely the intended one. BUG=b:269621551 TEST=Observe ADC conversions on HyperDebug Change-Id: Ia9fe3f6ca6f2f67614628b23bc7ba2e3a3caf058 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265221 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Extend ADC support to L5xx familyJes B. Klinke2023-02-174-6/+12
| | | | | | | | | | | | | | | | | The L5 family has basically the same ADC component as L4. L5 does not have ADC3, but that happened to not be used by the stm32l4.c, so the existing implementation can be used without modification. BUG=b:269621551 TEST=Observe ADC conversions on HyperDebug Change-Id: I4ce279dca3ff23ae2a9d2f00c23399732eecf15f Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265220 Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Fix for opting out of flash supportJes B. Klinke2023-02-081-1/+4
| | | | | | | | | | | | | Adapt dfu_bootmanager_main.c to compile without flash support. BUG=b:192262089 TEST=make BOARD=hyperdebug Change-Id: I9ceca733062b46ed7087ef7725bc1f6ac68c6b0a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4193071 Commit-Queue: Jes Klinke <jbk@chromium.org> Reviewed-by: Brian Nemec <bnemec@google.com> Tested-by: Jes Klinke <jbk@chromium.org>
* chip/stm32/clock-stm32l4: Fixed clock cmd documentationJes B. Klinke2023-02-051-2/+2
| | | | | | | | | | | | | | | | | | Looking at the code, it is apparent that the "pll" parameter to the "clock" console command is valid whether STM32_HSE_CLOCK is defined or not (though the effect may be slightly different). This CL updates the documentation to list "pll" as a valid option also when STM32_HSE_CLOCK is not defined. BUG=none TEST=make BOARD=hyperdebug Change-Id: I7da89c15b44fbc3dad2a5fe129b0e361d7f50714 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4216263 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* chip/stm32/dfu_bootmanager_main: Add memory barrierJes B. Klinke2023-02-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | ARM Cortex documentation calls for an ISB instruction to be executed immediately after modifying the stack pointer, see for instance: https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-processor/programmers-model/core-registers It would seem that instruction prefetch will "anticipate" stack pointer movements by counting the push and pop instructions, and that the prefetch queue needs to be cleared if the stack pointer is manually changed. Our particular code executes does not use the stack pointer, but executes a register jump, which I assume will also clear the prefetch queue. So in all likelihood, the barrier instructions is not required here, but we could as well add it, as the documentation calls for it. BUG=none TEST=make BOARD=hyperdebug, observe DFU upgrading still works Change-Id: I2a0609670b3554a39057b429fc2e0cd1201d185c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4216262 Reviewed-by: Brian Nemec <bnemec@google.com> Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org>
* ec: Use chromite isort configJeremy Bettis2023-02-034-0/+4
| | | | | | | | | | | | | | | | | | Remove the .isort.cfg from platform/ec and use the one from chromite instead. This should be compatible with cros format. BRANCH=None BUG=b:267757300 TEST=Ran firmware_builder.py Change-Id: Ice4955b6995bd1f9380e97f58e89efb7c1e8aeb1 Signed-off-by: Jeremy Bettis <jbettis@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4221928 Auto-Submit: Jeremy Bettis <jbettis@chromium.org> Tested-by: Jeremy Bettis <jbettis@chromium.org> Commit-Queue: Jeremy Bettis <jbettis@chromium.org> Commit-Queue: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* chip/stm32: Modification to DFU for STM32L5Jes B. Klinke2023-01-253-18/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The STM32L5 series behaves the same as STM32L4 to a large degree, so this CL adds code to enable RTC clock on L5 using the same register bits as on L4. The "backup registers" however, sit in a new "Tamper" component on L5, and not in the RTC component as on L4. This CL adds register declarations for the TAMP component. Lastly, jumping to the ROM bootloader with C function pointer call, as was done in jump_to_dfu(), does not work on the STM32L5 ROM bootloader (at least not on my Nucleo-X552EZ board.) The flaw seems to be that an ARM vector table contains a reset vector, and separately contains an initial value for the stack register. The previous code made no attempt at setting the stack point as the bootloader expected, and depending on how the EC code (and the STM ROM bootloader) is compiled, this may or may not work. This CL adds assembly code to set the stack pointer to the value given in the ROM header, before performing the jump. BUG=b:192262089 TEST=Upgrade firmware on STM32L5 based Nucleo board using dfu-util Change-Id: I2a871f0eaf9ea9f4c27c75ccb472cd4ff9616524 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4190164 Reviewed-by: Brian Nemec <bnemec@google.com> Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chip/stm32: Correction to EXTI register declarations for STM32L5Jes B. Klinke2023-01-243-13/+60
| | | | | | | | | | | | | | | | | | Originally, I copied STM32L4 declarations for STM32L5, making adjustments for base addresses, and other obvious differences. It turns out that the external interrupt controller has som subtle changes to its registers. Most notably the EXTICR registers (used for selection which external pin is routed to which of the 16 edge detection "engines") have been moved from the SYSCFG component into EXTI component. BUG=b:192262089 TEST=Observe edge detection working on HyperDebug (based on STM32L5) Change-Id: I4ad4f2559c60bef73a29812ebac1316cfa389a3e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4166670 Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* mchp: Remove undefined behavior in espi msvw handlersDustin L. Howett2023-01-231-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code in espi_msvw[12]_interrupt relies on undefined behavior today. __builtin_ctz is specified as returning values in the range [0, 31], but we are checking for 32. This behavior may be unexpected compared to the CTZ/CLZ instruction on ARM, which use the value 32 to indicate that there are no ones in the provided input. GCC 11+ optimizes the two loops below into infinite loops, as it can see that the condition will never be met. After this change, the disassembly of espi_mswv1_interrupt can be confirmed to contain an exit behind a branch. ... // r4 is loaded with girq24_result and has bits successively cleared 1a: b90c cbnz r4, 20 <espi_mswv1_interrupt+0x20> 1c: e8bd 81f0 ldmia.w sp!, {r4, r5, r6, r7, r8, pc} 20: fa94 f5a4 rbit r5, r4 ... BUG=None BRANCH=main TEST=Examined the disassembly for espi_msvw[12]_interrupt; see above Change-Id: I68a5c753233a17b6b0fb61a31f1eeccf78c00aba Signed-off-by: Dustin L. Howett <dustin@howett.net> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4114450 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org>
* chip/stm32: Fix copy/paste errorJes B. Klinke2023-01-181-2/+2
| | | | | | | | | | | | | | | | Existing code for extracting chip independent EC pin flags from stm32 registers suffered from a copy/paste error, meaning that it could never recognize interrupt triggering on a falling edge. BUG=none TEST=make BOARD=hyperdebug Change-Id: I4c752b092bfd3c6ea70192006a9453e0b81b0d9b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4166669 Tested-by: Jes Klinke <jbk@chromium.org> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* tree: Replace "unsigned" with "unsigned int"Andrea Grandi2023-01-0412-58/+60
| | | | | | | | | | | | | | | | | Fix checkpatch error: > Prefer 'unsigned int' to bare use of 'unsigned' BUG=b:262047616 TEST=./util/compare_build.sh -b all -j 120 => MATCH BRANCH=none Change-Id: Ibf82332a1e1ea0a0a03d3993336e24883e495e05 Signed-off-by: Andrea Grandi <agrandi@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4126483 Reviewed-by: Tom Hughes <tomhughes@chromium.org> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
* npcx9: SHA256: Fix the code definition of enum ncl_statusJun Lin2022-12-191-3/+3
| | | | | | | | | | | | | | | | | | | The coding of the enum ncl_status is not correctly defined in the SHA256 chip driver. This CL fixed it to meet the actual return code from the SHA ROM API. BRANCH=none BUG=b:155771688 TEST=manually dump and check the return value from SHA ROM API. Change-Id: Iee3ec5c7102ddc93f7afda6523c59393a5a0047a Signed-off-by: Jun Lin <CHLin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4113813 Commit-Queue: Keith Short <keithshort@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org> Tested-by: CH Lin <chlin56@nuvoton.com> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Reviewed-by: Fabio Baltieri <fabiobaltieri@google.com>
* chip/stm32: Add register declarations for OctoSPIJes B. Klinke2022-12-091-0/+291
| | | | | | | | | | | | | | | | The STM32L5 series of chips have a SPI controller capable of using up to eight data lines for fast transfers, primarily with SPI flash chips. This CL adds declarations of register addresses and bits. BUG=b:192262089 TEST=Flashed OpenTitan FPGA via HyperDebug OctoSPI Change-Id: I33d16ba493756cf338353a5f0952be97070720d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4087327 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Tested-by: Jes Klinke <jbk@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chips/stm32/usb_spi: Allow boards to handle non-standard SPI bussesJes B. Klinke2022-12-092-1/+27
| | | | | | | | | | | | | | | | | | The STM32L5 series has a special "OctoSPI" controller, which differs from the standard spi controllers in capabilities and means of programming. Rather than adding drivers for OctoSPI to the common EC code, this change allows special-purpose drivers for HyperDebug to be implemented in its board directory. BUG=b:192262089 TEST=Observed HyperDebug forwarding to OctoSPI controller Change-Id: Ia31eefcb53b08cc23aa0f14a8899bc227a88ea0c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077429 Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Tested-by: Jes Klinke <jbk@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jes Klinke <jbk@chromium.org>
* chips/stm32/usb_spi: Forwarding to multiple spi devicesJes B. Klinke2022-12-092-8/+30
| | | | | | | | | | | | | | | | For devices similar to Servo Micro, in case of multiple entries in spi_devices, this change allows the USB host to request which device its transaction requests are to be forwarded to. BUG=b:192262089 TEST=HyperDebug board forwards to two SPI busses Change-Id: Ic94e66a8d7f5502c3016a26a1beb24236b3c4893 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077428 Commit-Queue: Jes Klinke <jbk@chromium.org> Tested-by: Jes Klinke <jbk@chromium.org> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* ec: Support logging system boot time infoRajesh Kumar2022-12-073-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL add support logging system boot time and hostcommand to get boot time info. EC logs elapsed time (in micro second) info since boot for different signal events,that can be used to calculate system boot time in cold boot and warm boot scenarios. Below are the events when EC logs time info ARAIL EC turns on A-RAIL RSMRST EC releases RSMRST# ESPIRST ESPIRST received PLTRST_LOW PLTRST# asserted PLTRST_HIGH PLTRST# deasserted EC_CUR_TIME EC current time cnt increments on every warm reboot and reset to 0 on cold reboot BUG=b:249163956 BRANCH=none TEST='ectool boottime' AP console command is used to fetch data 'reboot' on AP console to trigger warm reboot 'apshutdown' on EC console to trigger cold reboot Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com> Change-Id: I47abe3f8a0b7ab43f2af11bf8387c006ba383020 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4081566 Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Tested-by: Li-Yu Yu <aaronyu@google.com> Reviewed-by: Boris Mittelberg <bmbm@google.com>
* Revert "ec: Support logging system boot time info"Piotr Pawliczek2022-12-033-17/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit c8325ba18b9f4d5b1f3f3bc739e83d8f591308cf. Reason for revert: broke at least 9 cq builds (https://ci.chromium.org/ui/p/chromeos/builders/cq/cq-orchestrator/b8795833246203447793/overview) Original change's description: > ec: Support logging system boot time info > > This CL add support logging system boot time and hostcommand to get > boot time info. > EC logs elapsed time (in micro second) info since boot for different > signal events,that can be used to calculate system boot time in cold > boot and warm boot scenarios. > > Below are the events when EC logs time info > > ARAIL EC turns on A-RAIL > RSMRST EC releases RSMRST# > ESPIRST ESPIRST received > PLTRST_LOW PLTRST# asserted > PLTRST_HIGH PLTRST# deasserted > EC_CUR_TIME EC current time > cnt increments on every warm reboot and reset to 0 on > cold reboot > > BUG=b:249163956 > BRANCH=none > TEST='ectool boottime' AP console command is used to fetch data > 'reboot' on AP console to trigger warm reboot > 'apshutdown' on EC console to trigger cold reboot > > Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com> > Change-Id: I15fedbde252e0452270ef0e3fd4391bf624169f1 > Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3794612 > Reviewed-by: Boris Mittelberg <bmbm@google.com> > Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Bug: b:249163956 Change-Id: Ie83026c4a3a38c3dd24522901233f06e03430a54 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077335 Reviewed-by: Jonathon Murphy <jpmurphy@google.com> Commit-Queue: Piotr Pawliczek <pawliczek@chromium.org> Tested-by: Piotr Pawliczek <pawliczek@chromium.org>
* ec: Support logging system boot time infoRajesh Kumar2022-12-023-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL add support logging system boot time and hostcommand to get boot time info. EC logs elapsed time (in micro second) info since boot for different signal events,that can be used to calculate system boot time in cold boot and warm boot scenarios. Below are the events when EC logs time info ARAIL EC turns on A-RAIL RSMRST EC releases RSMRST# ESPIRST ESPIRST received PLTRST_LOW PLTRST# asserted PLTRST_HIGH PLTRST# deasserted EC_CUR_TIME EC current time cnt increments on every warm reboot and reset to 0 on cold reboot BUG=b:249163956 BRANCH=none TEST='ectool boottime' AP console command is used to fetch data 'reboot' on AP console to trigger warm reboot 'apshutdown' on EC console to trigger cold reboot Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com> Change-Id: I15fedbde252e0452270ef0e3fd4391bf624169f1 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3794612 Reviewed-by: Boris Mittelberg <bmbm@google.com> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
* board: Sort header filesJeremy Bettis2022-12-011-1/+3
| | | | | | | | | | | | | | | | | | | | Sort all includes in board with the clang-format rules used by the zephyr project. BRANCH=None BUG=b:247100970 TEST=zmake build -a TEST=./twister --clobber -v -i TEST=make -j72 buildall_only runtests TEST=zmake compare-builds -a Signed-off-by: Jeremy Bettis <jbettis@google.com> Change-Id: I6ad72b167cbb768a64c338fa633eb4bf5a401897 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4060360 Reviewed-by: Tom Hughes <tomhughes@chromium.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Tested-by: Jeremy Bettis <jbettis@chromium.org> Commit-Queue: Jeremy Bettis <jbettis@chromium.org>
* chip: Sort header filesJeremy Bettis2022-11-29140-321/+313
| | | | | | | | | | | | | | | | | | | | Sort all includes in chip with the clang-format rules used by the zephyr project. BRANCH=None BUG=b:247100970 TEST=zmake build -a TEST=./twister --clobber -v -i TEST=make -j72 buildall_only runtests TEST=zmake compare-builds -a Signed-off-by: Jeremy Bettis <jbettis@google.com> Change-Id: I13454e38fa3766aa0ba26a058075f51965b8462e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4053346 Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Commit-Queue: Jeremy Bettis <jbettis@chromium.org> Tested-by: Jeremy Bettis <jbettis@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* ec: IWYU Add missing includesJeremy Bettis2022-11-243-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Add "chip/stm32/usb_hw.h" for usb_uint Add <stddef.h> for size_t Switch from board.h to config.h BRANCH=None BUG=b:247100970 TEST=zmake build -a TEST=./twister --clobber -v -i TEST=make -j72 buildall_only runtests TEST=zmake compare-builds Signed-off-by: Jeremy Bettis <jbettis@google.com> Change-Id: I8d6c7cb89cd54812b90afd9ec06d81f8122fbdc7 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4053345 Reviewed-by: Tomasz Michalec <tmichalec@google.com> Commit-Queue: Tomasz Michalec <tmichalec@google.com> Auto-Submit: Jeremy Bettis <jbettis@chromium.org> Tested-by: Jeremy Bettis <jbettis@chromium.org> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
* npcx9: fix SHA256 ROM API table addressJun Lin2022-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | It was found that the hardware SHA256 accelerator is broken. This is caused by the table address of SHA ROM API changed from 0x100 to 0x13C since the ES2 chip. This CL fixed the issues described above. BRANCH=none BUG=b:155771688 TEST=burn the same RW image; #define/#undef CONFIG_SHA256_HW_ACCELERATE; verify the RW hash value is the same in the console message. TEST=with the test CL:2455022, move test patterns in test/sha256.c to board/npcx9_evb/test_sha256.c; pass all test patterns. Signed-off-by: Jun Lin <CHLin56@nuvoton.com> Change-Id: I12ce8531a925f02474f66d90bf7efd950b3eeba3 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4033807 Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Boris Mittelberg <bmbm@google.com> Tested-by: CH Lin <chlin56@nuvoton.com> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
* chip/ish: fix system shutdown in D0i3Li Feng2022-11-154-40/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | ISH should set PMC LTR(Latency Tolerance Reporting) for DMA operation. Without doing this, we observed system shutdown during D0i3. This CL set LTR to 2ms before DMA operation and set LTR to a large number after DMA operation is completed to enable SOC to go into the lowest possible power state. BUG=b:234136500 BRANCH=none TEST=on Nirwen platform, ISH enter D0i3 host loading case, and also stitching to coreboot case; S0i3 is hit and no shutdown. Signed-off-by: Leifu Zhao <leifu.zhao@intel.com> Signed-off-by: Li Feng <li1.feng@intel.com> Change-Id: Ib0fe907470774998dda29a40197d6c18ad6372f1 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4003320 Code-Coverage: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com> Reviewed-by: Kyoung Kim <kyoung.il.kim@gmail.com> Reviewed-by: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com> Commit-Queue: Kangheui Won <khwon@chromium.org> Tested-by: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com> Reviewed-by: Kangheui Won <khwon@chromium.org>
View Lorry Controller Status