summaryrefslogtreecommitdiff
path: root/Documentation/ABI
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2019-05-12 07:00:21 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2019-05-12 07:00:21 -0400
commit47782361aca21a32ad4198f1b72f1655a7c9f7e5 (patch)
tree6a7abf61d6af8fc8a95ce0451c1ab745fc7462a0 /Documentation/ABI
parent8148c17b179d8acad190551fe0fb90d8f5193990 (diff)
parent58a2109f6eb46b2952e2ce3fe776ce02c0c540dd (diff)
Merge tag 'tag-chrome-platform-for-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung: "CrOS EC: - Add EC host command support using rpmsg - Add new CrOS USB PD logging driver - Transfer spi messages at high priority - Add support to trace CrOS EC commands - Minor fixes and cleanups in protocol and debugfs Wilco EC: - Standardize Wilco EC mailbox interface - Add h1_gpio status to debugfs" * tag 'tag-chrome-platform-for-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_proto: Add trace event to trace EC commands platform/chrome: cros_ec_debugfs: Use cros_ec_cmd_xfer_status helper platform/chrome: cros_ec: Add EC host command support using rpmsg platform/chrome: wilco_ec: Add h1_gpio status to debugfs platform/chrome: wilco_ec: Standardize mailbox interface platform/chrome: cros_ec_proto: check for NULL transfer function platform/chrome: Add CrOS USB PD logging driver platform/chrome: cros_ec_spi: Transfer messages at high priority platform/chrome: cros_ec_debugfs: no need to check return value of debugfs_create functions platform/chrome: cros_ec_debugfs: Remove dev_warn when console log is not supported
Diffstat (limited to 'Documentation/ABI')
-rw-r--r--Documentation/ABI/testing/debugfs-wilco-ec45
1 files changed, 34 insertions, 11 deletions
diff --git a/Documentation/ABI/testing/debugfs-wilco-ec b/Documentation/ABI/testing/debugfs-wilco-ec
index f814f112e213..73a5a66ddca6 100644
--- a/Documentation/ABI/testing/debugfs-wilco-ec
+++ b/Documentation/ABI/testing/debugfs-wilco-ec
@@ -1,23 +1,46 @@
+What: /sys/kernel/debug/wilco_ec/h1_gpio
+Date: April 2019
+KernelVersion: 5.2
+Description:
+ As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
+ tests, we need to ensure that the H1 chip is properly setting
+ some GPIO lines. The h1_gpio attribute exposes the state
+ of the lines:
+ - ENTRY_TO_FACT_MODE in BIT(0)
+ - SPI_CHROME_SEL in BIT(1)
+
+ Output will formatted with "0x%02x\n".
+
What: /sys/kernel/debug/wilco_ec/raw
Date: January 2019
KernelVersion: 5.1
Description:
Write and read raw mailbox commands to the EC.
- For writing:
- Bytes 0-1 indicate the message type:
- 00 F0 = Execute Legacy Command
- 00 F2 = Read/Write NVRAM Property
- Byte 2 provides the command code
- Bytes 3+ consist of the data passed in the request
+ You can write a hexadecimal sentence to raw, and that series of
+ bytes will be sent to the EC. Then, you can read the bytes of
+ response by reading from raw.
- At least three bytes are required, for the msg type and command,
- with additional bytes optional for additional data.
+ For writing, bytes 0-1 indicate the message type, one of enum
+ wilco_ec_msg_type. Byte 2+ consist of the data passed in the
+ request, starting at MBOX[0]
+
+ At least three bytes are required for writing, two for the type
+ and at least a single byte of data. Only the first
+ EC_MAILBOX_DATA_SIZE bytes of MBOX will be used.
Example:
// Request EC info type 3 (EC firmware build date)
- $ echo 00 f0 38 00 03 00 > raw
+ // Corresponds with sending type 0x00f0 with
+ // MBOX = [38, 00, 03, 00]
+ $ echo 00 f0 38 00 03 00 > /sys/kernel/debug/wilco_ec/raw
// View the result. The decoded ASCII result "12/21/18" is
// included after the raw hex.
- $ cat raw
- 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 .12/21/18.8...
+ // Corresponds with MBOX = [00, 00, 31, 32, 2f, 32, 31, 38, ...]
+ $ cat /sys/kernel/debug/wilco_ec/raw
+ 00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 ..12/21/18.8...
+
+ Note that the first 32 bytes of the received MBOX[] will be
+ printed, even if some of the data is junk. It is up to you to
+ know how many of the first bytes of data are the actual
+ response.