1. 31 3月, 2014 1 次提交
  2. 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
  3. 19 3月, 2014 1 次提交
  4. 18 3月, 2014 1 次提交
  5. 17 3月, 2014 4 次提交
  6. 15 3月, 2014 3 次提交
  7. 12 3月, 2014 1 次提交
  8. 07 3月, 2014 6 次提交
  9. 06 2月, 2014 1 次提交
  10. 04 2月, 2014 2 次提交
  11. 25 1月, 2014 17 次提交