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
On Fri, May 3, 2013 at 3:37 AM, Grant Likely <[email protected]> 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
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 <[email protected]> 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
On Fri, May 3, 2013 at 5:51 PM, Jean Delvare <[email protected]> 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.
On Fri, May 3, 2013 at 9:51 AM, Jean Delvare <[email protected]> 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
On Fri, May 3, 2013 at 5:14 PM, Linus Torvalds
<[email protected]> 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 <[email protected]>
Date: Sun Apr 14 20:35:48 2013 +0200
mfd: ucb1400: Pass ucb1400-gpio data through ac97 bus
Cc: Jean Delvare <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Grant Likely <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
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.
On Fri, 3 May 2013 09:56:09 -0700, Linus Torvalds wrote:
> On Fri, May 3, 2013 at 9:51 AM, Jean Delvare <[email protected]> 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
On Fri, May 3, 2013 at 2:22 PM, Jean Delvare <[email protected]> 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
On Fri, May 3, 2013 at 10:48 PM, Linus Torvalds
<[email protected]> wrote:
> On Fri, May 3, 2013 at 2:22 PM, Jean Delvare <[email protected]> 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.