1. 13 12月, 2017 2 次提交
    • M
      MIPS: Factor out NT_PRFPREG regset access helpers · a03fe725
      Maciej W. Rozycki 提交于
      In preparation to fix a commit 72b22bba ("MIPS: Don't assume 64-bit
      FP registers for FP regset") FCSR access regression factor out
      NT_PRFPREG regset access helpers for the non-MSA and the MSA variants
      respectively, to avoid having to deal with excessive indentation in the
      actual fix.
      
      No functional change, however use `target->thread.fpu.fpr[0]' rather
      than `target->thread.fpu.fpr[i]' for FGR holding type size determination
      as there's no `i' variable to refer to anymore, and for the factored out
      `i' variable declaration use `unsigned int' rather than `unsigned' as
      its type, following the common style.
      Signed-off-by: NMaciej W. Rozycki <macro@mips.com>
      Fixes: 72b22bba ("MIPS: Don't assume 64-bit FP registers for FP regset")
      Cc: James Hogan <james.hogan@mips.com>
      Cc: Paul Burton <Paul.Burton@mips.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.15+
      Patchwork: https://patchwork.linux-mips.org/patch/17925/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a03fe725
    • J
      MIPS: CPS: Fix r1 .set mt assembler warning · 17278a91
      James Hogan 提交于
      MIPS CPS has a build warning on kernels configured for MIPS32R1 or
      MIPS64R1, due to the use of .set mt without a prior .set mips{32,64}r2:
      
      arch/mips/kernel/cps-vec.S Assembler messages:
      arch/mips/kernel/cps-vec.S:238: Warning: the `mt' extension requires MIPS32 revision 2 or greater
      
      Add .set MIPS_ISA_LEVEL_RAW before .set mt to silence the warning.
      
      Fixes: 245a7868 ("MIPS: smp-cps: rework core/VPE initialisation")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17699/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      17278a91
  2. 14 11月, 2017 1 次提交
  3. 13 11月, 2017 1 次提交
    • D
      Pass mode to wait_on_atomic_t() action funcs and provide default actions · 5e4def20
      David Howells 提交于
      Make wait_on_atomic_t() pass the TASK_* mode onto its action function as an
      extra argument and make it 'unsigned int throughout.
      
      Also, consolidate a bunch of identical action functions into a default
      function that can do the appropriate thing for the mode.
      
      Also, change the argument name in the bit_wait*() function declarations to
      reflect the fact that it's the mode and not the bit number.
      
      [Peter Z gives this a grudging ACK, but thinks that the whole atomic_t wait
      should be done differently, though he's not immediately sure as to how]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      cc: Ingo Molnar <mingo@kernel.org>
      5e4def20
  4. 09 11月, 2017 4 次提交
    • J
      MIPS/ptrace: Update syscall nr on register changes · de8cd0dc
      James Hogan 提交于
      Update the thread_info::syscall field when registers are modified via
      ptrace to change or cancel the system call being entered.
      
      This is important to allow seccomp and the syscall entry and exit trace
      events to observe the new syscall number changed by the normal ptrace
      hook or seccomp. That includes allowing seccomp's recheck of the system
      call number after SECCOMP_RET_TRACE to notice if the syscall is changed
      to a denied one, which happens in seccomp since commit ce6526e8
      ("seccomp: recheck the syscall after RET_TRACE") in v4.8.
      
      In the process of doing this, the logic to determine whether an indirect
      system call is in progress (i.e. the O32 ABI's syscall()) is abstracted
      into mips_syscall_is_indirect(), and a new mips_syscall_update_nr() is
      used to update the thread_info::syscall based on the register state.
      
      The following ptrace operations are updated:
       - PTRACE_SETREGS (ptrace_setregs()).
       - PTRACE_SETREGSET with NT_PRSTATUS (gpr32_set() and gpr64_set()).
       - PTRACE_POKEUSR with 2/v0 or 4/a0 for indirect syscall
         ([compat_]arch_ptrace()).
      
      Fixes: c2d9f177 ("MIPS: Fix syscall_get_nr for the syscall exit tracing.")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Lars Persson <larper@axis.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16995/
      de8cd0dc
    • J
      MIPS/ptrace: Pick up ptrace/seccomp changed syscalls · b6318a90
      James Hogan 提交于
      The MIPS syscall_trace_enter() allows the system call number to be
      altered or cancelled by a ptrace tracer, via the normal ptrace hook
      (PTRACE_SYSCALL) and changing the system call number register on entry,
      and similarly via seccomp (PTRACE_EVENT_SECCOMP when a seccomp filter
      returns SECCOMP_RET_TRACE).
      
      Be sure to update the syscall local variable if this happens, so that
      seccomp will filter the correct system call number if the normal ptrace
      hook changes it first, and so that if either the normal ptrace hook or
      seccomp change it the correct system call number is passed to the trace
      event.
      
      This won't have any effect until the next commit, which fixes ptrace to
      update thread_info::syscall.
      
      Fixes: c2d9f177 ("MIPS: Fix syscall_get_nr for the syscall exit tracing.")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Lars Persson <lars.persson@axis.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16996/
      b6318a90
    • M
      MIPS: Fix an n32 core file generation regset support regression · 547da673
      Maciej W. Rozycki 提交于
      Fix a commit 7aeb753b ("MIPS: Implement task_user_regset_view.")
      regression, then activated by commit 6a9c001b ("MIPS: Switch ELF
      core dumper to use regsets.)", that caused n32 processes to dump o32
      core files by failing to set the EF_MIPS_ABI2 flag in the ELF core file
      header's `e_flags' member:
      
      $ file tls-core
      tls-core: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), [...]
      $ ./tls-core
      Aborted (core dumped)
      $ file core
      core: ELF 32-bit MSB core file MIPS, MIPS-I version 1 (SYSV), SVR4-style
      $
      
      Previously the flag was set as the result of a:
      
      statement placed in arch/mips/kernel/binfmt_elfn32.c, however in the
      regset case, i.e. when CORE_DUMP_USE_REGSET is set, ELF_CORE_EFLAGS is
      no longer used by `fill_note_info' in fs/binfmt_elf.c, and instead the
      `->e_flags' member of the regset view chosen is.  We have the views
      defined in arch/mips/kernel/ptrace.c, however only an o32 and an n64
      one, and the latter is used for n32 as well.  Consequently an o32 core
      file is incorrectly dumped from n32 processes (the ELF32 vs ELF64 class
      is chosen elsewhere, and the 32-bit one is correctly selected for n32).
      
      Correct the issue then by defining an n32 regset view and using it as
      appropriate.  Issue discovered in GDB testing.
      
      Fixes: 7aeb753b ("MIPS: Implement task_user_regset_view.")
      Signed-off-by: NMaciej W. Rozycki <macro@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Djordje Todorovic <djordje.todorovic@rt-rk.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.13+
      Patchwork: https://patchwork.linux-mips.org/patch/17617/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      547da673
    • J
      MIPS: Fix MIPS64 FP save/restore on 32-bit kernels · 22b8ba76
      James Hogan 提交于
      32-bit kernels can be configured to support MIPS64, in which case
      neither CONFIG_64BIT or CONFIG_CPU_MIPS32_R* will be set. This causes
      the CP0_Status.FR checks at the point of floating point register save
      and restore to be compiled out, which results in odd FP registers not
      being saved or restored to the task or signal context even when
      CP0_Status.FR is set.
      
      Fix the ifdefs to use CONFIG_CPU_MIPSR2 and CONFIG_CPU_MIPSR6, which are
      enabled for the relevant revisions of either MIPS32 or MIPS64, along
      with some other CPUs such as Octeon (r2), Loongson1 (r2), XLP (r2),
      Loongson 3A R2.
      
      The suspect code originates from commit 597ce172 ("MIPS: Support for
      64-bit FP with O32 binaries") in v3.14, however the code in
      __enable_fpu() was consistent and refused to set FR=1, falling back to
      software FPU emulation. This was suboptimal but should be functionally
      correct.
      
      Commit fcc53b5f ("MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6
      CPU") in v4.2 (and stable tagged back to 4.0) later introduced the bug
      by updating __enable_fpu() to set FR=1 but failing to update the other
      similar ifdefs to enable FR=1 state handling.
      
      Fixes: fcc53b5f ("MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 4.0+
      Patchwork: https://patchwork.linux-mips.org/patch/16739/
      22b8ba76
  5. 08 11月, 2017 2 次提交
  6. 04 11月, 2017 1 次提交
    • P
      Update MIPS email addresses · fb615d61
      Paul Burton 提交于
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list.  An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb615d61
  7. 02 11月, 2017 5 次提交
    • M
      MIPS: Update email address for Marcin Nowakowski · ca208b5f
      Marcin Nowakowski 提交于
      MIPS is no longer part of Imagination Technologies and my @imgtec.com
      address will soon stop working. Update any files containing my address
      as well as the .mailmap to point to my new @mips.com address.
      Signed-off-by: NMarcin Nowakowski <marcin.nowakowski@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/17579/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      ca208b5f
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
    • J
      MIPS: smp-cmp: Fix vpe_id build error · 7e7bf0ec
      James Hogan 提交于
      The smp-cmp build has been (further) broken since commit 856fbcee
      ("MIPS: Store core & VP IDs in GlobalNumber-style variable") in
      v4.14-rc1 like so:
      
      arch/mips/kernel/smp-cmp.c: In function ‘cmp_init_secondary’:
      arch/mips/kernel/smp-cmp.c:53:4: error: ‘struct cpuinfo_mips’ has no member named ‘vpe_id’
         c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) &
          ^
      
      Fix by replacing vpe_id with cpu_set_vpe_id().
      
      Fixes: 856fbcee ("MIPS: Store core & VP IDs in GlobalNumber-style variable")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17569/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      7e7bf0ec
    • J
      MIPS: smp-cmp: Use right include for task_struct · f677b770
      Jason A. Donenfeld 提交于
      When task_struct was moved, this MIPS code was neglected. Evidently
      nobody is using it anymore. This fixes this build error:
      
      In file included from ./arch/mips/include/asm/thread_info.h:15:0,
                       from ./include/linux/thread_info.h:37,
                       from ./include/asm-generic/current.h:4,
                       from ./arch/mips/include/generated/asm/current.h:1,
                       from ./include/linux/sched.h:11,
                       from arch/mips/kernel/smp-cmp.c:22:
      arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’:
      ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration
      of function ‘task_stack_page’ [-Werror=implicit-function-declaration]
       #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \
                                               ^
      arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’
        unsigned long sp = __KSTK_TOS(idle);
                           ^~~~~~~~~~
      
      Fixes: f3ac6067 ("sched/headers: Move task-stack related APIs from <linux/sched.h> to <linux/sched/task_stack.h>")
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Cc: <stable@vger.kernel.org> # 4.11+
      Patchwork: https://patchwork.linux-mips.org/patch/17522/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      f677b770
    • M
      MIPS: CPS: Fix use of current_cpu_data in preemptible code · 8a46f71d
      Matt Redfearn 提交于
      Commit 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters")
      added a check in cps_boot_secondary() that the secondary being booted is
      in the same cluster as the CPU running this code. This check is
      performed using current_cpu_data without disabling preemption. As such
      when CONFIG_PREEMPT=y, a BUG is triggered:
      
      [   57.991693] BUG: using smp_processor_id() in preemptible [00000000] code: hotplug/1749
      <snip>
      [   58.063077] Call Trace:
      [   58.065842] [<8040cdb4>] show_stack+0x84/0x114
      [   58.070830] [<80b11b38>] dump_stack+0xf8/0x140
      [   58.075796] [<8079b12c>] check_preemption_disabled+0xec/0x118
      [   58.082204] [<80415110>] cps_boot_secondary+0x84/0x44c
      [   58.087935] [<80413a14>] __cpu_up+0x34/0x98
      [   58.092624] [<80434240>] bringup_cpu+0x38/0x114
      [   58.097680] [<80434af0>] cpuhp_invoke_callback+0x168/0x8f0
      [   58.103801] [<804362d0>] _cpu_up+0x154/0x1c8
      [   58.108565] [<804363dc>] do_cpu_up+0x98/0xa8
      [   58.113333] [<808261f8>] device_online+0x84/0xc0
      [   58.118481] [<80826294>] online_store+0x60/0x98
      [   58.123562] [<8062261c>] kernfs_fop_write+0x158/0x1d4
      [   58.129196] [<805a2ae4>] __vfs_write+0x4c/0x168
      [   58.134247] [<805a2dc8>] vfs_write+0xe0/0x190
      [   58.139095] [<805a2fe0>] SyS_write+0x68/0xc4
      [   58.143854] [<80415d58>] syscall_common+0x34/0x58
      
      In reality we don't currently support running the kernel on CPUs not in
      cluster 0, so the answer to cpu_cluster(&current_cpu_data) will always
      be 0, even if this task being preempted and continues running on a
      different CPU. Regardless, the BUG should not be triggered, so fix this
      by switching to raw_current_cpu_data. When multicluster support lands
      upstream this check will need removing or changing anyway.
      
      Fixes: 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters")
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Reviewed-by: NPaul Burton <paul.burton@mips.com>
      CC: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17563/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      8a46f71d
  8. 01 11月, 2017 3 次提交
    • M
      MIPS: SMP: Fix deadlock & online race · 9e8c399a
      Matt Redfearn 提交于
      Commit 6f542ebe ("MIPS: Fix race on setting and getting
      cpu_online_mask") effectively reverted commit 8f46cca1 ("MIPS: SMP:
      Fix possibility of deadlock when bringing CPUs online") and thus has
      reinstated the possibility of deadlock.
      
      The commit was based on testing of kernel v4.4, where the CPU hotplug
      core code issued a BUG() if the starting CPU is not marked online when
      the boot CPU returns from __cpu_up. The commit fixes this race (in
      v4.4), but re-introduces the deadlock situation.
      
      As noted in the commit message, upstream differs in this area. Commit
      8df3e07e ("cpu/hotplug: Let upcoming cpu bring itself fully up")
      adds a completion event in the CPU hotplug core code, making this race
      impossible. However, people were unhappy with relying on the core code
      to do the right thing.
      
      To address the issues both commits were trying to fix, add a second
      completion event in the MIPS smp hotplug path. It removes the
      possibility of a race, since the MIPS smp hotplug code now synchronises
      both the boot and secondary CPUs before they return to the hotplug core
      code. It also addresses the deadlock by ensuring that the secondary CPU
      is not marked online before it's counters are synchronised.
      
      This fix should also be backported to fix the race condition introduced
      by the backport of commit 8f46cca1 ("MIPS: SMP: Fix possibility of
      deadlock when bringing CPUs online"), through really that race only
      existed before commit 8df3e07e ("cpu/hotplug: Let upcoming cpu
      bring itself fully up").
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Fixes: 6f542ebe ("MIPS: Fix race on setting and getting cpu_online_mask")
      CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
      Cc: <stable@vger.kernel.org> # v4.1+: 8f46cca1: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"
      Cc: <stable@vger.kernel.org> # v4.1+: a00eeede: "MIPS: SMP: Use a completion event to signal CPU up"
      Cc: <stable@vger.kernel.org> # v4.1+: 6f542ebe: "MIPS: Fix race on setting and getting cpu_online_mask"
      Cc: <stable@vger.kernel.org> # v4.1+
      Patchwork: https://patchwork.linux-mips.org/patch/17376/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      9e8c399a
    • M
      MIPS: generic: Fix compilation error from include asm/mips-cpc.h · 7f005f11
      Matt Redfearn 提交于
      Commit e83f7e02 ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC
      headers") adds a #error to arch/mips/include/asm/mips-cpc.h if it is
      included directly. While this commit replaced almost all direct includes
      of mips-cm.h and mips-cpc.h, 2 remain.
      
      With some defconfigs, mips-cps.h is indirectly included before
      mips-cpc.h, but in others this results in compilation errors:
      
      In file included from arch/mips/generic/init.c:23:0:
      ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include
      asm/mips-cps.h rather than asm/mips-cpc.h
       # error Please include asm/mips-cps.h rather than asm/mips-cpc.h
      
      In file included from arch/mips/kernel/smp.c:23:0:
      ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include
      asm/mips-cps.h rather than asm/mips-cpc.h
       # error Please include asm/mips-cps.h rather than asm/mips-cpc.h
      
      In both cases, fix this by including mips-cps.h instead.
      
      Fixes: e83f7e02 ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers")
      Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/17492/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      7f005f11
    • P
      Update MIPS email addresses · 48c834be
      Paul Burton 提交于
      MIPS will soon not be a part of Imagination Technologies, and as such
      many @imgtec.com email addresses will no longer be valid. This patch
      updates the addresses for those who:
      
       - Have 10 or more patches in mainline authored using an @imgtec.com
         email address, or any patches dated within the past year.
      
       - Are still with Imagination but leaving as part of the MIPS business
         unit, as determined from an internal email address list.
      
       - Haven't already updated their email address (ie. JamesH) or expressed
         a desire to be excluded (ie. Maciej).
      
       - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt &
         myself.
      
      New addresses are of the form firstname.lastname@mips.com, and all
      verified against an internal email address list. An entry is added to
      .mailmap for each person such that get_maintainer.pl will report the new
      addresses rather than @imgtec.com addresses which will soon be dead.
      
      Instances of the affected addresses throughout the tree are then
      mechanically replaced with the new @mips.com address.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com>
      Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@mips.com>
      Acked-by: NMatt Redfearn <matt.redfearn@mips.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: trivial@kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/17540/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      48c834be
  9. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  10. 09 10月, 2017 1 次提交
  11. 20 9月, 2017 1 次提交
    • P
      MIPS: Fix perf event init · fd0b19ed
      Paul Burton 提交于
      Commit c311c797 ("cpumask: make "nr_cpumask_bits" unsigned")
      modified mipspmu_event_init() to cast the struct perf_event cpu field to
      an unsigned integer before it is compared with nr_cpumask_bits (and
      *ahem* did so without copying the linux-mips mailing list or any MIPS
      developers...). This is broken because the cpu field may be -1 for
      events which follow a process rather than being affine to a particular
      CPU. When this is the case the cast to an unsigned int results in a
      value equal to ULONG_MAX, which is always greater than nr_cpumask_bits
      so we always fail mipspmu_event_init() and return -ENODEV.
      
      The check against nr_cpumask_bits seems nonsensical anyway, so this
      patch simply removes it. The cpu field is going to either be -1 or a
      valid CPU number. Comparing it with nr_cpumask_bits is effectively
      checking that it's a valid cpu number, but it seems safe to rely on the
      core perf events code to ensure that's the case.
      
      The end result is that this fixes use of perf on MIPS when not
      constraining events to a particular CPU, and fixes the "perf list hw"
      command which fails to list any events without this.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Fixes: c311c797 ("cpumask: make "nr_cpumask_bits" unsigned")
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable <stable@vger.kernel.org> # v4.12+
      Patchwork: https://patchwork.linux-mips.org/patch/17323/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fd0b19ed
  12. 06 9月, 2017 8 次提交
    • M
      MIPS: Refactor handling of stack pointer in get_frame_info · 56dfb700
      Matt Redfearn 提交于
      Commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      added handling of microMIPS instructions to manipulate the stack
      pointer. The code that was added violates code style rules with long
      lines caused by lots of nested conditionals.
      
      The added code interprets (inline) any known stack pointer manipulation
      instruction to find the stack frame size. Handling the microMIPS cases
      added quite a bit of complication to this function.
      
      Refactor is_sp_move_ins to perform the interpretation of the immediate
      as the instruction manipulating the stack pointer is found. This reduces
      the amount of indentation required in get_frame_info, and more closely
      matches the operation of is_ra_save_ins.
      Suggested-by: NMaciej W. Rozycki <macro@imgtec.com>
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16958/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      56dfb700
    • M
      MIPS: Stacktrace: Fix microMIPS stack unwinding on big endian systems · 41885b02
      Matt Redfearn 提交于
      The stack unwinding code uses the mips_instuction union to decode the
      instructions it finds. That union uses the __BITFIELD_FIELD macro to
      reorder depending on endianness. The stack unwinding code always places
      16bit instructions in halfword 1 of the union. This makes the union
      accesses correct for little endian systems. Similarly, 32bit
      instructions are reordered such that they are correct for little endian
      systems. This handling leaves unwinding the stack on big endian systems
      broken, as the mips_instruction union will then look for the fields in
      the wrong halfword.
      
      To fix this, use a logical shift to place the 16bit instruction into the
      correct position in the word field of the union. Use the same shifting
      to order the 2 halfwords of 32bit instuctions. Then replace accesses to
      the halfword with accesses to the shifted word.
      In the case of the ADDIUS5 instruction, switch to using the
      mm16_r5_format union member to avoid the need for a 16bit shift.
      
      Fixes: 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16956/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      41885b02
    • M
      MIPS: microMIPS: Fix decoding of swsp16 instruction · cea8cd49
      Matt Redfearn 提交于
      When the immediate encoded in the instruction is accessed, it is sign
      extended due to being a signed value being assigned to a signed integer.
      The ISA specifies that this operation is an unsigned operation.
      The sign extension leads us to incorrectly decode:
      
      801e9c8e:       cbf1            sw      ra,68(sp)
      
      As having an immediate of 1073741809.
      
      Since the instruction format does not specify signed/unsigned, and this
      is currently the only location to use this instuction format, change it
      to an unsigned immediate.
      
      Fixes: bb9bc468 ("MIPS: Calculate microMIPS ra properly when unwinding the stack")
      Suggested-by: NPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Miodrag Dinic <miodrag.dinic@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16957/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      cea8cd49
    • M
      MIPS: microMIPS: Fix decoding of addiusp instruction · a0ae2b08
      Matt Redfearn 提交于
      Commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      added handling of microMIPS instructions to manipulate the stack
      pointer. Unfortunately the decoding of the addiusp instruction was
      incorrect, and performed a left shift by 2 bits to the raw immediate,
      rather than decoding the immediate and then performing the shift, as
      documented in the ISA.
      
      This led to incomplete stack traces, due to incorrect frame sizes being
      calculated. For example the instruction:
      801faee0 <do_sys_poll>:
      801faee0:       4e25            addiu   sp,sp,-952
      
      As decoded by objdump, would be interpreted by the existing code as
      having manipulated the stack pointer by +1096.
      
      Fix this by changing the order of decoding the immediate and applying
      the left shift. Also change to accessing the instuction through the
      union to avoid the endianness problem of accesing halfword[0], which
      will fail on big endian systems.
      
      Cope with the special behaviour of immediates 0x0, 0x1, 0x1fe and 0x1ff
      by XORing with 0x100 again if mod(immediate) < 4. This logic was tested
      with the following test code:
      
      int main(int argc, char **argv)
      {
      	unsigned int enc;
      	int imm;
      
      	for (enc = 0; enc < 512; ++enc) {
      		int tmp = enc << 2;
      		imm = -(signed short)(tmp | ((tmp & 0x100) ? 0xfe00 : 0));
      		unsigned short tmp = enc;
      		tmp = (tmp ^ 0x100) - 0x100;
      		if ((unsigned short)(tmp + 2) < 4)
      			tmp ^= 0x100;
      		imm = -(signed short)(tmp << 2);
      		printf("%#x\t%d\t->\t(%#x\t%d)\t%#x\t%d\n",
      		       enc, enc,
      		       (short)tmp, (short)tmp,
      		       imm, imm);
      	}
      	return EXIT_SUCCESS;
      }
      
      Which generates the table:
      
      input encoding	->	tmp (matching manual)	frame size
      -----------------------------------------------------------------------
      0	0	->	(0x100		256)	0xfffffc00	-1024
      0x1	1	->	(0x101		257)	0xfffffbfc	-1028
      0x2	2	->	(0x2		2)	0xfffffff8	-8
      0x3	3	->	(0x3		3)	0xfffffff4	-12
      ...
      0xfe	254	->	(0xfe		254)	0xfffffc08	-1016
      0xff	255	->	(0xff		255)	0xfffffc04	-1020
      0x100	256	->	(0xffffff00	-256)	0x400		1024
      0x101	257	->	(0xffffff01	-255)	0x3fc		1020
      ...
      0x1fc	508	->	(0xfffffffc	-4)	0x10		16
      0x1fd	509	->	(0xfffffffd	-3)	0xc		12
      0x1fe	510	->	(0xfffffefe	-258)	0x408		1032
      0x1ff	511	->	(0xfffffeff	-257)	0x404		1028
      
      Thanks to James Hogan for the test code & verifying the logic.
      
      Fixes: 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      Suggested-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16955/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a0ae2b08
    • M
      MIPS: microMIPS: Fix detection of addiusp instruction · b332fec0
      Matt Redfearn 提交于
      The addiusp instruction uses the pool16d opcode, with bit 0 of the
      immediate set. The test for the addiusp opcode erroneously did a logical
      and of the immediate with mm_addiusp_func, which has value 1, so this
      test always passes when the immediate is non-zero.
      
      Fix the test by replacing the logical and with a bitwise and.
      
      Fixes: 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16954/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b332fec0
    • M
      MIPS: Handle non word sized instructions when examining frame · 11887ed1
      Matt Redfearn 提交于
      Commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      added fairly broken support for handling 16bit microMIPS instructions in
      get_frame_info(). It adjusts the instruction pointer by 16bits in the
      case of a 16bit sp move instruction, but not any other 16bit
      instruction.
      
      Commit b6c7a324 ("MIPS: Fix get_frame_info() handling of microMIPS
      function size") goes some way to fixing get_frame_info() to iterate over
      microMIPS instuctions, but the instruction pointer is still manipulated
      using a postincrement, and is of union mips_instruction type. Since the
      union is sized to the largest member (a word), but microMIPS
      instructions are a mix of halfword and word sizes, the function does not
      always iterate correctly, ending up misaligned with the instruction
      stream and interpreting it incorrectly.
      
      Since the instruction modifying the stack pointer is usually the first
      in the function, that one is usually handled correctly. But the
      instruction which saves the return address to the sp is some variable
      number of instructions into the frame and is frequently missed due to
      not being on a word boundary, leading to incomplete walking of the
      stack.
      
      Fix this by incrementing the instruction pointer based on the size of
      the previously decoded instruction (& remove the hack introduced by
      commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      which adjusts the instruction pointer in the case of a 16bit sp move
      instruction, but not any other).
      
      Fixes: 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16953/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      11887ed1
    • C
      MIPS: Add DWARF unwinding to assembly · 866b6a89
      Corey Minyard 提交于
      This will allow kdump dumps to work correclty with MIPS and
      future DWARF unwinding of the stack to give accurate tracebacks.
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16990/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      866b6a89
    • C
      MIPS: Fix issues in backtraces · aee16625
      Corey Minyard 提交于
      I saw two problems when doing backtraces:
      
      The compiler was putting a "fast return" at the top of some
      functions, before it set up the frame.  The backtrace code
      would stop when it saw a jump instruction, so it would never
      get to the stack frame setup and would thus misinterpret it.
      To fix this, don't look for jump instructions until the
      frame setup has been seen.
      
      The assembly code here is:
      
      ffffffff80b885a0 <serial8250_handle_irq>:
      ffffffff80b885a0:       c8a00003        bbit0   a1,0x0,ffffffff80b885b0 <serial8250_handle_irq+0x10>
      ffffffff80b885a4:       0000102d        move    v0,zero
      ffffffff80b885a8:       03e00008        jr      ra
      ffffffff80b885ac:       00000000        nop
      ffffffff80b885b0:       67bdffd0        daddiu  sp,sp,-48
      ffffffff80b885b4:       ffb00008        sd      s0,8(sp)
      
      The second problem was the compiler was putting the last
      instruction of the frame save in the delay slot of the
      jump instruction.  If it saved the RA in there, the
      backtrace could would miss it and misinterpret the frame.
      To fix this, make sure to process the instruction after
      the first jump seen.
      
      The assembly code for this is:
      
      ffffffff80806fd0 <plat_irq_dispatch>:
      ffffffff80806fd0:       67bdffd0        daddiu  sp,sp,-48
      ffffffff80806fd4:       ffb30020        sd      s3,32(sp)
      ffffffff80806fd8:       24130018        li      s3,24
      ffffffff80806fdc:       ffb20018        sd      s2,24(sp)
      ffffffff80806fe0:       3c12811c        lui     s2,0x811c
      ffffffff80806fe4:       ffb10010        sd      s1,16(sp)
      ffffffff80806fe8:       3c11811c        lui     s1,0x811c
      ffffffff80806fec:       ffb00008        sd      s0,8(sp)
      ffffffff80806ff0:       3c10811c        lui     s0,0x811c
      ffffffff80806ff4:       08201c03        j       ffffffff8080700c <plat_irq_dispa
      tch+0x3c>
      ffffffff80806ff8:       ffbf0028        sd      ra,40(sp)
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16992/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      aee16625
  13. 05 9月, 2017 1 次提交
  14. 04 9月, 2017 4 次提交
  15. 30 8月, 2017 5 次提交