linux-kernel - Re: [git pull] GPIO for v3.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 May 2013 18:51:48 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Marek Vasut <marex@...x.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Samuel Ortiz <samuel@...tiz.org>
Subject: Re: [git pull] GPIO for v3.10

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@...retlab.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/