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]

Message-ID: <CAJAp7OjpN-+S=OH1BW6Fcme9mp4qj8AsSNC3_41fhfpYzX-Shg@mail.gmail.com>
Date:	Fri, 24 Oct 2014 10:31:11 -0700
From:	Bjorn Andersson <bjorn@...o.se>
To:	Marc Zyngier <marc.zyngier@....com>,
	Stephen Boyd <sboyd@...eaurora.org>
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 Tue, Oct 21, 2014 at 2:34 AM, Marc Zyngier <marc.zyngier@....com> wrote:
> Hi all,
>
> On 21/10/14 10:22, Thomas Gleixner wrote:
>> On Thu, 4 Sep 2014, Bjorn Andersson wrote:
>>
>>> On Tue, Aug 19, 2014 at 1:23 PM, Bjorn Andersson
>>> <bjorn.andersson@...ymobile.com> wrote:
>>>> Introduce the irq_read_line() function to allow device drivers to read
>>>> the current logical state of an input when the hardware only exposes
>>>> this through status bits in the interrupt controller.
>>>>
>>>> The new function is backed by a new callback function in the irq_chip -
>>>> irq_read_line() - that can be implemented by irq_chips that owns such
>>>> status bits.
>>>>
>>>> Based on rfc patch from April 2011 by Abhijeet.
>>>>
>>>> Cc: Abhijeet Dharmapurikar <adharmap@...eaurora.org>
>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@...ymobile.com>
>>>
>>> ping?
>>
>> Sorry, slipped through the cracks. I was talking about this to Marc
>> last week and he needs it for yet another reason. He had some thoughts
>> about the state representation, so I wait for him to comment.
>
> Thanks for putting me in the loop. For the record, here's the RFC I
> posted back in June:
>

Thanks for having a similar problem as me :)

> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266328.html
>
> and the patch implementing a similar concept:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266331.html
>

I would prefer to see that you had explicit functions for the various things
that you would like to set and get. It would in my eyes give cleaner client
code, at the cost of a few extra functions.

> Basic idea is that you can read (and possibly write back) various
> low-level attributes (pending, masked, active) that an interrupt
> controller may implement. Given your use case, we should loose the
> checks on the interrupt being forwarded, as this makes little sense
> outside of virtualization.
>

Relaxing the forwarding requirement seems to solve my use cases. May I ask why
your accessors would only be made available for forwarded IRQs - at a framework
level?

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(?)

> I'm planning to respin the series this week, as I have a number of
> changes (there is hardly any need for the various states to be reported
> atomically, for example), and a number of bugs have been found.
>

Sounds good, for clarity I would like them to be explicit separate functions.
But as long as it's not limited to forwarded IRQs we should be able to use it.

Regards,
Bjorn
--
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/