linux-imx/Documentation/ABI/testing/debugfs-wilco-ec
Mauro Carvalho Chehab 54a19b4d3f docs: ABI: cleanup several ABI documents
There are some ABI documents that, while they don't generate
any warnings, they have issues when parsed by get_abi.pl script
on its output result.

Address them, in order to provide a clean output.

Reviewed-by: Tom Rix <trix@redhat.com> # for fpga-manager
Reviewed-By: Kajol Jain<kjain@linux.ibm.com> # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for IIO
Acked-by: Oded Gabbay <oded.gabbay@gmail.com> # for Habanalabs
Acked-by: Vaibhav Jain <vaibhav@linux.ibm.com> # for sysfs-bus-papr-pmem
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com> # for catpt
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Ilya Dryomov <idryomov@gmail.com> # for rbd
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/5bc78e5b68ed1e9e39135173857cb2e753be868f.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-30 13:14:29 +01:00

1.7 KiB

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.

	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 16 bytes of the received MBOX[] will be
	printed, even if some of the data is junk, and skipping bytes
	17 to 32. It is up to you to know how many of the first bytes of
	data are the actual response.