[PATCH 1/2] gpiolib: Add !CONFIG_GPIOLIB definitions of devm_ functions

[PATCH 1/2] gpiolib: Add !CONFIG_GPIOLIB definitions of devm_ functions

[Mark Brown]

Currently the managed gpio_request() and gpio_free() are not stubbed out
for configurations not using gpiolib - do that to aid use in drivers.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 include/linux/gpio.h |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index f8b46af..ceb8eef 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -89,6 +89,12 @@ static inline int gpio_request(unsigned gpio, const char *label)
 	return -ENOSYS;
 }
 
+static inline int devm_gpio_request(struct device *dev, unsigned gpio,
+				    const char *label)
+{
+	return -ENOSYS;
+}
+
 static inline int gpio_request_one(unsigned gpio,
 					unsigned long flags, const char *label)
 {
@@ -108,6 +114,14 @@ static inline void gpio_free(unsigned gpio)
 	WARN_ON(1);
 }
 
+static inline void devm_gpio_free(struct device *dev, unsigned gpio)
+{
+	might_sleep();
+
+	/* GPIO can never have been requested */
+	WARN_ON(1);
+}
+
 static inline void gpio_free_array(const struct gpio *array, size_t num)
 {
 	might_sleep();
-- 
1.7.9.1

[PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

Allow drivers to use the modern request and configure idiom together
with devres.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/gpio/devres.c      |   29 +++++++++++++++++++++++++++++
 include/asm-generic/gpio.h |    2 ++
 include/linux/gpio.h       |    6 ++++++
 3 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 3dd2939..d21a9ff 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -71,6 +71,35 @@ int devm_gpio_request(struct device *dev, unsigned gpio, const char *label)
 EXPORT_SYMBOL(devm_gpio_request);
 
 /**
+ *	devm_gpio_request_one - request a single GPIO with initial setup
+ *	@dev:   device to request for
+ *	@gpio:	the GPIO number
+ *	@flags:	GPIO configuration as specified by GPIOF_*
+ *	@label:	a literal description string of this GPIO
+ */
+int devm_gpio_request_one(struct device *dev, unsigned gpio,
+			  unsigned long flags, const char *label)
+{
+	unsigned *dr;
+	int rc;
+
+	dr = devres_alloc(devm_gpio_release, sizeof(unsigned), GFP_KERNEL);
+	if (!dr)
+		return -ENOMEM;
+
+	rc = gpio_request_one(gpio, flags, label);
+	if (rc) {
+		devres_free(dr);
+		return rc;
+	}
+
+	*dr = gpio;
+	devres_add(dev, dr);
+
+	return 0;
+}
+
+/**
  *      devm_gpio_free - free an interrupt
  *      @dev: device to free gpio for
  *      @gpio: gpio to free
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 5f52690..4ead123 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -179,6 +179,8 @@ extern void gpio_free_array(const struct gpio *array, size_t num);
 
 /* bindings for managed devices that want to request gpios */
 int devm_gpio_request(struct device *dev, unsigned gpio, const char *label);
+int devm_gpio_request_one(struct device *dev, unsigned gpio,
+			  unsigned long flags, const char *label);
 void devm_gpio_free(struct device *dev, unsigned int gpio);
 
 #ifdef CONFIG_GPIO_SYSFS
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index ceb8eef..a8bacb8 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -101,6 +101,12 @@ static inline int gpio_request_one(unsigned gpio,
 	return -ENOSYS;
 }
 
+static inline int devm_gpio_request_one(struct device *dev, unsigned gpio,
+					unsigned long flags, const char *label)
+{
+	return -ENOSYS;
+}
+
 static inline int gpio_request_array(const struct gpio *array, size_t num)
 {
 	return -ENOSYS;
-- 
1.7.9.1

Re: [PATCH 1/2] gpiolib: Add !CONFIG_GPIOLIB definitions of devm_ functions

[Grant Likely]

On Wed,  4 Apr 2012 16:14:48 +0100, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> Currently the managed gpio_request() and gpio_free() are not stubbed out
> for configurations not using gpiolib - do that to aid use in drivers.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Applied, thanks.

g.

> ---
>  include/linux/gpio.h |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/gpio.h b/include/linux/gpio.h
> index f8b46af..ceb8eef 100644
> --- a/include/linux/gpio.h
> +++ b/include/linux/gpio.h
> @@ -89,6 +89,12 @@ static inline int gpio_request(unsigned gpio, const char *label)
>  	return -ENOSYS;
>  }
>  
> +static inline int devm_gpio_request(struct device *dev, unsigned gpio,
> +				    const char *label)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int gpio_request_one(unsigned gpio,
>  					unsigned long flags, const char *label)
>  {
> @@ -108,6 +114,14 @@ static inline void gpio_free(unsigned gpio)
>  	WARN_ON(1);
>  }
>  
> +static inline void devm_gpio_free(struct device *dev, unsigned gpio)
> +{
> +	might_sleep();
> +
> +	/* GPIO can never have been requested */
> +	WARN_ON(1);
> +}
> +
>  static inline void gpio_free_array(const struct gpio *array, size_t num)
>  {
>  	might_sleep();
> -- 
> 1.7.9.1
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Grant Likely]

On Wed,  4 Apr 2012 16:14:49 +0100, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> Allow drivers to use the modern request and configure idiom together
> with devres.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/gpio/devres.c      |   29 +++++++++++++++++++++++++++++
>  include/asm-generic/gpio.h |    2 ++
>  include/linux/gpio.h       |    6 ++++++
>  3 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
> index 3dd2939..d21a9ff 100644
> --- a/drivers/gpio/devres.c
> +++ b/drivers/gpio/devres.c
> @@ -71,6 +71,35 @@ int devm_gpio_request(struct device *dev, unsigned gpio, const char *label)
>  EXPORT_SYMBOL(devm_gpio_request);
>  
>  /**
> + *	devm_gpio_request_one - request a single GPIO with initial setup
> + *	@dev:   device to request for
> + *	@gpio:	the GPIO number
> + *	@flags:	GPIO configuration as specified by GPIOF_*
> + *	@label:	a literal description string of this GPIO
> + */
> +int devm_gpio_request_one(struct device *dev, unsigned gpio,
> +			  unsigned long flags, const char *label)
> +{
> +	unsigned *dr;
> +	int rc;
> +
> +	dr = devres_alloc(devm_gpio_release, sizeof(unsigned), GFP_KERNEL);
> +	if (!dr)
> +		return -ENOMEM;
> +
> +	rc = gpio_request_one(gpio, flags, label);
> +	if (rc) {
> +		devres_free(dr);
> +		return rc;
> +	}
> +
> +	*dr = gpio;
> +	devres_add(dev, dr);
> +
> +	return 0;
> +}

Can we make devm_gpio_request a static inline wrapper around
devm_gpio_request_one() with the flags field set to '0'?  I don't liek
the duplication of this function.

Similarily, gpio_request() should actually be a static inline around
gpio_request_one() instead of the other way around as it is currently
written.

> +
> +/**
>   *      devm_gpio_free - free an interrupt
>   *      @dev: device to free gpio for
>   *      @gpio: gpio to free
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index 5f52690..4ead123 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -179,6 +179,8 @@ extern void gpio_free_array(const struct gpio *array, size_t num);
>  
>  /* bindings for managed devices that want to request gpios */
>  int devm_gpio_request(struct device *dev, unsigned gpio, const char *label);
> +int devm_gpio_request_one(struct device *dev, unsigned gpio,
> +			  unsigned long flags, const char *label);
>  void devm_gpio_free(struct device *dev, unsigned int gpio);
>  
>  #ifdef CONFIG_GPIO_SYSFS
> diff --git a/include/linux/gpio.h b/include/linux/gpio.h
> index ceb8eef..a8bacb8 100644
> --- a/include/linux/gpio.h
> +++ b/include/linux/gpio.h
> @@ -101,6 +101,12 @@ static inline int gpio_request_one(unsigned gpio,
>  	return -ENOSYS;
>  }
>  
> +static inline int devm_gpio_request_one(struct device *dev, unsigned gpio,
> +					unsigned long flags, const char *label)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int gpio_request_array(const struct gpio *array, size_t num)
>  {
>  	return -ENOSYS;
> -- 
> 1.7.9.1
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Thu, Apr 05, 2012 at 09:48:32PM -0700, Grant Likely wrote:

> Can we make devm_gpio_request a static inline wrapper around
> devm_gpio_request_one() with the flags field set to '0'?  I don't liek
> the duplication of this function.

> Similarily, gpio_request() should actually be a static inline around
> gpio_request_one() instead of the other way around as it is currently
> written.

Yeah, I couldn't understand why the non-managed functions were written
in this way so I followed the same pattern when I added the managed one
assuming that the original code was sane.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Grant Likely]

On Fri, 6 Apr 2012 15:49:17 +0100, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Apr 05, 2012 at 09:48:32PM -0700, Grant Likely wrote:
> 
> > Can we make devm_gpio_request a static inline wrapper around
> > devm_gpio_request_one() with the flags field set to '0'?  I don't liek
> > the duplication of this function.
> 
> > Similarily, gpio_request() should actually be a static inline around
> > gpio_request_one() instead of the other way around as it is currently
> > written.
> 
> Yeah, I couldn't understand why the non-managed functions were written
> in this way so I followed the same pattern when I added the managed one
> assuming that the original code was sane.

Actually, I looked at it again, and the _one version behaves subtly
different from the non-_one version.  That may be irrelevant though.

g.


-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Fri, Apr 06, 2012 at 07:25:12PM -0700, Grant Likely wrote:
> On Fri, 6 Apr 2012 15:49:17 +0100, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > Yeah, I couldn't understand why the non-managed functions were written
> > in this way so I followed the same pattern when I added the managed one
> > assuming that the original code was sane.

> Actually, I looked at it again, and the _one version behaves subtly
> different from the non-_one version.  That may be irrelevant though.

It always does a direction set, yes.  This will make a difference if the
direction call either fails or blocks future reconfigurations, what was
puzzling me was if this was an issue or not and like I say I decided to
assume it was and stick with the same pattern.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Sat, Apr 07, 2012 at 10:00:18AM +0100, Mark Brown wrote:
> On Fri, Apr 06, 2012 at 07:25:12PM -0700, Grant Likely wrote:

> > Actually, I looked at it again, and the _one version behaves subtly
> > different from the non-_one version.  That may be irrelevant though.

> It always does a direction set, yes.  This will make a difference if the
> direction call either fails or blocks future reconfigurations, what was
> puzzling me was if this was an issue or not and like I say I decided to
> assume it was and stick with the same pattern.

Just after sending this (isn't that always the way?) I realised there is
one important case where it makes a difference: if the code does this:

	gpio_request(foo, "bar");
	gpio_direction_output(foo, 1);

then if the GPIO was already driving out high we will maintain steady
state.  If, however, we were to do:

	gpio_request(foo, "bar");
	gpio_direction_input();
	gpio_direction_output(foo, 1);

where the first two calls are the natural result of implementing
gpio_request() in terms of gpio_request_one() then the GPIO would glitch
high Z during the process which might have unfortunate consequences for
whatever the GPIO is controlling.

I think instead of redoing the implementation we need start a campaign
to convert gpio_request() users to gpio_request_one() - coccinelle can
probably take a large chunk of the work but it'll need some manual help
I expect.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

Allow drivers to use the modern request and configure idiom together
with devres.

As with plain gpio_request() and gpio_request_one() we can't implement
the old school version in terms of _one() as this would force the
explicit selection of a direction in gpio_request() which could break
systems if we pick the wrong one.  Implementing devm_gpio_request_one()
in terms of devm_gpio_request() would needlessly complicate things or
lead to duplication from the unmanaged version depending on how it's
done.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/gpio/devres.c      |   29 +++++++++++++++++++++++++++++
 include/asm-generic/gpio.h |    2 ++
 include/linux/gpio.h       |    6 ++++++
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 3dd2939..d21a9ff 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -71,6 +71,35 @@ int devm_gpio_request(struct device *dev, unsigned gpio, const char *label)
 EXPORT_SYMBOL(devm_gpio_request);
 
 /**
+ *	devm_gpio_request_one - request a single GPIO with initial setup
+ *	@dev:   device to request for
+ *	@gpio:	the GPIO number
+ *	@flags:	GPIO configuration as specified by GPIOF_*
+ *	@label:	a literal description string of this GPIO
+ */
+int devm_gpio_request_one(struct device *dev, unsigned gpio,
+			  unsigned long flags, const char *label)
+{
+	unsigned *dr;
+	int rc;
+
+	dr = devres_alloc(devm_gpio_release, sizeof(unsigned), GFP_KERNEL);
+	if (!dr)
+		return -ENOMEM;
+
+	rc = gpio_request_one(gpio, flags, label);
+	if (rc) {
+		devres_free(dr);
+		return rc;
+	}
+
+	*dr = gpio;
+	devres_add(dev, dr);
+
+	return 0;
+}
+
+/**
  *      devm_gpio_free - free an interrupt
  *      @dev: device to free gpio for
  *      @gpio: gpio to free
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 5f52690..4ead123 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -179,6 +179,8 @@ extern void gpio_free_array(const struct gpio *array, size_t num);
 
 /* bindings for managed devices that want to request gpios */
 int devm_gpio_request(struct device *dev, unsigned gpio, const char *label);
+int devm_gpio_request_one(struct device *dev, unsigned gpio,
+			  unsigned long flags, const char *label);
 void devm_gpio_free(struct device *dev, unsigned int gpio);
 
 #ifdef CONFIG_GPIO_SYSFS
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 8e0fe1b..a68024e 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -78,6 +78,12 @@ static inline int gpio_request_one(unsigned gpio,
 	return -ENOSYS;
 }
 
+static inline int devm_gpio_request_one(struct device *dev, unsigned gpio,
+					unsigned long flags, const char *label)
+{
+	return -ENOSYS;
+}
+
 static inline int gpio_request_array(const struct gpio *array, size_t num)
 {
 	return -ENOSYS;
-- 
1.7.10

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Mark Brown]

On Wed, May 02, 2012 at 12:46:46PM +0100, Mark Brown wrote:
> Allow drivers to use the modern request and configure idiom together
> with devres.

> As with plain gpio_request() and gpio_request_one() we can't implement
> the old school version in terms of _one() as this would force the
> explicit selection of a direction in gpio_request() which could break
> systems if we pick the wrong one.  Implementing devm_gpio_request_one()
> in terms of devm_gpio_request() would needlessly complicate things or
> lead to duplication from the unmanaged version depending on how it's
> done.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Any chance we can get this into 3.5?  Writing error handling code is
boring :)

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Linus Walleij]

On Wed, May 2, 2012 at 1:46 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> Allow drivers to use the modern request and configure idiom together
> with devres.
>
> As with plain gpio_request() and gpio_request_one() we can't implement
> the old school version in terms of _one() as this would force the
> explicit selection of a direction in gpio_request() which could break
> systems if we pick the wrong one.  Implementing devm_gpio_request_one()
> in terms of devm_gpio_request() would needlessly complicate things or
> lead to duplication from the unmanaged version depending on how it's
> done.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 2/2] gpiolib: Implement devm_gpio_request_one()

[Grant Likely]

On Sat, 12 May 2012 20:05:02 +0100, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 02, 2012 at 12:46:46PM +0100, Mark Brown wrote:
> > Allow drivers to use the modern request and configure idiom together
> > with devres.
> 
> > As with plain gpio_request() and gpio_request_one() we can't implement
> > the old school version in terms of _one() as this would force the
> > explicit selection of a direction in gpio_request() which could break
> > systems if we pick the wrong one.  Implementing devm_gpio_request_one()
> > in terms of devm_gpio_request() would needlessly complicate things or
> > lead to duplication from the unmanaged version depending on how it's
> > done.
> > 
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> Any chance we can get this into 3.5?  Writing error handling code is
> boring :)

Applied, thanks.  I'll push it out this evening.

g.


-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.