Skip to content
  1. Dec 10, 2010
  2. Dec 01, 2010
  3. Nov 30, 2010
  4. Nov 01, 2010
  5. Oct 30, 2010
    • Yinghai Lu's avatar
      x86: Check irq_remapped instead of remapping_enabled in destroy_irq() · 7b79462a
      Yinghai Lu authored
      
      
      Russ Anderson reported:
      | There is a regression that is causing a NULL pointer dereference
      | in free_irte when shutting down xpc. git bisect narrowed it down
      | to git commit d585d060(intr_remap: Simplify the code further), which
      | changed free_irte(). Reverse applying the patch fixes the problem.
      
      We need to use irq_remapped() for each irq instead of checking only
      intr_remapping_enabled as there might be non remapped irqs even when
      remapping is enabled.
      
      [ tglx: use cfg instead of retrieving it again. Massaged changelog ]
      
      Reported-bisected-and-tested-by: default avatarRuss Anderson <rja@sgi.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <4CCBD511.40607@kernel.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      7b79462a
  6. Oct 29, 2010
    • Vasily Khoruzhick's avatar
      ARM: h1940: add UDA1380 to i2c devices list · 68730b45
      Vasily Khoruzhick authored
      
      
      Register UDA1380 codec during H1940 machine init
      
      Signed-off-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      68730b45
    • Vasily Khoruzhick's avatar
      ARM: h1940: Fix backlight and LCD power functions · 53193dd3
      Vasily Khoruzhick authored
      
      
      Current implementation of LCD and backlight power control functions
      is not complete, as result PDA consumes power in suspend.
      Fix this issue by managing state of some latch bits, just like
      WinMobile does.
      
      Signed-off-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      53193dd3
    • Jason Baron's avatar
      x86, alternative: Call stop_machine_text_poke() on all cpus · 404ba5d7
      Jason Baron authored
      
      
      Currently, text_poke_smp() passes a NULL as the third argument to
      __stop_machine(), which will only run stop_machine_text_poke()
      on 1 cpu. Change NULL -> cpu_online_mask, as stop_machine_text_poke()
      is intended to be run on all cpus.
      
      I actually didn't notice any problems with stop_machine_text_poke()
      only being called on 1 cpu, but found this via code inspection.
      
      Signed-off-by: default avatarJason Baron <jbaron@redhat.com>
      LKML-Reference: <20101028152026.GB2875@redhat.com>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      404ba5d7
    • Abdoulaye Walsimou Gaye's avatar
      ARM: S3C2440: fix boot failure introduced by recent changes in gpiolib · bdf5005b
      Abdoulaye Walsimou Gaye authored
      
      
      Recent changes in s3c gpio break mini2440 board and may be others.
      The problem is that mach-mini2440.c: mini2440_init()
      (where we call s3c_gpio_setpull()) is called before s3c2440.c: s3c2440_init()
      (where we initialize s3c24xx_gpiocfg_default.set_pull function pointer).
      This causes dereferencing of NULL pointer at boot time and a kernel panic.
      
      Signed-off-by: default avatarAbdoulaye Walsimou Gaye <awg@embtoolkit.org>
      
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-samsung-soc@vger.kernel.org
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      bdf5005b
    • Abdoulaye Walsimou Gaye's avatar
      ARM: S3C2440: various fixes in Kconfig file · e33ffd4d
      Abdoulaye Walsimou Gaye authored
      
      
      * kconfig symbols defined in arch/arm/mach-s3c2440/Kconfig are only available
        when ARCH_S3C2410 is selected, so no need to make some of them depend
        on ARCH_S3C2410.
      * fix CPU_S3C24405B typo in "config S3C2440_DMA".
      * mini2440: remove unconditionally select of SND_S3C24XX_SOC_S3C24XX_UDA134X.
      Those fixes avoid the following warnings at make time:
      
      scripts/kconfig/qconf arch/arm/Kconfig
      warning: (MACH_MINI2440 && ARCH_S3C2410) selects SND_S3C24XX_SOC_S3C24XX_UDA134X
      which has unmet direct dependencies (SND_S3C24XX_SOC && ARCH_S3C2410)
      warning: (CPU_S3C2440 && ARCH_S3C2410 && S3C2410_DMA) selects S3C2440_DMA which
      has unmet direct dependencies (ARCH_S3C2410 && CPU_S3C24405B)
      warning: (CPU_S3C2440 && ARCH_S3C2410 || CPU_S3C2442 && ARCH_S3C2410)
      selects CPU_S3C244X which has unmet direct dependencies (!ARCH_S3C2410)
      
      Signed-off-by: default avatarAbdoulaye Walsimou Gaye <awg@embtoolkit.org>
      
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-samsung-soc@vger.kernel.org
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      e33ffd4d
    • Daniel Walker's avatar
      msm: Kconfig: drop unused config options · 4ee7a6c2
      Daniel Walker authored
      
      
      These two config options don't exist, and aren't ever going to.
      So I simply delete them.
      
      Signed-off-by: default avatarDaniel Walker <dwalker@codeaurora.org>
      4ee7a6c2
    • Daniel Walker's avatar
      msm: fix compile failure when no debug uart is selected · 06125ff0
      Daniel Walker authored
      
      
      If the board has a debug uart the user is given a choice of which
      uart to use. The user can also select NONE, which means not to use one.
      In most of our header files when NONE is selected nothing is defined
      for MSM_DEBUG_UART_PHYS or MSM_DEBUG_UART_BASE. This causes a compile
      failure in debug-macro.S which expect something to be defined there.
      
      Example of the failure,
      
      arch/arm/kernel/built-in.o: In function `hexbuf':
      linux-2.6/arch/arm/kernel/debug.S:186: undefined reference to `MSM_DEBUG_UART_PHYS'
      linux-2.6/arch/arm/kernel/debug.S:186: undefined reference to `MSM_DEBUG_UART_BASE'
      
      This fixes the compile failure by adding an ifdef to debug-macro.S
      that removes all the debug uart code in the case of NONE.
      
      Signed-off-by: default avatarDaniel Walker <dwalker@codeaurora.org>
      06125ff0
    • Daniel Walker's avatar
      msm: fix debug-macro.S build failure · bcd72c3e
      Daniel Walker authored
      
      
      Originally there was an ifdef case to handle when no debug uart
      was selected. In commit 0ea12930
      that case was removed which causes the following build failure,
      
      linux-2.6/arch/arm/kernel/debug.S: Assembler messages:
      linux-2.6/arch/arm/kernel/debug.S:174: Error: bad instruction `addruart r1,r2'
      linux-2.6/arch/arm/kernel/debug.S:176: Error: bad instruction `waituart r2,r3'
      linux-2.6/arch/arm/kernel/debug.S:177: Error: bad instruction `senduart r1,r3'
      linux-2.6/arch/arm/kernel/debug.S:178: Error: bad instruction `busyuart r2,r3'
      linux-2.6/arch/arm/kernel/debug.S:190: Error: bad instruction `addruart r1,r2'
      
      This is a partial revert to add back the case which was removed with
      two caveats. First the API for the addruart macro was updated, and
      the new addruart case now return 0xfff00000 so that a know IO mapping
      is created instead of a random one.
      
      Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Jason Wang <jason77.wang@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: default avatarDaniel Walker <dwalker@codeaurora.org>
      bcd72c3e
    • Steven Rostedt's avatar
      jump label: Add work around to i386 gcc asm goto bug · 45f81b1c
      Steven Rostedt authored
      On i386 (not x86_64) early implementations of gcc would have a bug
      with asm goto causing it to produce code like the following:
      
      (This was noticed by Peter Zijlstra)
      
         56 pushl 0
         67 nopl         jmp 0x6f
            popl
            jmp 0x8c
      
         6f              mov
                         test
                         je 0x8c
      
         8c mov
            call *(%esp)
      
      The jump added in the asm goto skipped over the popl that matched
      the pushl 0, which lead up to a quick crash of the system when
      the jump was enabled. The nopl is defined in the asm goto () statement
      and when tracepoints are enabled, the nop changes to a jump to the label
      that was specified by the asm goto. asm goto is suppose to tell gcc that
      the code in the asm might jump to an external label. Here gcc obviously
      fails to make that work.
      
      The bug report for gcc is here:
      
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226
      
      
      
      The bug only appears on x86 when not compiled with
      -maccumulate-outgoing-args. This option is always set on x86_64 and it
      is also the work around for a function graph tracer i386 bug.
      (See commit: 746357d6)
      This explains why the bug only showed up on i386 when function graph
      tracer was not enabled.
      
      This patch now adds a CONFIG_JUMP_LABEL option that is default
      off instead of using jump labels by default. When jump labels are
      enabled, the -maccumulate-outgoing-args will be used (causing a
      slightly larger kernel image on i386). This option will exist
      until we have a way to detect if the gcc compiler in use is safe
      to use on all configurations without the work around.
      
      Note, there exists such a test, but for now we will keep the enabling
      of jump label as a manual option.
      
      Archs that know the compiler is safe with asm goto, may choose to
      select JUMP_LABEL and enable it by default.
      
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Cause-discovered-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Richard Henderson <rth@redhat.com>
      LKML-Reference: <1288028746.3673.11.camel@laptop>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      45f81b1c
    • Dongdong Deng's avatar
      kgdb,ppc: Individual register get/set for ppc · ff10b88b
      Dongdong Deng authored
      
      
      commit 534af108(kgdb,kdb: individual
      register set and and get API) introduce dbg_get_reg/dbg_set_reg API
      for individual register get and set.
      
      This patch implement those APIs for ppc.
      
      Signed-off-by: default avatarDongdong Deng <dongdong.deng@windriver.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      ff10b88b
    • Dongdong Deng's avatar
      debug_core,x86,blackfin: Clean up hw debug disable API · d7ba979d
      Dongdong Deng authored
      
      
      The kgdb_disable_hw_debug() was an architecture specific function for
      disabling all hardware breakpoints on a per cpu basis when entering
      the debug core.
      
      This patch will remove the weak function kdbg_disable_hw_debug() and
      change it into a call back which lives with the rest of hw breakpoint
      call backs in struct kgdb_arch.
      
      Signed-off-by: default avatarDongdong Deng <dongdong.deng@windriver.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      d7ba979d
    • Rabin Vincent's avatar
      kgdb,arm: fix register dump · 834b2964
      Rabin Vincent authored
      
      
      DBG_MAX_REG_NUM incorrectly had the number of indices in the GDB regs
      array rather than the number of registers, leading to an oops when the
      "rd" command is used in KDB.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      834b2964
    • Wu Zhangjin's avatar
      ftrace/MIPS: Enable C Version of recordmcount · 64575f91
      Wu Zhangjin authored
      
      
      Selects HAVE_C_RECORDMCOUNT to use the C version of the recordmcount
      intead of the old Perl Version of recordmcount.
      
      Signed-off-by: default avatarWu Zhangjin <wuzhangjin@gmail.com>
      LKML-Reference: <bb99009a9ac79d3f55a8c8bf1c8bd2bc0e1f160e.1288176026.git.wuzhangjin@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      64575f91
    • David Daney's avatar
      MIPS: Make TASK_SIZE reflect proper size for both 32 and 64 bit processes. · 949e51be
      David Daney authored
      
      
      The TASK_SIZE macro should reflect the size of a user process virtual
      address space.  Previously for 64-bit kernels, this was not the case.
      The immediate cause of pain was in
      hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes
      trying to mmap a huge page would be served a page with an address
      outside of the 32-bit address range.  But there are other uses of
      TASK_SIZE in the kernel as well that would like an accurate value.
      
      The new definition is nice because it now makes TASK_SIZE and
      TASK_SIZE_OF() yield the same value for any given process.
      
      For 32-bit kernels there should be no change, although I did factor
      out some code in asm/processor.h that became identical for the 32-bit and
      64-bit cases.
      
      __UA_LIMIT is now set to ~((1 << SEGBITS) - 1) for 64-bit kernels.
      This should eliminate the possibility of getting a
      AddressErrorException in the kernel for addresses that pass the
      access_ok() test.
      
      With the patch applied, I can still run o32, n32 and n64 processes,
      and have an o32 shell fork/exec both n32 and n64 processes.
      
      Signed-off-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
      To: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/1701/
      949e51be
Loading