[git pull] GPIO for v3.10

[git pull] GPIO for v3.10

[Grant Likely]

Hi Linus,

Here are the GPIO changes staged for v3.10. Please pull. I will send
another separate pull request for a large change removing
CONFIG_GENERIC_GPIO.

g.

The following changes since commit e97f9b5277afeabb54892ebc6f68500098467ba1:

  gpio/gpio-ich: fix ichx_gpio_check_available() return what callers
expect (2013-03-02 13:20:21 +0000)

are available in the git repository at:

  git://git.secretlab.ca/git/linux tags/gpio-for-linus

for you to fetch changes up to ab6ec0fb8901ce4359269ac56c691ffcb5071ccb:

  gpio/omap: ensure gpio context is initialised (2013-04-26 09:52:57 +0200)

----------------------------------------------------------------
GPIO changes for Linux 3.10

The usual selection of bug fixes and driver updates for GPIO. Nothing
really stands out except the addition of the GRGPIO driver and some
enhacements to ACPI support

----------------------------------------------------------------
Alexander Shiyan (1):
      GPIO: gpio-generic: remove kfree() from bgpio_remove call

Andreas Larsson (3):
      gpio: gpio-generic: Add 16 and 32 bit big endian byte order support
      gpio: grgpio: Add device driver for GRGPIO cores
      gpio: grgpio: Add irq support

Axel Lin (3):
      gpio: viperboard: Remove duplicate code to set gpio->gpiob_val
      gpio: samsung: Add terminating entry for exynos_pinctrl_ids
      gpio: lpc32xx: Fix off-by-one valid range checking for bank

Christophe Leroy (1):
      MAX7301 GPIO: Do not force SPI speed when using OF Platform

Darren Hart (1):
      gpio-sch: Allow for more than 8 lines in the resume well

Jean Delvare (2):
      gpio-ich: Check for pin availability at request time
      gpio: ucb1400: Can be built as a module

Jingoo Han (9):
      gpio: adp5520: use devm_kzalloc()
      gpio: max7300: use devm_kzalloc()
      gpio: max7301: use devm_kzalloc()
      gpio: max732x: use devm_kzalloc()
      gpio: mc33880: use devm_kzalloc()
      gpio: pcf857x: use devm_kzalloc()
      gpio: mc33880: use dev_err() instead of printk()
      gpio: 74x164: use spi_get_drvdata() and spi_set_drvdata()
      gpio: mc33880: use spi_get_drvdata() and spi_set_drvdata()

Jon Hunter (6):
      gpio/omap: convert gpio irq domain to linear mapping
      gpio/omap: warn if bank is not enabled on setting irq type
      gpio/omap: free irq domain in probe() failure paths
      gpio/omap: optimise interrupt service routine
      gpio/omap: force restore if context loss is not detectable
      gpio/omap: ensure gpio context is initialised

Lars Poeschel (1):
      gpio: mcp23s08: convert driver to DT

Laurent Navet (10):
      gpio: gpiolib-of.c: fix checkpatch error
      gpio: gpio-mvebu.c: fix checkpatch errors
      gpio: gpio-omap.c: fix checkpatch error
      gpio: gpio-pca953x.c: fix checkpatch error
      gpio: gpio-pxa.c: fix checkpatch errors
      gpio: gpio-sch.c: fix checkpatch error
      gpio: gpio-stp-xway.c: fix checkpatch error
      gpio: gpio-tc3589x.c: fix checkpatch errors
      gpio: gpio-timberdale.c: fix checkpatch error
      gpio: gpio-tps65910.c: fix checkpatch error

Magnus Damm (2):
      gpio/em: Add Device Tree support
      gpio: em: Make use of devm functions

Mathias Nyman (1):
      gpio-lynxpoint: Add X86 dependency and io-port handling header.

Mika Westerberg (2):
      gpio/gpio-ich: make ichx_gpio_check_available() return a pure
boolean value
      gpiolib-acpi: introduce acpi_get_gpio_by_index() helper

Nikolay Balandin (1):
      Add TI TCA9554 to supported devices table

Rafael J. Wysocki (1):
      gpio / ACPI: Handle ACPI events in accordance with the spec

Sachin Kamat (1):
      gpio/vt8500: Convert to devm_ioremap_resource()

Simon Guinot (1):
      gpio: mvebu: add dbg_show function

Stephen Warren (1):
      gpio/tegra: assume CONFIG_OF

Tarun Kanti DebBarma (1):
      gpio/omap: remove extra context restores in *_runtime_resume()

 Documentation/acpi/enumeration.txt                 |  32 +-
 .../devicetree/bindings/gpio/gpio-grgpio.txt       |  26 ++
 .../devicetree/bindings/gpio/gpio-mcp23s08.txt     |  47 ++
 .../devicetree/bindings/gpio/gpio-omap.txt         |   7 +-
 drivers/gpio/Kconfig                               |  13 +-
 drivers/gpio/Makefile                              |   1 +
 drivers/gpio/gpio-74x164.c                         |   8 +-
 drivers/gpio/gpio-adp5520.c                        |   4 +-
 drivers/gpio/gpio-em.c                             |  94 ++--
 drivers/gpio/gpio-generic.c                        |  62 ++-
 drivers/gpio/gpio-grgpio.c                         | 505 +++++++++++++++++++++
 drivers/gpio/gpio-ich.c                            |  17 +-
 drivers/gpio/gpio-lpc32xx.c                        |   2 +-
 drivers/gpio/gpio-lynxpoint.c                      |   1 +
 drivers/gpio/gpio-max7300.c                        |   4 +-
 drivers/gpio/gpio-max7301.c                        |   7 +-
 drivers/gpio/gpio-max732x.c                        |   5 +-
 drivers/gpio/gpio-mc33880.c                        |  19 +-
 drivers/gpio/gpio-mcp23s08.c                       | 137 ++++--
 drivers/gpio/gpio-mvebu.c                          |  85 +++-
 drivers/gpio/gpio-omap.c                           | 162 ++++---
 drivers/gpio/gpio-pca953x.c                        |   3 +-
 drivers/gpio/gpio-pcf857x.c                        |   8 +-
 drivers/gpio/gpio-pxa.c                            |   4 +-
 drivers/gpio/gpio-samsung.c                        |   1 +
 drivers/gpio/gpio-sch.c                            | 111 +++--
 drivers/gpio/gpio-stp-xway.c                       |   2 +-
 drivers/gpio/gpio-tc3589x.c                        |   8 +-
 drivers/gpio/gpio-tegra.c                          |  11 +-
 drivers/gpio/gpio-timberdale.c                     |   3 +-
 drivers/gpio/gpio-tps65910.c                       |   2 +-
 drivers/gpio/gpio-viperboard.c                     |   4 -
 drivers/gpio/gpio-vt8500.c                         |   8 +-
 drivers/gpio/gpiolib-acpi.c                        | 217 ++++++++-
 drivers/gpio/gpiolib-of.c                          |   2 +-
 include/linux/acpi_gpio.h                          |  19 +
 include/linux/basic_mmio_gpio.h                    |   1 +
 37 files changed, 1341 insertions(+), 301 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
 create mode 100644 drivers/gpio/gpio-grgpio.c

Re: [git pull] GPIO for v3.10

[Linus Torvalds]

On Fri, May 3, 2013 at 3:37 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> Here are the GPIO changes staged for v3.10. Please pull.

Grrr. These clearly have not been tested at all, and they break the
allmodconfig build.

> Jean Delvare (2):
>       gpio: ucb1400: Can be built as a module

The above one is pure and utter garbage. That driver cannot be built
as a module, and clearly nobody ever even tested it.

You have:

   void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data)

(which, btw, seems entirely unused), but then in the header file
(remember: this is a totally unused function as far as I can tell) we
have

   #ifdef CONFIG_GPIO_UCB1400
   void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data);
   #else
   static inline void ucb1400_gpio_set_data(struct ucb1400_gpio_data *data) {}
   #endif

which means that in the modular case, you get

   drivers/gpio/gpio-ucb1400.c:106:13: error: redefinition of
‘ucb1400_gpio_set_data’

again, I see absolutely no way that (a) this piece of crap has ever
been tested and (b) how /why that useless piece of shit even gets
used.

I'm upset. How the f*ck did this get into your tree in the first
place, and after it got into the tree, WHY THE HELL DID YOU SEND THIS
CRAP TO ME?

The one-liner commit that enables this piece of shit is signed off by
two people, has another person with a "Reviewed-by:" and there is no
way in hell it was ever tested or anybody has ever looked at the
driver in question. WTF?

I'm going out on a limb here, and guessing that it wasn't in linux-next either.

Piece of unadulterated shit.

Quite frankly, I'm not taking any GPIO changes from you this merge
window. I only noticed this after having done two other merges on top
of it, so now I'll have to go back and undo all of this, because quite
frankly, I'm upset enough that I don't want to have any remains of
this whole experience in my tree.

                    Linus

Re: [git pull] GPIO for v3.10

[Jean Delvare]

Hi Linus,

On Fri, 3 May 2013 09:14:44 -0700, Linus Torvalds wrote:
> On Fri, May 3, 2013 at 3:37 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > Here are the GPIO changes staged for v3.10. Please pull.
> 
> Grrr. These clearly have not been tested at all, and they break the
> allmodconfig build.
> 
> > Jean Delvare (2):
> >       gpio: ucb1400: Can be built as a module
> 
> The above one is pure and utter garbage. That driver cannot be built
> as a module, and clearly nobody ever even tested it.

Actually someone has, and that would be me, but definitely not in the
same context you did. Because for me it did build, see below.

> You have:
> 
>    void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data)
> 
> (which, btw, seems entirely unused), but then in the header file
> (remember: this is a totally unused function as far as I can tell) we
> have
> 
>    #ifdef CONFIG_GPIO_UCB1400
>    void __init ucb1400_gpio_set_data(struct ucb1400_gpio_data *data);
>    #else
>    static inline void ucb1400_gpio_set_data(struct ucb1400_gpio_data *data) {}
>    #endif
> 
> which means that in the modular case, you get
> 
>    drivers/gpio/gpio-ucb1400.c:106:13: error: redefinition of
> ‘ucb1400_gpio_set_data’
> 
> again, I see absolutely no way that (a) this piece of crap has ever
> been tested and (b) how /why that useless piece of shit even gets
> used.
> 
> I'm upset. How the f*ck did this get into your tree in the first
> place, and after it got into the tree, WHY THE HELL DID YOU SEND THIS
> CRAP TO ME?
> 
> The one-liner commit that enables this piece of shit is signed off by
> two people, has another person with a "Reviewed-by:" and there is no
> way in hell it was ever tested or anybody has ever looked at the
> driver in question. WTF?

I'm afraid you are slightly overreacting here :) We've been working
together for the past 8 years, I would think you know that I do not
push untested crap upstream.

> I'm going out on a limb here, and guessing that it wasn't in linux-next either.

This specific commit actually is in linux-next, and has been for 7 days
already:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-next&id=66791d8e8f9992ad13ee1fc0e4f0fe7534b095f8

> Piece of unadulterated shit.
> 
> Quite frankly, I'm not taking any GPIO changes from you this merge
> window. I only noticed this after having done two other merges on top
> of it, so now I'll have to go back and undo all of this, because quite
> frankly, I'm upset enough that I don't want to have any remains of
> this whole experience in my tree.

My patch is perfectly sane and correct, the only problem here is that
it depends on another patch from Marek Vasut (as the header comment
states, BTW.) That other patch has been for 3 weeks:
http://git.kernel.org/cgit/linux/kernel/git/sameo/mfd-next.git/commit/?id=360e64d8bbe7c78784d769a60d152804f5079577
which is why nobody complained.

The real problem here is that two patches which depended on each other
went to you through 2 different maintainer trees (mfd maintained by
Samuel Ortiz and gpio maintained by Grant L. & Linus W.), and the git
pull requests reached you in the wrong order. That doesn't make us all
irresponsible and lame contributors/maintainers, does it?

I am sorry for not noticing the problem when both maintainers applied
the two patches in question to their respective trees. It seems
everyone else involved missed that too.

Please accept my apologies for this human mistake. I'll do my best to
pay more attention next time.

Have a great week-end all,
-- 
Jean Delvare

Re: [git pull] GPIO for v3.10

[Grant Likely]

On Fri, May 3, 2013 at 5:51 PM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Linus,
>
> On Fri, 3 May 2013 09:14:44 -0700, Linus Torvalds wrote:
> The real problem here is that two patches which depended on each other
> went to you through 2 different maintainer trees (mfd maintained by
> Samuel Ortiz and gpio maintained by Grant L. & Linus W.), and the git
> pull requests reached you in the wrong order. That doesn't make us all
> irresponsible and lame contributors/maintainers, does it?

Actually, it does make us (me) wrong and irresponsible. It should
never have happened because dependencies should never be committed to
different trees.

g.

Re: [git pull] GPIO for v3.10

[Linus Torvalds]

On Fri, May 3, 2013 at 9:51 AM, Jean Delvare <khali@linux-fr.org> wrote:
>
> The real problem here is that two patches which depended on each other
> went to you through 2 different maintainer trees (mfd maintained by
> Samuel Ortiz and gpio maintained by Grant L. & Linus W.), and the git
> pull requests reached you in the wrong order. That doesn't make us all
> irresponsible and lame contributors/maintainers, does it?

F*ck yes it does.

It means that NOBODY EVEN TEST-COMPILED THE TREE THAT GOT SENT TO ME.

WTF?

If that's not "irresponsible and lame", I don't know what the hell is.

                      Linus

Re: [git pull] GPIO for v3.10

[Jean Delvare]

On Fri, 3 May 2013 09:56:09 -0700, Linus Torvalds wrote:
> On Fri, May 3, 2013 at 9:51 AM, Jean Delvare <khali@linux-fr.org> wrote:
> >
> > The real problem here is that two patches which depended on each other
> > went to you through 2 different maintainer trees (mfd maintained by
> > Samuel Ortiz and gpio maintained by Grant L. & Linus W.), and the git
> > pull requests reached you in the wrong order. That doesn't make us all
> > irresponsible and lame contributors/maintainers, does it?
> 
> F*ck yes it does.
> 
> It means that NOBODY EVEN TEST-COMPILED THE TREE THAT GOT SENT TO ME.
> 
> WTF?

It means that nobody test-compiled that tree with CONFIG_GPIO_UCB1400=m.

> If that's not "irresponsible and lame", I don't know what the hell is.

Hell, n.   1. The place or state of punishment of the wicked after
death.  2. A world where people volunteering to maintain kernel
subsystems get fewer, because they received more blame for their casual
mistakes than praise for their thankless work.

-- 
Jean Delvare

Re: [git pull] GPIO for v3.10

[Linus Torvalds]

On Fri, May 3, 2013 at 2:22 PM, Jean Delvare <khali@linux-fr.org> wrote:
>
> It means that nobody test-compiled that tree with CONFIG_GPIO_UCB1400=m.

And you are making that excuse exactly *why*?

Especially when one of the commits was to allow it. Especially since
the minimal you could expect is a "make allmodconfig" on the most
common platform out there.

Stop making excuses for bad behavior. Just admit that you guys screwed
up rather than trying to soldier on.

If this was some uncommon case like "it doesn't work on s390" or
"there was a subtle interaction with other changes", I'd be less
pissed off. But this was literally a commit that did *one* thing, and
one thing only ("driver can be compiled as a module") and nobody had
tested that *one* thing that the commit did.

That's a f*cking disgrace. That's not the kind of tree you should
expect me to be happy about pulling.

Stop making excuses for it. Really. It just makes you look even worse.
The only correct reply was the one that Grant already sent, which was
basically "sorry, that was wrong, my bad".

Next merge window I will have forgotten, and maybe people will have
learnt to do some minimal testing of the stuff they send me. In the
meantime, don't try to make it look like this was all ok.

                    Linus

Re: [git pull] GPIO for v3.10

[Grant Likely]

On Fri, May 3, 2013 at 10:48 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, May 3, 2013 at 2:22 PM, Jean Delvare <khali@linux-fr.org> wrote:
>>
>> It means that nobody test-compiled that tree with CONFIG_GPIO_UCB1400=m.
>
> And you are making that excuse exactly *why*?
>
> Especially when one of the commits was to allow it. Especially since
> the minimal you could expect is a "make allmodconfig" on the most
> common platform out there.
>
> Stop making excuses for bad behavior. Just admit that you guys screwed
> up rather than trying to soldier on.

Don't take it out on Jean. I screwed up. Jean did not. He wasn't even
remotely cause the problem and I appreciate that he has come to my
defence.

Yell at me if you like, but nobody else deserves the heat. Linusw did
something he didn't know he wasn't supposed to do. We've since talked,
it won't happen again, and he'll be a better maintainer for it. I
didn't do something I knew I was supposed to do because I trusted to
much in linux-next. There isn't an excuse for that and it won't happen
again either. I'm a lot more upset about that than about you freaking
out on me.

g.

Re: [git pull] GPIO for v3.10

[Grant Likely]

On Fri, May 3, 2013 at 5:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The one-liner commit that enables this piece of shit is signed off by
> two people, has another person with a "Reviewed-by:" and there is no
> way in hell it was ever tested or anybody has ever looked at the
> driver in question. WTF?
>
> I'm going out on a limb here, and guessing that it wasn't in linux-next either.

It's been in linux-next since April 29. The problem is that it depends
on the following commit which is in the mfd tree, which gets merged
into linux-next before the gpio tree. The following commit removes the
prototype that it breaks on. That is why linux-next didn't catch it,
but it doesn't change the fact that it never should have been
committed that way.

commit 360e64d8bbe7c78784d769a60d152804f5079577
Author: Marek Vasut <marex@denx.de>
Date:   Sun Apr 14 20:35:48 2013 +0200

    mfd: ucb1400: Pass ucb1400-gpio data through ac97 bus

    Cc: Jean Delvare <jdelvare@suse.de>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>

And, no, I didn't do a full build test of that tree before sending it.
Linusw has been a huge help and offloaded a bunch of the gpio work and
keeping on top of the gpio driver patches. Not his fault though, I got
lazy seeing that it had already been in linux next and so didn't build
everything.

> Quite frankly, I'm not taking any GPIO changes from you this merge
> window. I only noticed this after having done two other merges on top
> of it, so now I'll have to go back and undo all of this, because quite
> frankly, I'm upset enough that I don't want to have any remains of
> this whole experience in my tree.

Very well. I do apologize am sorry for causing you extra work. There
is another series of GPIO changes that removes GENERIC_GPIO. Alex
Courbot has done all the leg work of getting them prepared, dealing
with the cross-tree conflicts and getting it into linux-next for
testing. That branch is completely separate from the other GPIO
changes. I'll get him to send you the pull request directly and you
can decide whether or not to pull it.

g.