CC arch/mips/kernel/traps.o
arch/mips/kernel/traps.c: In function 'show_backtrace':
arch/mips/kernel/traps.c:110: warning: unused variable 'ra'
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Add generic irq_chip for TX39/TX49 SoCs. This can be replace
jmr3927_irq_irc, tx4927_irq_pic_type and tx4938_irq_pic_type.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
For the generation of asm-offset.h to work these need to be evaulatable
by gcc as a constant expression. This issue did exist for a while but
didn't bite because they're only in asm-offset.h for debugging purposes.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
due to adaptive granularity scheduling the role of sched_granularity
has changed to "minimum granularity", so rename the variable (and the
tunable) accordingly.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Instead of specifying the preemption granularity, specify the wanted
latency. By fixing the granlarity to a constany the wakeup latency
it a function of the number of running tasks on the rq.
Invert this relation.
sysctl_sched_granularity becomes a minimum for the dynamic granularity
computed from the new sysctl_sched_latency.
Then use this latency to do more intelligent granularity decisions: if
there are fewer tasks running then we can schedule coarser. This helps
performance while still always keeping the latency target.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'agp-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6:
agp: balance ioremap checks
agp: Add device id for P4M900 to via-agp module
efficeon-agp leaks 'struct agp_bridge_data' in error paths of agp_efficeon_probe()
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Renumber AUDIT_TTY_[GS]ET to avoid a conflict with netlink message types
already used in the wild.
Signed-off-by: Miloslav Trmac <mitr@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
PCI: Run k8t_sound_hostbridge quirk only when needed
PCI: disable MSI on RX790
PCI: disable MSI on RD580
PCI: disable MSI on RS690
PCI: make pcie_get_readrq visible in pci.h
PCI: lets kill the 'PCI hidden behind bridge' message
pci/hotplug/cpqphp_ctrl.c: remove stale BKL use
PCI: Document pci_iomap()
PCI: quirk_e100_interrupt() called too early
PCI: Move prototypes for pci_bus_find_capability to include/linux/pci.h
Include asm-generic/pgtable.h to pick up the lazy_mmu_mode and
lazy_cpu_mode macros. Won't build without them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Schedule /proc/acpi/event for removal in 6 months.
Re-name acpi_bus_generate_event() to acpi_bus_generate_proc_event()
to make sure there is no confusion that it is for /proc/acpi/event only.
Add CONFIG_ACPI_PROC_EVENT to allow removal of /proc/acpi/event.
There is no functional change if CONFIG_ACPI_PROC_EVENT=y
Signed-off-by: Len Brown <len.brown@intel.com>
The previous events patch added a netlink event for every
user of the legacy /proc/acpi/event interface.
However, some users of /proc/acpi/event are really input events,
and they already report their events via the input layer.
Introduce a new interface, acpi_bus_generate_netlink_event(),
which is explicitly called by devices that want to repoprt
events via netlink. This allows the input-like events
to opt-out of generating netlink events. In summary:
events that are sent via netlink:
ac/battery/sbs
thermal
processor
thinkpad_acpi dock/bay
events that are sent via input layer:
button
video hotkey
thinkpad_acpi hotkey
asus_acpi/asus-laptop hotkey
sonypi/sonylaptop
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On a four package system with HT - HT load balancing optimizations were
broken. For example, if two tasks end up running on two logical threads
of one of the packages, scheduler is not able to pull one of the tasks
to a completely idle package.
In this scenario, for nice-0 tasks, imbalance calculated by scheduler
will be 512 and find_busiest_queue() will return 0 (as each cpu's load
is 1024 > imbalance and has only one task running).
Similarly MC scheduler optimizations also get fixed with this patch.
[ mingo@elte.hu: restored fair balancing by increasing the fuzz and
adding it back to the power decision, without the /2
factor. ]
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
construct a more or less wall-clock time out of sched_clock(), by
using ACPI-idle's existing knowledge about how much time we spent
idling. This allows the rq clock to work around TSC-stops-in-C2,
TSC-gets-corrupted-in-C3 type of problems.
( Besides the scheduler's statistics this also benefits blktrace and
printk-timestamps as well. )
Furthermore, the precise before-C2/C3-sleep and after-C2/C3-wakeup
callbacks allow the scheduler to get out the most of the period where
the CPU has a reliable TSC. This results in slightly more precise
task statistics.
the ACPI bits were acked by Len.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Len Brown <len.brown@intel.com>
The NUMA layer only supports NUMA policies for the highest zone. When
ZONE_MOVABLE is configured with kernelcore=, the the highest zone becomes
ZONE_MOVABLE. The result is that policies are only applied to allocations
like anonymous pages and page cache allocated from ZONE_MOVABLE when the
zone is used.
This patch applies policies to the two highest zones when the highest zone
is ZONE_MOVABLE. As ZONE_MOVABLE consists of pages from the highest "real"
zone, it's always functionally equivalent.
The patch has been tested on a variety of machines both NUMA and non-NUMA
covering x86, x86_64 and ppc64. No abnormal results were seen in
kernbench, tbench, dbench or hackbench. It passes regression tests from
the numactl package with and without kernelcore= once numactl tests are
patched to wait for vmstat counters to update.
akpm: this is the nasty hack to fix NUMA mempolicies in the presence of
ZONE_MOVABLE and kernelcore= in 2.6.23. Christoph says "For .24 either merge
the mobility or get the other solution that Mel is working on. That solution
would only use a single zonelist per node and filter on the fly. That may
help performance and also help to make memory policies work better."
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Tested-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In file included from drivers/video/console/newport_con.c:16:
include/linux/selection.h:16: warning: "struct tty_struct" declared inside parameter list
include/linux/selection.h:16: warning: its scope is only this definition or declaration, which is probably not what you want
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
drivers/char/keyboard.c: In function 'kbd_keycode':
drivers/char/keyboard.c:1142: error: implicit declaration of function 'mac_hid_mouse_emulate_buttons'
The forward declaration of mac_hid_mouse_emulate_buttons() is not visible on
m68k because it's hidden in the middle of a big #ifdef block.
Move it to <linux/kbd_kern.h>, correct the type of the second parameter, and
include <linux/kbd_kern.h> where needed.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add the needed constants and defines to activate the existing code.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The new exec code inserts an accounted vma into an mm struct which is not
current->mm. The existing memory check code has a hard coded assumption
that this does not happen as does the security code.
As the correct mm is known we pass the mm to the security method and the
helper function. A new security test is added for the case where we need
to pass the mm and the existing one is modified to pass current->mm to
avoid the need to change large amounts of code.
(Thanks to Tobias for fixing rejects and testing)
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: WU Fengguang <wfg@mail.ustc.edu.cn>
Cc: James Morris <jmorris@redhat.com>
Cc: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reading the LSR clears the break, parity, frame error, and overrun bits in
the 8250 chip, but these are not being saved in all places that read the
LSR. Same goes for the MSR delta bits. Save the LSR bits off whenever the
lsr is read so they can be handled later in the receive routine. Save the
MSR bits to be handled in the modem status routine.
Also, clear the stored bits and clear the interrupt registers before
enabling interrupts, to avoid handling old values of the stored bits in the
interrupt routines.
[akpm@linux-foundation.org: clean up pre-existing code]
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Yinghai Lu <yinghai.lu@sun.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
RS690 can't do MSI like its predecessors. Disable MSI on RS690.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Henry Su <henry.su@amd.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] PCI: make pcie_get_readrq visible in pci.h
pcie_get_readrq() is EXPORT_SYMBOL'ed, but its prototype is not
visible in pci.h, add it there.
This is needed by some network drivers.
Signed-off-by: Brice Goglin <brice@myri.com>
Acked-by: Peter Oruba <peter.oruba@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need pci_bus_find_capability() in some arch/powerpc code so move
the prototype into a header accessible to it.
Also kill the duplicate prototype for pci_bus_alloc_resource().
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC32]: Revert f642b26380.
[SPARC64]: Need to clobber global reg vars in switch_to().
After doing some tests this seems to be the best variant for s390 and
should be correct as well. With gcc 4.2.1 we get the following kernel
image sizes using the default configuration:
atomic_t type volatile, atomic_read/set defines 5311824 bytes
atomic_t type int, atomic_read/set defines 5270864 bytes
atomic_t type int, atomic_read/set inline asm 5279056 bytes
atomic_t type int, atomic_read/set inline barrier 5270864 bytes
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
There are several s390 diagnose calls, which must be executed below the
2GB memory boundary. In order to enforce this, those diagnoses must be
compiled into the kernel. Currently diag 14 can be called within the
vmur kernel module from addresses above 2GB. This leads to specification
exceptions. This patch moves diag10, diag14 and diag210 into the new
diag.c file.
Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
The initial user manuals for MPC8544/8533 had some issues with properly
documenting the device IDs for MPC8544/8533. These processors are almost
identical and both show up on the reference boards.
Fix up the quirks for PCIe support to handle MPC8533/E.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>