Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 3月, 2012 8 次提交
  3. 02 3月, 2012 1 次提交
  5. 28 2月, 2012 6 次提交
  7. 27 2月, 2012 2 次提交
  9. 25 2月, 2012 3 次提交
  11. 24 2月, 2012 9 次提交
  13. 22 2月, 2012 8 次提交
    • B
      x86/mce/AMD: Fix UP build error · 3f806e50
      由 Borislav Petkov 提交于 
      141168c3 ("x86: Simplify code by removing a !SMP #ifdefs
from 'struct cpuinfo_x86'") removed a bunch of CONFIG_SMP ifdefs
around code touching struct cpuinfo_x86 members but also caused
the following build error with Randy's randconfigs:

mce_amd.c:(.cpuinit.text+0x4723): undefined reference to `cpu_llc_shared_map'

Restore the #ifdef in threshold_create_bank() which creates
symlinks on the non-BSP CPUs.

There's a better patch series being worked on by Kevin Winchester
which will solve this in a cleaner fashion, but that series is
too ambitious for v3.3 merging - so we first queue up this trivial
fix and then do the rest for v3.4.
Signed-off-by: NBorislav Petkov <bp@alien8.de>
Acked-by: NKevin Winchester <kjwinchester@gmail.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Nick Bowler <nbowler@elliptictech.com>
Link: http://lkml.kernel.org/r/20120203191801.GA2846@x1.osrc.amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      3f806e50
    • B
      powerpc: Fix various issues with return to userspace · 18b246fa
      由 Benjamin Herrenschmidt 提交于 
      We have a few problems when returning to userspace. This is a
quick set of fixes for 3.3, I'll look into a more comprehensive
rework for 3.4. This fixes:

 - We kept interrupts soft-disabled when schedule'ing or calling
do_signal when returning to userspace as a result of a hardware
interrupt.

 - Rename do_signal to do_notify_resume like all other archs (and
do_signal_pending back to do_signal, which it was before Roland
changed it).

 - Add the missing call to key_replace_session_keyring() to
do_notify_resume().
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---
      18b246fa
    • M
      powerpc: Fix program check handling when lockdep is enabled · 922b9f86
      由 Michael Ellerman 提交于 
      In commit 54321242 ("Disable interrupts early in Program Check"), we
switched from enabling to disabling interrupts in program_check_common.

Whereas ENABLE_INTS leaves r3 untouched, if lockdep is enabled DISABLE_INTS
calls into lockdep code and will clobber r3. That means we pass a bogus
struct pt_regs* into program_check_exception() and all hell breaks loose.

So load our regs pointer into r3 after we call DISABLE_INTS.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      922b9f86
    • R
      powerpc: Remove references to cpu_*_map · 07d2f1a5
      由 Rusty Russell 提交于 
      This has been obsolescent for a while; time for the final push.

In adjacent context, replaced old cpus_* with cpumask_*.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      07d2f1a5
    • L
      sys_poll: fix incorrect type for 'timeout' parameter · faf30900
      由 Linus Torvalds 提交于 
      The 'poll()' system call timeout parameter is supposed to be 'int', not
'long'.

Now, the reason this matters is that right now 32-bit compat mode is
broken on at least x86-64, because the 32-bit code just calls
'sys_poll()' directly on x86-64, and the 32-bit argument will have been
zero-extended, turning a signed 'int' into a large unsigned 'long'
value.

We could just introduce a 'compat_sys_poll()' function for this, and
that may eventually be what we have to do, but since the actual standard
poll() semantics is *supposed* to be 'int', and since at least on x86-64
glibc sign-extends the argument before invocing the system call (so
nobody can actually use a 64-bit timeout value in user space _anyway_,
even in 64-bit binaries), the simpler solution would seem to be to just
fix the definition of the system call to match what it should have been
from the very start.

If it turns out that somebody somehow circumvents the user-level libc
64-bit sign extension and actually uses a large unsigned 64-bit timeout
despite that not being how poll() is supposed to work, we will need to
do the compat_sys_poll() approach.
Reported-by: NThomas Meyer <thomas@m3y3r.de>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faf30900
    • T
      ARM: OMAP1: Fix out-of-bounds array access for Innovator · 2226957e
      由 Tony Lindgren 提交于 
      Otherwise we can get the following on some compilers:

arch/arm/mach-omap1/board-innovator.c:419:19: warning:
array subscript is above array bounds [-Warray-bounds]
arch/arm/mach-omap1/board-innovator.c:425:19: warning:
array subscript is above array bounds [-Warray-bounds]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      2226957e
    • A
      OMAP3 EVM: remove out-of-bounds array access of gpio_leds · ebe8f7e5
      由 Arnout Vandecappelle (Essensium/Mind) 提交于 
      Otherwise we can get the following warning on some compilers:

arch/arm/mach-omap2/board-omap3evm.c:384:11:
warning: array subscript is above array bounds

The omap3evm BSP enables a GPIO LED on the twl4030 chip.  However,
the static gpio_leds array doesn't have an entry for it.  This is
most likely a copy-and-paste error, because it has been in there
since the first commit of the omap3evm BSP (53c5ec31).
Signed-off-by: NArnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[tony@atomide.com: updated comments with the warning]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      ebe8f7e5
    • E
      ARM/audit: include audit header and fix audit arch · 5180bb39
      由 Eric Paris 提交于 
      Both bugs being fixed were introduced in:
29ef73b7

Include linux/audit.h to fix below build errors:

  CC      arch/arm/kernel/ptrace.o
arch/arm/kernel/ptrace.c: In function 'syscall_trace':
arch/arm/kernel/ptrace.c:919: error: implicit declaration of function 'audit_syscall_exit'
arch/arm/kernel/ptrace.c:921: error: implicit declaration of function 'audit_syscall_entry'
arch/arm/kernel/ptrace.c:921: error: 'AUDIT_ARCH_ARMEB' undeclared (first use in this function)
arch/arm/kernel/ptrace.c:921: error: (Each undeclared identifier is reported only once
arch/arm/kernel/ptrace.c:921: error: for each function it appears in.)
make[1]: *** [arch/arm/kernel/ptrace.o] Error 1
make: *** [arch/arm/kernel] Error 2

This part of the patch is:
Reported-by: NAxel Lin <axel.lin@gmail.com>
Reported-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
(They both provided patches to fix it)

This patch also (at the request of the list) fixes the fact that
ARM has both LE and BE versions however the audit code was called as if
it was always BE.  If audit userspace were to try to interpret the bits
it got from a LE system it would obviously do so incorrectly.  Fix this
by using the right arch flag on the right system.

This part of the patch is:
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5180bb39
  15. 21 2月, 2012 3 次提交
    • R
      ARM: OMAP: fix voltage domain build errors with PM_OPP disabled · 3ddd4d0c
      由 Russell King 提交于 
      The voltage domain code wants the voltage tables, which are in the
opp*.c files.  These files aren't built when PM_OPP is disabled,
causing the following build errors at link time:

twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data'
twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data'
twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data'
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3ddd4d0c
    • M
      ARM/PCI: Remove ARM's duplicate definition of 'pcibios_max_latency' · e23e8c06
      由 Myron Stowe 提交于 
      The patch series to re-factor PCI's 'latency timer' setup (re:
http://marc.info/?l=linux-kernel&m=131983853831049&w=2) forgot to
remove the ARM specific definition of 'pcibios_max_latency' once such
had been moved into the pci core resulting in ARM related compile
errors -
  drivers/built-in.o:(.data+0x230): multiple definition of
  `pcibios_max_latency'
  arch/arm/common/built-in.o:(.data+0x40c): first defined here
  make[1]: *** [vmlinux.o] Error 1

In the series, patch 2/16 (commit 168c8619) converted the ARM
specific version of 'pcibios_set_master()' to a non-inlined version.
This was done in preperation for hosting it up into PCI's core, which
was done in patch 10/16 (commit 96c55900) of the series (and
where the removal of ARM's 'pcibios_max_latency' was overlooked).
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e23e8c06
    • S
      ARM: 7336/1: smp_twd: Don't register CPUFREQ notifiers if local timers are not initialised · 910ba598
      由 Santosh Shilimkar 提交于 
      Current ARM local timer code registers CPUFREQ notifiers even in case
the twd_timer_setup() isn't called. That seems to be wrong and
would eventually lead to kernel crash on the CPU frequency transitions
on the SOCs where the local timer doesn't exist or broken because of
hardware BUG. Fix it by testing twd_evt and *__this_cpu_ptr(twd_evt).

The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
on OMAP3 SOC which doesn't have TWD.

Below is the dump for reference :

 Unable to handle kernel paging request at virtual address 007e900
 pgd = cdc20000
 [007e9000] *pgd=00000000
 Internal error: Oops: 5 [#1] SMP
 Modules linked in:
 CPU: 0    Not tainted  (3.3.0-rc3-pm+debug+initramfs #9)
 PC is at twd_update_frequency+0x34/0x48
 LR is at twd_update_frequency+0x10/0x48
 pc : [<c001382c>]    lr : [<c0013808>]    psr: 60000093
 sp : ce311dd8  ip : 00000000  fp : 00000000
 r10: 00000000  r9 : 00000001  r8 : ce310000
 r7 : c0440458  r6 : c00137f8  r5 : 00000000  r4 : c0947a74
 r3 : 00000000  r2 : 007e9000  r1 : 00000000  r0 : 00000000
 Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment usr
 Control: 10c5387d  Table: 8dc20019  DAC: 00000015
 Process sh (pid: 599, stack limit = 0xce3102f8)
 Stack: (0xce311dd8 to 0xce312000)
 1dc0:                                                       6000c
 1de0: 00000001 00000002 00000000 00000000 00000000 00000000 00000
 1e00: ffffffff c093d8f0 00000000 ce311ebc 00000001 00000001 ce310
 1e20: c001386c c0437c4c c0e95b60 c0e95ba8 00000001 c0e95bf8 ffff4
 1e40: 00000000 00000000 c005ef74 ce310000 c0435cf0 ce311ebc 00000
 1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 00000
 1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 ffff8
 1ea0: c08ba040 c033364c ce311ecc c0433b50 00000002 ffffffea c0330
 1ec0: 0007a120 0007a120 22222201 00000000 22222222 00000000 ce357
 1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 00000002 c032f47c 00034
 1f00: c0331cac ce352b40 00000007 c032f6d0 ce352bbc 0003d090 c0930
 1f20: c093d8bc c03306a4 00000007 ce311f80 00000007 cdc2aec0 ce358
 1f40: ce8d20c0 00000007 b6fe5000 ce311f80 00000007 ce310000 0000c
 1f60: c000de74 ce987400 ce8d20c0 b6fe5000 00000000 00000000 0000c
 1f80: 00000000 00000000 001fbac8 00000000 00000007 001fbac8 00004
 1fa0: c000df04 c000dd60 00000007 001fbac8 00000001 b6fe5000 00000
 1fc0: 00000007 001fbac8 00000007 00000004 b6fe5000 00000000 00202
 1fe0: 00000000 beb565f8 00101ffc 00008e8c 60000010 00000001 00000
 [<c001382c>] (twd_update_frequency+0x34/0x48) from [<c008ac4c>] )
 [<c008ac4c>] (smp_call_function_single+0x17c/0x1c8) from [<c0013)
 [<c0013890>] (twd_cpufreq_transition+0x24/0x30) from [<c0437c4c>)
 [<c0437c4c>] (notifier_call_chain+0x44/0x84) from [<c005efe4>] ()
 [<c005efe4>] (__srcu_notifier_call_chain+0x70/0xa4) from [<c005f)
 [<c005f030>] (srcu_notifier_call_chain+0x18/0x20) from [<c032fe2)
 [<c032fe2c>] (cpufreq_notify_transition+0xc8/0x1b0) from [<c0333)
 [<c033364c>] (omap_target+0x1b4/0x28c) from [<c032f47c>] (__cpuf)
 [<c032f47c>] (__cpufreq_driver_target+0x50/0x64) from [<c0331d24)
 [<c0331d24>] (cpufreq_set+0x78/0x98) from [<c032f6d0>] (store_sc)
 [<c032f6d0>] (store_scaling_setspeed+0x5c/0x74) from [<c03306a4>)
 [<c03306a4>] (store+0x58/0x74) from [<c014d868>] (sysfs_write_fi)
 [<c014d868>] (sysfs_write_file+0x80/0xb4) from [<c00f2c2c>] (vfs)
 [<c00f2c2c>] (vfs_write+0xa8/0x138) from [<c00f2e9c>] (sys_write)
 [<c00f2e9c>] (sys_write+0x40/0x6c) from [<c000dd60>] (ret_fast_s)
 Code: e594300c e792210c e1a01000 e5840004 (e7930002)
 ---[ end trace 5da3b5167c1ecdda ]---
Reported-by: NKevin Hilman <khilman@ti.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      910ba598