linux-kernel - Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq handling

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] [day] [month] [year] [list]

Date:	Tue, 15 Dec 2015 19:57:13 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Felipe Balbi <balbi@...com>, Tony Lindgren <tony@...mide.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>
CC:	John Ogness <john.ogness@...utronix.de>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq
 handling

On Thursday 10 December 2015 08:46 PM, Sekhar Nori wrote:
> Hi Felipe,
> 
> On Tuesday 08 December 2015 07:15 PM, Felipe Balbi wrote:
>> Sekhar Nori <nsekhar@...com> writes:
> 
>>> +	/*
>>> +	 * A spurious IRQ can result if interrupt that triggered the
>>> +	 * sorting is no longer active during the sorting (10 INTC
>>> +	 * functional clock cycles after interrupt assertion). Or a
>>> +	 * change in interrupt mask affected the result during sorting
>>> +	 * time. There is no special handling required except ignoring
>>> +	 * the SIR register value just read and retrying.
>>> +	 * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
>>> +	 *
>>> +	 * Many a times, a spurious interrupt situation has been fixed
>>> +	 * by adding a flush for the posted write acking the IRQ in
>>> +	 * the device driver. Typically, this is going be the device
>>> +	 * driver whose interrupt was handled just before the spurious
>>> +	 * IRQ occurred. Pay attention to those device drivers if you
>>> +	 * run into hitting the spurious IRQ condition below.
>>> +	 */
>>> +	if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
>>
>> sounds like unlikely() wouldn't hurt here.
> 
> I can add, but looks like it does not make a big difference. See below.
> 
>>
>>> +		pr_err_once("%s: spurious irq!\n", __func__);
>>> +		irq_err_count++;
>>> +		omap_ack_irq(NULL);
>>> +		return;
>>> +	}
>>> +
>>>  	irqnr &= ACTIVEIRQ_MASK;
>>> -	WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>>>  	handle_domain_irq(domain, irqnr, regs);
>>
>> care to run kernel function profiler against omap_intc_handle_irq()
>> before and after this patch ?
> 
> Before this patch I see average running time time of 34us. That
> increases to 37.8us after this patch. With unlikely() the number I got
> was 37.4us. So the benefit with unlikely() is in the noise range.
> 
> This was using AM335x EVM at 720 MHz.

Just sent a v3 with unlikely() and profiling information added to commit
message.

Thanks,
Sekhar
--
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/