1. 26 3月, 2014 4 次提交
  2. 25 3月, 2014 1 次提交
  3. 24 3月, 2014 1 次提交
  4. 23 3月, 2014 2 次提交
  5. 20 3月, 2014 3 次提交
    • J
      MIPS: Make local_irq_disable macro safe for non-Mipsr2 · 71ca7588
      Jim Quinlan 提交于
      For non-mipsr2 processors, the local_irq_disable contains an mfc0-mtc0
      pair with instructions inbetween.  With preemption enabled, this sequence
      may get preempted and effect a stale value of CP0_STATUS when executing
      the mtc0 instruction.  This commit avoids this scenario by incrementing
      the preempt count before the mfc0 and decrementing it after the mtc9.
      
      [ralf@linux-mips.org: This patch is sorting out the part that were missed
      by e97c5b60 [MIPS: Make irqflags.h functions preempt-safe for non-mipsr2
      cpus.]  I also re-enabled the inclusion of <asm/asm-offsets.h> at the top
      of <asm/asmmacro.h>].
      Signed-off-by: NJim Quinlan <jim2101024@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: cernekee@gmail.com
      Patchwork: https://patchwork.linux-mips.org/patch/6164/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      71ca7588
    • A
      MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx · 2eddb708
      Andreas Herrmann 提交于
      Starting with commit 3da52787 (of/irq:
      Rework of_irq_count()) the following warning is triggered on octeon
      cn3xxx:
      
      [    0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230()
      [    0.895642] Modules linked in:
      [    0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41
      [    0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc
      [    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 000000000000000b
      [    0.906860] 	  000000000000000a 000000000000000a 0000000000000000 0000000000000000
      [    0.906860] 	  ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177
      [    0.906860] 	  ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000
      [    0.906860] 	  0000000000000000 0000000000000038 0000000000000001 ffffffff81568484
      [    0.906860] 	  800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4
      [    0.906860] 	  800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c
      [    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [    0.906860] 	  0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000
      [    0.906860] 	  ...
      [    0.971695] Call Trace:
      [    0.974139] [<ffffffff811205e0>] show_stack+0x68/0x80
      [    0.979183] [<ffffffff81569c9c>] dump_stack+0x8c/0xe0
      [    0.984196] [<ffffffff81145efc>] warn_slowpath_common+0x84/0xb8
      [    0.990110] [<ffffffff81436888>] of_device_alloc+0x228/0x230
      [    0.995726] [<ffffffff814368d8>] of_platform_device_create_pdata+0x48/0xd0
      [    1.002593] [<ffffffff81436a94>] of_platform_bus_create+0x134/0x1e8
      [    1.008837] [<ffffffff81436af8>] of_platform_bus_create+0x198/0x1e8
      [    1.015064] [<ffffffff81436cc4>] of_platform_bus_probe+0xa4/0x100
      [    1.021149] [<ffffffff81100570>] do_one_initcall+0xd8/0x128
      [    1.026701] [<ffffffff816e2a10>] kernel_init_freeable+0x144/0x210
      [    1.032753] [<ffffffff81564bc4>] kernel_init+0x14/0x110
      [    1.037973] [<ffffffff8111bb44>] ret_from_kernel_thread+0x14/0x1c
      
      With this commit the kernel starts mapping the interrupts listed for
      gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and
      octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL)
      and this is causing above warning in of_device_alloc().
      
      Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO
      lines (neither return error code nor call octeon_irq_set_ciu_mapping
      for it). This should avoid the warning.
      
      (As before the real setup for GPIO lines will happen using
      irq_domain_ops of gpio-controller.)
      
      This patch is based on Wei's patch v2 (see
      http://marc.info/?l=linux-mips&m=139511814813247).
      Signed-off-by: NAndreas Herrmann <andreas.herrmann@caviumnetworks.com>
      Reported-by: NYang Wei <wei.yang@windriver.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6624/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2eddb708
    • V
      MIPS: ftrace: Tweak safe_load()/safe_store() macros · b08ac66b
      Viller Hsiao 提交于
      Due to name collision in ftrace safe_load and safe_store macros,
      these macros cannot take expressions as operands.
      
      For example, compiler will complain for a macro call like the following:
        safe_store_code(new_code2, ip + 4, faulted);
      
        arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
           : [dst] "r" (dst), [src] "r" (src)\
              ^
        arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
          safe_store_code(new_code2, ip + 4, faulted);
          ^
        arch/mips/kernel/ftrace.c:118:32: error: undefined named operand 'ip + 4'
          safe_store_code(new_code2, ip + 4, faulted);
                                        ^
        arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
           : [dst] "r" (dst), [src] "r" (src)\
              ^
        arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
          safe_store_code(new_code2, ip + 4, faulted);
          ^
      
      This build error is triggered by a4671094 [MIPS: ftrace: Fix icache flush
      range error].  Tweak variable naming in those macros to allow flexible
      operands.
      Signed-off-by: NViller Hsiao <villerhsiao@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: fweisbec@gmail.com
      Cc: mingo@redhat.com
      Cc: Qais.Yousef@imgtec.com
      Patchwork: https://patchwork.linux-mips.org/patch/6622/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b08ac66b
  6. 19 3月, 2014 2 次提交
  7. 18 3月, 2014 3 次提交
  8. 17 3月, 2014 4 次提交
  9. 15 3月, 2014 3 次提交
  10. 14 3月, 2014 1 次提交
  11. 13 3月, 2014 3 次提交
  12. 12 3月, 2014 5 次提交
  13. 11 3月, 2014 3 次提交
  14. 08 3月, 2014 5 次提交
    • L
      x86: fix compile error due to X86_TRAP_NMI use in asm files · b01d4e68
      Linus Torvalds 提交于
      It's an enum, not a #define, you can't use it in asm files.
      
      Introduced in commit 5fa10196 ("x86: Ignore NMIs that come in during
      early boot"), and sadly I didn't compile-test things like I should have
      before pushing out.
      
      My weak excuse is that the x86 tree generally doesn't introduce stupid
      things like this (and the ARM pull afterwards doesn't cause me to do a
      compile-test either, since I don't cross-compile).
      
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b01d4e68
    • H
      x86: Ignore NMIs that come in during early boot · 5fa10196
      H. Peter Anvin 提交于
      Don Zickus reports:
      
      A customer generated an external NMI using their iLO to test kdump
      worked.  Unfortunately, the machine hung.  Disabling the nmi_watchdog
      made things work.
      
      I speculated the external NMI fired, caused the machine to panic (as
      expected) and the perf NMI from the watchdog came in and was latched.
      My guess was this somehow caused the hang.
      
         ----
      
      It appears that the latched NMI stays latched until the early page
      table generation on 64 bits, which causes exceptions to happen which
      end in IRET, which re-enable NMI.  Therefore, ignore NMIs that come in
      during early execution, until we have proper exception handling.
      Reported-and-tested-by: NDon Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v3.5+, older with some backport effort
      5fa10196
    • M
      ARM: 7992/1: boot: compressed: ignore bswapsdi2.S · 38e0b088
      Mark Rutland 提交于
      Commit 017f161a (ARM: 7877/1: use built-in byte swap function) added
      bswapsdi2.{o,S} to arch/arm/boot/compressed/Makefile, but didn't update
      the .gitignore. Thus after a a build git status shows bswapsdi2.S as a
      new file, which is a little annoying.
      
      This patch updates arch/arm/boot/compressed/.gitignore to ignore
      bswapsdi2.S, as we already do for ashldi3.S and others.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NKim Phillips <kim.phillips@freescale.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      38e0b088
    • L
      ARM: 7991/1: sa1100: fix compile problem on Collie · 052450fd
      Linus Walleij 提交于
      Due to a problem in the MFD Kconfig it was not possible to
      compile the UCB battery driver for the Collie SA1100 system,
      in turn making it impossible to compile in the battery driver.
      (See patch "mfd: include all drivers in subsystem menu".)
      
      After fixing the MFD Kconfig (separate patch) a compile error
      appears in the Collie battery driver due to the <mach/collie.h>
      implicitly requiring <mach/hardware.h> through <linux/gpio.h>
      via <mach/gpio.h> prior to commit
      40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".
      
      Fix this up by including the required header into
      <mach/collie.h>.
      
      Cc: stable@vger.kernel.org
      Cc: Andrea Adami <andrea.adami@gmail.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      052450fd
    • R
      ARM: fix noMMU kallsyms symbol filtering · 006fa259
      Russell King 提交于
      With noMMU, CONFIG_PAGE_OFFSET was not being set correctly.  As there's
      no MMU, PAGE_OFFSET should be equal to PHYS_OFFSET in all cases.  This
      commit makes that explicit.
      
      Since we do this, we don't need to mess around in asm/memory.h with
      ifdefs to sort this out, so let's get rid of that, and there's no point
      offering the "Memory split" option for noMMU as that's meaningless
      there.
      
      Fixes: b9b32bf7 ("ARM: use linker magic for vectors and vector stubs")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      006fa259
新手
引导
客服 返回
顶部