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>
We incorrectly returned -EINVAL when none of the devices in the array
had an integrity profile. This in turn prevented mdadm from starting
the metadevice. Fix this so we only return errors on mismatched
profiles and memory allocation failures.
Reported-by: Giacomo Catenazzi <cate@cateee.net>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
MFD changes in 4ec1b54c ('mfd: mfd_cell is now implicitly available to
mc13xxx drivers') changed the mc13xxx_platform_data struct layout.
At the time all users were changed, but this driver was introduced in
another tree at the same time. This updates the mc13xxx_platform_data
user, fixing a build error.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'irq-cleanup-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
vlynq: Convert irq functions
* 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
genirq; Fix cleanup fallout
genirq: Fix typo and remove unused variable
genirq: Fix new kernel-doc warnings
genirq: Add setter for AFFINITY_SET in irq_data state
genirq: Provide setter inline for IRQD_IRQ_INPROGRESS
genirq: Remove handle_IRQ_event
arm: Ns9xxx: Remove private irq flow handler
powerpc: cell: Use the core flow handler
genirq: Provide edge_eoi flow handler
genirq: Move INPROGRESS, MASKED and DISABLED state flags to irq_data
genirq: Split irq_set_affinity() so it can be called with lock held.
genirq: Add chip flag for restricting cpu_on/offline calls
genirq: Add chip hooks for taking CPUs on/off line.
genirq: Add irq disabled flag to irq_data state
genirq: Reserve the irq when calling irq_set_chip()
I missed the CONFIG_GENERIC_PENDING_IRQ dependency in the affinity
related functions and the IRQ_LEVEL propagation into irq_data
state. Did not pop up on my main test platforms. :(
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: David Daney <ddaney@caviumnetworks.com>
Commit 6f5317e730 introduced a bug in the
handling of userspace object classes that is causing breakage for Xorg
when XSELinux is enabled. Fix the bug by changing map_class() to return
SECCLASS_NULL when the class cannot be mapped to a kernel object class.
Reported-by: "Justin P. Mattock" <justinmattock@gmail.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
Fixes this build error:
drivers/memstick/host/r592.c:26: error: 'enable_dma' redeclared as different kind of symbol
arch/powerpc/include/asm/dma.h:189: note: previous definition of 'enable_dma' was here
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Alex Dubov <oakad@yahoo.com>
Acked-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: stop using the page cache to back the buffer cache
xfs: register the inode cache shrinker before quotachecks
xfs: xfs_trans_read_buf() should return an error on failure
xfs: introduce inode cluster buffer trylocks for xfs_iflush
vmap: flush vmap aliases when mapping fails
xfs: preallocation transactions do not need to be synchronous
Fix up trivial conflicts in fs/xfs/linux-2.6/xfs_buf.c due to plug removal.
Commit da48524eb2 ("Prevent rt_sigqueueinfo and rt_tgsigqueueinfo
from spoofing the signal code") made the check on si_code too strict.
There are several legitimate places where glibc wants to queue a
negative si_code different from SI_QUEUE:
- This was first noticed with glibc's aio implementation, which wants
to queue a signal with si_code SI_ASYNCIO; the current kernel
causes glibc's tst-aio4 test to fail because rt_sigqueueinfo()
fails with EPERM.
- Further examination of the glibc source shows that getaddrinfo_a()
wants to use SI_ASYNCNL (which the kernel does not even define).
The timer_create() fallback code wants to queue signals with SI_TIMER.
As suggested by Oleg Nesterov <oleg@redhat.com>, loosen the check to
forbid only the problematic SI_TKILL case.
Reported-by: Klaus Dittrich <kladit@arcor.de>
Acked-by: Julien Tinnes <jln@google.com>
Cc: <stable@kernel.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://www.jni.nu/cris:
Correct auto-restart of syscalls via restartblock
CRISv10: Fix return before mutex_unlock in pcf8563
Drop the CRISv32 version of pcf8563
