1. 26 Mar, 2014 1 commit
  2. 24 Mar, 2014 2 commits
  3. 23 Mar, 2014 3 commits
  4. 20 Mar, 2014 1 commit
    • Jim Quinlan's avatar
      MIPS: Make local_irq_disable macro safe for non-Mipsr2 · 71ca7588
      Jim Quinlan authored
      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: default avatarJim 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: default avatarRalf Baechle <ralf@linux-mips.org>
      71ca7588
  5. 19 Mar, 2014 3 commits
    • Andreas Herrmann's avatar
      MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx · 2eddb708
      Andreas Herrmann authored
      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: default avatarAndreas Herrmann <andreas.herrmann@caviumnetworks.com>
      Reported-by: default avatarYang Wei <wei.yang@windriver.com>
      Acked-by: default avatarDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6624/
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      2eddb708
    • Viller Hsiao's avatar
      MIPS: ftrace: Tweak safe_load()/safe_store() macros · b08ac66b
      Viller Hsiao authored
      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: default avatarViller 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: default avatarRalf Baechle <ralf@linux-mips.org>
      b08ac66b
    • Rafał Miłecki's avatar
      MIPS: BCM47XX: Check all (32) GPIOs when looking for a pin · 4fe2169a
      Rafał Miłecki authored
      
      
      Broadcom boards support 32 GPIOs and NVRAM may have entires for higher
      ones too. Example:
      gpio23=wombo_reset
      Signed-off-by: default avatarRafa? Mi?ecki <zajec5@gmail.com>
      Acked-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Cc: linux-mips@linux-mips.org
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/6547/
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      4fe2169a
  6. 18 Mar, 2014 2 commits
    • Bjorn Helgaas's avatar
      Revert "[PATCH] Insert GART region into resource map" · 707d4eef
      Bjorn Helgaas authored
      This reverts commit 56dd669a, which makes the GART visible in
      /proc/iomem.  This fixes a regression: e501b3d8 ("agp: Support 64-bit
      APBASE") exposed an existing problem with a conflict between the GART
      region and a PCI BAR region.
      
      The GART addresses are bus addresses, not CPU addresses, and therefore
      should not be inserted in iomem_resource.
      
      On many machines, the GART region is addressable by the CPU as well as by
      an AGP master, but CPU addressability is not required by the spec.  On some
      of these machines, the GART is mapped by a PCI BAR, and in that case, the
      PCI core automatically inserts it into iomem_resource, just as it does for
      all BARs.
      
      Inserting it here means we'll have a conflict if the PCI core later tries
      to claim the GART region, so let's drop the insertion here.
      
      The conflict indirectly causes X failures, as reported by Jouni in the
      bugzilla below.  We detected the conflict even before e501b3d8, but
      after it the AGP code (fix_northbridge()) uses the PCI resource (which is
      zeroed because of the conflict) instead of reading the BAR again.
      
      Conflicts:
      	arch/x86_64/kernel/aperture.c
      
      Fixes: e501b3d8 agp: Support 64-bit APBASE
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
      
      Reported-and-tested-by: default avatarJouni Mettälä <jtmettala@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      707d4eef
    • Alex Smith's avatar
      MIPS: Fix possible build error with transparent hugepages enabled · e4362d1e
      Alex Smith authored
      
      
      If CONFIG_TRANSPARENT_HUGEPAGE is enabled, but CONFIG_HUGETLB_PAGE is not,
      it is possible to end up with a configuration that fails to build with the
      following error:
      
      include/linux/huge_mm.h:125:2: error: #error "hugepages can't be allocated by the buddy allocator"
      
      This is due to CONFIG_FORCE_MAX_ZONEORDER defaulting to 11. It already has
      ranges that change the valid values when HUGETLB_PAGE is enabled, but this
      is not done for TRANSPARENT_HUGEPAGE. Fix by changing the HUGETLB_PAGE
      dependencies to MIPS_HUGE_TLB_SUPPORT, which includes both
      TRANSPARENT_HUGEPAGE and HUGETLB_PAGE.
      Signed-off-by: default avatarAlex Smith <alex.smith@imgtec.com>
      Reviewed-by: default avatarMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6391/
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e4362d1e
  7. 17 Mar, 2014 6 commits
  8. 14 Mar, 2014 4 commits
  9. 13 Mar, 2014 2 commits
  10. 12 Mar, 2014 2 commits
  11. 11 Mar, 2014 7 commits
  12. 08 Mar, 2014 1 commit
    • Linus Torvalds's avatar
      x86: fix compile error due to X86_TRAP_NMI use in asm files · b01d4e68
      Linus Torvalds authored
      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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b01d4e68
  13. 07 Mar, 2014 6 commits