Some chained IRQ handlers are written to cope with primary chips of
potentially different flow types. Whether this a sensible thing to do
is a point of contention.
This patch introduces entry/exit functions for chained handlers which
infer the flow type of the primary chip as fasteoi or level-type by
checking whether or not the ->irq_eoi function pointer is present and
calling back to the primary chip as necessary. Other methods of flow
control are not considered.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Various binutils versions can resolve Thumb-2 branches to
locally-defined, preemptible global symbols as short-range "b.n"
branch instructions.
This is a problem, because there's no guarantee the final
destination of the symbol, or any candidate locations for a
trampoline, are within range of the branch. For this reason, the
kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
relocation in modules at all, and it makes little sense to add
support.
The symptom is that the kernel fails with an "unsupported
relocation" error when loading some modules.
Until fixed tools are available, passing
-fno-optimize-sibling-calls to gcc should prevent gcc generating
code which hits this problem, at the cost of a bit of extra runtime
stack usage in some cases.
The problem is described in more detail at:
https://bugs.launchpad.net/binutils-linaro/+bug/725126
Only Thumb-2 kernels are affected.
This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
when building a Thumb-2 kernel.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The removal of the single-step emulation from ptrace on ARM means that
thread_struct no longer has software breakpoint fields in its debug
member.
This patch fixes the a.out core dump code so that the debug registers
are zeroed rather than trying to copy from non-existent fields.
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use the correct I/O address definitions for Footbridge
peripherals when the kernel is compiled without MMU
support.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use straight 64-bit values as 64-bit operations are fairly efficient on ARM.
Comparing the asm output with and without KTIME_SCALAR, using 64-bit math
generates clearly better code.
Comparing kernel/hrtimer.c .text size, it goes from 0x1414 to 0x119c with
this change.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The simply expanded variable may be evaluated before the target file for
the stat command is up to date or even exists. Switching to a recursively
expanded variable move the execution of the stat command to the location
where LDFLAGS_vmlinux is actually used, fixing the dependency issue
introduced by patch #6746/1.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Few architectures combine the GIC with an external interrupt
controller. On such systems it may be necessary to update both
the GIC registers and the external controller's registers to control
IRQ behavior.
This can be addressed in couple of possible methods.
1. Export common GIC routines along with 'struct irq_chip gic_chip'
and allow architectures to have custom function by override.
2. Provide architecture specific function pointer hooks
within GIC library and leave platforms to add the necessary
code as part of these hooks.
First one might be non-intrusive but have few shortcomings like arch
needs to have there own custom gic library. Locks used should be
common since it caters to same IRQs etc. Maintenance point of view
also it leads to multiple file fixes.
The second probably is cleaner and portable. It ensures that all the
common GIC infrastructure is not touched and also provides archs to
address their specific issue.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Colin Cross <ccross@android.com>
Tested-by: Colin Cross <ccross@android.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Populate the l2x0 set_debug function pointer with OMAP secure call
and enable the PL310 Errata 727915
This patch has dependency on the earlier patch
ARM: l2x0: Errata fix for flush by Way operation can cause data
corruption
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PL310 implements the Clean & Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
This patch also removes any OMAP dependency on PL310 Errata's
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We currently presume a 4x expansion to guess the decompressed kernel size
in order to determine if the decompressed kernel is in conflict with
the location where zImage is loaded. This guess may cause many issues
by overestimating the final kernel image size:
- This may force a needless relocation if the location of zImage was
fine, wasting some precious microseconds of boot time.
- The relocation may be located way too far, possibly overwriting the
initrd image in RAM.
- If the kernel image includes a large already-compressed initramfs image
then the problem is even more exacerbated.
And if by some strange means the 4x guess is too low then we may overwrite
ourselves with the decompressed image.
So let's use the exact decompressed kernel image size instead. For that
we need to rely on the stat command, but this is hardly a new build
dependency as the kernel already depends on many external commands
to be built provided by the coreutils package where stat is found.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In the case of a conflict between the memory used by the compressed
kernel with its decompressor code and the memory used for the
decompressed kernel, we currently store the later after the former and
relocate it afterwards.
This would be more efficient to do this the other way around i.e.
relocate the compressed data up front instead, resulting in a smaller
copy. That also has the advantage of making the code smaller and more
straight forward.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PTRACE_SINGLESTEP is a ptrace request designed to offer single-stepping
support to userspace when the underlying architecture has hardware
support for this operation.
On ARM, we set arch_has_single_step() to 1 and attempt to emulate hardware
single-stepping by disassembling the current instruction to determine the
next pc and placing a software breakpoint on that location.
Unfortunately this has the following problems:
1.) Only a subset of ARMv7 instructions are supported
2.) Thumb-2 is unsupported
3.) The code is not SMP safe
We could try to fix this code, but it turns out that because of the above
issues it is rarely used in practice. GDB, for example, uses PTRACE_POKETEXT
and PTRACE_PEEKTEXT to manage breakpoints itself and does not require any
kernel assistance.
This patch removes the single-step emulation code from ptrace meaning that
the PTRACE_SINGLESTEP request will return -EIO on ARM. Portable code must
check the return value from a ptrace call and handle the failure gracefully.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move L1_CACHE_SHIFT related options together, rather than spreading them
across two separate Kconfig files.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Some installers would binary patch the kernel zImage to replace the
first few nops with custom instructions. This breaks the Thumb2 kernel
as the mode switch is right at the beginning. Let's move it towards the
end of the nop sequence instead.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Improve the documentation for the VFP hotplug notifier handler, so
that people better understand what's going on there and what has
been done for them.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In commit e616c59140, highmem support was
deactivated for SMP platforms without hardware TLB ops broadcast because
usage of kmap_high_get() requires that IRQs be disabled when kmap_lock
is locked which is incompatible with the IPI mechanism used by the
software TLB ops broadcast invoked through flush_all_zero_pkmaps().
The reason for kmap_high_get() is to ensure that the currently kmap'd
page usage count does not decrease to zero while we're using its
existing virtual mapping in an atomic context. With a VIVT cache this
is essential to do due to cache coherency issues, but with a VIPT cache
this is only an optimization so not to pay the price of establishing a
second mapping if an existing one can be used. However, on VIPT
platforms without hardware TLB maintenance we can give up on that
optimization in order to be able to use highmem.
From ARMv7 onwards the TLB ops are broadcasted in hardware, so let's
disable ARCH_NEEDS_KMAP_HIGH_GET only when CONFIG_SMP and
CONFIG_CPU_TLB_V6 are defined.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Saeed Bishara <saeed.bishara@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This cleans up after the conversion to irq_data. Rename the function
to match the method, and remove the now useless lookup of the irq
descriptor which is never used. Move the bitmask calculation out of
the irq_controller_lock region.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ensure appropriate locks are taken to ensure that IRQ migration off
the current CPU is race-free. We may have a concurrent set_affinity
via procfs running on another CPU in parallel with the IRQ migration,
resulting in unpredictable results.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The force argument to irq_set_affinity really should be 'true' as
moving IRQs off a CPU which is going down isn't optional.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add a missing call to pci_enable_bridges() so that devices behind
bridges get found by the pci bus scan.
Signed-off-by: Chris Partington <chris.partington@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Current diagnostics are rather poor when things go wrong:
ipv6: relocation out of range, section 2 reloc 0 sym 'snmp_mib_free'
Let's include a little more information about the problem:
ipv6: section 2 reloc 0 sym 'snmp_mib_free': relocation 28 out of range (0xbf0000a4 -> 0xc11b4858)
so that we show exactly what the problem is - not only what type of
relocation but also the offending address range too.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We have 'install' and 'zinstall' for installing Image and zImage
kernels, so add 'uinstall' to complete the set.
This allows developers to have a ~/bin/installkernel script which (eg)
copies the kernel to the tftp server automatically once the kernel
has built, resulting in a better workflow.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch/arm/kernel/return_address.c:37:6: warning: symbol 'return_address' was not declared. Should it be static?
arch/arm/kernel/setup.c:76:14: warning: symbol 'processor_id' was not declared. Should it be static?
arch/arm/kernel/traps.c:259:1: warning: symbol 'die_lock' was not declared. Should it be static?
arch/arm/vfp/vfpmodule.c:156:6: warning: symbol 'vfp_raise_sigfpe' was not declared. Should it be static?
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Achieve better usage of the DMA coherent region by doing top-down
allocation rather than bottom up. If we ask for a 128kB allocation,
this will be aligned to 128kB and satisfied from the very bottom
address. If we then ask for a 600kB allocation, this will be aligned
to 1MB, and we will have a 896kB hole.
Performing top-down allocation resolves this by allocating the 128kB
at the very top, and then the 600kB can come in below it without any
unnecessary wastage.
This problem was reported by Janusz Krzysztofik, who had 2 x 128kB +
1 x 640kB allocations which wouldn't fit into 1MB.
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since the debug macros no longer depend on the machine type information,
the machine type lookup can be deferred to setup_arch() in setup.c which
simplifies the code somewhat.
We also move the __error_a functionality into setup.c for displaying a
message when a bad machine ID is passed to the kernel via the LL debug
code. We also log this into the kernel ring buffer which makes it
possible to retrieve the message via a debugger.
Original idea from Grant Likely.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
arch/arm/mach-omap2/dma.c: Convert IS_ERR result to PTR_ERR
arm: omap2: mux: fix compile warning
omap1: Simplify use of omap_irq_flags
omap2+: Fix unused variable warning for omap_irq_base
Fix kernel-doc warning in kernel.h from commit 7ef88ad561
("BUILD_BUG_ON: make it handle more cases"):
Warning(include/linux/kernel.h:605): No description found for parameter 'condition'
Warning(include/linux/kernel.h:605): Excess function parameter 'cond' description in 'BUILD_BUG_ON'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patches should keep coming through Rusty but it helps if I'm Cc'd as
well.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (42 commits)
usb: gadget: composite: avoid access beyond array max length
USB: serial: handle Data Carrier Detect changes
USB: gadget: Fix endpoint representation in ci13xxx_udc
USB: gadget: Fix error path in ci13xxx_udc gadget probe function
usb: pch_udc: Fix the worning log issue at gadget driver remove
USB: serial: Updated support for ICOM devices
USB: ehci-mxc: add work-around for efika mx/sb bug
USB: unbreak ehci-mxc on otg port of i.MX27
drivers: update to pl2303 usb-serial to support Motorola cables
USB: adding USB support for Cinterion's HC2x, EU3 and PH8 products
USB serial: add missing .usb_driver field in serial drivers
USB: ehci-fsl: Fix 'have_sysif_regs' detection
USB: g_printer: fix bug in module parameter definitions
USB: g_printer: fix bug in unregistration
USB: uss720: remove duplicate USB device
MAINTAINERS: add ueagle-atm entry
USB: EHCI: fix DMA deallocation bug
USB: pch_udc: support new device ML7213 IOH
usb: pch_udc: Fixed issue which does not work with g_serial
usb: set ep_dev async suspend should be later than device_initialize
...
* 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (26 commits)
staging: r8712u: Add new device IDs
staging: brcm80211: fix suspend/resume issue in brcmsmac
staging: brcm80211: remove assert to avoid panic since 2.6.37 kernel
Staging: iio: Aditional fixpoint formatted output bugfix
staging: usbip: vhci: use urb->dev->portnum to find port
staging: usbip: vhci: handle EAGAIN from SO_RCVTIMEO
staging: usbip: vhci: friendly log messages for connection errors
staging: usbip: vhci: refuse to enqueue for dead connections
staging: usbip: vhci: give back URBs from in-flight unlink requests
staging: usbip: vhci: update reference count for usb_device
staging: usbip: stub: update refcounts for devices and interfaces
staging: tidspbridge: replace mbox callback with notifier_call
staging: comedi: ni_labpc: Use shared IRQ for PCMCIA card
Staging: speakup: &&/|| confusion in silent_store()
iio: Fixpoint formatted output bugfix
staging: rt2860: Fix incorrect netif_stop_queue usage warning
staging: r8712u: Fix memory leak in firmware loading
staging: tidspbridge: configure full L1 MMU range
staging: rt2870sta: Add ID for Linksys WUSB100v2
Staging: xgfib: put parenthesis in the right place
...
* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
tty/serial: fix apbuart build
n_hdlc: fix read and write locking
serial: unbreak billionton CF card
tty: use for_each_console() and WARN() on sysfs failures
vt: fix issue when fbcon wants to takeover a second time.
Fix up trivial conflict in drivers/tty/tty_io.c
Allow non-ARM SMP processors to use the SMP_ON_UP feature. CPUs
supporting SMP must have the new CPU ID format, so check for this first.
Then check for ARM11MPCore, which fails the MPIDR check. Lastly check
the MPIDR reports multiprocessing extensions and that the CPU is part of
a multiprocessing system.
Cc: <stable@kernel.org>
Reported-and-Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ensure that the ISA/PCI IO space accessors are properly ordered on
ARMv6+ architectures. These should always be ordered with respect to
all other accesses.
This also fixes __iormb() and __iowmb() not being visible to ioread/
iowrite if a platform defines its own MMIO accessors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Disable the initrd if the passed address already overlaps the reserved
region. This avoids oopses on Netwinders when NeTTrom tells the kernel
that an initrd is located at mem+4MB, but this overlaps the BSS,
resulting in the kernels in-use BSS being freed.
This should be applied to v2.6.37-stable.
Cc: <stable@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
0ea1293 (arm: return both physical and virtual addresses from addruart)
changed the way the 'addruart' worked, making it return both the virt
and phys addresses. Unfortunately, for footbridge, these were reversed.
Fix that. Tested on Netwinder.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We should not report incomplete blocks on error. Return the number of
bytes successfully transferred, rounded down to the nearest block.
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When we encounter an error, make sure we complete the transaction
otherwise we'll leave the request dangling.
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped
scancodes, but rather return KEY_RESERVED.
This fixes breakage with Ubuntu's input-kbd utility that stopped
returning full keymaps for remote controls.
Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tested-by: Mark Lord <kernel@teksavvy.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since check_prlimit_permission always fails in the case of SUID/GUID
processes, such processes are not able to read or set their own limits.
This commit changes this by assuming that process can always read/change
its own limits.
Signed-off-by: Kacper Kornet <kornet@camk.edu.pl>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In ntfs_mft_record_alloc() when mapping the new extent mft record with
map_extent_mft_record() we overwrite @m with the return value and on
error, we then try to use the old @m but that is no longer there as @m
now contains an error code instead so we crash when dereferencing the
error code as if it were a pointer.
The simple fix is to use a temporary variable to store the return value
thus preserving the original @m for later use. This is a backport from
the commercial Tuxera-NTFS driver and is well tested...
Thanks go to Julia Lawall for pointing this out (whilst I had fixed it
in the commercial driver I had failed to fix it in the Linux kernel).
Signed-off-by: Anton Altaparmakov <anton@tuxera.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-2.6-cm:
kmemleak: Allow kmemleak metadata allocations to fail
kmemleak: remove memset by using kzalloc
