Thread (1 message) 1 message, 1 author, 2013-07-16

[PATCH v8] reset: Add driver for gpio-controlled reset pins

From: Stephen Warren <hidden>
Date: 2013-07-16 15:47:02
Also in: linux-devicetree

On 07/16/2013 12:51 AM, Shawn Guo wrote:
On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
quoted
Hi Philipp,

On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
quoted
This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Stephen Warren <redacted>
I see this patch is very useful, as GPIOs are widely used to reset
components/devices on board.  But I do not find the patch in v3.11-rc1.
What's your plan about it?

Also, I'm wondering if we should register the driver a little bit
early.  Please see the following patch.  If it makes sense to you,
I can send the patch to you, or you can just quash it into yours.
And here is another change request.
quoted hunk
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
-	gpio_set_value(drvdata->gpio, value);
+	if (gpio_cansleep(drvdata->gpio))
+		gpio_set_value_cansleep(drvdata->gpio, value);
+	else
+		gpio_set_value(drvdata->gpio, value);
That's not right. Calling gpio_set_value() v.s.
gpio_set_value_cansleep() should be based on the properties of the
calling context, not the GPIO being controlled. In other words, if it's
permissible to call gpio_set_value_cansleep() at this point in the code,
simply always call that, and remove the conditional logic.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help