Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 2月, 2011 6 次提交
  3. 16 2月, 2011 1 次提交
  5. 01 2月, 2011 1 次提交
  7. 31 1月, 2011 3 次提交
  9. 28 1月, 2011 5 次提交
  11. 27 1月, 2011 5 次提交
  13. 26 1月, 2011 9 次提交
  15. 25 1月, 2011 5 次提交
    • R
      ARM: versatile: name configuration options after actual board names · e5310f61
      由 Russell King 提交于 
      Update the option text to those which appear on the front of the
appropriate board user guides.  This gives consistent board naming, and
makes it obvious which option is for which platform.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e5310f61
    • R
      ARM: realview: name configuration options after actual board names · d2a1c9ad
      由 Russell King 提交于 
      As no one seems to really know which configuration options tie up with
which boards, I thought I'd do some investigation and try to work it
out.  After discussion with some folk in linaro, I think I have this
nailed.

The names are updated to use the name on the front of the appropriate
board user guide for the various baseboards, which I've taken to be
the official name for each board.

I haven't significantly updated the descriptions for the tiles as that
is even less clear - as far as I can see on ARMs website, there is no
Cortex-A9 tile for Realview EB - only ARM11MPCore, ARM1156T2F-S,
ARM1176TZF-S and Cortex-R4F.  So exactly what this 'Multicore Cortex-A9
Tile' is...
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d2a1c9ad
    • R
      ARM: realview,vexpress: fix section mismatch warning for pen_release · ec15038f
      由 Russell King 提交于 
      Fix two section mismatch warnings in the platform SMP bringup code for
Realview and Versatile Express:

WARNING: arch/arm/mach-realview/built-in.o(.text+0x8ac): Section mismatch in reference from the function write_pen_release() to the variable .cpuinit.data:pen_release
The function write_pen_release() references
the variable __cpuinitdata pen_release.
This is often because write_pen_release lacks a __cpuinitdata
annotation or the annotation of pen_release is wrong.

WARNING: arch/arm/mach-vexpress/built-in.o(.text+0x7b4): Section mismatch in reference from the function write_pen_release() to the variable .cpuinit.data:pen_release
The function write_pen_release() references
the variable __cpuinitdata pen_release.
This is often because write_pen_release lacks a __cpuinitdata
annotation or the annotation of pen_release is wrong.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ec15038f
    • N
      sh: Fix build of sh7750 base boards · 75a9fa0a
      由 Nobuhiro Iwamatsu 提交于 
      Renamed platform_register_device to platform_device_register.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      75a9fa0a
    • J
      x86-64: Don't use pointer to out-of-scope variable in dump_trace() · 2e5aa682
      由 Jesper Juhl 提交于 
      In arch/x86/kernel/dumpstack_64.c::dump_trace() we have this code:

...
  		if (!stack) {
  			unsigned long dummy;
  			stack = &dummy;
  			if (task && task != current)
  				stack = (unsigned long *)task->thread.sp;
  		}

  		bp = stack_frame(task, regs);
  		/*
  		 * Print function call entries in all stacks, starting at the
  		 * current stack address. If the stacks consist of nested
  		 * exceptions
  		 */
  		tinfo = task_thread_info(task);

  		for (;;) {
  			char *id;
  			unsigned long *estack_end;
  			estack_end = in_exception_stack(cpu, (unsigned long)stack,
  							&used, &id);
...

You'll notice that we assign to 'stack' the address of the variable
'dummy' which is only in-scope inside the 'if (!stack)'. So when we later
access stack (at the end of the above, and assuming we did not take the
'if (task && task != current)' branch) we'll be using the address of a
variable that is no longer in scope. I believe this patch is the proper
fix, but I freely admit that I'm not 100% certain.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
LKML-Reference: <alpine.LNX.2.00.1101242232590.10252@swampdragon.chaosbits.net>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      2e5aa682
  17. 23 1月, 2011 4 次提交
    • M
      x86: Fix jump label with RO/NX module protection crash · 89696913
      由 matthieu castet 提交于 
      If we use jump table in module init, there are marked
as removed in __jump_table section after init is done.

But we already applied ro permissions on the module, so
we can't modify a read only section (crash in
remove_jump_label_module_init).

Make the __jump_table section rw.
Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
Cc: Xiaotian Feng <xtfeng@gmail.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Siarhei Liakh <sliakh.lkml@gmail.com>
Cc: Xuxian Jiang <jiang@cs.ncsu.edu>
Cc: James Morris <jmorris@namei.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Dave Jones <davej@redhat.com>
Cc: Kees Cook <kees.cook@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4D3C3F20.7030203@free.fr>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89696913
    • G
      m68k/amiga: Fix "debug=mem" · 5df1abdb
      由 Geert Uytterhoeven 提交于 
      `debug=mem' on Amiga has been broken for a while.
early_param() processing is done very/too early, i.e. before
amiga_identify() / amiga_chip_init(), causing amiga_savekmsg_setup() not
to find any Chip RAM.

As we don't plan to free this memory anyway, just steal it from the initial
Chip RAM memory block instead.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      5df1abdb
    • G
      m68k/atari: Rename "scc" to "atari_scc" · de339e4b
      由 Geert Uytterhoeven 提交于 
      It's a way too generic name for a global #define and conflicts with a variable
with the same name, causing build errors like:

| drivers/staging/brcm80211/brcmfmac/../util/siutils.c: In function ‘_si_clkctl_cc’:
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected identifier or ‘(’ before ‘volatile’
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected ‘)’ before ‘(’ token
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1421: error: incompatible types in assignment
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1422: error: invalid operands to binary &
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1423: error: invalid operands to binary &
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1424: error: invalid operands to binary |
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: incompatible type for argument 4 of ‘bcmsdh_reg_write’
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1428: error: invalid operands to binary &
| make[8]: *** [drivers/staging/brcm80211/brcmfmac/../util/siutils.o] Error 1
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      de339e4b
    • G
      m68k: Uninline strchr() · f9b07897
      由 Geert Uytterhoeven 提交于 
      Some versions of gcc replace calls to strstr() with single-character
"needle" string parameters by calls to strchr() behind our back.

If strchr() is defined as an inline function, this causes linking errors
like

	ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined!

As m68k is the only architecture that has an inline strchr() and this
inline version is not an optimized asm version, uninline strchr() and use
the standard out-of-line C version in lib/string.c instead.

This also decreases the defconfig/allmodconfig kernel image sizes by a few
hundred bytes.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      f9b07897
  19. 22 1月, 2011 1 次提交
    • B
      x86, hotplug: Fix powersavings with offlined cores on AMD · 93789b32
      由 Borislav Petkov 提交于 
      ea530692 made a CPU use monitor/mwait
when offline. This is not the optimal choice for AMD wrt to powersavings
and we'd prefer our cores to halt (i.e. enter C1) instead. For this, the
same selection whether to use monitor/mwait has to be used as when we
select the idle routine for the machine.

With this patch, offlining cores 1-5 on a X6 machine allows core0 to
boost again.

[ hpa: putting this in urgent since it is a (power) regression fix ]
Reported-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@kernel.org # 37.x
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.hl>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
LKML-Reference: <1295534572-10730-1-git-send-email-bp@amd64.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      93789b32