[GIT PULL] GPIO changes for v3.6

[GIT PULL] GPIO changes for v3.6

[Linus Walleij]

Hi Linus,

in Grants absence, these are my queued and -next-tested changes
for v3.6, please pull them in. Grants "merge" branch prior to his
absence was merged in as a base for this patch series.

The following is the same information as found in the tag:

GPIO changes for v3.6:
- New driver for AMD-8111 southbridge GPIOs
- New driver for Wolfson Micro Arizona devices
- Propagate device tree parse errors
- Probe deferral finalizations - all expected calls to
  GPIO will now hopefully request deferral where apropriate
- Misc updates to TCA6424, WM8994, LPC32xx, PCF857x, Samsung
  MXC, OMAP and PCA953X drivers.

Please pull it in!

The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:

  Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-for-v3.6

Alexandre Courbot (1):
      gpio: propagate of_parse_phandle_with_args errors

Andreas Schallenberg (1):
      gpio/tca6424: merge I2C transactions, remove cast

Benoît Thébaudeau (1):
      gpio/mxc: use the edge_sel feature if available

Chandrabhanu Mahapatra (1):
      GPIO: PCA953X: Increase size of invert variable to support 24 bit

Dmitry Eremin-Solenikov (1):
      gpio: add a driver for GPIO pins found on AMD-8111 south bridge chips

Dong Aisheng (1):
      gpio/of: fix a typo of comment message

Kevin Hilman (1):
      MAINTAINERS: add entry OMAP GPIO driver

Kuninori Morimoto (1):
      gpio: pcf857x: share 8/16 bit access functions

Leed Aguilar (1):
      gpio/pca953x: increase variables size to support 24 bit of data

Linus Walleij (1):
      Merge branch 'gpio/merge' of
git://git.secretlab.ca/git/linux-2.6 into grant

Mark Brown (5):
      gpiolib: wm8994: Use irq_domain mappings for gpios
      gpiolib: wm8994: Convert to devm_kzalloc()
      MAINTAINERS: Add Wolfson gpiolib drivers to the Wolfson entry
      gpiolib: Add support for Wolfson Microelectronics Arizona class devices
      gpiolib: Defer failed gpio requests by default

Olof Johansson (1):
      gpio: samsung: add flags specifier to device-tree binding

Roland Stigge (3):
      gpio: LPC32xx: Driver cleanup
      gpio: gpio-lpc32xx: Add gpio_to_irq mapping
      gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not
yet available

Tarun Kanti DebBarma (1):
      gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()

 .../devicetree/bindings/gpio/fsl-imx-gpio.txt      |    2 +-
 .../devicetree/bindings/gpio/gpio-samsung.txt      |    9 +-
 MAINTAINERS                                        |    8 +
 arch/arm/boot/dts/imx51.dtsi                       |    8 +-
 arch/arm/boot/dts/imx53.dtsi                       |   14 +-
 arch/arm/boot/dts/imx6q.dtsi                       |   14 +-
 arch/arm/mach-imx/mm-imx25.c                       |   10 +-
 arch/arm/mach-imx/mm-imx3.c                        |    7 +-
 arch/arm/mach-imx/mm-imx5.c                        |   40 ++--
 drivers/gpio/Kconfig                               |   18 ++
 drivers/gpio/Makefile                              |    2 +
 drivers/gpio/gpio-amd8111.c                        |  246 ++++++++++++++++++++
 drivers/gpio/gpio-arizona.c                        |  163 +++++++++++++
 drivers/gpio/gpio-lpc32xx.c                        |   74 ++++++-
 drivers/gpio/gpio-mxc.c                            |   71 +++++--
 drivers/gpio/gpio-omap.c                           |   10 +-
 drivers/gpio/gpio-pca953x.c                        |   67 +++---
 drivers/gpio/gpio-pcf857x.c                        |   93 +++-----
 drivers/gpio/gpio-samsung.c                        |    5 +-
 drivers/gpio/gpio-wm8994.c                         |   17 +-
 drivers/gpio/gpiolib-of.c                          |    9 +-
 drivers/gpio/gpiolib.c                             |    2 +-
 include/linux/i2c/pca953x.h                        |    2 +-
 23 files changed, 700 insertions(+), 191 deletions(-)
 create mode 100644 drivers/gpio/gpio-amd8111.c
 create mode 100644 drivers/gpio/gpio-arizona.c

Yours,
Linus Walleij

Re: [GIT PULL] GPIO changes for v3.6

[Linus Torvalds]

On Wed, Jul 25, 2012 at 3:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> in Grants absence, these are my queued and -next-tested changes
> for v3.6, please pull them in. Grants "merge" branch prior to his
> absence was merged in as a base for this patch series.

Please verify my conflict resolution in drivers/gpio/gpio-mxc.c.

The resolution seemed pretty straight-forward, but I obviously didn't
test the result, so it would be best to double-check,

             Linus

Re: [GIT PULL] GPIO changes for v3.6

[Linus Walleij]

On Thu, Jul 26, 2012 at 10:58 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Jul 25, 2012 at 3:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> in Grants absence, these are my queued and -next-tested changes
>> for v3.6, please pull them in. Grants "merge" branch prior to his
>> absence was merged in as a base for this patch series.
>
> Please verify my conflict resolution in drivers/gpio/gpio-mxc.c.
>
> The resolution seemed pretty straight-forward, but I obviously didn't
> test the result, so it would be best to double-check,

LooksGoodToMe(TM).

Better page the MXC people so they can scream if something
goes wild.

Yours,
Linus Walleij

Re: [GIT PULL] GPIO changes for v3.6

[Shawn Guo]

On Sat, Jul 28, 2012 at 12:37:05AM +0200, Linus Walleij wrote:
> Better page the MXC people so they can scream if something
> goes wild.
> 
Just tested the driver a little bit, and it still works for me.

-- 
Regards,
Shawn

Re: [GIT PULL] GPIO changes for v3.6

[NeilBrown]

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

On Thu, 26 Jul 2012 00:48:57 +0200 Linus Walleij <linus.walleij@linaro.org>
wrote:

> Hi Linus,
> 
> in Grants absence, these are my queued and -next-tested changes
> for v3.6, please pull them in. Grants "merge" branch prior to his
> absence was merged in as a base for this patch series.
> 
> The following is the same information as found in the tag:
> 
> GPIO changes for v3.6:
> - New driver for AMD-8111 southbridge GPIOs
> - New driver for Wolfson Micro Arizona devices
> - Propagate device tree parse errors
> - Probe deferral finalizations - all expected calls to
>   GPIO will now hopefully request deferral where apropriate
> - Misc updates to TCA6424, WM8994, LPC32xx, PCF857x, Samsung
>   MXC, OMAP and PCA953X drivers.
> 
..
> Mark Brown (5):
>       gpiolib: Defer failed gpio requests by default

Hi,
 this doesn't look quite right to me.

it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER 
which isn't right (an invalid gpio number will never become valid).
If a driver happened to use gpio_request to check the validity of the gpio
rather than doing it itself, it would defer the probe, rather than assume
that the GPIO doesn't exist.

I would suggest the following.  Reasonable?

NeilBrown

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index de0213c..259233b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1186,13 +1186,14 @@ int gpio_request(unsigned gpio, const char *label)
 {
 	struct gpio_desc	*desc;
 	struct gpio_chip	*chip;
-	int			status = -EPROBE_DEFER;
+	int			status = -EINVAL;
 	unsigned long		flags;
 
 	spin_lock_irqsave(&gpio_lock, flags);
 
 	if (!gpio_is_valid(gpio))
 		goto done;
+	status = -EPROBE_DEFER;
 	desc = &gpio_desc[gpio];
 	chip = desc->chip;
 	if (chip == NULL)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [GIT PULL] GPIO changes for v3.6

[Mark Brown]

On Mon, Jul 30, 2012 at 04:57:33PM +1000, NeilBrown wrote:

> it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER 
> which isn't right (an invalid gpio number will never become valid).
> If a driver happened to use gpio_request to check the validity of the gpio
> rather than doing it itself, it would defer the probe, rather than assume
> that the GPIO doesn't exist.

Is anything actually doing this?  For positive numbers that just seems
like it's asking for things to explode, for negative numbers I guess you
can get away with it at the minute though it's obviously not awesome
error handling.

> I would suggest the following.  Reasonable?

TBH I'd actually expect that gpio_is_valid() were checking that there's
a gpio_chip behind the GPIO number, now I look at the implementation
it's very surprising to me that it's just checking the GPIO array bounds
(and also that we remove the need for the fixed size GPIO array which is
just an endless source of annoyance).

Re: [GIT PULL] GPIO changes for v3.6

[NeilBrown]

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

On Mon, 30 Jul 2012 14:36:15 +0100 Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> On Mon, Jul 30, 2012 at 04:57:33PM +1000, NeilBrown wrote:
> 
> > it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER 
> > which isn't right (an invalid gpio number will never become valid).
> > If a driver happened to use gpio_request to check the validity of the gpio
> > rather than doing it itself, it would defer the probe, rather than assume
> > that the GPIO doesn't exist.
> 
> Is anything actually doing this?  For positive numbers that just seems
> like it's asking for things to explode, for negative numbers I guess you
> can get away with it at the minute though it's obviously not awesome
> error handling.

I suspect not, but stranger things have happened.

... though it occurs to me that it is possible that the GPIO number might not
be allocated until something else has been probed, so a -ve gpio number could
mean "there is no such gpio" or it could mean "gpio has not been allocated
yet".  I wonder if that should be allowed and where it should be handled.

> 
> > I would suggest the following.  Reasonable?
> 
> TBH I'd actually expect that gpio_is_valid() were checking that there's
> a gpio_chip behind the GPIO number, now I look at the implementation
> it's very surprising to me that it's just checking the GPIO array bounds
> (and also that we remove the need for the fixed size GPIO array which is
> just an endless source of annoyance).

Yes, gpio_is_valid is really just a check that the gpio_desc array dereference
won't over-flow.

I'd really like to see gpios be requested by name ... anyone know if there
are any plans along that line?

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [GIT PULL] GPIO changes for v3.6

[Mark Brown]

On Tue, Jul 31, 2012 at 02:47:24PM +1000, NeilBrown wrote:

> ... though it occurs to me that it is possible that the GPIO number might not
> be allocated until something else has been probed, so a -ve gpio number could
> mean "there is no such gpio" or it could mean "gpio has not been allocated
> yet".  I wonder if that should be allowed and where it should be handled.

If there's logic to do things like that I'd 

> I'd really like to see gpios be requested by name ... anyone know if there
> are any plans along that line?

I've not noticed anyone doing much substantial work on GPIO recently.

Re: [GIT PULL] GPIO changes for v3.6

[Linus Walleij]

On Mon, Jul 30, 2012 at 8:57 AM, NeilBrown <neilb@suse.de> wrote:

> it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER
> which isn't right (an invalid gpio number will never become valid).
> If a driver happened to use gpio_request to check the validity of the gpio
> rather than doing it itself, it would defer the probe, rather than assume
> that the GPIO doesn't exist.
>
> I would suggest the following.  Reasonable?

Unless there is a firm regression solved by this we can very well
discuss this until the next merge window.

The solution from Mark looks very much like the method used in
regulators, clocks etc. I bet if we look at the error paths of the
driver doing gpio_is_valid() the majority will be something in the
probe() path just bailing out if that was not supplied, alternatively
shunting in some non-GPIO code.

The more typical problem for
deferring driver to solve will be something like commit
2805b9ab7c836cfbe01e86129983e36205078cb2
where we have to check for -EPROBE_DEFER explicitly
and bail out before doing any gpio_is_valid() checks.

Yours,
Linus Walleij