On Monday, December 15, 2014 11:20:17 PM Rafael J. Wysocki wrote:

On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote:

quoted

Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON
test which triggers a WARNING backtrace on at91 platforms.

Pretty much as intended.

quoted

While this WARN_ON is absolutely necessary to warn users that they should
not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs,
there is no easy way to solve this issue on at91 platforms.

The main reason is that the init timer is often using a shared irq line
and thus request this irq with IRQF_NO_SUSPEND flag set, while other
peripherals request the same irq line without this flag.

We could deal with that by identifying whether a given peripheral is
connected to the init timer shared irq line and add the IRQF_NO_SUSPEND
in this case, but this implies adding the logic in all peripheral drivers
that could be connected to this shared irq.

This series takes the reverse approach: force IRQ users to specify that
they take care of disabling peripheral interrupts and that IRQ core can
safely leave the handler in a suspended state without having to bother
about spurious interrupts.
This is done by mean of a new IRQF_SUSPEND_NOACTION flag which tells the
core to move the action handler to a suspended list, thus preventing its
execution when we are in suspend mode.
Of course, specifying the IRQF_SUSPEND_NOACTION flag implies taking care
of masking/unmasking the peripheral interrupts in the suspend/resume
implementation.

Well, I'm not sure how much value is in all that to be honest.  The only
thing it helps with is to make the WARN_ON go away in some cases, while
the drivers in question need to make sure that they disable their interrupts
properly anyway, so what exactly is the purpose of the new irqaction
shuffling?

It might just be simpler to add a flag to suppress the WARN_ON that would be
set by the user of IRQF_NO_SUSPEND that is broken enough to have to share the
interrupt with others ...

Or even set IRFQ_NO_SUSPEND for all of the users of this interrupt and add
comments to them explaining why it is set.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.