mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-05 18:39:59 +00:00
9e2b0e0be6
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) There are two reasons that I am exposing this in debugfs, and not as a GPIO: 1. This is only useful for testing, so end users shouldn't ever care about this. In fact, if it passes the tests, then the value of h1_gpio will always be 2, so it would be really uninteresting for users. 2. This GPIO is not connected to, controlled by, or really even related to the AP. The GPIO runs between the EC and the H1 security chip. Changes in v4: - Use "0x02x\n" instead of "02x\n" for format string - Use DEFINE_DEBUGFS_ATTRIBUTE() - Add documentation Changes in v3: - Fix documentation to correspond with formatting change in v2. Changes in v2: - Zero out the unused fields in the request. - Format result as "%02x\n" instead of as a decimal. Signed-off-by: Nick Crews <ncrews@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
46 lines
1.7 KiB
Text
46 lines
1.7 KiB
Text
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.
|
|
|
|
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.
|
|
|
|
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)
|
|
// 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.
|
|
// 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.
|