linux-kernel - Re: [PATCH] genirq: Introduce irq_read

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]

Message-ID: <544AABB8.10302@codeaurora.org>
Date:	Fri, 24 Oct 2014 12:42:48 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Marc Zyngier <marc.zyngier@....com>,
	Bjorn Andersson <bjorn@...o.se>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
Subject: Re: [PATCH] genirq: Introduce irq_read_line()

On 10/24/2014 10:59 AM, Marc Zyngier wrote:
> Hi Bjorn,
>
> On 24/10/14 18:31, Bjorn Andersson wrote:
>>
>> Stephen Boyd talked about the need to be able to mask/unmask interrupts from
>> client code in the Qualcomm platform as well - most likely to block wakeup
>> sources(?)
> What's wrong with irq_disable?

The problem is irq_disable() is lazy and doesn't actually disable the
interrupt.

This is the scenario. During idle we want to communicate with another
processor in the SoC and tell it to turn off something after we go to
idle. The communication mechanism uses some shared memory and an
interrupt to trigger the other processor to go look at what we told it
to do. When the other processor is done handling the message it will
send us an ack interrupt. We want to temporarily ignore that ack
interrupt because 1) we're going to execute a wfi to trigger a deep idle
and any pending interrupt will abort that instruction and 2) if the
interrupt comes after we execute the wfi it will wake us up out of deep
idle unnecessarily and waste power. There isn't anything in the
communication protocol that says we don't want the interrupt to be sent
and it would probably make things more complicated anyway. The solution
is to mask the interrupt before we send the message, and then execute
the wfi. Once we wake up, we unmask the interrupt and then handle the ack.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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