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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1374137590-17865-2-git-send-email-rogerq@ti.com>
Date:	Thu, 18 Jul 2013 11:53:05 +0300
From:	Roger Quadros <rogerq@...com>
To:	<balbi@...com>, <benoit.cousson@...aro.org>
CC:	<p.zabel@...gutronix.de>, <linux-usb@...r.kernel.org>,
	<linux-omap@...r.kernel.org>,
	<devicetree-discuss@...ts.ozlabs.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, Roger Quadros <rogerq@...com>
Subject: [PATCH 1/6] usb: phy-nop: Use RESET Controller for managing the reset line

Till now we were modelling the RESET line as a voltage regulator and
using the regulator framework to manage it.

[1] introduces a GPIO based reset controller driver. We use that
to manage the PHY reset line, at least for DT boots. For legacy boots,
will still need to use the regulator framework for reset lines.

[1] - http://thread.gmane.org/gmane.linux.drivers.devicetree/41348

Signed-off-by: Roger Quadros <rogerq@...com>
---
 .../devicetree/bindings/usb/usb-nop-xceiv.txt      |   10 +++--
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-nop.c                          |   48 +++++++++++++++-----
 3 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..5c3e978 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,9 @@ Optional properties:
 
 - vcc-supply: phandle to the regulator that provides RESET to the PHY.
 
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- resets: phandle to the reset controller.
+
+- reset-names: must be "reset"
 
 Example:
 
@@ -25,10 +27,10 @@ Example:
 		clocks = <&osc 0>;
 		clock-names = "main_clk";
 		vcc-supply = <&hsusb1_vcc_regulator>;
-		reset-supply = <&hsusb1_reset_regulator>;
+		resets = <&hsusb1_reset>;
+		reset-names = "reset"
 	};
 
 hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
 and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset controls RESET.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..213b5ad 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -58,6 +58,7 @@ config MV_U3D_PHY
 
 config NOP_USB_XCEIV
 	tristate "NOP USB Transceiver Driver"
+	depends on RESET_CONTROLLER
 	help
 	  This driver is to be used by all the usb transceiver which are either
 	  built-in with usb ip or which are autonomous and doesn't require any
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index 55445e5d..a2cbda5 100644
--- a/drivers/usb/phy/phy-nop.c
+++ b/drivers/usb/phy/phy-nop.c
@@ -35,13 +35,15 @@
 #include <linux/clk.h>
 #include <linux/regulator/consumer.h>
 #include <linux/of.h>
+#include <linux/reset.h>
 
 struct nop_usb_xceiv {
 	struct usb_phy phy;
 	struct device *dev;
 	struct clk *clk;
 	struct regulator *vcc;
-	struct regulator *reset;
+	struct regulator *reset_reg; /* only used for non-DT boot */
+	struct reset_control *reset;
 };
 
 static struct platform_device *pd;
@@ -82,9 +84,14 @@ static int nop_init(struct usb_phy *phy)
 	if (!IS_ERR(nop->clk))
 		clk_enable(nop->clk);
 
+	/* De-assert RESET */
+	if (!IS_ERR(nop->reset_reg)) {
+		if (regulator_enable(nop->reset_reg))
+			dev_err(phy->dev, "Failed to de-assert reset\n");
+	}
+
 	if (!IS_ERR(nop->reset)) {
-		/* De-assert RESET */
-		if (regulator_enable(nop->reset))
+		if (reset_control_deassert(nop->reset))
 			dev_err(phy->dev, "Failed to de-assert reset\n");
 	}
 
@@ -95,9 +102,14 @@ static void nop_shutdown(struct usb_phy *phy)
 {
 	struct nop_usb_xceiv *nop = dev_get_drvdata(phy->dev);
 
+	/* Assert RESET */
+	if (!IS_ERR(nop->reset_reg)) {
+		if (regulator_disable(nop->reset_reg))
+			dev_err(phy->dev, "Failed to assert reset\n");
+	}
+
 	if (!IS_ERR(nop->reset)) {
-		/* Assert RESET */
-		if (regulator_disable(nop->reset))
+		if (reset_control_assert(nop->reset))
 			dev_err(phy->dev, "Failed to assert reset\n");
 	}
 
@@ -166,7 +178,7 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
 			clk_rate = 0;
 
 		needs_vcc = of_property_read_bool(node, "vcc-supply");
-		needs_reset = of_property_read_bool(node, "reset-supply");
+		needs_reset = of_property_read_bool(node, "resets");
 
 	} else if (pdata) {
 		type = pdata->type;
@@ -205,12 +217,26 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
 			return -EPROBE_DEFER;
 	}
 
-	nop->reset = devm_regulator_get(&pdev->dev, "reset");
-	if (IS_ERR(nop->reset)) {
-		dev_dbg(&pdev->dev, "Error getting reset regulator: %ld\n",
+	nop->reset_reg = ERR_PTR(-EINVAL);
+	nop->reset = ERR_PTR(-EINVAL);
+
+	if (dev->of_node) {
+		nop->reset = devm_reset_control_get(dev, "reset");
+		if (IS_ERR(nop->reset)) {
+			dev_dbg(dev, "Couldn't get reset controller: %ld\n",
 					PTR_ERR(nop->reset));
-		if (needs_reset)
-			return -EPROBE_DEFER;
+			if (needs_reset && PTR_ERR(nop->reset) == -ENODEV)
+				return -EPROBE_DEFER;
+		}
+
+	} else {
+		nop->reset_reg = devm_regulator_get(&pdev->dev, "reset");
+		if (IS_ERR(nop->reset_reg)) {
+			dev_dbg(&pdev->dev, "Error getting reset regulator: %ld\n",
+					PTR_ERR(nop->reset_reg));
+			if (needs_reset)
+				return -EPROBE_DEFER;
+		}
 	}
 
 	nop->dev		= &pdev->dev;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ