Reduce use of low-level i2c_xfer commands |
|||||
Issue descriptionThere are a number of modules in the EC codebase that are performing low-level I2C transfers instead of using the high-level APIs. This is error-prone, as evidenced by CL's like https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1163542 Action Items - Refactor users of low-level I2C functions to use the high-level functions when available. - In the rare places where the high-level API is inadequate, extend it. - Reduce the visibility of i2c_xfer() to discourage misuse in the future.
,
Aug 8
,
Aug 8
There are two main problems with i2c_xfer(): 1) Security. Some i2c components (e.g. TCPCs, batteries) have upgradeable firmware. 2) Host bus blocking. i2c_xfer() blocks all other host bus access. On ARM systems, this includes the keyboard, accelerometer data, etc. Talking to a component that clock-stretches can interfere with device usability. For test/manufacturing, there are no issues with either one. In a MP user environment, both are concerns.
,
Aug 8
For security, we've implemented some I2C bus filtering on the EC. But it's only partial coverage. Full coverage is difficult, since it requires stateful inspection of I2C commands on the EC and knowledge of what they mean to each peripheral. For host bus blocking, the problem is that host commands are strictly sequential. We don't have the ability to process a queue of commands out-of-order or asynchronously.
,
Aug 8
After hacking on this for a bit, there remain a few entry points that are too custom to completely hide i2c_xfer, including some that need their own locking commands. My primary motivation is to reduce the likelihood of error by otherwise well-meaning engineers. Direct access to the bus from outside the EC can be restricted by means of CONFIG_I2C_PASSTHRU_RESTRICTED and by disabling CONFIG_USB_I2C. Right now, only hammer, servo_micro, servo_v4, sweetberry, and tigertail enable CONFIG_USB_I2C. Unfortunately, only a tiny handful of systems enable CONFIG_I2C_PASSTHRU_RESTRICTED. I'm not sure which host tools rely on this command. See also https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1167958
,
Aug 8
> 2) Host bus blocking. i2c_xfer() blocks all other host bus access. I believe that this is dependent on the particular EC. For example, the Grunt peripherals on an NPCX7 part are divided among 5 separate I2C busses, all with their own independent locking.
,
Aug 8
Note that CONFIG_I2C_PASSTHRU_RESTRICTED is for hostcommands over SPI/I2C from the AP, while CONFIG_USB_I2C covers USB I2C bridges. Note that i2c_read/write also block bus access and just call i2c_xfer. So these aren't really different.
,
Aug 8
Also to clarify #1, by user facing, I mean available as an API for safe use within EC code by people writing EC code. Not like end users.
,
Aug 8
re #8, As I mentioned in https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1167958/4#message-e9ba9eddf87153af7be4dc3c91777fda7a64450f, some of the remaining callers still do want their own custom locking. I'll have to provide an i2c_xfer_unlocked just for them. I don't think I can keep the unlocked API strictly internal to the module, but uglifying the name of the unlocked entry point should still help.
,
Aug 9
Re#6: I'm not talking about the i2c bus mutex. I'm talking about the host command interface. The EC processes host commands sequentially. So while it's processing one host command, it is not processing any other host commands of any type. If you issue an I2C command which takes 150ms due to clock stretching, then *all* other host commands (keyboard, sensors, etc.) are held off for 150ms. This is one key reason why we went to a virtual battery interface for ARM systems instead of using I2C passthru for battery communication. Batteries are one of the key clock-stretching offenders, and are on a relatively slow I2C bus as well.
,
Aug 9
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/21e235dbe468bfa80bab86900ab4baeb48533a94 commit 21e235dbe468bfa80bab86900ab4baeb48533a94 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Thu Aug 09 18:40:02 2018 i2c master: Add block read/write commands. These commands are used by several modules that manage their own block read/write protocols today. This is the first of a series that refactors several modules to use the I2C driver functions instead of their own. BUG= chromium:871851 BRANCH=none TEST=make -j buildall; USB-PD and motionsense testing on Grunt convertible, which exercises several users of the new interface. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: I08475a72031e5fbf49dc344d5b4858622f0d5e93 Reviewed-on: https://chromium-review.googlesource.com/1167957 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> [modify] https://crrev.com/21e235dbe468bfa80bab86900ab4baeb48533a94/common/i2c_master.c [modify] https://crrev.com/21e235dbe468bfa80bab86900ab4baeb48533a94/include/i2c.h
,
Aug 10
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/740427a24398b3fd66904e913b742f751371d09c commit 740427a24398b3fd66904e913b742f751371d09c Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Fri Aug 10 05:04:40 2018 drivers: Refactor to use high-level i2c APIs Using the high-level APIs for block transfers eliminates some code duplication and error-prone manual locking sequences. - common/cbi: Block transfers - driver/accel_bma2x2: Block transfers - driver/accel_kionix: Block transfers - driver/accelgyro_bmi160: Block transfers - driver/accelgyro_lsm6ds0: Block transfers - driver/baro_bmp280: Block and byte transfers - driver/charger/rt946x: Block transfers - driver/gyro_l3gd20h: Block transfers - driver/stm_mems_common: Block transfers - driver/tcpm: Block transfers TEST=buildall; motionsense and PD testing on Grunt convertible which exercises the bma160, kionix and tcpcm drivers. BRANCH=none BUG= chromium:871851 Change-Id: I1732253a244c3343459265ce1e1e54488cee65b8 Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1167958 Reviewed-by: Jett Rink <jettrink@chromium.org> [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/accel_kionix.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/tcpm/tcpm.h [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/baro_bmp280.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/accelgyro_bmi160.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/charger/rt946x.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/accelgyro_lsm6ds0.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/gyro_l3gd20h.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/tcpm/tcpci.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/stm_mems_common.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/driver/accel_bma2x2.c [modify] https://crrev.com/740427a24398b3fd66904e913b742f751371d09c/common/cbi.c
,
Aug 16
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/39ab7a039676ef3738171ed00dc3c7f61802e7b3 commit 39ab7a039676ef3738171ed00dc3c7f61802e7b3 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Thu Aug 16 20:14:49 2018 i2c: Split i2c_xfer into locked/unlocked versions. Rename i2c_xfer to i2c_xfer_unlocked. Audit all users of i2c_xfer to see if they can use simple locking semantics or require their own locking. Since locked accesses are only safe for I2C_XFER_SINGLE transactions, remove the flags parameter from i2c_xfer. This also makes the audit a bit easier. Some remaining applications hold the bus locked across several transactions that would otherwise be atomic, and a few others implement complex I2C transactions in multiple commands. Add a (nondeterministic) verification on the I2C port locking correctness. This will catch all statically incorrect locking patterns, although dynamically incorrect locking patterns may not be caught. Related: Revise the i2c_port_active_count to be a bitmap of the active ports instead of a count of the active ports. The EC's mutex does not provide an is_locked() primitive, and we would prefer not to have one. - board/glados: Custom locking for battery reset - board/mchpevb1: Custom locking for battery reset - board/oak: Custom locking for battery reset - board/samus: Custom locking for lightbar reset - board/sweetberry: simple locking - board/servo_micro: Custom locking for funky i2c transfers - capsense: simple locking - host_command_master: multi-command transactions - lb_common: manual locking to support samus power sequence - smbus: multi-command transactions - usb_i2c: simple locking - driver/tcpm/fusb302: simple locking and multi-command transactions - driver/tcpm/tcpi: Forward _unlocked and implicitly locked interface to fusb302 - driver/touchpad_elan: simple locking BUG= chromium:871851 BRANCH=none TEST=buildall; very careful audit TEST=grunt clamshell and Coral clamshell, test boot, battery charging, PD communication, and TCPC port low-power mode. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: Ieabf22bcab42780bdb994fca3ced5d8c62519d56 Reviewed-on: https://chromium-review.googlesource.com/1169913 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/chip/stm32/usb_power.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/servo_micro/board.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/driver/tcpm/tcpm.h [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/include/i2c.h [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/host_command_master.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/smbus.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/usb_i2c.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/samus/battery.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/lb_common.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/glados/battery.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/driver/touchpad_elan.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/sweetberry/board.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/capsense.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/driver/tcpm/tcpci.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/mchpevb1/battery.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/common/i2c_master.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/board/oak/battery.c [modify] https://crrev.com/39ab7a039676ef3738171ed00dc3c7f61802e7b3/driver/tcpm/fusb302.c
,
Sep 6
I've completed the refactoring I initially set out to do. I've also looked into the issue of bus locking. Whole bus transactions have a default timeout of 100 ms and some I2C masters are following this policy, including the NPCX-series. Additionally, some drivers provide a maximum clock-stretching timeout. For example, NPCX-series parts set the SCL timeout to 35 ms. The STM32 drivers use a different timeout regime of 10ms for each transmitted byte, plus 100ms for the entire master RX portion of the transaction. If the 100ms transaction timeout is too large for the host command interface, then please open a separate feature request to shorten the timeout for transactions initiated through this path.
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/14d333d5c593c77b95aa62c1f0c39b723f3ed5c8 commit 14d333d5c593c77b95aa62c1f0c39b723f3ed5c8 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Fri Oct 12 18:20:18 2018 i2c master: Add block read/write commands. These commands are used by several modules that manage their own block read/write protocols today. This is the first of a series that refactors several modules to use the I2C driver functions instead of their own. BUG= chromium:871851 BRANCH=none TEST=make -j buildall; USB-PD and motionsense testing on Grunt convertible, which exercises several users of the new interface. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: I08475a72031e5fbf49dc344d5b4858622f0d5e93 Reviewed-on: https://chromium-review.googlesource.com/1167957 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 21e235dbe468bfa80bab86900ab4baeb48533a94) Reviewed-on: https://chromium-review.googlesource.com/c/1278029 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> [modify] https://crrev.com/14d333d5c593c77b95aa62c1f0c39b723f3ed5c8/common/i2c_master.c [modify] https://crrev.com/14d333d5c593c77b95aa62c1f0c39b723f3ed5c8/include/i2c.h
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/97efa7737b8116c369def1fafe9e9bc896634eb9 commit 97efa7737b8116c369def1fafe9e9bc896634eb9 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Fri Oct 12 18:20:19 2018 i2c: Split i2c_xfer into locked/unlocked versions. Rename i2c_xfer to i2c_xfer_unlocked. Audit all users of i2c_xfer to see if they can use simple locking semantics or require their own locking. Since locked accesses are only safe for I2C_XFER_SINGLE transactions, remove the flags parameter from i2c_xfer. This also makes the audit a bit easier. Some remaining applications hold the bus locked across several transactions that would otherwise be atomic, and a few others implement complex I2C transactions in multiple commands. Add a (nondeterministic) verification on the I2C port locking correctness. This will catch all statically incorrect locking patterns, although dynamically incorrect locking patterns may not be caught. Related: Revise the i2c_port_active_count to be a bitmap of the active ports instead of a count of the active ports. The EC's mutex does not provide an is_locked() primitive, and we would prefer not to have one. - board/glados: Custom locking for battery reset - board/mchpevb1: Custom locking for battery reset - board/oak: Custom locking for battery reset - board/samus: Custom locking for lightbar reset - board/sweetberry: simple locking - board/servo_micro: Custom locking for funky i2c transfers - capsense: simple locking - host_command_master: multi-command transactions - lb_common: manual locking to support samus power sequence - smbus: multi-command transactions - usb_i2c: simple locking - driver/tcpm/fusb302: simple locking and multi-command transactions - driver/tcpm/tcpi: Forward _unlocked and implicitly locked interface to fusb302 - driver/touchpad_elan: simple locking Conflicts: The following boards are not in this branch: board/glados board/mchpevb1 board/oak board/samus board/servo_micro board/sweetberry Thiese conflicts were resolved manually: driver/tcpm/tcpci.c driver/tcpm/tcpm.h driver/touchpad_elan.c BUG= chromium:871851 BRANCH=none TEST=buildall; very careful audit TEST=grunt clamshell and Coral clamshell, test boot, battery charging, PD communication, and TCPC port low-power mode. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: Ieabf22bcab42780bdb994fca3ced5d8c62519d56 Reviewed-on: https://chromium-review.googlesource.com/1169913 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 39ab7a039676ef3738171ed00dc3c7f61802e7b3) Reviewed-on: https://chromium-review.googlesource.com/c/1278030 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/chip/stm32/usb_power.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/driver/tcpm/tcpm.h [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/host_command_master.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/smbus.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/usb_i2c.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/lb_common.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/capsense.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/common/i2c_master.c [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/include/i2c.h [modify] https://crrev.com/97efa7737b8116c369def1fafe9e9bc896634eb9/driver/tcpm/fusb302.c
,
Dec 7
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/d91fb269de2ed15253ad485e67c818fb18b64ae0 commit d91fb269de2ed15253ad485e67c818fb18b64ae0 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Fri Dec 07 00:25:50 2018 i2c master: Add block read/write commands. These commands are used by several modules that manage their own block read/write protocols today. This is the first of a series that refactors several modules to use the I2C driver functions instead of their own. BUG= chromium:871851 BRANCH=none TEST=make -j buildall; USB-PD and motionsense testing on Grunt convertible, which exercises several users of the new interface. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: I08475a72031e5fbf49dc344d5b4858622f0d5e93 Reviewed-on: https://chromium-review.googlesource.com/1167957 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 21e235dbe468bfa80bab86900ab4baeb48533a94) Reviewed-on: https://chromium-review.googlesource.com/c/1278029 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit 14d333d5c593c77b95aa62c1f0c39b723f3ed5c8) Reviewed-on: https://chromium-review.googlesource.com/c/1366970 [modify] https://crrev.com/d91fb269de2ed15253ad485e67c818fb18b64ae0/common/i2c_master.c [modify] https://crrev.com/d91fb269de2ed15253ad485e67c818fb18b64ae0/include/i2c.h
,
Dec 7
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526 commit caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526 Author: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Date: Fri Dec 07 00:25:52 2018 i2c: Split i2c_xfer into locked/unlocked versions. Rename i2c_xfer to i2c_xfer_unlocked. Audit all users of i2c_xfer to see if they can use simple locking semantics or require their own locking. Since locked accesses are only safe for I2C_XFER_SINGLE transactions, remove the flags parameter from i2c_xfer. This also makes the audit a bit easier. Some remaining applications hold the bus locked across several transactions that would otherwise be atomic, and a few others implement complex I2C transactions in multiple commands. Add a (nondeterministic) verification on the I2C port locking correctness. This will catch all statically incorrect locking patterns, although dynamically incorrect locking patterns may not be caught. Related: Revise the i2c_port_active_count to be a bitmap of the active ports instead of a count of the active ports. The EC's mutex does not provide an is_locked() primitive, and we would prefer not to have one. - board/glados: Custom locking for battery reset - board/mchpevb1: Custom locking for battery reset - board/oak: Custom locking for battery reset - board/samus: Custom locking for lightbar reset - board/sweetberry: simple locking - board/servo_micro: Custom locking for funky i2c transfers - capsense: simple locking - host_command_master: multi-command transactions - lb_common: manual locking to support samus power sequence - smbus: multi-command transactions - usb_i2c: simple locking - driver/tcpm/fusb302: simple locking and multi-command transactions - driver/tcpm/tcpi: Forward _unlocked and implicitly locked interface to fusb302 - driver/touchpad_elan: simple locking Conflicts: The following boards are not in this branch: board/glados board/mchpevb1 board/oak board/samus board/servo_micro board/sweetberry Thiese conflicts were resolved manually: driver/tcpm/tcpci.c driver/tcpm/tcpm.h driver/touchpad_elan.c BUG= chromium:871851 BRANCH=none TEST=buildall; very careful audit TEST=grunt clamshell and Coral clamshell, test boot, battery charging, PD communication, and TCPC port low-power mode. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: Ieabf22bcab42780bdb994fca3ced5d8c62519d56 Reviewed-on: https://chromium-review.googlesource.com/1169913 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 39ab7a039676ef3738171ed00dc3c7f61802e7b3) Reviewed-on: https://chromium-review.googlesource.com/c/1278030 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit 97efa7737b8116c369def1fafe9e9bc896634eb9) Reviewed-on: https://chromium-review.googlesource.com/c/1366971 [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/chip/stm32/usb_power.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/driver/tcpm/tcpm.h [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/host_command_master.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/smbus.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/usb_i2c.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/lb_common.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/capsense.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/common/i2c_master.c [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/include/i2c.h [modify] https://crrev.com/caaaa47fdd4cbb0cc81a835c6b2ed9c73db3d526/driver/tcpm/fusb302.c |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nsanders@chromium.org
, Aug 8