linux-kernel - Re: [PATCH 12/17] ARM: OMAP2+: remove misuse of IRQF_NO

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:	Tue, 13 Oct 2015 16:20:15 +0100
From:	Sudeep Holla <sudeep.holla@....com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Sudeep Holla <sudeep.holla@....com>, linux-pm@...r.kernel.org,
	Kevin Hilman <khilman@...prootsystems.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag



On 13/10/15 15:53, Tony Lindgren wrote:
> * Sudeep Holla <sudeep.holla@....com> [151013 03:46]:
>>
>>
>> On 12/10/15 21:28, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@...mide.com> [151012 13:27]:
>>>> * Sudeep Holla <sudeep.holla@....com> [150921 08:52]:
>>>>> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
>>>>> be left enabled so as to allow them to work as expected during the
>>>>> suspend-resume cycle, but doesn't guarantee that it will wake the system
>>>> >from a suspended state, enable_irq_wake is recommended to be used for
>>>>> the wakeup.
>>>>>
>>>>> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
>>>>> enable_irq_wake instead.
>>>>
>>>> Applying into omap-for-v4.4/cleanup thanks.
>>>
>>> Actually I don't think this does the right thing. The interrupts
>>> in the $subject patch are in the always on powerdomain, and we really
>>
>> Agreed
>>
>>> want them to be excluded from the suspend.
>>>
>>
>> OK but what's wrong with this patch. At-least the name suggest it's a
>> wakeup interrupt. And using IRQF_NO_SUSPEND for the wakeup interrupt is
>> simply wrong.
>
> Hmm so if we have a separate always on irq controller for the wake-up events
> and we want to keep it always on and exclude it from any suspend related
> things.. Why would we not use IRQF_NO_SUSPEND on it?
>
> Above you say "The IRQF_NO_SUSPEND flag is used to identify the interrupts
> that should be left enabled so as to allow them to work as expected during
> the suspend-resume cycle..." and that's exactly what we want to do here :)
>

OK if these interrupts meet that criteria to use IRQF_NO_SUSPEND, then
it should be fine, my earlier argument was based on the assumption that
it's just another wakeup interrupt.

> For the dedicated wake-up interrupts, we have separate registers to enable
> and disable them. The $subject irq is the shared interrupt that allows
> making use of the pin specific wake-up interrupts, and for those yes we
> are using enable_irq_wake().
>

If it's already take care, then fine. I am just hunting all the misuse
of IRQF_NO_SUSPEND flag especially as wakeup source and fixing them

>>> So not applying without further explanations.
>>>
>>
>> But I don't understand the real need for IRQF_NO_SUSPEND over wakeup APIs ?
>
> Because in the $subject case we just want to always keep it on and
> never suspend it. It's unrelated to the wakeup APIs at least for the
> omap related SoCs.
>

OK, understood now. Thanks

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