Convert to the new function names. Scripted with coccinelle.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org
Use the trigger type in irq_data and check level type instead of
looking at desc->handle_irq.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org
The only subtle difference is that alpha uses ACTUAL_NR_IRQS and
prints the IRQF_DISABLED flag.
Change the generic implementation to deal with ACTUAL_NR_IRQS if
defined.
The IRQF_DISABLED printing is pointless, as we nowadays run all
interrupts with irqs disabled.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reorder
irq_set_chip()
irq_set_chip_data()
irq_set_handler()
to
irq_set_chip()
irq_set_handler()
irq_set_chip_data()
so the next patch can combine irq_set_chip() and irq_set_handler() to
irq_set_chip_and_handler().
Automated conversion with coccinelle.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Avoid the whole lazy disable dance in the demux handler by providing a
irq_disable() callback.
Use the proper accessor functions and tidy up gpio_irq_handler()
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Make use of the new functionality which ensures that irq_set_type is
called with the chip masked. Unmask is only done when the interrupt is
not disabled.
Retrieve the trigger type from irq_data in unmask
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Use the proper accessor function instead of fiddling in the status
bits directly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Remove the open coded access to irq_desc which will fail on sparse irq
and use the proper wrappers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The conversion missed, that one of the irq functions is called from
the init code. Split it out, so the irq number based call works.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 9eac6d0 (ARM: Remove dependency of plat-orion GPIO code on mach
directory includes) missed to convert one instance of
DOVE_GPIO_VIRT_BASE and left the orion_gpio_init() in mpp.c
Fix it up.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This is needed for determining the reason for failure when a softdog
timeout occurs.
We use softdog to watch for critical application failures and at the
minimum a snapshot of the system would help to determine the cause. In
such a scenario the application could fail but there isn't a softlockup as
such, hence the detect softlockup feature does not help.
The patch adds a module parameter soft_panic which when set to 1 causes
softdog to invoke panic instead of reboot when the softdog timer expires.
By invoking panic we execute kdump if it is configured and the vmcore
generated by kdump should provide atleast a minimal idea of the reason for
failure.
Based on an original patch by Ken Sugawara <sugaken.r3@gmail.com>
Signed-off-by: Anithra P J <anithra@linux.vnet.ibm.com>
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Fix section mismatch warning:
Mark the called nv_tco_getdevice() as __devinit, just like its caller.
WARNING: drivers/watchdog/nv_tco.o(.devinit.text+0x16): Section mismatch in reference from the function nv_tco_init() to the function .init.text:nv_tco_getdevice()
The function __devinit nv_tco_init() references
a function __init nv_tco_getdevice().
If nv_tco_getdevice is only used by nv_tco_init then
annotate nv_tco_getdevice with a matching annotation.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Stefano found SP5100 TCO watchdog driver using wrong address.
[ 9.148536] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01
[ 9.148628] DEBUG __ioremap_caller WARNING address=b8fe00 size=8 valid=1 reserved=1
and e820 said that range is RAM.
We should check if we can use that reading out. BIOS could just program wrong address there.
Reported-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by:Yinghai Lu <yinghai@kernel.org>
Acked-by: Mike Waychison <mikew@google.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>
Request_mem_region should be used with release_mem_region, not
release_resource.
In pnx4008_wdt.c, a missing clk_put is added as well.
The semantic match that finds the first problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,E;
@@
*x = request_mem_region(...)
... when != release_mem_region(x)
when != x = E
* release_resource(x);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>
Request_mem_region should be used with release_mem_region, not
release_resource.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,E;
@@
*x = request_mem_region(...)
... when != release_mem_region(x)
when != x = E
* release_resource(x);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>
The late night fixup missed to convert the data type from irq_desc to
irq_data, which results in a harmless but annoying warning.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The IPsec extended sequence numbers are fully implemented just for
esp. So restrict the usage to esp until other protocols have
support too.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
In xfrm_new_ae() we may overwrite the allocated esn replay state
buffer with a wrong size. So check that the new size matches the
original allocated size and return an error if this is not the case.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When we clone a xfrm state we have to assign the replay_esn
and the preplay_esn pointers to the state if we use the
new replay detection method. To this end, we add a
xfrm_replay_clone() function that allocates memory for
the replay detection and takes over the necessary values
from the original state.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
As it is, the replay check is just performed if the replay window of the
legacy implementation is nonzero. So we move the test on a nonzero replay
window inside the replay check functions to be sure we are testing for the
right implementation.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code sometimes generates build warnings due to how it checks
the silicon revision, so clean it up and properly document things.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The correct usage should be "static inline void" instead of "static void inline"
Signed-off-by: G.Balaji <balajig81@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While testing the performance of different receive interrupt
coalescing settings on a single stream TCP benchmark, I noticed two
very different results. With rx-usecs=50, most of the time a
connection would hit 8280 Mbps but once in a while it would hit
9330 Mbps.
It turns out we are only applying the interrupt coalescing settings
to the first queue and whenever the rx hash would direct us onto
that queue we ran faster.
With this patch applied and rx-usecs=50, I get 9330 Mbps
consistently.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When analysing performance of the cxgb3 on a ppc64 box I noticed that
we weren't doing much GRO merging. It turns out we are limited by the
number of SKB frags:
#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
With a 4kB page size we have 18 frags, but with a 64kB page size we
only have 3 frags.
I ran a single stream TCP bandwidth test to compare the performance of
Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Gleixner