linux-kernel - [PATCH 2/2] platform/chrome: Add a new interrupt path for cros_ec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20181003184506.149579-1-egranata@google.com>
Date:   Wed,  3 Oct 2018 11:45:06 -0700
From:   Enrico Granata <egranata@...gle.com>
To:     Benson Leung <bleung@...omium.org>,
        Olof Johansson <olof@...om.net>, linux-kernel@...r.kernel.org,
        gwendal@...omium.org
Cc:     Enrico Granata <egranata@...omium.org>
Subject: [PATCH 2/2] platform/chrome: Add a new interrupt path for cros_ec_lpc

From: Enrico Granata <egranata@...omium.org>

This commit allows cros_ec_lpc to register a direct IRQ instead of relying
on the ACPI notification chain to receive MKBP events.

This change is done in the interest of allowing reduced jitter in the
communication path between the CrOS EC and the host for receiving sensor
data.

Signed-off-by: Enrico Granata <egranata@...omium.org>
---
 drivers/platform/chrome/cros_ec_lpc.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c
index 31c8b8c49e45..07eea608915e 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -25,6 +25,7 @@
 #include <linux/dmi.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/interrupt.h>
 #include <linux/mfd/cros_ec.h>
 #include <linux/mfd/cros_ec_commands.h>
 #include <linux/mfd/cros_ec_lpc_reg.h>
@@ -248,7 +249,7 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
 	acpi_status status;
 	struct cros_ec_device *ec_dev;
 	u8 buf[2];
-	int ret;
+	int irq, ret;
 
 	if (!devm_request_region(dev, EC_LPC_ADDR_MEMMAP, EC_MEMMAP_SIZE,
 				 dev_name(dev))) {
@@ -287,6 +288,18 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
 			   sizeof(struct ec_response_get_protocol_info);
 	ec_dev->dout_size = sizeof(struct ec_host_request);
 
+	/*
+	 * Some boards do not have an IRQ allotted for cros_ec_lpc,
+	 * which makes ENXIO an expected (and safe) scenario.
+	 */
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0)
+		ec_dev->irq = irq;
+	else if (irq != -ENXIO) {
+		dev_err(dev, "couldn't retrieve IRQ number (%d)\n", irq);
+		return irq;
+	}
+
 	ret = cros_ec_register(ec_dev);
 	if (ret) {
 		dev_err(dev, "couldn't register ec_dev (%d)\n", ret);
@@ -294,11 +307,11 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
 	}
 
 	/*
-	 * Connect a notify handler to process MKBP messages if we have a
-	 * companion ACPI device.
+	 * If we have a companion ACPI device and no dedicated IRQ
+	 * connect a notify handler to process MKBP messages.
 	 */
 	adev = ACPI_COMPANION(dev);
-	if (adev) {
+	if (adev && ec_dev->irq <= 0) {
 		status = acpi_install_notify_handler(adev->handle,
 						     ACPI_ALL_NOTIFY,
 						     cros_ec_lpc_acpi_notify,
-- 
2.19.0.605.g01d371f741-goog