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:	Sat, 6 Aug 2016 16:13:23 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	linux-kernel@...r.kernel.org, Jon Hunter <jonathanh@...dia.com>,
	Björn Andersson <bjorn.andersson@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
Subject: Re: [PATCH] Revert "irqdomain: Don't set type when mapping an IRQ"

On Sat,  6 Aug 2016 10:18:03 +0200
Linus Walleij <linus.walleij@...aro.org> wrote:

> This reverts commit 1e2a7d78499ec8859d2b469051b7b80bad3b08aa.
> 
> When using the APQ8060 Dragonboard I have lost all interrupts from
> the PMIC after this commit: power button, keypad, RTC alarm and
> all GPIOs. Reverting the commit solves the issue.
> 
> The affected irqchip driver is drivers/mfd/pm8921-core.c
> 
> I cannot immediately see what the problem is, so if you have a
> better solution than just reverting the patch, please suggest.
> 
> Cc: Jon Hunter <jonathanh@...dia.com>
> Cc: Marc Zyngier <marc.zyngier@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: John Stultz <john.stultz@...aro.org>
> Cc: Björn Andersson <bjorn.andersson@...aro.org>
> Cc: Stephen Boyd <sboyd@...eaurora.org>
> Cc: Abhijeet Dharmapurikar <adharmap@...eaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
> I am pretty sure that this is the same bug that John Stultz is
> seeing on the Nexus 7, John: please confirm.

Hi Linus,

Before blindly reverting this patch (which itself is going to cause
other things to break), I'd like to understand the failure mode.

Any chance you could instrument pm8xxx_irq_set_type() and see if we get
called (and which which parameters)? A call stack would be ideal. I'm
normally expecting __irq_set_trigger() to be called from
manage.c::__setup_irq(), but your failure mode would tend to indicate
that it is not going that way. Is there any irq line sharing going on
by any chance?

Also, John has now isolated the failure to a much simpler piece of code,
so I'd hope to narrow it down pretty quickly (see the other thread).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ