Hi Rafael,

On Mon, 15 Dec 2014 23:48:14 +0100
"Rafael J. Wysocki" [off-list ref] wrote:

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

quoted

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.

Yep. BTW did you have other platforms/drivers in mind when proposing
this patch, or were you just trying to identify the offending ones ?

quoted

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.

Maybe I should have sent this series as a RFC, anyway, I'm not trying
to make existing code more complicated just for fun, and I'm open to
any suggestion.

Actually I thought about adding a new flag (let's call it
IRQF_DONT_COMPLAIN for now ;-)) to remove those warnings (or specifying
IRFQ_NO_SUSPEND in all peripherals sharing the IRQ with the init
timer), but after discussing the problem with Thomas I decided to go
for the approach described in my cover letter.

Thomas, correct me if I'm wrong, but your concern about the
IRQF_DONT_COMPLAIN approach was that it was leaving interrupt handlers
of suspended devices in an active state (meaning that they could be
called in "suspend" or "early resume" state), and such devices might
not properly handle interrupts while being in a suspended state (clocks
and regulators disabled).
In at91 specific case this should not be an issue thought.

We have the same problem when setting IRFQ_NO_SUSPEND on all peripherals
sharing the IRQ with the init timer.
Moreover, I'd like to keep the core automatically disabling the IRQ when
the PMC, RTC, watchdog or DBGU (UART) peripherals have their own
dedicated IRQ (which is the case on Atmel sama5 SoCs).
This implies testing for the SoC version in each of these drivers and
adapting the request_irq call accordingly.

Thomas, Rafael, if both of you think I should either introduce a new
flag or specify IRFQ_NO_SUSPEND in all shared IRQ users, then I can go
for one of this solution.

BTW, have you heard about other platforms/drivers impacted by this
WARN_ON addition, and if so how did they solve the problem ?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com