summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2011-12-05Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched, x86: Avoid unnecessary overflow in sched_clock sched: Fix buglet in return_cfs_rq_runtime() sched: Avoid SMT siblings in select_idle_sibling() if possible sched: Set the command name of the idle tasks in SMP kernels sched, rt: Provide means of disabling cross-cpu bandwidth sharing sched: Document wait_for_completion_*() return values sched_fair: Fix a typo in the comment describing update_sd_lb_stats sched: Add a comment to effective_load() since it's a pain
2011-12-05Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] ap: Setup timer for sending messages after reset. [S390] cio: fix chsc_chp_vary [S390] cio: provide fake irb for transport mode IO [S390] cio: disallow driver io for known to be broken paths [S390] hibernate: directly trigger subchannel evaluation [S390] remove reset of system call restart on psw changes [S390] add missing .set function for NT_S390_LAST_BREAK regset [S390] fix page change underindication in pgste_update_all [S390] ptrace inferior call interactions with TIF_SYSCALL [S390] kdump: Replace is_kdump_kernel() with OLDMEM_BASE check
2011-12-05ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogramJanusz Krzysztofik
Otherwise timing is inaccurate, resulting in devices which depend on it, like omap-keypad, broken. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-05x86, amd: Fix up numa_node information for AMD CPU family 15h model 0-0fh ↵Andreas Herrmann
northbridge functions I've received complaints that the numa_node attribute for family 15h model 00-0fh (e.g. Interlagos) northbridge functions shows -1 instead of the proper node ID. Correct this with attached quirks (similar to quirks for other AMD CPU families used in multi-socket systems). Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Frank Arnold <frank.arnold@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/20111202072143.GA31916@alberich.amd.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86/rtc, mrst: Don't register a platform RTC device for for Intel MID platformsMathias Nyman
Intel MID x86 platforms have a memory mapped virtual RTC instead. No MID platform have the default ports (and accessing them may do weird stuff). Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: feng.tang@intel.com Cc: Feng Tang <feng.tang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, ↵Konrad Rzeszutek Wilk
regardless of lazy_mmu mode Fix an outstanding issue that has been reported since 2.6.37. Under a heavy loaded machine processing "fork()" calls could crash with: BUG: unable to handle kernel paging request at f573fc8c IP: [<c01abc54>] swap_count_continued+0x104/0x180 *pdpt = 000000002a3b9027 *pde = 0000000001bed067 *pte = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1638, comm: apache2 Not tainted 3.0.4-linode37 #1 EIP: 0061:[<c01abc54>] EFLAGS: 00210246 CPU: 3 EIP is at swap_count_continued+0x104/0x180 .. snip.. Call Trace: [<c01ac222>] ? __swap_duplicate+0xc2/0x160 [<c01040f7>] ? pte_mfn_to_pfn+0x87/0xe0 [<c01ac2e4>] ? swap_duplicate+0x14/0x40 [<c01a0a6b>] ? copy_pte_range+0x45b/0x500 [<c01a0ca5>] ? copy_page_range+0x195/0x200 [<c01328c6>] ? dup_mmap+0x1c6/0x2c0 [<c0132cf8>] ? dup_mm+0xa8/0x130 [<c013376a>] ? copy_process+0x98a/0xb30 [<c013395f>] ? do_fork+0x4f/0x280 [<c01573b3>] ? getnstimeofday+0x43/0x100 [<c010f770>] ? sys_clone+0x30/0x40 [<c06c048d>] ? ptregs_clone+0x15/0x48 [<c06bfb71>] ? syscall_call+0x7/0xb The problem is that in copy_page_range() we turn lazy mode on, and then in swap_entry_free() we call swap_count_continued() which ends up in: map = kmap_atomic(page, KM_USER0) + offset; and then later we touch *map. Since we are running in batched mode (lazy) we don't actually set up the PTE mappings and the kmap_atomic is not done synchronously and ends up trying to dereference a page that has not been set. Looking at kmap_atomic_prot_pfn(), it uses 'arch_flush_lazy_mmu_mode' and doing the same in kmap_atomic_prot() and __kunmap_atomic() makes the problem go away. Interestingly, commit b8bcfe997e4615 ("x86/paravirt: remove lazy mode in interrupts") removed part of this to fix an interrupt issue - but it went to far and did not consider this scenario. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05Merge branch 'ucode' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp ↵Ingo Molnar
into x86/urgent
2011-12-05x86: Fix "Acer Aspire 1" reboot hangPeter Chubb
Looks like on some Acer Aspire 1s with older bioses, reboot via bios fails. It works on my machine, (with BIOS version 0.3310) but not on some others (BIOS version 0.3309). There's a log of problems at: https://bbs.archlinux.org/viewtopic.php?id=124136 This patch adds a different callback to the reboot quirk table, to allow rebooting via keybaord controller. Reported-by: Uroš Vampl <mobile.leecher@gmail.com> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au> Cc: Don Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: stable@kernel.org Link: http://lkml.kernel.org/r/1323093233-9481-1-git-send-email-anarsoul@gmail.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86/mtrr: Resolve inconsistency with Intel processor manualAjaykumar Hotchandani
Following is from Notes of section 11.5.3 of Intel processor manual available at: http://www.intel.com/Assets/PDF/manual/325384.pdf For the Pentium 4 and Intel Xeon processors, after the sequence of steps given above has been executed, the cache lines containing the code between the end of the WBINVD instruction and before the MTRRS have actually been disabled may be retained in the cache hierarchy. Here, to remove code from the cache completely, a second WBINVD instruction must be executed after the MTRRs have been disabled. This patch provides resolution for that. Ideally, I will like to make changes only for Pentium 4 and Xeon processors. But, I am not finding easier way to do it. And, extra wbinvd() instruction does not hurt much for other processors. Signed-off-by: Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Link: http://lkml.kernel.org/r/4EBD1CC5.3030008@oracle.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86: Document rdmsr_safe restrictionsBorislav Petkov
Recently, I got bitten by using rdmsr_safe too early in the boot process. Document its shortcomings for future reference. Link: http://lkml.kernel.org/r/4ED5B70F.606@lwfinger.net Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
2011-12-05x86, microcode: Fix the failure path of microcode update driver init codeSrivatsa S. Bhat
The microcode update driver's initialization code does not handle failures correctly. This patch fixes this issue. Signed-off-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20111107123530.12164.31227.stgit@srivatsabhat.in.ibm.com Link: http://lkml.kernel.org/r/4ED8E2270200007800065120@nat28.tlf.novell.com Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
2011-12-05Add TAINT_FIRMWARE_WORKAROUND on MTRR fixupPrarit Bhargava
TAINT_FIRMWARE_WORKAROUND should be set when an MTRR fixup is done. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Link: http://lkml.kernel.org/r/1318958650-12447-1-git-send-email-prarit@redhat.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86/mpparse: Account for bus types other than ISA and PCIBjorn Helgaas
In commit f8924e770e04 ("x86: unify mp_bus_info"), the 32-bit and 64-bit versions of MP_bus_info were rearranged to match each other better. Unfortunately it introduced a regression: prior to that change we used to always set the mp_bus_not_pci bit, then clear it if we found a PCI bus. After it, we set mp_bus_not_pci for ISA buses, clear it for PCI buses, and leave it alone otherwise. In the cases of ISA and PCI, there's not much difference. But ISA is not the only non-PCI bus, so it's better to always set mp_bus_not_pci and clear it only for PCI. Without this change, Dan's Dell PowerEdge 4200 panics on boot with a log indicating interrupt routing trouble unless the "noapic" option is supplied. With this change, the machine boots reliably without "noapic". Fixes http://bugs.debian.org/586494 Reported-bisected-and-tested-by: Dan McGrath <troubledaemon@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # 2.6.26+ Cc: Dan McGrath <troubledaemon@gmail.com> Cc: Alexey Starikovskiy <aystarik@gmail.com> [jrnieder@gmail.com: clarified commit message] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Link: http://lkml.kernel.org/r/20111122215000.GA9151@elie.hsd1.il.comcast.net Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86, mrst: Change the pmic_gpio device type to IPCFeng Tang
In latest firmware's SFI tables, pmic_gpio has been set to IPC type of device, so we need handle it too. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05mrst: Added some platform data for the SFI translationsJekyll Lai
Add SFI glue for the following devices: tca6416: a gpio expander compatible with max7315 mpu3050: gyro sensor Both of these actual drivers are already upstream Signed-off-by: Jekyll Lai <jekyll_lai@wistron.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86,mrst: Power control commands updateJacob Pan
On the Intel MID devices SCU commands are issued to manage power off and the like. We need to issue different ones for non-Lincroft based devices. Signed-off-by: Alek Du <alek.du@intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI rebootRafael J. Wysocki
Dell OptiPlex 990 is known to require PCI reboot, so add it to the reboot blacklist in pci_reboot_dmi_table[]. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Link: http://lkml.kernel.org/r/201111160019.51303.rjw@sisk.pl Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05ARM: davinci: dm365 evm: align nand partition table to u-bootShankarmurthy,Akshay
Current partition information maintained in kernel does not match with u-boot, this leads to corruption of u-boot env when we update uImage from kernel. Patch fixes it to match with u-boot partition information. Signed-off-by: Shankarmurthy,Akshay <akshay.s@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-05ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0Manjunathappa, Prakash
On OMAP-L138 platform, EDMA event queue 0 should be used for audio transfers so that they are not starved by video data moving on event queue 1. Commit 48519f0ae03bc7e86b3dc93e56f1334d53803770 (ASoC: davinci: let platform data define edma queue numbers) had a side-effect of changing this behavior by making the driver actually honor the platform data passed. Fix this now by passing event queue 0 as the queue to be used for audio transfers. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Cc: <stable@vger.kernel.org> # v2.6.36.x and above
2011-12-05ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_modeHans Verkuil
The function setup_vpif_input_channel_mode() used the VSCLKDIS register instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0 used a different clock from channel 1. Clearly a copy-and-paste error. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Manjunath Hadli <manjunath.hadli@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Cc: stable@kernel.org
2011-12-05ARM: davinci: dm646x does not have a DSP domainSekhar Nori
Fix the incorrect classification of DSP clock into a seperate DSP domain on DM646x. Per the reference guide (http://www.ti.com/lit/ug/spruep9e/spruep9e.pdf) there is only one "AlwaysON" power domain on DM6467. Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-05ARM: davinci: psc: fix incorrect offsetsMurali Karicheri
Seperate PDSTAT and PDCTL registers are defined for domain 0 and domain 1 where as the code always reads the domain 0 PDSTAT register and domain 1 PDCTL register. Fix this issue. While at it, introduce usage of macros for register masks to improve readability. Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-05ARM: davinci: psc: fix incorrect maskMurali Karicheri
There are 5 LSB bits defined in PDSTAT and the code currently uses a mask of 1 bit to check the status. Use a proper mask per the hardware specification. While at it, use a #define for the mask to improve readability. Reviewed-by: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-12-05x86, UV: Fix UV2 hub part numberJack Steiner
There was a mixup when the SGI UV2 hub chip was sent to be fabricated, and it ended up with the wrong part number in the HRP_NODE_ID mmr. Future versions of the chip will (may) have the correct part number. Change the UV infrastructure to recognize both part numbers as valid IDs of a UV2 hub chip. Signed-off-by: Jack Steiner <steiner@sgi.com> Link: http://lkml.kernel.org/r/20111129210058.GA20452@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05x86: Add user_mode_vm check in stack_overflow_checkMitsuo Hayasaka
The kernel stack overflow is checked in stack_overflow_check(), which may wrongly detect the overflow if the stack pointer in user space points to the kernel stack intentionally or accidentally. So, the actual overflow is never detected after this misdetection because WARN_ONCE() is used on the detection of it. This patch adds user-mode-vm checking before it to avoid this problem and bails out early if the user stack is used. Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> Cc: yrl.pp-manager.tt@hitachi.com Cc: Randy Dunlap <rdunlap@xenotime.net> Link: http://lkml.kernel.org/r/20111129060821.11076.55315.stgit@ltc219.sdl.hitachi.co.jp Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com>
2011-12-05perf, x86: Force IBS LVT offset assignment for family 10hRobert Richter
On AMD family 10h we see firmware bug messages like the following: [Firmware Bug]: cpu 6, try to use APIC500 (LVT offset 0) for vector 0x10400, but the register is already in use for vector 0xf9 on another cpu [Firmware Bug]: cpu 6, IBS interrupt offset 0 not available (MSRC001103A=0x0000000000000100) [Firmware Bug]: using offset 1 for IBS interrupts [Firmware Bug]: workaround enabled for IBS LVT offset perf: AMD IBS detected (0x00000007) We always see this, since the offsets are not assigned by the BIOS for this family. Force LVT offset assignment in this case. If the OS assignment fails, fallback to BIOS settings and try to setup this. The fallback to BIOS settings weakens the family check since force_ibs_eilvt_setup() may fail e.g. in case of virtual machines. But setup may still succeed if BIOS offsets are correct. Other families don't have a workaround implemented that assigns LVT offsets. It's ok, to drop calling force_ibs_eilvt_setup() for that families. With the patch the [Firmware Bug] messages vanish. We see now: IBS: LVT offset 1 assigned perf: AMD IBS detected (0x00000007) Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20111109162225.GO12451@erda.amd.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-05perf, x86: Disable PEBS on SandyBridge chipsPeter Zijlstra
Cc: Stephane Eranian <eranian@google.com> Cc: stable@kernel.org Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-04x86: Fix boot failures on older AMD CPU'sLinus Torvalds
People with old AMD chips are getting hung boots, because commit bcb80e53877c ("x86, microcode, AMD: Add microcode revision to /proc/cpuinfo") moved the microcode detection too early into "early_init_amd()". At that point we are *so* early in the booth that the exception tables haven't even been set up yet, so the whole rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy); doesn't actually work: if the rdmsr does a GP fault (due to non-existant MSR register on older CPU's), we can't fix it up yet, and the boot fails. Fix it by simply moving the code to a slightly later point in the boot (init_amd() instead of early_init_amd()), since the kernel itself doesn't even really care about the microcode patchlevel at this point (or really ever: it's made available to user space in /proc/cpuinfo, and updated if you do a microcode load). Reported-tested-and-bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Bob Tracy <rct@gherkin.frus.com> Acked-by: Borislav Petkov <borislav.petkov@amd.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-04sparc: Use kmemdup rather than duplicating its implementationThomas Meyer
The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-03arch/tile: use new generic {enable,disable}_percpu_irq() routinesChris Metcalf
We provided very similar routines internally, but now we can hook into the generic framework by supplying our routines as function pointers in the irq_chip structure instead. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-12-03arch/tile: fix double-free bug in homecache_free_pages()Chris Metcalf
When freeing the page with this API, the page was "put" twice. This was only discovered bringing up an MPT fusion controller, which actually used the API; it hadn't been invoked previously, so the bug had gone unnoticed. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-12-03arch/tile: add a few #includes and an EXPORT to catch up with kernel changes.Chris Metcalf
The empty_zero_page[] export is required for ZERO_PAGE() module references. The #includes are due to changes in implicit inclusion, and should of course have been in the sources from the beginning. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-12-03xen/pm_idle: Make pm_idle be default_idle under Xen.Konrad Rzeszutek Wilk
The idea behind commit d91ee5863b71 ("cpuidle: replace xen access to x86 pm_idle and default_idle") was to have one call - disable_cpuidle() which would make pm_idle not be molested by other code. It disallows cpuidle_idle_call to be set to pm_idle (which is excellent). But in the select_idle_routine() and idle_setup(), the pm_idle can still be set to either: amd_e400_idle, mwait_idle or default_idle. This depends on some CPU flags (MWAIT) and in AMD case on the type of CPU. In case of mwait_idle we can hit some instances where the hypervisor (Amazon EC2 specifically) sets the MWAIT and we get: Brought up 2 CPUs invalid opcode: 0000 [#1] SMP Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 RIP: e030:[<ffffffff81015d1d>] [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4 ... Call Trace: [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8 [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10 RIP [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4 RSP <ffff8801d28ddf10> In the case of amd_e400_idle we don't get so spectacular crashes, but we do end up making an MSR which is trapped in the hypervisor, and then follow it up with a yield hypercall. Meaning we end up going to hypervisor twice instead of just once. The previous behavior before v3.0 was that pm_idle was set to default_idle regardless of select_idle_routine/idle_setup. We want to do that, but only for one specific case: Xen. This patch does that. Fixes RH BZ #739499 and Ubuntu #881076 Reported-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-02ARM: mx28: LRADC macro renamePeter Rusko
It's a correction of two macro names, renaming them from IRADC to LRADC. Signed-off-by: Peter Rusko <rusko.peter@prolan.hu> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
2011-12-02arm: mx23: recognise stmp378x as mx23Wolfram Sang
Adding the machine_is_* line was forgotten when converting mach-stmp378x to mach-mxs. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: stable@kernel.org
2011-12-02ARM: mxs: fix machines' initializers orderLauri Hintsala
Initializers of m28evk and stmp378x_devb fixed to be in order they are called. reference: http://article.gmane.org/gmane.linux.ports.arm.omap/50721 Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
2011-12-02ARM: mxs/tx28: add __initconst for fec pdataDong Aisheng
Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
2011-12-02ARM: S3C64XX: Staticise s3c6400_sysclassMark Brown
The symbol is not exported and doesn't need to be. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2011-12-02ARM: S3C64XX: Add linux/export.h to dev-spi.cMark Brown
This is required for the EXPORT_SYMBOL()s the code uses, previously the header was being included implicitly by another header. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2011-12-02ARM: S3C64XX: Remove extern from definition of framebuffer setup callMark Brown
The extern is only useful on prototypes. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2011-12-02ARM: CSR: PM: fix build error due to undeclared 'THIS_MODULE'Barry Song
In the new kernel, we will get the following compile error: arch/arm/mach-prima2/pm.c:141: error: 'THIS_MODULE' undeclared here (not in a function) so include module.h head file explicitly Signed-off-by: Barry Song <baohua.song@csr.com>
2011-12-02ARM: CSR: fix build error due to new mdesc->dma_zone_sizeBarry Song
commit 98b0124f0e2b88 "ARM: mach-prima2: move ARM_DMA_ZONE_SIZE to mdesc->dma_zone_size" causes building error: arch/arm/mach-prima2/prima2.c:39:19: error: 'SZ_256M' undeclared here (not in a function) Signed-off-by: Barry Song <baohua.song@csr.com>
2011-12-01ARM: OMAP1: Fix ckctl value used for dpll1 defualt rateJanusz Krzysztofik
Use the exact value found in omap1_rate_table, otherwise I have been experiencing issues with correct timekeeping on my Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-01ARM: OMAP1: Remove unsafe clock values from omap1_defconfigJanusz Krzysztofik
DPLL1 reprogramming to a different rate is actually blocked inside omap1_select_table_rate(), resulting in the defalut rate of 60 MHz always used instead of the one selected in .config. OTOH, in omap1_defconfig we currently rely on Kconfig options for the supported MHz rates in case of boards which boot with dpll1 not set correctly by their boot loaders. This means that before we allow for reprogramming of dpll1 rate, we should remove all unsafe clock selections from omap1_defconfig, otherwise it will stop booting on boards with imperfect boot loaders, as it would always try to change to 216MHz. Keep only one safe clock rate per each supported xtal frequency, i.e. 60MHZ dpll1 for 12MHz xtal and 182MHz dpll1 for 13MHz xtal. BTW, this change goes into the direction of removing all OMAP1 clock rate options, planned for next merge window. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-01ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot at rates below ↵Tony Lindgren
60MHz Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix reprogramming of dpll1 rate) fixed a regression for systems that did not rely on bootloader set rates. However, it also introduced a new problem where the rates selected in .config would not take affect as omap1_select_table_rate currently refuses to reprogram DPLL1 if it's already initialized. This was not a problem earlier, as the reprogramming was done earlier with ck_dpll1_p->rate uninitialized. Fix this by forcing the reprogramming on systems booting at rates below 60MHz. Note that the long term fix is to make the rates SoC specific later on. Thanks for Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> for figuring this one out. Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-01Merge branch 'fixes' of ↵Linus Torvalds
http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm * 'fixes' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm: ARM: 7182/1: ARM cpu topology: fix warning ARM: 7181/1: Restrict kprobes probing SWP instructions to ARMv5 and below ARM: 7180/1: Change kprobes testcase with unpredictable STRD instruction ARM: 7177/1: GIC: avoid skipping non-existent PPIs in irq_start calculation ARM: 7176/1: cpu_pm: register GIC PM notifier only once ARM: 7175/1: add subname parameter to mfp_set_groupg callers ARM: 7174/1: Fix build error in kprobes test code on Thumb2 kernels ARM: 7172/1: dma: Drop GFP_COMP for DMA memory allocations ARM: 7171/1: unwind: add unwind directives to bitops assembly macros ARM: 7170/2: fix compilation breakage in entry-armv.S ARM: 7168/1: use cache type functions for arch_get_unmapped_area ARM: perf: check that we have a platform device when reserving PMU ARM: 7166/1: Use PMD_SHIFT instead of PGDIR_SHIFT in dma-consistent.c ARM: 7165/2: PL330: Fix typo in _prepare_ccr() ARM: 7163/2: PL330: Only register usable channels ARM: 7162/1: errata: tidy up Kconfig options for PL310 errata workarounds ARM: 7161/1: errata: no automatic store buffer drain ARM: perf: initialise used_mask for fake PMU during validation ARM: PMU: remove pmu_init declaration ARM: PMU: re-export release_pmu symbol to modules
2011-12-01[S390] remove reset of system call restart on psw changesMartin Schwidefsky
git commit 20b40a794baf3b4b "signal race with restarting system calls" added code to the poke_user/poke_user_compat to reset the system call restart information in the thread-info if the PSW address is changed. The purpose of that change has been to workaround old gdbs that do not know about the REGSET_SYSTEM_CALL. It turned out that this is not a good idea, it makes the behaviour of the debuggee dependent on the order of specific ptrace call, e.g. the REGSET_SYSTEM_CALL register set needs to be written last. And the workaround does not really fix old gdbs, inferior calls on interrupted restarting system calls do not work either way. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-12-01[S390] add missing .set function for NT_S390_LAST_BREAK regsetMartin Schwidefsky
The last breaking event address is a read-only value, the regset misses the .set function. If a PTRACE_SETREGSET is done for NT_S390_LAST_BREAK we get an oops due to a branch to zero: Kernel BUG at 0000000000000002 verbose debug info unavailable illegal operation: 0001 #1 SMP ... Call Trace: (<0000000000158294> ptrace_regset+0x184/0x188) <00000000001595b6> ptrace_request+0x37a/0x4fc <0000000000109a78> arch_ptrace+0x108/0x1fc <00000000001590d6> SyS_ptrace+0xaa/0x12c <00000000005c7a42> sysc_noemu+0x16/0x1c <000003fffd5ec10c> 0x3fffd5ec10c Last Breaking-Event-Address: <0000000000158242> ptrace_regset+0x132/0x188 Add a nop .set function to prevent the branch to zero. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: stable@kernel.org
2011-12-01[S390] fix page change underindication in pgste_update_allCarsten Otte
This patch makes sure we don't underindicate _PAGE_CHANGED in case we have a race between an operation that changes the page and this code path that hits us between page_get_storage_key and page_set_storage_key. Note that we still have a potential underindication on _PAGE_REFERENCED in the unlikely event that the page was changed but not referenced _and_ someone references the page in the race window. That's not considered to be a problem. Signed-off-by: Carsten Otte <cotte@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-12-01[S390] ptrace inferior call interactions with TIF_SYSCALLMartin Schwidefsky
The TIF_SYSCALL bit needs to be cleared if the debugger changes the state of the ptraced process in regard to the presence of a system call. Otherwise the system call will be restarted although the debugger set up an inferior call. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-08 06:09:16 +0000