linux-kernel - [PATCH v2 2/2] i2c: mux: pca954x: Support multiple devices on a single reset line

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20210727160315.15575-3-eajames@linux.ibm.com>
Date:   Tue, 27 Jul 2021 11:03:15 -0500
From:   Eddie James <eajames@...ux.ibm.com>
To:     linux-i2c@...r.kernel.org
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        peda@...ntia.se, robh+dt@...nel.org,
        Eddie James <eajames@...ux.ibm.com>
Subject: [PATCH v2 2/2] i2c: mux: pca954x: Support multiple devices on a single reset line

Some systems connect several PCA954x devices to a single reset GPIO. For
these devices to get out of reset and probe successfully, each device must
defer the probe until the GPIO has been hogged. Accomplish this by
attempting to grab a new "reset-shared-hogged" devicetree property, but
expect it to fail with EPROBE_DEFER or EBUSY.

Signed-off-by: Eddie James <eajames@...ux.ibm.com>
---
 drivers/i2c/muxes/i2c-mux-pca954x.c | 46 +++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 4ad665757dd8..376b54ffb590 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -434,15 +434,43 @@ static int pca954x_probe(struct i2c_client *client,
 	i2c_set_clientdata(client, muxc);
 	data->client = client;
 
-	/* Reset the mux if a reset GPIO is specified. */
-	gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
-	if (IS_ERR(gpio))
-		return PTR_ERR(gpio);
-	if (gpio) {
-		udelay(1);
-		gpiod_set_value_cansleep(gpio, 0);
-		/* Give the chip some time to recover. */
-		udelay(1);
+	/*
+	 * Grab the shared, hogged gpio that controls the mux reset. We expect
+	 * this to fail with either EPROBE_DEFER or EBUSY. The only purpose of
+	 * trying to get it is to make sure the gpio controller has probed up
+	 * and hogged the line to take the mux out of reset, meaning that the
+	 * mux is ready to be probed up. Don't try and set the line any way; in
+	 * the event we actually successfully get the line (if it wasn't
+	 * hogged) then we immediately release it, since there is no way to
+	 * sync up the line between muxes.
+	 */
+	gpio = gpiod_get_optional(dev, "reset-shared-hogged", 0);
+	if (IS_ERR(gpio)) {
+		ret = PTR_ERR(gpio);
+		if (ret != -EBUSY)
+			return ret;
+	} else {
+		if (gpio) {
+			/* This is really a problem since now we don't know the
+			 * state of the gpio. Log a warning and keep trying to
+			 * probe the mux just in case it works.
+			 */
+			dev_warn(dev, "got hogged reset line, expect error\n");
+			gpiod_put(gpio);
+		} else {
+			/* Reset the mux if a reset GPIO is specified. */
+			gpio = devm_gpiod_get_optional(dev, "reset",
+						       GPIOD_OUT_HIGH);
+			if (IS_ERR(gpio))
+				return PTR_ERR(gpio);
+
+			if (gpio) {
+				udelay(1);
+				gpiod_set_value_cansleep(gpio, 0);
+				/* Give the chip some time to recover. */
+				udelay(1);
+			}
+		}
 	}
 
 	data->chip = device_get_match_data(dev);
-- 
2.27.0