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

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

Date:	Mon, 27 Oct 2014 14:57:27 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Marc Zyngier <marc.zyngier@....com>,
	Bjorn Andersson <bjorn@...o.se>,
	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/25/2014 01:34 AM, Thomas Gleixner wrote:
> On Fri, 24 Oct 2014, Stephen Boyd wrote:
>
>> 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.
> Nothing prevents you from adding your own irq_disable() callback for
> those interrupts. Just the default is lazy.
>
>

Ok, if we did that it would be global for the entire arm gic right? I see:

void irq_disable(struct irq_desc *desc)
{
        irq_state_set_disabled(desc);
        if (desc->irq_data.chip->irq_disable) {
                desc->irq_data.chip->irq_disable(&desc->irq_data);
                irq_state_set_masked(desc);
        }
}       

so we would need to add some return value to irq_disable() so that we
could tell if this particular interrupt needs to be disabled or not or
we would need to set a different chip for this particular interrupt with
the irq_disable callback set? Plus any scheme would need to be SoC
specific somehow and be setup early when the gic is probed. Maybe we can
encode this information in the DT specifier somehow to indicate that we
want disable_irq() to actually mask the irq? This is all under the
assumption that we can't just force every gic interrupt to mask on disable.

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