- 22 Oct, 2011 1 commit
-
-
Javi Merino authored
If two requests have been submitted and one of them is running, if you call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time between the spin_lock_irqsave() and the _state() check in which the running transaction may finish. In that case, we don't receive the interrupt (because they are disabled), but _start() sees that the DMA is stopped, so it starts it. The problem is that it sends the transaction that has just finished again, because pl330_update() hasn't mark it as done yet. This patch fixes this race condition by not calling _start() if the DMA is already executing transactions. When interrupts are reenabled, pl330_update() will call _start(). Reference: <1317892206-3600-1-git-send-email-javi.merino@arm.com> Signed-off-by: Javi Merino <javi.merino@arm.com> Acked-by: Jassi Brar <jassi.brar@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 20 Oct, 2011 1 commit
-
-
Afzal Mohammed authored
Upon adding new board LL debug support, if the resultant code addition would not cause PC relative offset of "hexbuf" from "adr r2, hexbuf" (+2) instruction to be representable in a shifted 8-bit value (hence indirectly putting higher aligment requirement on larger offsets), following error occurs, arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:138: Error: invalid constant (428) after fixup Fix it by bringing "hexbuf" closer so that "adr" can have the offset. Signed-off-by: Afzal Mohammed <afzal@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 17 Oct, 2011 29 commits
-
-
Russell King authored
Add vision_ep9307, rwi_ews, usb_a9g20, karo, apf9328, tx37, tx25, tx51, mx51_m2id, pca101, gplugd, smdk4212 and smdk4412. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Ohad Ben-Cohen authored
Add a private iommu pointer to the ARM-specific arch data in the device struct, which will be used to attach iommu-specific data to devices which require iommu support. Different iommu implementations (on different platforms) will attach different types of data to this pointer, so 'void *' is currently used (the downside is reduced typesafety). Note: ia64, x86 and sparc have this exact iommu extension as well, and if others are likely to adopt it too, we might want to consider adding this to the device struct itself directly. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Laura Abbott authored
The 64bit division functions never had unwinding annotations added. This prevents a backtrace from being printed within the function and if a division by 0 occurs. Add the annotations. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Rabin Vincent authored
Get rid of this complaint from dash: AS arch/arm/boot/compressed/lib1funcs.o /bin/sh: 1: [: y: unexpected operator LD arch/arm/boot/compressed/vmlinux Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Olof Johansson authored
This resolves the following sparse warning from readl() and other macros, which ends up embedding readl_relaxed() using the same variable. arch/arm/mach-tegra/dma.c:169:8: warning: symbol '__v' shadows an earlier one arch/arm/mach-tegra/dma.c:169:8: originally declared here Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
This exposes the PB1176 ROM if you compile in the MTD physmap mapping and also the map_rom chiptype. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Lei Wen authored
This copy really don't need to do at the very second before the kernel would crash. Signed-off-by: Lei Wen <leiwen@marvell.com> Acked-by: Simon Horman <horms@verge.net.au> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Will Deacon authored
The Cache Type Register L1Ip field identifies I-caches with a PIPT policy using the encoding 11b. This patch extends the cache policy parsing to identify PIPT I-caches correctly and prevent them from being treated as VIPT aliasing in cases where they are sufficiently large. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Get rid of the mdesc pointer in the fixup function call. No one uses the mdesc pointer, it shouldn't be modified anyway, and we can't wrap it, so let's remove it. Platform files found by: $ regexp=$(git grep -h '\.fixup.*=' arch/arm | sed 's!.*= *\([^,]*\),* *!\1!' | sort -u | tr '\n' '|' | sed 's,|$,,;s,|,\\|,g') $ git grep $regexp arch/arm Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Simon Glass authored
ARM uses its own BUG() handler which makes its output slightly different from other archtectures. One of the problems is that the ARM implementation doesn't report the function with the BUG() in it, but always reports the PC being in __bug(). The generic implementation doesn't have this problem. Currently we get something like: kernel BUG at fs/proc/breakme.c:35! Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... PC is at __bug+0x20/0x2c With this patch it displays: kernel BUG at fs/proc/breakme.c:35! Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ... PC is at write_breakme+0xd0/0x1b4 This implementation uses an undefined instruction to implement BUG, and sets up a bug table containing the relevant information. Many versions of gcc do not support %c properly for ARM (inserting a # when they shouldn't) so we work around this using distasteful macro magic. v1: Initial version to replace existing ARM BUG() implementation with something more similar to other architectures. v2: Add Thumb support, remove backtrace whitespace output changes. Change to use macros instead of requiring the asm %d flag to work (thanks to Dave Martin <dave.martin@linaro.org>) v3: Remove old BUG() implementation in favor of this one. Remove the Backtrace: message (will submit this separately). Use ARM_EXIT_KEEP() so that some architectures can dump exit text at link time thanks to Stephen Boyd <sboyd@codeaurora.org> (although since we always define GENERIC_BUG this might be academic.) Rebase to linux-2.6.git master. v4: Allow BUGS in modules (these were not reported correctly in v3) (thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting that.) Remove __bug() as this is no longer needed. v5: Add %progbits as the section flags. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
Update the Integrator defconfig with some sensible defaults: - Compile a combined image supporting Integrator/AP and Integrator/CP, with the core modules CM720, CM920, CM922, CM926, CM1020, CM1022 and CM1026 in a single image, this works just fine and gives some nice compilation coverage - NOHZ (tickless) and HRTIMERS turned on - Compile using EABI, let's assume recent compilers are used now (tested using GCC 4.4.1) - Remove forced 32MiB at command line, the bootloader usually knows this better, and my U-Boot patches nowadays make that boot loader pass the correct adjusted value - Enable the MTD Physmap flash driver, so that the changes done earlier by Marc Zyngier replacing integrator-flash takes effect - Enable the PL030 RTC driver that has not been default-compiled with any config for a while This has been tested on the real hardware Integrator AP with both an ARM920T and ARM926EJ-S core module. Cc: Marc Zyngier <Marc.Zyngier@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
We already have a clock definition for the 24MHz clock in the Integrator, use that instead of some unclear defines from the platform.h header. Also delete the senseless comment that the file shouldn't be edited, I just edited it and the world didn't come to an end, so it's obviously false. If anyone still has the mentioned ".s file" and the s2h awk script generating that header, raise your hand (and give me your files). Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
Drop mult, shift and delta calculations and let the clockevent core scale this as appropriate. Set the minimum interval to 1 rather than 15 (0xf), there is nothing in the data sheets I have indicating that 15 should be some minimum value. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
The Integrator AP timer has no problem supporting oneshot ticks with proper code, so let's do it so we can have NOHZ configured in for this platform too. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Linus Walleij authored
These macros are not used by anything since the switch to generic time in commit b9cedda2 so let's retire them. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Peter Hüwe authored
As per request of rmk, the options should be sorted alphabetically. Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jochen Friedrich authored
Remove the legacy ARM LED code for simpad devices and register a stadard LED platform device using GPIO line instead. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jochen Friedrich authored
Register keyboard, polled keyboard and I2C platform devices based on GPIOs. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jochen Friedrich authored
- prepend CS3 accessors by simpad_ to indicate they are specific to simpad devices. - use spinlock to protect shadow register. - implement 8 read-only pins. - use readl/writel macros so barriers are used where necessary. - register CS3 as GPIO controller with 24 pins (16 output only and 8 input only). - fix PCMCIA driver to access the read-only pins rather than the shadow register for status bits. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jochen Friedrich authored
Add ucb1x00 GPIO definitions to simpad.h and add gpio_base to ucb1x00 platform device so the pins are available using the GPIO API. Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Laura Abbott authored
Currently, show_regs calls __backtrace which does nothing if CONFIG_FRAME_POINTER is not set. Switch to dump_stack which handles both CONFIG_FRAME_POINTER and CONFIG_ARM_UNWIND correctly. __backtrace is now superseded by dump_stack in general and show_regs was the last caller so remove __backtrace as well. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nick Bowler authored
Current Versatile Express CPU hotplug code includes a hardcoded WFI instruction, in ARM encoding. When the kernel is compiled in Thumb-2 mode, this is invalid and causes the machine to hang hard when a CPU is offlined. Using the wfi macro (which uses the appropriate assembler mnemonic) causes the correct instruction to be emitted in either case. As a consequence of this change, an apparently vestigial "cc" clobber is dropped from the asm (the macro uses "memory" only). Signed-off-by: Nick Bowler <nbowler@elliptictech.com> Reviewed-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Dave Martin authored
When v6 and >=v7 boards are supported in the same kernel, the __und_usr code currently makes a build-time assumption that Thumb-2 instructions occurring in userspace don't need to be supported. Strictly speaking this is incorrect. This patch fixes the above case by doing a run-time check on the CPU architecture in these cases. This only affects kernels which support v6 and >=v7 CPUs together: plain v6 and plain v7 kernels are unaffected. Signed-off-by: Dave Martin <dave.martin@linaro.org> Reviewed-by: Jon Medhurst <tixy@yxit.co.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Dave Martin authored
When testing whether a Thumb-2 instruction is 32 bits long or not, the masking done in order to test bits 11-15 of the first instruction halfword won't affect the result of the comparison, so remove it. Signed-off-by: Dave Martin <dave.martin@linaro.org> Reviewed-by: Jon Medhurst <tixy@yxit.co.uk> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Dave Martin authored
The CPU architecture really should not be changing at runtime, so make it a global variable instead of a function. The cpu_architecture() function declared in <asm/system.h> remains the correct way to read this variable from C code. Signed-off-by: Dave Martin <dave.martin@linaro.org> Reviewed-by: Jon Medhurst <tixy@yxit.co.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Sascha Hauer authored
Boards used to specify zreladdr in their Makefile.boot with zreladdr-y := x, so conflicting zreladdrs were silently overwritten. This patch changes this to zreladdr-y += x, so that we end up with multiple words in zreladdr in such a case. We can detect this later and complain if necessary. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Sascha Hauer authored
uImages need a load address specified. This makes them incompatible with multiple zreladdrs. Catch this error before building an uImage so that we do not end up with broken uImages. The load address can still be specified with LOADADDR= on the command line. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Sascha Hauer authored
Without CONFIG_AUTO_ZRELADDR being set the kernel needs a single zreladdr for building zImages. Bail out if we detect multiple zreladdrs without CONFIG_AUTO_ZRELADDR. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Stephen Boyd authored
With d8ecc5cd (kbuild: asm-generic support, 2011-04-27) we can remove a handful of asm-generic wrappers in ARM code. Since the generic version of sizes.h doesn't contain SZ_48M, we replace the 4 users of SZ_48M with the equivalent SZ_32M + SZ_16M. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Cc: Imre Kaloz <kaloz@openwrt.org> Acked-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 11 Sep, 2011 1 commit
-
-
http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-armLinus Torvalds authored
* 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm: ARM: 7088/1: entry: fix wrong parameter name used in do_thumb_abort ARM: 7080/1: l2x0: make sure I&D are not locked down on init ARM: 7081/1: mach-integrator: fix the clocksource NET: am79c961: fix race in link status code ARM: 7067/1: mm: keep significant bits in pfn_valid
-
- 10 Sep, 2011 8 commits
-
-
Janusz Krzysztofik authored
Commit be020f86, "ARM: entry: abort-macro: specify registers to be used for macros", while replacing register numbers with macro parameter names, mismatched the name used for r1. For me, this resulted in user space built for EABI with -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb broken on my OMAP1510 based Amstrad Delta (old ABI and no thumb still worked for me though). Fix this by using correct parameter name fsr instead of mismatched psr, used by callers for another purpose. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Bart Van Assche authored
Since backlight_types[] isn't modified, let's declare it const. That was probably the intention of the author of commit bb7ca747 ("backlight: add backlight type"), via which the "const char const *" construct was introduced. The duplicate const was detected by sparse. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://neil.brown.name/mdLinus Torvalds authored
* 'for-linus' of git://neil.brown.name/md: md: Fix handling for devices from 2TB to 4TB in 0.90 metadata. md/raid1,10: Remove use-after-free bug in make_request. md/raid10: unify handling of write completion. Avoid dereferencing a 'request_queue' after last close.
-
NeilBrown authored
0.90 metadata uses an unsigned 32bit number to count the number of kilobytes used from each device. This should allow up to 4TB per device. However we multiply this by 2 (to get sectors) before casting to a larger type, so sizes above 2TB get truncated. Also we allow rdev->sectors to be larger than 4TB, so it is possible for the array to be resized larger than the metadata can handle. So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in used. Also the sanity check at the end of super_90_load should include level 1 as it used ->size too. (RAID0 and Linear don't use ->size at all). Reported-by: Pim Zandbergen <P.Zandbergen@macroscoop.nl> Cc: stable@kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
A single request to RAID1 or RAID10 might result in multiple requests if there are known bad blocks that need to be avoided. To detect if we need to submit another write request we test: if (sectors_handled < (bio->bi_size >> 9)) { However this is after we call **_write_done() so the 'bio' no longer belongs to us - the writes could have completed and the bio freed. So move the **_write_done call until after the test against bio->bi_size. This addresses https://bugzilla.kernel.org/show_bug.cgi?id=41862Reported-by: Bruno Wolff III <bruno@wolff.to> Tested-by: Bruno Wolff III <bruno@wolff.to> Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
A write can complete at two different places: 1/ when the last member-device write completes, through raid10_end_write_request 2/ in make_request() when we remove the initial bias from ->remaining. These two should do exactly the same thing and the comment says they do, but they don't. So factor the correct code out into a function and call it in both places. This makes the code much more similar to RAID1. The difference is only significant if there is an error, and they usually take a while, so it is unlikely that there will be an error already when make_request is completing, so this is unlikely to cause real problems. Signed-off-by: NeilBrown <neilb@suse.de>
-
NeilBrown authored
On the last close of an 'md' device which as been stopped, the device is destroyed and in particular the request_queue is freed. The free is done in a separate thread so it might happen a short time later. __blkdev_put calls bdev_inode_switch_bdi *after* ->release has been called. Since commit f758eeab bdev_inode_switch_bdi will dereference the 'old' bdi, which lives inside a request_queue, to get a spin lock. This causes the last close on an md device to sometime take a spin_lock which lives in freed memory - which results in an oops. So move the called to bdev_inode_switch_bdi before the call to ->release. Cc: Christoph Hellwig <hch@lst.de> Cc: Hugh Dickins <hughd@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Wu Fengguang <fengguang.wu@intel.com> Acked-by: Wu Fengguang <fengguang.wu@intel.com> Cc: stable@kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
-
Jon Mason authored
Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has massive negative ramifications on some devices. Without knowing which devices have this issue, do not modify from the default value when walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe the default procedure. Tested-by: Sven Schnelle <svens@stackframe.org> Tested-by: Simon Kirby <sim@hostway.ca> Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com> Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.de> References: https://bugzilla.kernel.org/show_bug.cgi?id=42162Signed-off-by: Jon Mason <mason@myri.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-