[PATCH v4 1/2] platform/chrome: wilco_ec: Fix documentation for debugfs raw attribute

[PATCH v4 1/2] platform/chrome: wilco_ec: Fix documentation for debugfs raw attribute

[Nick Crews]

In a previous refactor [repo chrome-platform, branch for-next,
commit 9cced499d6fdb60434ffa94f8f4b5087ad35802b
("platform/chrome: wilco_ec: Standardize mailbox interface")], the
documentation for the raw debugfs attribute became incorrect, but I
forgot to fix it. This patch fixes it, as well as de-duplicates
the documentation by removing it from the source file header comment.

Signed-off-by: Nick Crews <ncrews@chromium.org>
---
 Documentation/ABI/testing/debugfs-wilco-ec | 32 ++++++++++++++--------
 drivers/platform/chrome/wilco_ec/debugfs.c | 27 +-----------------
 2 files changed, 22 insertions(+), 37 deletions(-)

diff --git a/Documentation/ABI/testing/debugfs-wilco-ec b/Documentation/ABI/testing/debugfs-wilco-ec
index f814f112e213..7ff6b45be703 100644
--- a/Documentation/ABI/testing/debugfs-wilco-ec
+++ b/Documentation/ABI/testing/debugfs-wilco-ec
@@ -4,20 +4,30 @@ 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.
diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c b/drivers/platform/chrome/wilco_ec/debugfs.c
index 17c4c9068aaf..8d307378c1cb 100644
--- a/drivers/platform/chrome/wilco_ec/debugfs.c
+++ b/drivers/platform/chrome/wilco_ec/debugfs.c
@@ -4,32 +4,7 @@
  *
  * Copyright 2019 Google LLC
  *
- * There is only one attribute used for debugging, called raw.
- * 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, ...]
- * $ 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.
+ * See Documentation/ABI/testing/debugfs-wilco-ec for usage.
  */
 
 #include <linux/ctype.h>
-- 
2.20.1

[PATCH v4 2/2] platform/chrome: wilco_ec: Add h1_gpio status to debugfs

[Nick Crews]

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>
---
 Documentation/ABI/testing/debugfs-wilco-ec | 13 ++++++
 drivers/platform/chrome/wilco_ec/debugfs.c | 47 ++++++++++++++++++++++
 2 files changed, 60 insertions(+)

diff --git a/Documentation/ABI/testing/debugfs-wilco-ec b/Documentation/ABI/testing/debugfs-wilco-ec
index 7ff6b45be703..73a5a66ddca6 100644
--- a/Documentation/ABI/testing/debugfs-wilco-ec
+++ b/Documentation/ABI/testing/debugfs-wilco-ec
@@ -1,3 +1,16 @@
+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
diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c b/drivers/platform/chrome/wilco_ec/debugfs.c
index 8d307378c1cb..20482e590587 100644
--- a/drivers/platform/chrome/wilco_ec/debugfs.c
+++ b/drivers/platform/chrome/wilco_ec/debugfs.c
@@ -164,6 +164,51 @@ static const struct file_operations fops_raw = {
 	.llseek = no_llseek,
 };
 
+#define CMD_KB_CHROME		0x88
+#define SUB_CMD_H1_GPIO		0x0A
+
+struct h1_gpio_status_request {
+	u8 cmd;		/* Always CMD_KB_CHROME */
+	u8 reserved;
+	u8 sub_cmd;	/* Always SUB_CMD_H1_GPIO */
+} __packed;
+
+struct hi_gpio_status_response {
+	u8 status;	/* 0 if allowed */
+	u8 val;		/* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL */
+} __packed;
+
+static int h1_gpio_get(void *arg, u64 *val)
+{
+	struct wilco_ec_device *ec = arg;
+	struct h1_gpio_status_request rq;
+	struct hi_gpio_status_response rs;
+	struct wilco_ec_message msg;
+	int ret;
+
+	memset(&rq, 0, sizeof(rq));
+	rq.cmd = CMD_KB_CHROME;
+	rq.sub_cmd = SUB_CMD_H1_GPIO;
+
+	memset(&msg, 0, sizeof(msg));
+	msg.type = WILCO_EC_MSG_LEGACY;
+	msg.request_data = &rq;
+	msg.request_size = sizeof(rq);
+	msg.response_data = &rs;
+	msg.response_size = sizeof(rs);
+	ret = wilco_ec_mailbox(ec, &msg);
+	if (ret < 0)
+		return ret;
+	if (rs.status)
+		return -EIO;
+
+	*val = rs.val;
+
+	return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(fops_h1_gpio, h1_gpio_get, NULL, "0x%02x\n");
+
 /**
  * wilco_ec_debugfs_probe() - Create the debugfs node
  * @pdev: The platform device, probably created in core.c
@@ -185,6 +230,8 @@ static int wilco_ec_debugfs_probe(struct platform_device *pdev)
 	if (!debug_info->dir)
 		return 0;
 	debugfs_create_file("raw", 0644, debug_info->dir, NULL, &fops_raw);
+	debugfs_create_file("h1_gpio", 0444, debug_info->dir, ec,
+			    &fops_h1_gpio);
 
 	return 0;
 }
-- 
2.20.1

Re: [PATCH v4 1/2] platform/chrome: wilco_ec: Fix documentation for debugfs raw attribute

[Enric Balletbo i Serra]

Hi Nick,

On 12/4/19 20:14, Nick Crews wrote:
> In a previous refactor [repo chrome-platform, branch for-next,
> commit 9cced499d6fdb60434ffa94f8f4b5087ad35802b
> ("platform/chrome: wilco_ec: Standardize mailbox interface")], the
> documentation for the raw debugfs attribute became incorrect, but I
> forgot to fix it. This patch fixes it, as well as de-duplicates
> the documentation by removing it from the source file header comment.
> 
> Signed-off-by: Nick Crews <ncrews@chromium.org>
> ---
>  Documentation/ABI/testing/debugfs-wilco-ec | 32 ++++++++++++++--------
>  drivers/platform/chrome/wilco_ec/debugfs.c | 27 +-----------------
>  2 files changed, 22 insertions(+), 37 deletions(-)

I'm going to squash this commit and queue for 5.2.

Thanks,
 Enric

Re: [PATCH v4 2/2] platform/chrome: wilco_ec: Add h1_gpio status to debugfs

[Enric Balletbo i Serra]

On 12/4/19 20:14, Nick Crews wrote:
> 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>

Applied for 5.2

Thanks