linux-kernel - Re: [PATCH] irq: Consider a negative return value of irq

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.02.1403121555140.18573@ionos.tec.linutronix.de>
Date:	Wed, 12 Mar 2014 16:10:40 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Walleij <linus.walleij@...aro.org>
cc:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>,
	Grant Likely <grant.likely@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] irq: Consider a negative return value of irq_startup()
 as an error

On Wed, 12 Mar 2014, Linus Walleij wrote:
> On Sat, Mar 8, 2014 at 10:15 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > On Fri, 7 Mar 2014, Linus Walleij wrote:
> >> I'll see what Jean-Jacques comes up with and take it from there unless
> >> he's interested in taking it all the way.
> >
> > Thought more about it while trying to come up with a persuasive
> > argument for the other Linus to take the irq_startup change that late
> > in the cycle:
> >
> > Using startup is the wrong point in __setup_irq() because we call
> > chip->irq_set_type() before we call chip->irq_startup(). And we want
> > this to be in that order to avoid spurious interrupts.
> >
> > Proper solution below. That leaves the startup/unmask logic untouched
> > and provides separate callbacks for this kind of requirements. That
> > makes it also simpler to have common functions for all gpios as you
> > don't have to do the mask/unmask dance in startup/shutdown. So you can
> > simply create gpio_irq_request/release_resources() and let the drivers
> > add those to their callbacks.
> >
> > If you agree, I put that into a separate branch based on an upstream
> > -rc so you can pull it into your gpiolib stuff and work from there.
> 
> Yeah I really like the looks of this!
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> 
> We need to think about whether the gpiolib changes are serious
> enough to be pushed this late in the -rc cycle though.
> 
> The thing is that the flagging of GPIO lines as IRQs was to fix
> up the ages-old mess of sequential semantic dependencies between
> different unrelated gpiolib and irqchip calls, and these bugs have
> been around since the first irqchip was implemented in
> drivers/gpio I think :-(
> 
> But if you prefer, I'll surely do it.

Nah. We can just do that for 3.15. If people have the urge to backport
it, it's simple enough to do so.

I pushed out the patch to a separate branch

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip irq/for-gpio

and merged that branch back into irq/core.

So you can just pull irq/for-gpio into the gpio work and base the gpio
related changes on top of that. Just mention it in the pull request to
the other Linus that it contains an irq/core change which avoids merge
dependencies.

Thanks,

	tglx

--
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/