Thread (1 message) 1 message, 1 author, 2014-01-22

[PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear

From: Ezequiel Garcia <hidden>
Date: 2014-01-22 22:56:55
Also in: linux-devicetree, linux-watchdog

On Wed, Jan 22, 2014 at 03:31:17PM -0700, Jason Gunthorpe wrote:
On Wed, Jan 22, 2014 at 07:12:38PM -0300, Ezequiel Garcia wrote:
quoted
On Wed, Jan 22, 2014 at 01:52:13PM -0700, Jason Gunthorpe wrote:
quoted
quoted
Clearing BRIDGE_CAUSE will only clear all currently pending upstream
IRQs, of course. If WDT IRQ will be re-raised right after that in
BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
Which is why it makes no sense to clear it one time at kernel start.
So, it seems we need to handle irq_startup(), as you suggested.
I've just tested the attached patch, and it's working fine: the driver's
probe() fully stops the watchdog, and then request_irq() acks and
pending interrupts, through the added irq_startup().

How does it look?
Looks sane to me.

I looked some more and there are other drivers (eg irq-metag-ext) that
take this same approach.
Yup, I took that one as a starting point.

[..]
I looked at the irq-orion driver a bit more and noticed this:

        ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
                             handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
                           ^^^^^^^^^^^^^^^^^^^^^
Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
does this work at all? :)
I'm not familiar with the differences between handle_level_irq and
handle_edge_irq, but -AFAICS- both seem to ack the IRQ.

In fact handle_level_irq(), masks and acks the IRQ as the first thing.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help