* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
[PATCH] x86-64: Fix warnings in ia32_aout.c
[PATCH] i386: Convert some functions to __init to avoid MODPOST warnings
[PATCH] i386: Fix memory hotplug related MODPOST generated warning
[PATCH] x86-64: tighten up printks
[PATCH] x86-64: - Ignore long SMI interrupts in clock calibration
[PATCH] x86-64: pci quirks MODPOST warning fix
[PATCH] x86-64: Modpost whitelist reference to more symbols (pattern 3)
[PATCH] x86-64: modpost add more symbols to whitelist pattern2
[PATCH] i386: make apic probe function non-init
[PATCH] i386: cpu hotplug/smpboot misc MODPOST warning fixes
[PATCH] x86-64: Use different constraint for gcc < 4.1 in bitops.h
[PATCH] x86-64: Make noirqdebug_setup function non init to fix modpost warning
[PATCH] i386: Update defconfig
[PATCH] x86-64: Update defconfig
Fix
linux/arch/x86_64/ia32/ia32_aout.c: In function ‘create_aout_tables’:
linux/arch/x86_64/ia32/ia32_aout.c:244: warning: cast from pointer to integer of different size
linux/arch/x86_64/ia32/ia32_aout.c:253: warning: cast from pointer to integer of different size
with gcc 4.3
Signed-off-by: Andi Kleen <ak@suse.de>
o Some functions which should have been in init sections as they are called
only once. Put them in init sections. Otherwise MODPOST generates warning
as these functions are placed in .text and they end up accessing something
in init sections.
WARNING: vmlinux - Section mismatch: reference to .init.text:migration_init
from .text between 'do_pre_smp_initcalls' (at offset 0xc01000d1) and
'run_init_process'
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Ensure that no SMI interrupts occur between the read of the HPET & TSC
in the clock calibration loop.
I noticed that a 2.66GHz system incorrectly detected the processor
clock speed about 1/7 of the time:
time.c: Detected 2660.005 MHz processor. (most of the time)
time.c: Detected 2988.203 MHz processor. (sometime)
The problem is caused by an SMI interrupt occuring in hpet_calibrate_tsc()
between the read of the HPET & TSC. Prior to switching the BIOS into
ACPI mode, it appears that every 27msec an SMI interrupt occurs. The
SMI interrupt takes 4.8 msec to process.
Note: On my test system, TICK_MIN had to be >380. I picked 5000
to minimize risk of having a value that is too small for other
platforms.
Signed-off-by: Jack Steiner <steiner@sgi.com>
Signed-off-by: Andi Kleen <ak@suse.de>
arch/x86_64/kernel/time.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
o struct genapic contains pointer to probe() function which is of type
__init. Hence MODPOST generates warning if kernel is compiled with
CONFIG_RELOCATABLE=y for i386.
WARNING: vmlinux - Section mismatch: reference to .init.text: from .data between 'apic_summit' (at offset 0xc058b504) and 'apic_bigsmp'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .data between 'apic_bigsmp' (at offset 0xc058b5a4) and 'cpu.4471'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .data between 'apic_es7000' (at offset 0xc058b644) and 'apic_default'
WARNING: vmlinux - Section mismatch: reference to .init.text: from .data between 'apic_default' (at offset 0xc058b6e4) and 'interrupt'
o One of the possible options is to put special case check in MODPOST to
not emit warnings for this case but I think it is not a very good option
in terms of maintenance.
o Another option is to make probe() function non __init. Anyway this function
is really small so not freeing this memory after init is not a big deal.
Secondly, from a programming perspective, probably genapic should not
provide pointers to functions which have been freed as genapic is non
__init and is used even after initialization is complete.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
o Misc smpboot/cpu hotplug path cleanups. I did those to supress the
warnings generated by MODPOST. These warnings are visible only
if CONFIG_RELOCATABLE=y.
o CONFIG_RELOCATABLE compiles the kernel with --emit-relocs option. This
option retains relocation information in vmlinux file and MODPOST
is quick to spit out "Section mismatch" warnings.
o This patch fixes some of those warnings. Many of the functions in
smpboot case are __devinit type and they in turn accesses text/data which
if of type __cpuinit. Now if CONFIG_HOTPLUG=y and CONFIG_HOTPLUG_CPU=n
then we end up in cases where a function in .text segment is calling
another function in .init.text segment and MODPOST emits warning.
WARNING: vmlinux - Section mismatch: reference to .init.text:identify_cpu from .text between 'smp_store_cpu_info' (at offset 0xc011020d) and 'do_boot_cpu'
WARNING: vmlinux - Section mismatch: reference to .init.text:init_gdt from .text between 'do_boot_cpu' (at offset 0xc01102ca) and '__cpu_up'
WARNING: vmlinux - Section mismatch: reference to .init.text:print_cpu_info from .text between 'do_boot_cpu' (at offset 0xc01105d0) and '__cpu_up'
o It also fixes the issues where CONFIG_HOTPLUG_CPU=y and start_secondary()
is calling smp_callin() which in-turn calls synchronize_tsc_ap() which is
of type __init. This should have meant broken CPU hotplug.
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'start_secondary' (at offset 0xc011603f) and 'initialize_secondary'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'MP_processor_info' (at offset 0xc0116a4f) and 'mp_register_lapic'
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andi Kleen <ak@suse.de>
The problem was introduced in 2.6.18.3 with the casting of some
36bit-defines (PCI memory) in au1000.h to resource_size_t which may be
u32 or u64 depending on the experimental CONFIG_RESOURCES_64BIT.
With unset CONFIG_RESOURCES_64BIT, the pci-memory cannot be accessed
because the ioremap in arch/mips/au1000/common/pci.c already used the
truncated addresses.
With set CONFIG_RESOURCES_64BIT, things get even worse, because PCI-scan
aborts, due to resource conflict: request_resource() in arch/mips/pci/pci.c
fails because the maximum iomem-address is 0xffffffff (32bit) but the
pci-memory-start-address is 0x440000000 (36bit).
To get pci working again, I propose the following patch:
1. remove the resource_size_t-casting from au1000.h again
2. make the casting in arch/mips/au1000/common/pci.c (it's allowed and
necessary here. The 36bit-handling will be done in __fixup_bigphys_addr).
With this patch pci works again like in 2.6.18.2, the gcc-compile warnings
in pci.c are gone and it doesn't depend on CONFIG_EXPERIMENTAL.
Signed-off-by: Alexander Bigga <ab@mycable.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
Add wrappers for N32 msg{snd,rcv}. compat_sys_msg{snd,rcv} can not not be
used as system call entries as is. This fix is based on Kaz Kylheku's
patch.
Also change a type of last argument of sysn32_semctl to match its true
size.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* 'merge' of master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] Fix bugs in the hypervisor call stats code
[POWERPC] Fix corruption in hcall9
[POWERPC] iSeries: fix setup initcall
[POWERPC] iSeries: fix viopath initialisation
[POWERPC] iSeries: fix lpevents initialisation
[POWERPC] iSeries: fix proc/iSeries initialisation
[POWERPC] iSeries: fix mf proc initialisation
[POWERPC] disable PReP and EFIKA during make oldconfig
[POWERPC] Fix mpc52xx serial driver to work for arch/ppc again
[POWERPC] Don't include powerpc/sysdev/rom.o for arch/ppc builds
[POWERPC] Fix mpc52xx fdt to use correct device_type for sound devices
[POWERPC] 52xx: Don't use device_initcall to probe of_platform_bus
[POWERPC] Add legacy iSeries to ppc64_defconfig
[POWERPC] Update ppc64_defconfig
[POWERPC] Fix manual assembly WARN_ON() in enter_rtas().
[POWERPC] Avoid calling get_irq_server() with a real, not virtual irq.
[POWERPC] Fix unbalanced uses of of_node_put
[POWERPC] Fix bogus BUG_ON() in in hugetlb_get_unmapped_area()
There are several places in the futex code where a spin_lock is held
and still uaccesses happen. Deadlocks are avoided by increasing the
preempt count. The pagefault handler will then not take any locks
but will immediately search the fixup tables.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
setup_memory_end() uses VMALLOC_END instead of VMALLOC_END_INIT to
calculate the maximum supported size of physical memory. Since
VMALLOC_END is zero, this will cause a crash on 31 bit systems.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
72486f1f8f inverts the logic if an
'online' attribute in /sys/devices/system/cpu/cpuX should appear.
So we end up with no hotpluggable cpus at all...
Set the hotpluggable value to one to make sure the online
attribute appears again.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix a memory leak problem in the memory detection routines. A memory leak
of 128k occurs when we have a contiguous memory with mixed access-mode
(read or write) ranges.
Signed-off-by: Hongjie Yang <hongjie@us.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
There were a few issues with the HCALL_STATS code:
- PURR cpu feature checks were backwards
- We iterated one entry off the end of the hcall_stats array
- Remove dead update_hcall_stats() function prototype
I noticed one thing while debugging, and that is we call H_ENTER (to set
up the MMU hashtable in early init) before we have done the cpu fixups.
This means we will execute the PURR SPR reads even on a CPU that isnt
capable of it. I wonder if we can move the CPU feature fixups earlier.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
It looks to me like we are corrupting r12 in the hcall9 function.
Although we have r0 free we cant use offsets against it, so save
away r12 in there instead. r12 holds the ninth return value from
the hypervisor call, so without this fix, the caller will see the
wrong value for the ninth element in the array that gets the return
values.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Clearing the progress indicator should only be done if we are running
on legacy iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/proc/iSeries/config should only be created if we are running on legacy
iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
/proc/iSeries/lpevents should only be created if we are running
on legacy iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
These proc files should only be created if we are running on legacy
iSeries.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This proc file should only be created if we are running on legacy
iSeries. Since we can now run the same kernel on legacy iSeries and
other machines, we currently get the /proc/iSeries directory and the
files in it on non-iSeries machines, and accessing them causes an oops
in some cases. This and the following patches make sure that these
files are not created on non-iSeries machines, thus avoiding the oops.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
New boards should not be enabled per default.
Disable EFIKA and PReP per default.
Anyone who really needes the new code can enable it during make oldconfig.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
sysdev/rom.c is for arch/powerpc only. Don't compile it when building
an arch/ppc kernel.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Sylvain Munaut <tnt@246tNt.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This corrects the documented interface for mpc52xx device trees.
Sound devices should be using 'sound' for the device_type field, not
the type of sound interface.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Sylvain Munaut <tnt@246tNt.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Using device_initcall makes it happen for every platform that
compiles this file in. This is really bad, for obvious reasons.
Instead, we use the .init field of the machine description. If
the platform needs the hook to do something specific it can provides
its own function and call mpc52xx_declare_of_platform_devices from
there. If not, the mpc52xx_declare_of_platform_devices function can
directly be used as the init hook.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Since we can now boot legacy iSeries and other machines with the same
config, enable legacy iSeries in ppc64_defconfig.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Enabled new netfilter stuff corresponding to what was enabled before
under different names, and turned on the gxt4500 video driver;
otherwise just took the defaults.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we switched over to the generic BUG mechanism we forgot to change
the assembly code which open-codes a WARN_ON() in enter_rtas(), so the
bug table got corrupted.
This patch provides an EMIT_BUG_ENTRY macro for use in assembly code,
and uses it in entry_64.S. Tested with CONFIG_DEBUG_BUGVERBOSE on ppc64
but not without -- I tried to turn it off but it wouldn't go away; I
suspect Aunt Tillie probably needed it.
This version gets __FILE__ and __LINE__ right in the assembly version --
rather than saying include/asm-powerpc/bug.h line 21 every time which is
a little suboptimal.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
We can use default_server when masking an interrupt vector.
get_irq_server() assumes a virtual irq, so badness may happen if we
give it a real one.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The (maple|pasemi)_init_IRQ functions call of_node_put(root) once more
than they should, causing the refcount of the root node to underflow,
which triggers the WARN_ON in kref_get.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The powerpc specific version of hugetlb_get_unmapped_area() makes some
unwarranted assumptions about what checks have been made to its
parameters by its callers. This will lead to a BUG_ON() if a 32-bit
process attempts to make a hugepage mapping which extends above
TASK_SIZE (4GB).
I'm not sure if these assumptions came about because they were valid
with earlier versions of the get_unmapped_area() path, or if it was
always broken. Nonetheless this patch fixes the logic, and removes
the crash.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This reverts commit b026872601, which has
been linked to several problem reports with IO-APIC and the timer.
Machines either don't boot because the timer doesn't happen, or we get
double timer interrupts because we end up double-routing the timer irq
through multiple interfaces.
See for example
http://lkml.org/lkml/2006/12/16/101http://lkml.org/lkml/2007/1/3/9http://bugzilla.kernel.org/show_bug.cgi?id=7789
about some of the discussion.
Patches to fix this cleanup exist (and have been confirmed to work fine
at least for some of the affected cases) and we'll revisit it for
2.6.21, but this late in the -rc series we're better off just reverting
the incomplete commit that caused the problems.
Suggested-by: Adrian Bunk <bunk@stusta.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai.lu@amd.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
the patch inlined below restores proper time accounting for PNX8550-based
boards. It also gets rid of #ifdef in the generic code which becomes
unnecessary then.
It's functionally identical to the previous patch with the same name but
it has minor comments from Atsushi and Sergei taken into account.
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The commit a923660d786a53e78834b19062f7af2535f7f8ad accidently
prevents TX49 from using CDEX. Use build_dst_pref() only if prefetch
for store was really available.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
There's a serious typo in the function:
arch/mips/pci/ops-pnx8550.c:write_config_byte()
The parameter passed to the function config_access() is PCI_CMD_CONFIG_READ
instead of PCI_CMD_CONFIG_WRITE. This renders any attempts to write
a single byte to the PCI configuration registers useless.
This problem does not exist for write_config_word() nor write_config_dword().
This problem has been there since kernel v2.6.17 and is still there
as of kernel v2.6.19.1.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Implement optimized asm version of csum_partial_copy_nocheck,
csum_partial_copy_from_user and csum_and_copy_to_user which can do
calculate and copy in parallel, based on memcpy.S.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Current sched_clock() implementations on ARM cause unbootable kernels
with PRINTK_TIME support enabled. To avoid this, provide a basic
printk_clock() implementation which avoids sched_clock() being called
before the page tables have been set up.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
fuse does not work on ARM due to cache incoherency issues - fuse wants
to use get_user_pages() to copy data from the current process into
kernel space. However, since this accesses userspace via the kernel
mapping, the kernel mapping can be out of date wrt data written to
userspace.
This can lead to unpredictable behaviour (in the case of fuse) or data
corruption for direct-IO.
This resolves debian bug #402876
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If the kernel attempts to execute a CP1 or CP2 instruction and it
aborts, and a FP emulator is not loaded, we try to return as if to
a user context, instead of the proper kernel context. Since the
fault came from kernel mode, we must use the kernel return paths.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Include <asm/io.h> to fix the warning:
arch/arm/kernel/traps.c:647:6: warning: symbol '__readwrite_bug' was not declared. Should it be static?
Include <linux/mc146818rtc.h> to fix the warning:
arch/arm/kernel/time.c:42:1: warning: symbol 'rtc_lock' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
o Currently synchronize_tsc_ap() is of type __init. It is called by
smp_callin() which is of type __cpuinit. So synchronize_tsc_ap()
should be of type __cpuinit.
o Modpost generates warnings for i386 if CONFIG_RELOCATABLE=y and
CONFIG_HOTPLUG_CPU=y
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'start_secondary' (at offset 0xc01164dc) and 'initialize_secondary'
WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'start_secondary' (at offset 0xc01164e8) and 'initialize_secondary'
o tsc is of type __initdata. It should be of type __cpuinitdata.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
o MODPOST generates warning for i386 if kernel is compiled with
CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.data: from .data between 'this_cpu' (at offset 0xc05194d0) and 'cpuinfo_op'
o this_cpu pointer should be of type __cpuinitdata.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
o MODPOST generates warning for i386 if kernel is compiled with
CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.text:startup_32_smp
from .data between 'trampoline_data' (at offset 0xc0519cf8) and 'boot_gdt'
o trampoline code/data can go into init section is CPU hotplug is not
enabled.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
o Relocatable bzImage support had got rid of CONFIG_PHYSICAL_START option
thinking that now this option is not required as people can build a
second kernel as relocatable and load it anywhere. So need of compiling
the kernel for a custom address was gone. But Magnus uses vmlinux images
for second kernel in Xen environment and he wants to continue to use
it.
o Restoring the CONFIG_PHYSICAL_START option for the time being. I think
down the line we can get rid of it.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Provide ACPI _PRT support for SN Altix systems.
The SN Altix platform does not conform to the
IOSAPIC IRQ routing model, so a new acpi_irq_model
(ACPI_IRQ_MODEL_PLATFORM) has been defined. The SN
platform specific code sets acpi_irq_model to
this new value, and keys off of it in acpi_register_gsi()
to avoid the iosapic code path.
Signed-off-by: John Keller <jpk@sgi.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] longhaul: Kill off warnings introduced by recent changes.
[CPUFREQ] Uninitialized use of cmd.val in arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:acpi_cpufreq_target()
[CPUFREQ] Longhaul - Always guess FSB
[CPUFREQ] Longhaul - Fix up powersaver assumptions.
[CPUFREQ] longhaul: Fix up unreachable code.
[CPUFREQ] speedstep-centrino: missing space and bracket
[CPUFREQ] Bug fix for acpi-cpufreq and cpufreq_stats oops on frequency change notification
[CPUFREQ] select consistently
If caller passed the tsk, we should use it to validate a stack ptr.
Otherwise, sysrq-t and other debugging stuff doesn't work.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
cmd.val was used uninitialized on the line below.
Signed-off-by: Guillaume Chazarain <guichaz@yahoo.fr>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
This is patch that solves Ebox mini PC issue and make
FSB code more specification compilant. At start guess_fsb
function is guessing 200MHz FSB too. It is better to
make it in this way because, thanks to this function, driver
will fail for bogus FSB values caused by bogus multiplier
value. For PowerSaver processors we can't depend on Max /
MinMHzFSB because these values are only used for
PowerSaver 2.0 and 3.0. Most processors on which Longhaul
is used are PowerSaver 1.0 only. I'm changing code for older
CPU's too, but not so much as previously, and this code was
already used for Ezra. Using MinMHzBR for Ezra-T is outside
spec. It is for voltage scaling purpose and don't have to
be equal to minmult (but it is). Same for Nehemiah (it
isn't for sure). Added mult - current multiplier value.
Signed-off-by: Rafa Bilski <rafalbilski@interia.pl>
Signed-off-by: Dave Jones <davej@redhat.com>
When we install the handlers for context switching, we must enable
VFP on all CPU cores, otherwise undefined (and random) effects
occur.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 968de4f026 ("i386: Relocatable
kernel support") caused problems for people with old binutils versions
that didn't mark ".text.*" sections automatically allocated.
So we should use .section command to specifically mark .text.head
section as AX (allocatable and executable) to solve the problem.
This should be unnecessary with binutils 2.15 and later, which is
already three years old, but it doesn't hurt supporting older toolchains
where possible.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dunno why this pops out in only in the allmodconfig build.
Though the warning is accurate, all the callers of the flagged
non __init function are __init, this is not a functional change.
WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at offset 0xc010f0a
6) and 'acpi_gsi_to_irq' WARNING: vmlinux - Section mismatch: reference to .init.text:mp_override_legacy_irq from .text between 'acpi_sci_ioapic_setup' (at offset 0
xc010f0de) and 'acpi_gsi_to_irq' WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_override_gsi from .text between 'acpi_sci_ioapic_setup' (at offset 0x
c010f0e4) and 'acpi_gsi_to_irq'
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit a9622f6219. Now that
the Calgary code apparently detects itself properly, it's not needed any
more.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
And this points out that the return value from
isa_dev_get_resource() and the 'pregs' arg to
isa_dev_get_irq() are totally unused.
Based upon a patch from Richard Mortimer <richm@oldelvet.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to pass in the resource otherwise we cannot
release the region properly. We must know whether it is
an I/O or MEM resource.
Spotted by Eric Brower.
Signed-off-by: David S. Miller <davem@davemloft.net>
We were not being careful enough. When we trim the physical
memory areas, we have to make sure we don't remove the kernel
image or initial ramdisk image ranges.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32. Without the
offset, transfers to buffers that do not begin on a page boundary will not
work as expected.
Signed-off-by: Jan Andersson <jan.andersson@ieee.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix apollon board compiler error
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix GPMC compiler errors on OMAP2
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The apple fn keys don't work anymore with 2.6.20-rc1.
The reason is that USB_HID_POWERBOOK appears in several files although
USB_HIDINPUT_POWERBOOK is the thing to be used.
The patch fixes this.
Cc: Greg KH <greg@kroah.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Due to the changes to make the kernel relocateable a new file is created
during the build process.
[jirislaby@gmail.com: The .gitigonre was intended to be in arch/ subtree]
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If PG_dcache_dirty is set for a page, we need to flush the source page
before performing any copypage operation using a different virtual address.
This fixes the copypage implementations for XScale, StrongARM and ARMv6.
This patch fixes segmentation faults seen in the dynamic linker under
the usage patterns in glibc 2.4/2.5.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since iop13xx defines the PCI I/O spaces with physical resource addresses
the __io macro needs to perform the physical to virtual conversion. I
incorrectly assumed that this would be handled by ioremap, but drivers
(like e1000) directly dereference the address returned from __io.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The commit 505788cccb in linus kernel tree
introduced some printks (for debugging ?) which are flooding the logs on
my h1940. This patch replace them with pr_debug calls.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ACPI PM2 register was fallback for "Longhaul ver. 1" CPU's.
My assumption that this register isn't present at
"PowerSaver" motherboards is so far true, but current code
will not work correctly in other case. There are three possible
supports: ACPI C3, PM2 and northbridge. That was my assumption
that ACPI C3 and northbridge is for PS and northbridge and PM2
is for V1. In current code we can only check if it is ACPI
support or not by port22_en. So remove port22_en and add
longhaul_flags. If USE_ACPI_C3 and USE_NORTHBRIDGE are both
clear then it means ACPI PM2 support. Also change order of
support probe from ACPI C3, PM2, northbridge to ACPI C3,
northbridge, ACPI PM2. Paranoid protection against port 0x22
cast as ACPI PM2 register. Bit 1 clear in such case - lockup
on AGP DMA. And obvious (now) fixup for do_powersaver. Use
cx->address only for ACPI C3 ("PowerSaver" processor using
PM2 support).
Signed-off-by: Rafa Bilski <rafalbilski@interia.pl>
Signed-off-by: Dave Jones <davej@redhat.com>
We use the fixmap for accessing pci config space in pci_mmcfg_read/write().
The problem is in pci_exp_set_dev_base(). It is caching a last
accessed address to avoid calling set_fixmap_nocache() whenever
pci_mmcfg_read/write() is used.
static inline void pci_exp_set_dev_base(int bus, int devfn)
{
u32 dev_base = base | (bus << 20) | (devfn << 12);
if (dev_base != mmcfg_last_accessed_device) {
mmcfg_last_accessed_device = dev_base;
set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
}
}
cpu0 cpu1
---------------------------------------------------------------------------
pci_mmcfg_read("device-A")
pci_exp_set_dev_base()
set_fixmap_nocache()
pci_mmcfg_read("device-B")
pci_exp_set_dev_base()
set_fixmap_nocache()
pci_mmcfg_read("device-B")
pci_exp_set_dev_base()
/* doesn't flush tlb */
But if cpus accessed the above order, the second pci_mmcfg_read() on
cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is
device-B. So, second pci_mmcfg_read() on cpu0 accesses a device-A via
a previous TLB cache. This problem became the cause of several strange
behavior.
This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check.
[ Alternatively, we could make a per-cpu mapping area or something. Not
that it's probably worth it, but if we wanted to avoid all locking and
instead just disable preemption, that would be the way to go. --Linus ]
Signed-off-by: OGAWA Hirofumi <hogawa@miraclelinux.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A space and a bracket are missing (and indentation is wrong).
Signed-off-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Fixes the oops in cpufreq_stats with acpi_cpufreq driver. The issue was
that the frequency was reported as 0 in acpi-cpufreq.c. The bug is due to
different indicies for freq_table and ACPI perf table.
Also adds a check in cpufreq_stats to check for error return from
freq_table_get_index() and avoid using the error return value.
Patch fixes the issue reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0629.html
and also other similar issue here
http://bugme.osdl.org/show_bug.cgi?id=7383 comment 53
Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Make x86_64 ACPI_CPU_FREQ select CPU_FREQ_TABLE like other methods do.
(although we should still eliminate as much use of 'select' as possible)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (68 commits)
ACPI: replace kmalloc+memset with kzalloc
ACPI: Add support for acpi_load_table/acpi_unload_table_id
fbdev: update after backlight argument change
ACPI: video: Add dev argument for backlight_device_register
ACPI: Implement acpi_video_get_next_level()
ACPI: Kconfig - depend on PM rather than selecting it
ACPI: fix NULL check in drivers/acpi/osl.c
ACPI: make drivers/acpi/ec.c:ec_ecdt static
ACPI: prevent processor module from loading on failures
ACPI: fix single linked list manipulation
ACPI: ibm_acpi: allow clean removal
ACPI: fix git automerge failure
ACPI: ibm_acpi: respond to workqueue update
ACPI: dock: add uevent to indicate change in device status
ACPI: ec: Lindent once again
ACPI: ec: Change #define to enums there possible.
ACPI: ec: Style changes.
ACPI: ec: Acquire Global Lock under EC mutex.
ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead.
ACPI: ec: Rename gpe_bit to gpe
...
Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
xruns starting at the 2.6.18-rt kernel, and those problems persisted all
until current -rt kernels. The latencies were serious and unjustified by
system load, often in the milliseconds range.
After a patient and heroic multi-month effort of Fernando, where he
tested dozens of kernels, tried various configs, boot options,
test-patches of mine and provided latency traces of those incidents, the
following 'smoking gun' trace was captured by him:
_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (try_to_wake_up)
IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup <<...>-5856> (37 0)
IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (c01262ba 0 0)
IRQ_19-1479 1D..1 0us : resched_task (try_to_wake_up)
IRQ_19-1479 1D..1 0us : __spin_unlock_irqrestore (try_to_wake_up)
...
<idle>-0 1...1 11us!: default_idle (cpu_idle)
...
<idle>-0 0Dn.1 602us : smp_apic_timer_interrupt (c0103baf 1 0)
...
<...>-5856 0D..2 618us : __switch_to (__schedule)
<...>-5856 0D..2 618us : __schedule <<idle>-0> (20 162)
<...>-5856 0D..2 619us : __spin_unlock_irq (__schedule)
<...>-5856 0...1 619us : trace_stop_sched_switched (__schedule)
<...>-5856 0D..1 619us : trace_stop_sched_switched <<...>-5856> (37 0)
what is visible in this trace is that CPU#1 ran try_to_wake_up() for
PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
for CPU#0. But it decided to not send an IPI that no CPU - due to
TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
result was a 600+ usecs latency and a missed wakeup!
the bug turned out to be an idle-wakeup bug introduced into the mainline
kernel this summer via an optimization in the x86_64 tree:
commit 495ab9c045
Author: Andi Kleen <ak@suse.de>
Date: Mon Jun 26 13:59:11 2006 +0200
[PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status
During some profiling I noticed that default_idle causes a lot of
memory traffic. I think that is caused by the atomic operations
to clear/set the polling flag in thread_info. There is actually
no reason to make this atomic - only the idle thread does it
to itself, other CPUs only read it. So I moved it into ti->status.
the problem is this type of change:
if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
- clear_thread_flag(TIF_POLLING_NRFLAG);
+ current_thread_info()->status &= ~TS_POLLING;
smp_mb__after_clear_bit();
while (!need_resched()) {
local_irq_disable();
this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
clear_thread_flag() is defined as:
clear_bit(flag, &ti->flags);
and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:
static inline void clear_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btrl %1,%0"
hence smp_mb__after_clear_bit() is defined as a simple compile barrier:
#define smp_mb__after_clear_bit() barrier()
but the explicit TS_POLLING clearing introduced by the patch:
+ current_thread_info()->status &= ~TS_POLLING;
is not an atomic op! So the clearing of the TS_POLLING bit is freely
reorderable with the reading of the NEED_RESCHED bit - and both now
reside in different memory addresses.
CPU idle wakeup very much depends on ordered memory ops, the clearing of
the TS_POLLING flag must always be done before we test need_resched()
and hit the idle instruction(s). [Symmetrically, the wakeup code needs
to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
ordering is paramount.]
Fernando's dual-core Athlon64 system has a sufficiently advanced memory
ordering model so that it triggered this scenario very often.
( And it also turned out that the reason why these latencies never
triggered on my testsystems is that i routinely use idle=poll, which
was the only idle variant not affected by this bug. )
The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
act as an absolute barrier between the TS_POLLING write and the
NEED_RESCHED read. This affects almost all idling methods (default,
ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Tested-by: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The PDA patches introduced a bug in ptrace: it reads eflags from the wrong
place on the target's stack, but writes it back to the correct place. The
result is a corrupted eflags, which is most visible when it turns interrupts
off unexpectedly.
This patch fixes this by making the ptrace code a little less fragile. It
changes [gs]et_stack_long to take a straightforward byte offset into struct
pt_regs, rather than requiring all callers to do a sizeof(struct pt_regs)
offset adjustment. This means that the eflag's offset (EFL_OFFSET) on the
target stack can be simply computed with offsetof().
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Frederik Deweerdt <deweerdt@free.fr>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix compile error when config memory hotplug with numa on i386.
The cause of compile error was missing of arch_add_memory(),
remove_memory(), and memory_add_physaddr_to_nid().
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@cs.washington.edu>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
register_memory() becomes double definition in 2.6.20-rc1. It is defined
in arch/i386/kernel/setup.c as static definition in 2.6.19. But it is
moved to arch/i386/kernel/e820.c in 2.6.20-rc1. And same name function is
defined in driver/base/memory.c too. So, it becomes cause of compile error
of duplicate definition if memory hotplug option is on.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
if CONFIG_CALGARY_IOMMU is built into the kernel via
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT, or is enabled via the
iommu=calgary boot option, then the detect_calgary() function runs to
detect the presence of a Calgary IOMMU.
detect_calgary() first searches the BIOS EBDA area for a "rio_table_hdr"
BIOS table. It has this parsing algorithm for the EBDA:
while (offset) {
...
/* The next offset is stored in the 1st word. 0 means no more */
offset = *((unsigned short *)(ptr + offset));
}
got that? Lets repeat it slowly: we've got a BIOS-supplied data
structure, plus Linux kernel code that will only break out of an
infinite parsing loop once the BIOS gives a zero offset. Ok?
Translation: what an excellent opportunity for BIOS writers to lock up
the Linux boot process in an utterly hard to debug place! Indeed the
BIOS jumped on that opportunity on my box, which has the following EBDA
chaining layout:
384, 65282, 65535, 65535, 65535, 65535, 65535, 65535 ...
see the pattern? So my, definitely non-Calgary system happily locks up
in detect_calgary()!
the patch below fixes the boot hang by trusting the BIOS-supplied data
structure a bit less: the parser always has to make forward progress,
and if it doesnt, we break out of the loop and i get the expected kernel
message:
Calgary: Unable to locate Rio Grande Table in EBDA - bailing!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
one of my boxes didnt boot the 2.6.20-rc1-rt0 kernel rpm, it hung during
early bootup. After an hour or two of happy debugging i narrowed it down
to the CALGARY_IOMMU_ENABLED_BY_DEFAULT option, which was freshly added
to 2.6.20 via the x86_64 tree and /enabled by default/.
commit bff6547bb6 claims:
[PATCH] Calgary: allow compiling Calgary in but not using it by default
This patch makes it possible to compile Calgary in but not use it by
default. In this mode, use 'iommu=calgary' to activate it.
but the change does not actually practice it:
config CALGARY_IOMMU_ENABLED_BY_DEFAULT
bool "Should Calgary be enabled by default?"
default y
depends on CALGARY_IOMMU
help
Should Calgary be enabled by default? if you choose 'y', Calgary
will be used (if it exists). If you choose 'n', Calgary will not be
used even if it exists. If you choose 'n' and would like to use
Calgary anyway, pass 'iommu=calgary' on the kernel command line.
If unsure, say Y.
it's both 'default y', and says "If unsure, say Y". Clearly not a typo.
disabling this option makes my box boot again. The patch below fixes the
Kconfig entry. Grumble.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM
The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.
The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.
From: Jean Delvare <khali@linux-fr.org>
Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.
[akpm@osdl.org: fix const warning]
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Only compare the exact HT capability bits against HT_CAPTYPE_IRQ,
this is a little paranoid, but doesn't hurt.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For 32-bit processes, the getcontext side of the swapcontext system
call (i.e. the saving of the context when the first argument is
non-NULL) has to set the ctx->uc_mcontext.uc_regs pointer to the place
where it saves the registers. Which it does, but it doesn't ensure
that the pointer is 16-byte aligned. 16-byte alignment is needed
because the Altivec/VMX registers are saved in there, and they need to
be on a 16-byte boundary.
This fixes it by ensuring the appropriate alignment of the pointer.
This issue was pointed out by Jakub Jelinek.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Initialize the pci device pci channel state. This is critical
for having the pci_channel_offline() routine (in pci.h) to
function correctly.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The Efika matches chrp_probe() too, so put its own probe first to make
sure we get it right in a multiplatform build.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The patch adding support for zImage.ps3 didn't add a zImage.initrd.ps3
target causing builds of zImage.initrd to fail when ps3 is included in
the .config. The current method of generating ps3 images doesn't support
initrd's yet, so we create a dummy target that only displays a warning
message instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
On some oldworld PowerMacs, OF doesn't assign interrupts properly
beyond P2P bridges. Fortunately, the fix is easy as all those machines
just wire all IRQ lines together to one IRQ which is assigned to the
bridge itself. We already have a special function for parsing Apple
OldWorld interrupts which are special, so let's add to it the ability
to walk up the PCI tree to find interrupts.
This fixes irqs on the lower slots of s900 clones among others.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Both CONFIG_MACH_OSIRIS and CONFIG_MACH_ANUBIS
should select CONFIG_PM_SIMTEC.
This patch moves the selection of CONFIG_PM_SIMTEC
to the machines that require it, as currently done
with other machines in the S3C2410 architecture.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Update the ep93xx, iop13xx, iop32x, iop33x, ixp2000, ixp23xx,
lpd270 and onearm defconfigs to 2.6.20-rc1.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Deepak Saxena has agreed to hand xsc3 maintainership over to me.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
LED 3 should have been registered with the
platform deviceid of 3, instead of 1 (which
was used for LED 1).
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* use irq_chip
* use handle_level_irq
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch add scanning of ebc bus to of_platform, which is needed
to recognize devices located on that bus.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
The difference between 'nid' and 'node' fields in an
spu structure was used incorrectly. The common 'node'
number now reflects the NUMA node, and it is used
in other places in the code as well.
The 'nid' value is meaningful only in one place, namely
the computation of the interrupt numbers based on the
physical location of an spu. Consequently, we look it
up directly in the place where it is used now.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Some SPU code was a bit too convoluted and broke when adding support for
the new style device-tree, most notably the struct pages for SPEs no
longer get created. oops...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Don't limit spider I/O workarounds to the first two buses.
The IBM Cell blade has three of them (one PCI, two PCIe)
and we want to handle them all.
Signed-off-by: Jens Osterkamp <jens@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
* master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] longhaul compile fix.
[CPUFREQ] Advise not to use longhaul on VIA C7.
[CPUFREQ] set policy->curfreq on initialization
[CPUFREQ] Trivial cleanup for acpi read/write port in acpi-cpufreq.c
[CPUFREQ] fixes typo in cpufreq.c
Recent workqueue changes basically make this a formal requirement.
Also, move atomic32.o from lib-y to obj-y since it exports symbols
to modules.
Signed-off-by: David S. Miller <davem@davemloft.net>
The patch adds ifdefs around per cpu definitions. Otherwise, if
not all cpu types are selected, the kernel does not link.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The struct resource 'end' field is inclusive, the iop13xx flash
setup code got this wrong.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The phys_io/io_pg_offst machine record variables were being set
to bogus values, causing problems when enabling DEBUG_LL.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add HWCAP_CRUNCH so that the dynamic linker knows whether it can
use Crunch-optimised libraries or not.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix up the CONFIG_PM mixups in arch/arm/mach-s3c2410/Kconfig
causing CONFIG_S3C2410_PM and CONFIG_PM_H1940 to get enabled
permanently.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move adjust_cr() into arch/arm/mm/mmu.c, and move irqflags.h to
a more appropriate place in the header file.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Clean the includes in arch/arm/mach-s3c2410/s3c2440.c
and arch/arm/mach-s3c2410/s3c2442.c which should have
been pruned when these where split and updated.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove old changelog entries in arch/arm/mach-s3c2410
which should be available from the version control
system.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Change the include/asm-arm/arch-s3c2410/regs-serial.h
platform data to use the prorper type (upf_t) for the
uart_flags.
Fix all the other parts of arch/arm/mach-s3c2410 to
include <linux/serial_core.h> and all other uses of
the include file.
mach-rx3715.c:101:18: warning: incorrect type in initializer (different base types)
mach-rx3715.c:101:18: expected unsigned long [unsigned] uart_flags
mach-rx3715.c:101:18: got restricted unsigned int [usertype] [force] <noident>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove warning from s3c2410_pm_resume() not being
declared by making it static.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the following sparse errors in arch/arm/mach-s3c2410
by fixing the include paths and making un-exported items
static.
s3c2410-clock.c:206:12: warning: symbol 's3c2410_baseclk_add' was not declared. Should it be static?
s3c2412-clock.c:559:17: warning: symbol 'clks_src' was not declared. Should it be static?
s3c2412-clock.c:622:12: warning: symbol 'clks' was not declared. Should it be static?
s3c2412-clock.c:630:12: warning: symbol 's3c2412_baseclk_add' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove old (and non-shared) VA addresses from the mappings
in arch/arm/mach-s3c2410/map.h and anywhere they are being
mapped in arch/arm/mach-s3c2410
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix sparse errors in arch/arm/mach-s3c2410/s3c2442-clock.c
warning: symbol 'clk_h' shadows an earlier one
warning: symbol 'clk_p' shadows an earlier one
warning: symbol 'clk_upll' shadows an earlier one
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the sparse errors in arch/arm/mach-s3c2410/s3c2440-clock.c
warning: symbol 'clk_h' shadows an earlier one
warning: symbol 'clk_p' shadows an earlier one
warning: symbol 'clk_upll' shadows an earlier one
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix the copyright messages in arch/arm/mach-s3c2410
to actually have `Copyright` in the line.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We need to ensure that the area size is page aligned so that
remap_area_pte() doesn't increment the address past the end of
the desired area.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Check the correct variable and set policy->cur upon acpi-cpufreq
initialization to allow the userspace governor to be used as default.
Signed-off-by: Mattia Dongili <malattia@linux.it>
Acked-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dave Jones <davej@redhat.com>
It branches around some necessary prom calls, which we would
need to do even if we are mapped at the correct location already.
So it doesn't work.
The idea was that this sort of thing could be used for the eventual
kexec implementation, but it is clear that this will need to be
done differently.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add:
sys_unshare
sys_set_robust_list
sys_get_robust_list
sys_splice
sys_arm_sync_file_range
sys_tee
sys_vmsplice
sys_move_pages
sys_getcpu
Special note about sys_arm_sync_file_range(), which is implemented as:
asmlinkage long sys_arm_sync_file_range(int fd, unsigned int flags,
loff_t offset, loff_t nbytes)
{
return sys_sync_file_range(fd, offset, nbytes, flags);
}
We can't export sys_sync_file_range() directly on ARM because the
argument list someone picked does not fit in the available registers.
Would be nice if... there was an arch maintainer review mechanism for
new syscalls before they hit the kernel.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It has caused more problems than it ever really solved, and is
apparently not getting cleaned up and fixed. We can put it back when
it's stable and isn't likely to make warning or bug events worse.
In the meantime, enable frame pointers for more readable stack traces.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The dump tools expect that the saved prefix register points to the
lowcore of the dump cpu. Since we set the prefix register to 0 during
reipl/dump, we have to save the original prefix register. Before we
start the dump program, we copy the original prefix register to the
designated location in the lowcore.
Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
We use printks after shutting down all other cpus. This is not allowed
and can lead to deadlocks. Therefore the printks have to be removed.
Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Reboot hangs on LPARs without diag308 support. The reason for this is,
that before the reboot is done, the channel subsystem is shut down.
During the reset on each possible subchannel a "store subchannel" is
done. This operation can end in a program check interruption, if the
specified subchannel set is not implemented by the hardware. During
the reset, currently we do not have a program check handler, which
leads to the described kernel bug. We install now a new program check
handler for the reboot code to fix this problem.
Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>