1. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      Ralf Baechle 提交于
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
      Which is a pity - the SMTC technology primarily developed by Kevin D.
      Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
      ASE's power and elegance.
      
      Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
      https://patchwork.linux-mips.org/patch/6719/ which while very similar did
      no longer apply cleanly when I tried to merge it plus some additional
      post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
      merge once upon a time.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  2. 01 4月, 2014 1 次提交
  3. 27 3月, 2014 1 次提交
  4. 07 3月, 2014 1 次提交
  5. 23 1月, 2014 2 次提交
  6. 30 10月, 2013 2 次提交
    • M
      MIPS: malta: Fix GIC interrupt offsets · 13b7ea63
      Markos Chandras 提交于
      The GIC interrupt offsets are calculated based on the value of NR_CPUS.
      However, this is wrong because NR_CPUS may or may not contain the real
      number of the actual cpus present in the system. We fix that by using
      the 'nr_cpu_ids' variable which contains the real number of cpus in
      the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
      NR_CPUS was > 8 with the following errors:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164()
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W    3.12.0-rc5-00087-gced5633 5
      Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053
                807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000
                00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000
                00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4
                807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0
                ...
      Call Trace:
      [<801098c0>] show_stack+0x64/0x7c
      [<8049c6b0>] dump_stack+0x64/0x84
      [<8012efc4>] warn_slowpath_common+0x84/0xb4
      [<8012f00c>] warn_slowpath_null+0x18/0x24
      [<80173218>] __irq_set_handler+0x15c/0x164
      [<80587cf4>] arch_init_ipiirq+0x2c/0x3c
      [<805880c8>] arch_init_irq+0x3c4/0x4bc
      [<80588e28>] init_IRQ+0x3c/0x50
      [<805847e8>] start_kernel+0x230/0x3d8
      
      ---[ end trace 4eaa2a86a8e2da26 ]---
      
      This is now fixed and the Malta board can boot with any NR_CPUS value
      which also helps supporting more processors in a single kernel binary.
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6091/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      13b7ea63
    • D
      MIPS: Remove unused defines in piix4.h · 40b15b28
      Deng-Cheng Zhu 提交于
      The PIIX4_ICTLR* and PIIX4_OCW* defines are not used by any other files.
      Remove them.
      
      The only file (other than fixup-malta.c which includes piix4.h in patch #1)
      containing "#include <asm/mips-boards/piix4.h>" is
      arch/mips/mti-malta/malta-int.c whose first version is actually
      "1da177e4:arch/mips/mips-boards/malta/malta_int.c". In that version, in
      the function get_int(), things in piix4.h are used. But now malta-int.c no
      longer needs those stuff.
      Signed-off-by: NDeng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6032/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      40b15b28
  7. 01 7月, 2013 1 次提交
  8. 09 5月, 2013 2 次提交
  9. 01 2月, 2013 1 次提交
  10. 17 9月, 2012 1 次提交
    • R
      MIPS: Malta: Don't crash on spurious interrupt. · e376fdf4
      Ralf Baechle 提交于
      48d480b0 [[MIPS] Malta: Fix off by one bug in interrupt
      handler.] did not take in account that irq_ffs() will also return 0 if for some reason
      the set of pending interrupts happens to be empty.
      
      This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
      in something like the following:
      
      CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
      Oops[#1]:
      Cpu 0
      $ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
      $ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
      $ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
      $12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
      $16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
      $20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
      $24   : 0000000000000028 ffffffff803226e8
      $28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
      Hi    : 0000000000000000
      Lo    : 0000006388974000
      epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
          Not tainted
      ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
      Status: 9000a4e2    KX SX UX KERNEL EXL
      Cause : 00808008
      BadVA : 0000000000000000
      PrId  : 000028a0 (Nevada)
      Modules linked in:
      Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
      Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
              ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
              9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
              ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
              0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
              0000000000000000 9000000018000000 90000000180003f9 0000000000000001
              0000000000000000 00000000000000ff 0000000000000018 0000000000000001
              0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
              ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
              0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
              ...
      Call Trace:
      [<ffffffff801772d0>] handle_irq_event_percpu+0x70/0x2f0
      [<ffffffff8017ad24>] handle_percpu_irq+0x54/0x88
      [<ffffffff801769f4>] generic_handle_irq+0x44/0x60
      [<ffffffff801037f8>] do_IRQ+0x48/0x70
      [<ffffffff80101c44>] ret_from_irq+0x0/0x4
      [<ffffffff80326170>] serial8250_startup+0x310/0x870
      [<ffffffff8032175c>] uart_startup.part.7+0x9c/0x330
      [<ffffffff80321b4c>] uart_open+0x15c/0x1b0
      [<ffffffff80302034>] tty_open+0x1fc/0x720
      [<ffffffff801bffac>] chrdev_open+0x7c/0x180
      [<ffffffff801b9ab8>] do_dentry_open.isra.14+0x288/0x390
      [<ffffffff801bac5c>] nameidata_to_filp+0x5c/0xc0
      [<ffffffff801ca700>] do_last.isra.33+0x330/0x8f0
      [<ffffffff801caf3c>] path_openat+0xbc/0x440
      [<ffffffff801cb3c8>] do_filp_open+0x38/0xa8
      [<ffffffff801bade4>] do_sys_open+0x124/0x218
      [<ffffffff80110538>] handle_sys+0x118/0x13c
      
      Code: 02d5a825  12800012  02a0b02d <de820000> de850008  0040f809  0220202d  0040a82d  40026000
      ---[ end trace 5d8e7b9a86badd2d ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e376fdf4
  11. 14 9月, 2012 1 次提交
  12. 29 3月, 2012 1 次提交
  13. 08 12月, 2011 1 次提交
  14. 21 9月, 2011 1 次提交
  15. 11 5月, 2011 1 次提交
  16. 14 4月, 2011 1 次提交
  17. 29 3月, 2011 1 次提交
  18. 05 10月, 2010 1 次提交
  19. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  20. 27 2月, 2010 1 次提交
  21. 02 11月, 2009 3 次提交
  22. 04 8月, 2009 1 次提交
  23. 03 7月, 2009 3 次提交
  24. 25 6月, 2009 1 次提交
  25. 16 7月, 2008 4 次提交
  26. 29 4月, 2008 2 次提交
  27. 29 1月, 2008 3 次提交