All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/3] power: Add simple poweroff-gpio driver
Date: Mon, 19 Nov 2012 10:38:06 -0700	[thread overview]
Message-ID: <50AA6E7E.5060501@wwwdotorg.org> (raw)
In-Reply-To: <1353142266-1289-2-git-send-email-andrew@lunn.ch>

On 11/17/2012 01:51 AM, Andrew Lunn wrote:
> Given appropriate devicetree bindings, this driver registers a
> pm_power_off function to set a GPIO line high/low to power down
> your board.

> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig

> +menuconfig POWER_RESET
> +	bool "Board level reset or power off"
> +	help
> +	  Provides a number of drivers which either reset a complete board
> +	  or shut it down, by manipulating the main power supply on the board.
> +
> +	  Say Y here to enable board reset and power off
> +
> +config POWER_RESET_GPIO
> +	bool "GPIO power-off driver"
> +	depends on OF_GPIO && POWER_RESET

I assume CONFIG_POWER_RESET won't really provide any/much
infra-structure itself. So, does it make sense to put all the individual
drives inside "if POWER_RESET" or a menu definition, so they don't all
have to depend on POWER_RESET explicitly?

> diff --git a/drivers/power/reset/gpio-poweroff.c b/drivers/power/reset/gpio-poweroff.c

> +static void gpio_poweroff_do_poweroff(void)
> +{
> +	BUG_ON(gpio_num == -1);

Perhaps use gpio_is_valid() here?

> +	/* drive it active */
> +	gpio_direction_output(gpio_num, !gpio_active_low);

The rest of the code below doesn't make a lot of sense to me. From
reading the binding documentation, it seems like the GPIO is expected to
be level-sensitive, and as such the above gpio_direction_output() call
should be all that's needed. What is the code below doing? If this
driver supports either a level-sensitive GPIO or generating a pulse on a
GPIO, I think the binding should be enhanced to specify which signalling
type is required. Also, all the delays should be specified as DT properties.

> +	mdelay(100);
> +	/* rising edge or drive inactive */

You can't assume that an active->inactive edge is a rising edge if you
allow the polarity to be configurable; I would remove that part of the
comment. Same below for "falling edge".

> +	gpio_set_value(gpio_num, gpio_active_low);
> +	mdelay(100);
> +	/* falling edge */
> +	gpio_set_value(gpio_num, !gpio_active_low);
> +
> +	/* give it some time */
> +	mdelay(3000);

> +static int __devinit gpio_poweroff_probe(struct platform_device *pdev)

> +	gpio_num = of_get_gpio_flags(pdev->dev.of_node, 0, &flags);
> +	if (gpio_num < 0) {

Perhaps use gpio_is_valid() here?

> +		pr_err("%s: Could not get GPIO configuration: %d",
> +		       __func__, gpio_num);
> +		return -ENODEV;
> +	}

This doesn't handle deferred probe correctly; if gpio_num ==
-EPROBE_DEFER, then this function needs to return -EPROBE_DEFER too; why
not "return gpio_num" rather than "return -ENODEV" above?

> +	gpio_active_low = flags & OF_GPIO_ACTIVE_LOW;
> +
> +	if (of_get_property(pdev->dev.of_node, "input", NULL))
> +		input = true;

Perhaps use of_property_read_bool() here.

> +static int __devexit gpio_poweroff_remove(struct platform_device *pdev)
> +{
> +	if (gpio_num != -1)
> +		gpio_free(gpio_num);

Perhaps use gpio_is_valid() here? Actually, how could this happen;
presumably if the GPIO is valid, probe() never succeeded, so you should
always just free the GPIO.

> +static struct platform_driver gpio_poweroff_driver = {
> +	.probe = gpio_poweroff_probe,
> +	.remove = __devexit_p(gpio_poweroff_remove),
> +	.driver = {
> +		   .name = "poweroff-gpio",
> +		   .owner = THIS_MODULE,
> +		   .of_match_table = of_gpio_poweroff_match,
> +		   },

There seems to be a mix of TAB/space indents there, and the closing }
should probably be aligned with the start of ".driver"?

> +MODULE_LICENSE("GPL");

That should be "GPL v2".

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org,
	linux ARM
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	gmbnomis-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH v3 1/3] power: Add simple poweroff-gpio driver
Date: Mon, 19 Nov 2012 10:38:06 -0700	[thread overview]
Message-ID: <50AA6E7E.5060501@wwwdotorg.org> (raw)
In-Reply-To: <1353142266-1289-2-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>

On 11/17/2012 01:51 AM, Andrew Lunn wrote:
> Given appropriate devicetree bindings, this driver registers a
> pm_power_off function to set a GPIO line high/low to power down
> your board.

> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig

> +menuconfig POWER_RESET
> +	bool "Board level reset or power off"
> +	help
> +	  Provides a number of drivers which either reset a complete board
> +	  or shut it down, by manipulating the main power supply on the board.
> +
> +	  Say Y here to enable board reset and power off
> +
> +config POWER_RESET_GPIO
> +	bool "GPIO power-off driver"
> +	depends on OF_GPIO && POWER_RESET

I assume CONFIG_POWER_RESET won't really provide any/much
infra-structure itself. So, does it make sense to put all the individual
drives inside "if POWER_RESET" or a menu definition, so they don't all
have to depend on POWER_RESET explicitly?

> diff --git a/drivers/power/reset/gpio-poweroff.c b/drivers/power/reset/gpio-poweroff.c

> +static void gpio_poweroff_do_poweroff(void)
> +{
> +	BUG_ON(gpio_num == -1);

Perhaps use gpio_is_valid() here?

> +	/* drive it active */
> +	gpio_direction_output(gpio_num, !gpio_active_low);

The rest of the code below doesn't make a lot of sense to me. From
reading the binding documentation, it seems like the GPIO is expected to
be level-sensitive, and as such the above gpio_direction_output() call
should be all that's needed. What is the code below doing? If this
driver supports either a level-sensitive GPIO or generating a pulse on a
GPIO, I think the binding should be enhanced to specify which signalling
type is required. Also, all the delays should be specified as DT properties.

> +	mdelay(100);
> +	/* rising edge or drive inactive */

You can't assume that an active->inactive edge is a rising edge if you
allow the polarity to be configurable; I would remove that part of the
comment. Same below for "falling edge".

> +	gpio_set_value(gpio_num, gpio_active_low);
> +	mdelay(100);
> +	/* falling edge */
> +	gpio_set_value(gpio_num, !gpio_active_low);
> +
> +	/* give it some time */
> +	mdelay(3000);

> +static int __devinit gpio_poweroff_probe(struct platform_device *pdev)

> +	gpio_num = of_get_gpio_flags(pdev->dev.of_node, 0, &flags);
> +	if (gpio_num < 0) {

Perhaps use gpio_is_valid() here?

> +		pr_err("%s: Could not get GPIO configuration: %d",
> +		       __func__, gpio_num);
> +		return -ENODEV;
> +	}

This doesn't handle deferred probe correctly; if gpio_num ==
-EPROBE_DEFER, then this function needs to return -EPROBE_DEFER too; why
not "return gpio_num" rather than "return -ENODEV" above?

> +	gpio_active_low = flags & OF_GPIO_ACTIVE_LOW;
> +
> +	if (of_get_property(pdev->dev.of_node, "input", NULL))
> +		input = true;

Perhaps use of_property_read_bool() here.

> +static int __devexit gpio_poweroff_remove(struct platform_device *pdev)
> +{
> +	if (gpio_num != -1)
> +		gpio_free(gpio_num);

Perhaps use gpio_is_valid() here? Actually, how could this happen;
presumably if the GPIO is valid, probe() never succeeded, so you should
always just free the GPIO.

> +static struct platform_driver gpio_poweroff_driver = {
> +	.probe = gpio_poweroff_probe,
> +	.remove = __devexit_p(gpio_poweroff_remove),
> +	.driver = {
> +		   .name = "poweroff-gpio",
> +		   .owner = THIS_MODULE,
> +		   .of_match_table = of_gpio_poweroff_match,
> +		   },

There seems to be a mix of TAB/space indents there, and the closing }
should probably be aligned with the start of ".driver"?

> +MODULE_LICENSE("GPL");

That should be "GPL v2".

  reply	other threads:[~2012-11-19 17:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-17  8:51 [PATCH v3 0/3] GPIO driver to turn power off Andrew Lunn
2012-11-17  8:51 ` Andrew Lunn
2012-11-17  8:51 ` [PATCH v3 1/3] power: Add simple poweroff-gpio driver Andrew Lunn
2012-11-17  8:51   ` Andrew Lunn
2012-11-19 17:38   ` Stephen Warren [this message]
2012-11-19 17:38     ` Stephen Warren
2012-11-20  8:37     ` Andrew Lunn
2012-11-20  8:37       ` Andrew Lunn
2012-11-20  8:48       ` Anton Vorontsov
2012-11-20  8:48         ` Anton Vorontsov
2012-11-20 17:11       ` Stephen Warren
2012-11-20 17:11         ` Stephen Warren
2012-11-20 20:31         ` Andrew Lunn
2012-11-20 20:31           ` Andrew Lunn
2012-11-20 21:17           ` Stephen Warren
2012-11-20 21:17             ` Stephen Warren
2012-11-20 22:05             ` Andrew Lunn
2012-11-20 22:05               ` Andrew Lunn
2012-11-21  0:17               ` Stephen Warren
2012-11-21  0:17                 ` Stephen Warren
2012-11-17  8:51 ` [PATCH v3 2/3] ARM: Kirkwood: Convert DNSKW to use gpio-poweroff Andrew Lunn
2012-11-17  8:51   ` Andrew Lunn
2012-11-17  8:51 ` [PATCH v3 3/3] ARM: Kirkwood: Convert IB62x0 " Andrew Lunn
2012-11-17  8:51   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50AA6E7E.5060501@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.