linux-kernel - [PATCH] ARM: dts: imx51-zii-rdu1: Make sure SD1

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: <20180525030153.15986-1-andrew.smirnov@gmail.com>
Date:   Thu, 24 May 2018 20:01:53 -0700
From:   Andrey Smirnov <andrew.smirnov@...il.com>
To:     Shawn Guo <shawnguo@...nel.org>
Cc:     Andrey Smirnov <andrew.smirnov@...il.com>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Fabio Estevam <fabio.estevam@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Chris Healy <cphealy@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH] ARM: dts: imx51-zii-rdu1: Make sure SD1_WP is low

Make sure that MX51_PAD_GPIO1_1 does not remain configure as
ALT0/SD1_WP (it is out of reset). This is needed because of external
pull-up resistor attached to that pad that, when left unchanged, will
drive SD1_WP high preventing eSDHC1/eMMC from working correctly.

To fix that add a pinmux configuration line configureing the pad to
function as a GPIO. While we are at it, add a corresponding input GPIO
hog in an effort to minimize current consumption.

Cc: Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc: Shawn Guo <shawnguo@...nel.org>
Cc: Fabio Estevam <fabio.estevam@....com>
Cc: Lucas Stach <l.stach@...gutronix.de>
Cc: Chris Healy <cphealy@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org
Cc: devicetree@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@...il.com>
---
 arch/arm/boot/dts/imx51-zii-rdu1.dts | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..d484e7e46b27 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -476,6 +476,17 @@
 	status = "okay";
 };
 
+&gpio1 {
+	unused-sd3-wp-gpio {
+		/*
+		 * See pinctrl_esdhc1 below for more details on this
+		 */
+		gpio-hog;
+		gpios = <1 GPIO_ACTIVE_HIGH>;
+		input;
+	};
+};
+
 &i2c2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_i2c2>;
@@ -660,6 +671,23 @@
 			MX51_PAD_SD1_DATA1__SD1_DATA1		0x20d5
 			MX51_PAD_SD1_DATA2__SD1_DATA2		0x20d5
 			MX51_PAD_SD1_DATA3__SD1_DATA3		0x20d5
+			/*
+			 * GPIO1_1 is not directly used by eSDHC1 in
+			 * any capacity, but earlier versions of RDU1
+			 * used that pin as WP GPIO for eSDHC3 and
+			 * because of that that pad has an external
+			 * pull-up resistor. This is problematic
+			 * because out of reset the pad is configured
+			 * as ALT0 which serves as SD1_WP, which, when
+			 * pulled high by and external pull-up, will
+			 * inhibit execution of any write request to
+			 * attached eMMC device.
+			 *
+			 * To avoid this problem we configure the pad
+                	 * to ALT1/GPIO and avoid driving SD1_WP
+                	 * signal high.
+			 */
+			MX51_PAD_GPIO1_1__GPIO1_1		0x0000
 		>;
 	};
 
-- 
2.17.0