- 16 8月, 2011 4 次提交
-
-
由 Randy Dunlap 提交于
arch/x86/mm/fault.c needs to include asm/vsyscall.h to fix a build error: arch/x86/mm/fault.c: In function '__bad_area_nosemaphore': arch/x86/mm/fault.c:728: error: 'VSYSCALL_START' undeclared (first use in this function) Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mikael Pettersson 提交于
The sparc32 version of arch_write_unlock() is just a plain assignment. Unfortunately this allows the compiler to schedule side-effects in a protected region to occur after the HW-level unlock, which is broken. E.g., the following trivial test case gets miscompiled: #include <linux/spinlock.h> rwlock_t lock; int counter; void foo(void) { write_lock(&lock); ++counter; write_unlock(&lock); } Fixed by adding a compiler memory barrier to arch_write_unlock(). The sparc64 version combines the barrier and assignment into a single asm(), and implements the operation as a static inline, so that's what I did too. Compile-tested with sparc32_defconfig + CONFIG_SMP=y. Signed-off-by: NMikael Pettersson <mikpe@it.uu.se> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mikael Pettersson 提交于
The sparc64 spinlock_64.h contains a number of operations defined first as static inline functions, and then as macros with the same names and parameters as the functions. Maybe this was needed at some point in the past, but now nothing seems to depend on these macros (checked with a recursive grep looking for ifdefs on these names). Other archs don't define these identity-macros. So this patch deletes these unnecessary macros. Compile-tested with sparc64_defconfig. Signed-off-by: NMikael Pettersson <mikpe@it.uu.se> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 8月, 2011 1 次提交
-
-
由 David S. Miller 提交于
Reported-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 8月, 2011 10 次提交
-
-
由 Lennert Buytenhek 提交于
Instead of setting up a match interrupt for 'current_time + delta' on ->set_next_event(), program timer 0 to count down from 'delta - 1' and trigger an interrupt when it reaches zero. Signed-off-by: NLennert Buytenhek <buytenh@laptop.org> Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Lennert Buytenhek 提交于
Signed-off-by: NLennert Buytenhek <buytenh@laptop.org> Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Lennert Buytenhek 提交于
Currently, arch-mmp/time.c uses timer 0 both as a clocksource timer and as a clockevent timer, the latter by setting up a comparator interrupt to match on 'current_time + delta'. This is problematic if delta is small enough, as that can lead to 'current_time + delta' already being in the past when comparator setup has finished, leading to the requested event not triggering. As there is also a silicon issue that requires stopping a timer's counter while writing to one of its match registers, we'll switch to using two separate timers -- timer 0 as clockevent timer, which we'll start and stop on every invocation of ->set_next_event(), and timer 1 as clocksource timer, which will be free-running. This first patch enables timer 1 on boot, so that we can use it as clocksource timer. Signed-off-by: NLennert Buytenhek <buytenh@laptop.org> Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Tanmay Upadhyay 提交于
Signed-off-by: NTanmay Upadhyay <tanmay.upadhyay@einfochips.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Tanmay Upadhyay 提交于
Move definitions from mfp-gplugd.h to mfp-pxa168.h as they aren't gplugD specific. Signed-off-by: NTanmay Upadhyay <tanmay.upadhyay@einfochips.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Lennert Buytenhek 提交于
This got added in: commit ef6c8445 Author: Haojian Zhuang <haojian.zhuang@marvell.com> Date: Wed Nov 24 11:54:25 2010 +0800 ARM: pxa: add iwmmx support for PJ4 which does: - mrc p15, 0, r2, c15, c1, 0 - orr r2, r2, #0x3 @ enable access to CP0 and CP1 - mcr p15, 0, r2, c15, c1, 0 + @ enable access to CP0 and CP1 + XSC(mrc p15, 0, r2, c15, c1, 0) + XSC(orr r2, r2, #0x3) + XSC(mcr p15, 0, r2, c15, c1, 0) but then later does: - mrc p15, 0, r4, c15, c1, 0 - orr r4, r4, #0x3 @ enable access to CP0 and CP1 - mcr p15, 0, r4, c15, c1, 0 + @ enable access to CP0 and CP1 + XSC(mrc p15, 0, r4, c15, c1, 0) + XSC(orr r4, r4, #0xf) + XSC(mcr p15, 0, r4, c15, c1, 0) Signed-off-by: NLennert Buytenhek <buytenh@laptop.org> Acked-by Haojian <haojian.zhuang@gmail.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Andy Lutomirski 提交于
There are three choices: vsyscall=native: Vsyscalls are native code that issues the corresponding syscalls. vsyscall=emulate (default): Vsyscalls are emulated by instruction fault traps, tested in the bad_area path. The actual contents of the vsyscall page is the same as the vsyscall=native case except that it's marked NX. This way programs that make assumptions about what the code in the page does will not be confused when they read that code. vsyscall=none: Trying to execute a vsyscall will segfault. Signed-off-by: NAndy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/8449fb3abf89851fd6b2260972666a6f82542284.1312988155.git.luto@mit.eduSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Andy Lutomirski 提交于
getcpu is available as a vdso entry and an emulated vsyscall. Programs that for some reason don't want to use the vdso should still be able to call getcpu without relying on the slow emulated vsyscall. It costs almost nothing to expose it as a real syscall. We also need this for the following patch in vsyscall=native mode. Signed-off-by: NAndy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/6b19f55bdb06a0c32c2fa6dba9b6f222e1fde999.1312988155.git.luto@mit.eduSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Andy Lutomirski 提交于
As of commit 98d0ac38 Author: Andy Lutomirski <luto@mit.edu> Date: Thu Jul 14 06:47:22 2011 -0400 x86-64: Move vread_tsc and vread_hpet into the vDSO user code no longer directly calls into code in arch/x86/kernel/, so we don't need compile flag hacks to make it safe. All vdso code is in the vdso directory now. Signed-off-by: NAndy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/835cd05a4c7740544d09723d6ba48f4406f9826c.1312988155.git.luto@mit.eduSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Linus Walleij 提交于
The PCI nanoengine driver in the SA1100 machine probably has not been building for some time. It probably dragged hardware.h in implicitly and now it doesn't anymore. After this an SA1100 build selecting all system variants will build successfully. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 10 8月, 2011 10 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Brown paper bag day, previous commit wouldn't work very well with modules enabled. Move the exports into the ifdef. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Hemant Pedanekar 提交于
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the timer stops counting once overflow occurs as it was not set in autoreload mode. This results into timekeeping failure: for example, 'sleep 1' at the shell after the timer counter overflow would hang. This patch sets up autoreload when starting the clocksource timer which fixes the above issue. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Johan Hovold 提交于
Since 7203f8a4 (arm: mach-omap2: remove NULL board_mux from board files) NULL board_mux is defined in mux.h. Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Thomas Meyer 提交于
Use kstrdup rather than duplicating its implementation The semantic patch that makes this output is available in scripts/coccinelle/api/kstrdup.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/Signed-off-by: NThomas Meyer <thomas@m3y3r.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Maxin John 提交于
The pointer "va" returned from "phys_to_virt(pa)" is never used in "sgtable_fill_kmalloc()".So,it is safe to remove this set-but-unused variable. Signed-off-by: NMaxin B. John <maxin.john@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Oleg Drokin 提交于
Machine database already updated: http://www.arm.linux.org.uk/developer/machines/list.php?id=3284Signed-off-by: NOleg Drokin <green@linuxhacker.ru> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Raphaël Assénat 提交于
Add missing definitions for the AM3505/3517 UART4 such as DMAs, INTs and base address. Signed-of-by: NRaphael Assenat <raph@8d.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Russell King 提交于
This has now been well tested, and several platforms are now selecting this directly. It's time to drop its experimental status. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Paul Walmsley 提交于
Builds for multi-OMAP2 (e.g., OMAP2420 with OMAP2430) with CONFIG_ARCH_OMAP4=n fail with the following errors: arch/arm/mach-omap2/built-in.o: In function `_enable_module': arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable' arch/arm/mach-omap2/built-in.o: In function `_disable_module': arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable' arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable': arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle' This is probably due to the preprocessor directives in arch/arm/plat-omap/include/plat/cpu.h that convert some cpu_is_omap*() expressions from preprocessor directives into something that is only resolvable during runtime, if multiple OMAP2 build targets are selected. Thanks to Tony Lindgren <tony@atomide.com> for reporting. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Peter Ujfalusi 提交于
Commit b22f954b (OMAP4: Move common twl6030 configuration to twl-common) caused compile failures for code for OMAP arch which is not selected by the config. Fixes issues like: With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this: arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend' Fix the problem by moving the code to ifdef sections for omap3 and omap4. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> [tony@atomide.com: updated comments] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 09 8月, 2011 5 次提交
-
-
由 Youquan Song 提交于
Add support to Romely-EP SandyBridge. Signed-off-by: NYouquan Song <youquan.song@intel.com> Signed-off-by: NAnhua Xu <anhua.xu@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1312264895-2010-1-git-send-email-youquan.song@intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Dave Martin 提交于
With the UM_SIGNAL alignment fault mode, no siginfo structure is passed to userspace. POSIX specifies how siginfo_t should be populated for alignment faults, so this patch does just that: * si_signo = SIGBUS * si_code = BUS_ADRALN * si_addr = misaligned data address at which access was attempted Signed-off-by: NDave Martin <dave.martin@linaro.org> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Acked-by: NKirill A. Shutemov <kirill@shutemov.name> Reviewed-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Dave Martin 提交于
Currently, it's possible to set the kernel to ignore alignment faults when changing the alignment fault handling mode at runtime via /proc/sys/alignment, even though this is undesirable on ARMv6 and above, where it can result in infinite spins where an un-fixed- up instruction repeatedly faults. In addition, the kernel clobbers any alignment mode specified on the command-line if running on ARMv6 or above. This patch factors out the necessary safety check into a couple of new helper functions, and checks and modifies the fault handling mode as appropriate on boot and on writes to /proc/cpu/alignment. Prior to ARMv6, the behaviour is unchanged. For ARMv6 and above, the behaviour changes as follows: * Attempting to ignore faults on ARMv6 results in the mode being forced to UM_FIXUP instead. A warning is printed if this happened as a result of a write to /proc/cpu/alignment. The user's UM_WARN bit (if present) is still honoured. * An alignment= argument from the kernel command-line is now honoured, except that the kernel will modify the specified mode as described above. This is allows modes such as UM_SIGNAL and UM_WARN to be active immediately from boot, which is useful for debugging purposes. Signed-off-by: NDave Martin <dave.martin@linaro.org> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Jamie Iles 提交于
poison_init_mem() used a loop of: while ((count = count - 4)) which has 2 problems - an off by one error so that we do one less word than we should, and the other is that if count == 0 then we loop forever and poison too much. On a platform with HAVE_TCM=y but nothing in the TCM's, this caused corruption and the platform failed to boot. Acked-by: NStephen Boyd <sboyd@codeaurora.org> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Brian S. Julin 提交于
The file mm/proc-arm946.S contains a typo and is missing a structure member in __arm946_proc_info. The former prevents compilation and the latter causes problems during boot. It is likely this file was manually copied from a similar file and not tested, then later updates to the *_proc_info structures missed this file. This patch will apply (with offset) with or without the recent macro unification work that has been done in this directory. This was verified against linux-next/stable last week. See arm-linux-kernel thread: http://lists.arm.linux.org.uk/lurker/message/20110718.103237.0106d468.en.htmlSigned-off-by: NBrian S. Julin <bri@abrij.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 08 8月, 2011 5 次提交
-
-
由 Arnaud Patard (Rtp) 提交于
Commit fad10708 fixed the wrong test for MX51 as the MX51 addresses are wrong for MX50 and MX53 but now it's MX51 only, UART_PADDR is not defined anymore when building for MX50/MX53. Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org> Tested-by: NSteev Klimaszewski <steev@genesi-usa.com> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Ben Dooks 提交于
irq_to_gpio() is being called on a GPIO so change to using gpio_to_irq() instead. Signed-off-by: NBen Dooks <ben-linux@fluff.org> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Mark Brown 提交于
For marketing reasons the part will be called WM8996. In order to avoid user confusion rename the driver to reflect this. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NKukjin Kim <kgene.kim@samsung.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
由 Linus Torvalds 提交于
The generic library code already exports the generic function, this was left-over from the ARM-specific version that just got removed. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Since commit 1eb19a12 ("lib/sha1: use the git implementation of SHA-1"), the ARM SHA1 routines no longer work. The reason? They depended on the larger 320-byte workspace, and now the sha1 workspace is just 16 words (64 bytes). So the assembly version would overwrite the stack randomly. The optimized asm version is also probably slower than the new improved C version, so there's no reason to keep it around. At least that was the case in git, where what appears to be the same assembly language version was removed two years ago because the optimized C BLK_SHA1 code was faster. Reported-and-tested-by: NJoachim Eastwood <manabian@gmail.com> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 8月, 2011 5 次提交
-
-
由 David S. Miller 提交于
arch/sparc/mm/init_64.c:1622:22: error: unused variable '__swapper_4m_tsb_phys_patch_end' [-Werror=unused-variable] arch/sparc/mm/init_64.c:1621:22: error: unused variable '__swapper_4m_tsb_phys_patch' [-Werror=unused-variable] Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Colin Cross 提交于
omap_sr_disable_reset_volt is called with irqs off in omapx_enter_sleep, as part of idle sequence, this eventually calls sr_disable and pm_runtime_put_sync. pm_runtime_put_sync calls rpm_idle, which will enable interrupts in order to call the callback. In this short interval when interrupts are enabled, scenarios such as the following can occur: while interrupts are enabled, the timer interrupt that is supposed to wake the device out of idle occurs and is acked, so when the CPU finally goes to off, the timer is already gone, missing a wakeup event. Further, as the documentation for runtime states:" However, subsystems can use the pm_runtime_irq_safe() helper function to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume() callbacks should be invoked in atomic context with interrupts disabled (->runtime_idle() is still invoked the default way)." Hence, replace pm_runtime_put_sync with pm_runtime_put_sync_suspend to invoke the suspend handler and shut off the fclk for SmartReflex module instead of using the idle handler in interrupt disabled context. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NColin Cross <ccross@google.com> [khilman@ti.com: minor Subject edits] Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
Board code should not touch omap_device internals. To get the MPU/IVA devices, use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device(). Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
OMAP1 needs this also since GPIO driver (common for all OMAPs) is being converted to use generic IRQ chip. Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
SmartReflex should be disabled while entering low power mode due to a) SmartReflex values are not defined for retention voltage, further b) with SmartReflex enabled, if CPU enters lower c-states, FSM will try to bump the voltage to current OPP's voltage for which it has entered c-state; hence SmartReflex needs to be disabled for MPU, CORE and IVA voltage domains in idle path before enabling auto retention voltage achievement on the device. However, since the current pm_runtime setup for SmartReflex devices are setup to allow callbacks to be invoked with interrupts enabled, calling SmartReflex enable/disable from other contexts such as idle paths where preemption is disabled causes warnings such as the following indicating of a potential race. [ 82.023895] [<c04d079c>] (__irq_svc+0x3c/0x120) from [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c) [ 82.023895] [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c) from [<c0323234>] (rpm_callback+0x4c/0x68) [ 82.023956] [<c0323234>] (rpm_callback+0x4c/0x68) from [<c0323f7c>] (rpm_resume+0x338/0x53c) [ 82.023956] [<c0323f7c>] (rpm_resume+0x338/0x53c) from [<c03243f4>] (__pm_runtime_resume+0x48/0x60) [ 82.023986] [<c03243f4>] (__pm_runtime_resume+0x48/0x60) from [<c008aee0>] (sr_enable+0xa8/0x19c) [ 82.023986] [<c008aee0>] (sr_enable+0xa8/0x19c) from [<c008b2fc>] (omap_sr_enable+0x50/0x90) [ 82.024017] [<c008b2fc>] (omap_sr_enable+0x50/0x90) from [<c00888c0>] (omap4_enter_sleep+0x138/0x168) Instead, we use pm_runtime_irq_safe to tell the PM core that callbacks can be invoked in interrupt disabled contexts. Acked-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> [khilman@ti.com: minor changelog edits] Signed-off-by: NKevin Hilman <khilman@ti.com>
-